If you were looking to hire a web developer who would primarily be working with TurboGears/Python - what sort of questions should you ask them?
The best interview questions are the ones where you ask them to solve problems.
Here are a few semi-random suggestions (after the FizzBizz test)
Python
Give them a non-trivial project to implement over a week in the domain where you're working. I applied once to a search firm and they asked me to implement a collaborative filtering system.
The areas that are usually confusing are decorators, the type system, metaclasses, perhaps iterators. You could ask them something about these things to probe their depth.
TurboGears
I Can't suggest much here but you could quiz them on the ORM of their choice (construct some mappers and queries), ask a little bit about validation (I had some trouble getting conditional validation to work with FormEncode). You could also wander a little into how they'd test the app, make sure that it scaled, test it's performance and deploy it.
Ask him for:
- Instrospection
- Model-View-Control design
- Documenting tools
If he know a lot about that, surely know a lot about other issues.
In addition to the good suggestions in the other answers, something I always like to ask (from anybody who's a candidate to develop anything at all that's related to the web) is: "when a user types www.foo.com on their browser's address bar and hits return, what happens then? Please describe in as much or as little detail as you think best, then we may drill down into some or all parts of the answer".
Quite apart from the server-side framework(s) in use, this can tell me a lot about the candidate's understanding of other crucial technologies that they may well end up having to deal with: HTTP and the whole TCP/IP stack below it, DNS, caches of many and sundry sorts (and how they can sometimes be a bother and what can you, the developer, try to do about that...), surface-visible aspects of browser technologies, cookies, HTML and CSS and perhaps some Javascript, ...
Yes, everyday technologies we use, such as frameworks, try hard to abstract away from all this (and increase productivity thereby), but Joel Spolsky's Law of Leaky Abstractions applies -- being aware of layers of the stack that you're normally abstracting away from is crucial to real mastery of the software craft.
Depending on the details of the position the candidate's interviewing for, deeper drill downs will be appropriate in different areas. For example, describing (at reasonable abstraction level) how the HTTP request would get (through a web server and Turbogears machinery, perhaps by way of WSGI) to your application code, roughly how your code would study the request and prepare a response, how the response would be packaged up and sent back to the requesting browser, may all be items of interest -- depending on what kind of frontend/UI responsibilities the developer in question might have, more about the way the browser will deal with various aspects of the response (including links to style sheets, scripts, images, ...) might also be appropriate.
Anybody can "cram" about a specific technology such as a framework, enough, if they're smart enough, to "ace" a "quiz"-style interview. But anybody who's able to ace a more open-ended, discursive interview such as this one, is overwhelmingly likely to have really mastered and understood many of the layers of the relevant stack of technologies and abstractions -- I'd much rather hire somebody with such a thorough, deep-rooted understanding, even if they've never used Turbogears (but rather, say, Django, Wekrzeug and web.py) [they'll be able to cram and get the Turbogears-specific details down pat in a week, tops], than somebody who's committed to memory a stack of Turbogears reference manuals but doesn't really understand HTTP, cookies, TCP/IP... (that lack would take, at least, many months to remedy).
Don't quiz. Get some real (possibly broken) code from you vcs. Get them to tell you how they would fix it / add a feature.
If they can, ask them to bring some samples of previous work.
big mistake, just posted material to the wrong thread. sorry guys/gals.