python interview quuestions

[Roy Smith]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> wrote:

> 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.

Perhaps I'm reading more into your choice of words than you intended, 
but I'm curious what you envision a "coder" does.  I think of "coder" 
and a rather low-level job.  Somebody who just writes code.  I'm 
generally looking for somebody who is more of a software engineer.  
Somebody who is not just writing some code, but who is building a 
product.  That means, as you suggest, that it's documented, tested, 
robust, maintainable, portable, all that good stuff.

> 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?".

I think this depends on the situation.  For writing code at a whiteboard 
while i watched, I'd expect the candidate to concentrate just on the 
code itself.  If it was an assigment, as in, "Write a program to do X, 
and mail it to me by tomorrow", I'd expect a much more complete 
treatment.