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?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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 http://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).