python interview quuestions

[Steven D'Aprano]

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