at the end you need your work done in any case in specific time with the best performance. so, giving him tasks related to your work in real environment with ability to access internet on anything he needs will be the best way to decide how he will be useful for you -imo-
Ibrahim On Wed, Jul 30, 2008 at 12:14 PM, Ian Thomas <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
