In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Andrew Lentvorski) writes: > > This is counterproductive. > > Asking a candidate to provide negative feedback is just a nasty > interview trick. > > Candidates who ignore the code are fairly astute. What if the > interviewer wrote the code? How will he react to negative criticism? > What about the policies? Who wrote those? How immutable are those? > > Candidates who criticize the code and guidelines without concern are > likely to do so to co-workers and can make a really negative environment. > > So, rather than creating a useful question, you have actually managed to > create a *negative* correlation question where you are selecting > *against* the best candidates (good coders who recognize the issues but > also pay attention to the human side of things, too). > > You need to be a bit more cognizant of your power over interview > candidates. Keep your questions on neutral political ground to get the > best information from the candidate. > > I personally find that the best solution to this is to ask a candidate, > "Send me 1000 lines of your best code. Any language, any project." > > Any decent developer has 1000 lines of some project laying around to > send in. Then I'll ask some questions about it in the interview. > > This cleans out people you don't want *very* quickly.
I agree with you completely, I know it is a nasty trick hence the use of the term 'trap', but that is the way I weed out coders who are pro-active perfectionists, those who are not afraid to tell me what they think. I was told by one of our new employees that he feared criticising the code might cost him the job, but he did it anyway because he thought that was the right thing to do ( I tell them that they should treat the sample code as if it was the crown jewels and of they see anything wrong to contact me, few do ). I take development very seriously and I want those who I select do the same, they know people *will* look at *their* code and that they need to keep a high standard of quality at all times. The work environment is quite calm if not happy, since most feel motivated by the fact that they are surrounded by similar people and the quality control stays high since we split them off into Scrum groups. I did try the "send me your code" approach before for another company, but I found it a bit hard to get some real data out of it since most of the code they send in has been checked, cleaned and rechecked time and time again for the soul purpose an interview, I am not interested in just how well they know *x*, *y* or *z* language, but more in how much attention to detail they put on something they have never seen before and if they will speak up when the time comes. But that is the way *I* filter out people, it should only be used under certain circumstances and let me point out that I don't do this for a living but I have been hired to filter out applicants for IT jobs by my own clients :-) * The funny thing is that the contract they sign in order to apply for the job and see the sample code tells them *everything* even a URL where they can download my written apology, I do show them after they get hired. -- Guillermo Antonio Amaral Bastidas (gamaral) Free/Libre/Open-Source Software Advocate & KDE Developer http://blog.guillermoamaral.com/ -- KPLUG-List@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
