On Wed, Jul 30, 2008 at 9:53 AM, Steven Sacks <[EMAIL PROTECTED]> wrote: > Don't ask questions. You won't learn anything. Make him code some stuff. > Something tricky. Come up with something good. That is, if you care if > they know how to code.
(for once!) I kind of agree with Steven. Talking to the interviewee - asking questions - _is_ important, because one of the most critical things you need to find out is whether they'll fit into your team, and getting into a decent conversation with them is one of the ways to judge that. But that's a whole different topic, and probably not one for this list. However to get an idea what their coding abilities are like, you can do worse than get them to write a couple of functions for you to do specific things. On paper. With a pencil. :-D A 'what's wrong with this syntax'? test is good, too. So is a 'what is this function meant to do?' - showing them a listing. You can also get a rough idea of their architectural/code organisation skills in a similar way, by detailing a simple system and getting them to throw together a rough diagram of how the classes in it might interact (UML or whatever, your choice). You'll still need to ask coding-related questions to get some idea of the breadth of their experience. Here it's good to ask specific questions, not general 'so, what about this whole MVC thing, then?'. Be more specific - and ask more about _why_ than _how_. If they don't understand the _why_, the how is often just a regurgitation of rote-learned stuff or what they might have read on Wikipedia today. At the end of the day, though, it very much depends what role you're trying to fill, how big your team is, what this guy's responsibilities are going to be, whether he'll have to talk to clients, etc. etc. HTH, Ian _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders