agreed on that On Wed, Jul 30, 2008 at 11:12 AM, Ibrahim Y <[EMAIL PROTECTED]> wrote:
> 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 > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
