A lot of non-technical recruiters are stuck with the difficult task of interviewing technical candidates. The obvious problem is that it's hard enough for the developer to keep up with the latest technology; certainly one can't expect the HR recruiter to do so as well. It's even harder for small companies that have one recruiter interviewing for all departments, as opposed to a dedicated recruiter. While it's a difficult situation, there are some things that the recruiter can do. Here's an informal brainstorm:
Do not:
Don't ever bluff. While this may impress a poor candidate (who you don't want anyway), it will turn off the good one (who you do want).
Don't just assume that years of experience makes a better developer. In the NBA, the top draft rookies will add far more value in their first year than a below-average veteran. That's why 20-something kids like Lebron James and Dwayne Wade make millions. They're that good. And the talent spread is even greater in mental work like programming than in a physical sport like basketball.
Maybe:
Ask the developer to rate themselves. I.e: "On a scale of 1-to-10, how good are you with C#?" Some recruiters love these ("the candidate is doing my job for me by telling me how good they are!"). I find them silly:
Problem 1: Usually the scale is undefined. What's a 10 - Scott Guthrie, an MVP, someone who can perfectly fix all the company's problems? Perfaps the ambiguity is good for other jobs, but development requires more precision. Do you really want to hire a developer who so readily uses an undefined system?
Problem 2: The candidate already knows the correct answer - they had better say something better than a 7, or they're disqualified.
Problem 3: Usually people think they're better than they are, especially if they were a big fish in a small pond. I've seen lots of guys answer 9 or 10 on these, only to fail to answer trivial C# syntax.
Do
Round 0: The Resume
At least be familiar with the top 10 buzzwords and technologies so that you can see if the resume is on the right planet.
Check their resume for extra curriculars. Do they at least have something more than their normal work-hour projects?
Round1: Asking basic questions
Ask simple technical questions, just to see if they can give a confident sounding answer. If a developer can't give at least a confident-sounding answer for "what is polymorphism", they're probably not ready for a real job.
Ask questions that transcend the technology and show that the candidate knows how to think, like "what's the hardest problem that you've ever had to solve" (then ask a follow up question). Behavioral questions are great for that. You could ask them to compare projects on their own resume.
Round 2: a simple quiz
Have a simple in-house, 10-question, written exam that has practical questions. Don't send a candidate to take some 2-hour, third-party, trivia quiz ("What are the 19 method overloads for StringBuilder"). The third-party quiz is usually a one-size-fits-all trivia marathon. Instead, use a quiz written by your own developers to test the knowledge your team cares about. Paylocity uses http://www.pereless.com to help administer this kind of quiz. Then ask your devs to grade the quiz; they'll usually be able to run through it in less than 10 minutes.
At this point, you're probably ready to decide if the candidate is fair game to send to the development department for a real interview - the kind where they write real code on a whiteboard and get drilled by technical experts.
No comments:
Post a Comment