Tricky Areas in Python

[Alex Martelli]

Tim Roberts <timr at probo.com> wrote:

> "PyPK" <superprad at gmail.com> wrote:
> >
> >What possible tricky areas/questions could be asked in Python based
> >Technical Interviews?
> 
> What's the point of asking "tricky" questions?  Aren't you really more
> interested in what applications they have worked on and whether they were
> successful?

Understanding exactly what contribution they did, to the applications
they worked on, may be even more important.  After all, we've all seen
people who worked on app "X" and made a NEGATIVE net contribution to
"X"'s success, compensated by the far better efforts of others on the
team.  But it's unlikely that the candidate will actually say "I worked
on X, but my grasp of the language was so feeble that in fact I made it
_worse_ than it would have been without me in the team";-).

 
> I don't know.  I'm not sure I need a job with a company that insists on
> playing "Programming Jeopardy" during the interview.

I understand how some "quiz-like" questions may rub you the wrong way.
For questions such that knowing the answers is of little or no use on
the job I might even concur -- e.g., "On what exact date was Python 1.0
released" (even if the candidate claims to have been actively part of
that release, he might perfectly well misremember the date!-).

Others are iffier, e.g., "what are all the optional arguments to
built-in function 'open'" -- some people easily memorize those even if
they use them once in a blue moon, others look them up in 2 seconds
every time they need to with a "help(open)" on the interactive
interpreter prompt, so while the knowledge sure doesn't hurt it's not
very important.  That's even truer for other functions and classes with
many more, and more obscure, optional arguments.

If I asked such a question in the course of a programming task, I would
consider "hmmm, there's an optional argument for that, I don't remember
it but in real life I'd look it up in a jiffy" perfectly acceptable (if
the candidate appears to have no idea that there IS an optional argument
for a cerrtain purpose, that's slightly less good, but no disaster).

But -- being presented with a flawed solution and asked to help debug it
(by identifying the "tricky issue" on which it fails) appears to me to
be perfectly acceptable.  It IS the kind of task you face all the time
IRL, and checks how well you know the language and libraries...


Alex