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 -- http://mail.python.org/mailman/listinfo/python-list
