I agree. The only way you can clearly establish a coders credentials in a short amount of time is to look at their portfolio. See what work they've done in the past, if it's up to snuff, and have them explain what they did and why. (People might not use strict; for a reason -- i.e. they inherited a code base like yours. Best if they explain themselves and you don't jump to conclusions -- you might pass over a great coder!).
Want to support the EFF and FSF by buying cool stuff? Click here.
| [reply]
[d/l] |
This isn't exactly fair if they have mostly commercial work that they cannot share. I know this is true of me -- I want to code in my spare time, but 50 hrs a week of staring at a monitor is usually enough for me.
I think the best is to measure analytical skills, ask them to walk you through a previous design, or so on .. or maybe ask them to explain one of your Perl programs.
But don't get TOO technical. I had a few interviews from PhD types who thought they were Gods gift to computer science (giving a bunch of problems they thought were clever, but really weren't -- and then made up arbitrary restrictions to limit my ability to solve them through 'normal' means). They rubbed me the wrong way, were full of themselves, and I wouldn't have wanted to work for those sort of elistists.
So it comes down to ... (1) can they work and play nice with others, and (2) can they think on their feat and do they have a general grasp on good design, and (3) I think it's perfectly fine to ask if they understand closures and lexicals. You see, this is what distinguishes a basic hack-and-slash 'scripter' from someone who is into the stuff from a programming perspective. Maybe. Just don't become that PhD jerk who thinks he is smarter than the interviewee. Intimidation does nothing for anyone, and will problably just make your subject feel uncomfortable.
| [reply] |
My attitude is the diametric opposite.
Code samples need not be long to be useful. Any competent person should be able to sit down and in a couple of hours have a code sample that gives an idea what their coding level is. If you can't produce code on demand before you're hired, then why should anyone believe that you will be able to after you're hired?
Of course anyone who codes in their spare time will have code available on a moment's notice. But even if you don't, asking for you to produce a code sample is not an unreasonable imposition.
| [reply] |
| [reply] |
I realize that it's not always possible to view a coders best work -- even if you have the option of signing an NDA (which you don't always). However, I think that it's the best way to evaluate a coder if you can see examples of their previous work.
Want to support the EFF and FSF by buying cool stuff? Click here.
| [reply] |
We do this, too, if the candidate has something they can show us. As someone else mentioned, this isn't always possible.
For what it's worth, we had someone come in a few weeks ago. Their code sample was pretty good, but there were things I'd have done differently, and, I think, better. But when he explained the code to me, not only was it clear he'd thought carefully about how it was supposed to work, but he had a solid explanation for every design decision. Based on that interview, I thought he should get an offer right away, test be darned. Sadly, after driving down for that, he decided that he didn't want to take on the commute that working for us would require.
And even if he was willing, I'd still have had to give him a test, because that's what management demands. | [reply] |
