From: Steven D'Aprano on 11 Aug 2010 08:34 On Tue, 10 Aug 2010 16:44:17 -0400, J Kenneth King wrote: > Fizzbuzz is annoying in interviews. It's not for the benefit of the interviewee, but for the interviewer. > I've never worked at a job where I was under a timer while a group of > people sat across from me and scrutinized everything I was doing. > > I don't see how it can honestly tell you anything useful about the > person you're interviewing either. Do you really think that what you > assume about the interviewee based on characteristics you can infer from > their solution to be really, honestly true? They might even completely > bomb the solution and still be a brilliant programmer, but you'll never > know that if you trust this simple "fizzbuzz" test. I think you've missed the point of the FizzBuzz test. Nobody should judge your skill as a programmer from whether you can write FizzBuzz in 3 minutes during an interview. The test is to weed out the people who aren't programmers at all, but think they can bluff their way into a programming job. Sounds ridiculous, but apparently there are vast hordes of people who can barely program "Hello World" applying for programming jobs. One figure bandied about -- how accurately, I don't know -- is 199 out of every 200 job applicants for programming jobs are barely capable of writing a line of code. http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html Fizz Buzz and similar tests aim to weed them out, *quickly*, so you can spend more time interviewing people who actually are programmers. I personally know somebody who got his start as a professional programmer through pure bluff. He had read up just enough about the language to be able to toss in the odd buzzword, his CV was a masterpiece of imagination, and he was applying for a job during the Y2K panic when companies would hire anyone who could spell COBOL correctly by the third attempt. The other reason for starting with something like the Fizz Buzz test is precisely to see how the interviewee will react. Do they ask for clarification if the question is underspecified? That tells you they're smart enough to *notice* when something is underspecified, and confident enough to raise the issue in an interview. That's 100 bonus points right there. Do they go to pieces? That tells you they don't perform well under pressure. Do they argue with you that the question is pointless? That tells you that they're very confident, and quite likely arrogant enough not to worry about offending a potential employer (and maybe even deservedly so). This means they are potentially difficult to deal with. That doesn't mean you don't hire them: some people are so good that they deserve to be prima donna. But if you're not looking for a prima donna, then it's better to find out early, so you don't waste either your time or the other guy's. > I've been in those interviews on both sides of the table. Neither side > was a good experience. > > If a test is necessary, make it a take-home or demand source code if > they have it. Read their code and judge for yourself the quality of > their work. Getting interviewees to do a take-home problem just means you hire the guy who is friends with a good programmer, rather than the good programmer. > Any questions in an interview should be the usual "get to know you" type > stuff. "What was the most difficult challenge you've faced on the job? > How did you respond?" That sort of thing. I *hate* those questions. For many people, the honest answer would be "Nothing I've ever done in my job has been even half as difficult as getting through the interview, because I'm bad at selling myself", but if you say that, it just sounds like you're trying to bullshit your way through the interview. -- Steven
From: Roy Smith on 11 Aug 2010 09:04 In article <4c6298c1$0$11101$c3e8da3(a)news.astraweb.com>, Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> wrote: > Sounds ridiculous, but apparently there are vast hordes of people who can > barely program "Hello World" applying for programming jobs. One figure > bandied about -- how accurately, I don't know -- is 199 out of every 200 > job applicants for programming jobs are barely capable of writing a line > of code. By the same token, there are lots of people with advanced degrees in computer science who can't code their way out of a paper bag. One advantage of the take-home test is that you can prepare the test once and amortize the preparation cost over many applicants. It's a big investment of time to interview somebody. By the time I get up to investing an hour or so of my time on a phone screen, I'd like to weed out the obvious rejects as cheaply as possible. Even more interesting is to publish some problems on your web site and instruct applicants to submit a solution to one of them along with their resume. This makes the per-applicant cost to administer the exam essentially zero. It also has the nice side-effect of weeding out the resume spammers. To be honest, I've never done this, but I've seen companies that do. I may try it sometime. I still want to see the candidate write some code during the interview. This gives me a chance to feed them a problem incrementally and see where they take it.
From: Ben Finney on 11 Aug 2010 09:35 Tim Chase <python.list(a)tim.thechases.com> writes: > Unfortunately there are candidates who would give your answer but then > have trouble with "Then why are the Last-Modified HTTP headers showing > a date several months before our interview?" My response: “Ha! That's a trick question; 'Last-Modified' is a field in the header, not a header itself”. That might lead to the “why are you interested in leaving your current position” question rather precipitously, though. -- \ “Courage is not the absence of fear, but the decision that | `\ something else is more important than fear.” —Ambrose Redmoon | _o__) | Ben Finney
From: geremy condra on 11 Aug 2010 15:51 On Wed, Aug 11, 2010 at 6:04 AM, Roy Smith <roy(a)panix.com> wrote: > In article <4c6298c1$0$11101$c3e8da3(a)news.astraweb.com>, > Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> wrote: > >> Sounds ridiculous, but apparently there are vast hordes of people who can >> barely program "Hello World" applying for programming jobs. One figure >> bandied about -- how accurately, I don't know -- is 199 out of every 200 >> job applicants for programming jobs are barely capable of writing a line >> of code. > > By the same token, there are lots of people with advanced degrees in > computer science who can't code their way out of a paper bag. > > One advantage of the take-home test is that you can prepare the test > once and amortize the preparation cost over many applicants. It's a big > investment of time to interview somebody. By the time I get up to > investing an hour or so of my time on a phone screen, I'd like to weed > out the obvious rejects as cheaply as possible. > > Even more interesting is to publish some problems on your web site and > instruct applicants to submit a solution to one of them along with their > resume. This makes the per-applicant cost to administer the exam > essentially zero. It also has the nice side-effect of weeding out the > resume spammers. To be honest, I've never done this, but I've seen > companies that do. I may try it sometime. I can't recall who it was, but I remember being very impressed by a company that did a variant of this a few years ago: they put programming problems on the sides of pay phones, taxis, etc. with a note that said 'If you can solve this, call us'. I have zero doubt that they got some top talent that way. Geremy Condra
From: Paul Rubin on 11 Aug 2010 16:11
geremy condra <debatem1(a)gmail.com> writes: > I can't recall who it was, but I remember being very impressed by a > company that did a variant of this a few years ago: they put > programming problems on the sides of pay phones, taxis, etc. with a > note that said 'If you can solve this, call us'. I have zero doubt > that they got some top talent that way. Several companies have done that. You might be thinking of ITA Software: http://www.itasoftware.com/careers/puzzle_archive.html |