Tricky Areas in Python

[Alex Martelli]

Andrew Durdin <adurdin at gmail.com> wrote:

> On 10/24/05, Alex Martelli <aleaxit at yahoo.com> wrote:
> > I may branch out into more advanced stuff such as asking
> > for an example use case for a closure, a custom descriptor, or an import
> > hook, for example
> 
> Isn't that approaching things from the wrong angle? You're asking them
> to synthesise a problem for a given solution, rather than analyse a
> problem to determine an appropriate solution. Asking questions like
> these tests memory more than competence -- for example, if you ask me
> of a use case for a closure, the only answer I could give would be to
> remember a problem I'd solved in the past using one.

And why do you think that would be wrong?  If you've used closures, you
know what you've used them for, and (I would hope) why.  If you've never
used them, you're welcome to answer "I have no idea why anybody would
wanna use THAT crazy thing for" (I always give points for honesty;-), or
else try to bluff your way through (sorry, no points for chutzpah!-).

I don't know of any issue that could be solved ONLY by a closure (we
didn't have closures in 1.5.2 yet we made out excellently well
anyhow;-), after all.  The point is, does the candidate really
understand closures (ideally by practical experience)?  Within the
limited confines of a less-than-an-hour interview (which is what we
normally use -- several interviewers, but no more than about 45 minutes
each, with different focus for each interviewer) I believe that asking
for use cases is a perfectly good way to gauge if a candidate fully
understands (ideally by experience) a certain language feature.

It's not just Python, btw.  When I'm asked to focus on C++ skills, I
will similarly ask, e.g., what a use case would be for virtual
inheritance, say.  How ELSE would you gauge, within that very limited
time-span, a candidate's grasp of some advanced language feechur?-)


Alex