python interview quuestions

[Steven D'Aprano]

On Sat, 07 Aug 2010 06:37:05 +1000, James Mills wrote:

> On Sat, Aug 7, 2010 at 6:28 AM, geremy condra <debatem1 at gmail.com>
> wrote:
>> If I had to wait 5 minutes while a candidate tried to solve this
>> problem I would not hire them.
> 
> Yes you do raise a valid point. It should really only take you a mere
> few seconds or so to write a solution to this.

Yes, but the point is to come up with a solution that is *correct*, not 
merely a solution. *wink* 

Just the mere typing time will be "a few seconds or so", so you're 
leaving zero time for actual thought, let alone running the code at least 
once to test it.

Personally, I'd rather see how a potential hire *tests* his code than how 
he writes it. Writing code is easy. Testing code is harder. Testing it 
properly is harder still -- it's amazing how many people forget that it's 
not just necessary to test the function on data that *works*, but also on 
data that fails as well (unless, of course, you're happy with function 
behaviour that is unspecified in the face of errors).

I also want to see when the coder thinks she's done. If I say "Write a 
function that does fizzbuzz", does she assume I want *just* the function, 
or does she ask questions like "Do you want documentation and tests? What 
sort of tests?". Does she assume that because the fizzbuzz function is 
small it doesn't need documentation or testing? The Fizzbuzz algorithm 
itself is the simple part. If I'm hiring a coder, I care more about their 
attitude to documentation and testing than their ability to code up a 
tiny algorithm in five seconds time. I want to see if they are a careful 
coder, or a cowboy.


> More over, it can be done in just a single line of Python.
> 
> 7 if you're not very familiar with Python.

Or if you value readability over conserving newlines.



Some months ago I wrote a version of FizzBuzz. By the time I read the 
description of the problem, re-read it to make sure I understood it and 
looking for any hidden traps ("seems too simple to me, what have I 
missed?"), wrote a first draft, tested it, fixed a silly typo, and then 
tested it again, it took about 3-5 minutes. I don't believe I have 
anything to be ashamed about that, especially not when I look at the 
number of comments by people who claimed the exercise was so trivial that 
they did it in ten seconds, AND GOT IT WRONG.

Then I added error checking, tests and documentation, and the whole 
exercise took about 20 minutes. That was probably overkill, but I was 
bored :)

(At least I didn't turn it into a class.)


-- 
Steven