P is for Practical | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Having been on both sides of the table, a few comments:
If an applicant is familiar with a skill/language, they should be able to apply that skill/language to a simple example or provide some examples of problems they have recently solved. dws's node (see above) talks about implementing Minesweeper, and another example is the Game of Life (Conway) -- both probably involve two nested for loops somewhere, and a programmer should be able to figure that out. Get examples of their logic to solve the puzzle, along with boundary conditions (that's important) like "What happens when you get to the edge?" and some idea of how to store the game board (two arrays, maybe?). One of the links about interviews that I read recently frowned on the "Solve this mental challenge" type questions because either you got the trick or you didn't -- it wasn't really a good measuring stick for smart, methodical, get it done right type programmers. Without the "Aha!" moment, the applicant's sunk. So, if they claim to know SQL, ask about doing a join. If they ask if you want an inner or an outer join, they may be showing off, or they may really know their stuff. You could also ask about the efficiency of using different fields for indexes. Or what foreign indexes are (hint: nothing to do with some other country's stock market). If they claim to know Perl, ask some regex questions, some array questions, some reference questions, and about what resources they use when they get stuck (they must get stuck sometimes). Do they have any of the excellent O'Reilly books? What on-line resources do they use? Do they have a favourite module? A favourite authour? Finally, shoot them through a little test -- I used to give candidates a one hour test. It pretty clearly showed whether their skills matched the contents of their resume. One more quick story: part of my test was to code a bubble sort in C (yes, I know it's N*N and not always that efficient). One applicant wrote out the code for the QuickSort algorithim instead. Later, I typed his code in: it compiled and ran correctly the first time. However .. I had not asked for "any" sorting algorithim, I had asked specifically for a bubble sort. So I rejected that candidate, because in my opinion he would go off and do his own thing after being told what to do, and that's not the kind of person I wanted to hire.
On a personal note.. --t. alex "Excellent. Release the hounds." -- Monty Burns. In reply to Re: Interview with a Programmer
by talexb
|
|