Andrew Durdin <[EMAIL PROTECTED]> wrote: > On 10/24/05, Alex Martelli <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
