The Resume` Whisperer

Hi Brent,

 

I don’t have super fine-tuned recommendations, but I will tell you what I do for programming positions (for QA I usually let a QA person drive the interview!):

 

1. I go over resume`s with a fine-toothed comb and I do not limit the scope of my questions to just the skills we are looking for. For example, if an applicant’s resume` or CV says they can do both Java and C# and we are hiring for Java, I ask them to describe the differences between the two languages as well as their favorite features of each. Although this comes across as laid back and open ended (and it is), I’m actually fishing for a deeper truth: I want evidence they have done what they say they have done and have the skills they claim they have.
   
   The reason for THAT is that if people will lie on their resume` (and estimates are that 80%+ do), then they will lie about other things, too. Credibility and transparency are very important to me, and this approach has paid off in the teams I have hired. I had one applicant say straightaway the recruiter told him to add a bunch of skills he didn’t have. When I confronted the recruiter, he admitted it, but added, “He’s a good developer and deserved an interview. You interviewed him, didn’t you?” 
   
   Needless to say, we blacklisted that recruiter. Oddly enough, we did wind up hiring the developer, LOL.
   
   
2. I generally give two fairly small programming exercises. I prefer to let the applicant screen share and use their IDE of choice on both exercises. The first task is usually a warm-up, something like reversing the characters in a string, although now that Java added that to the String class I’ll have to think of something else. During this exercise no web searches or books are allowed. This is just a 5 to 10 minute effort and most of the point is to make sure the applicant understands the underlying data structures involved and can find their way around an IDE.
   
   The second exercise should be more significant and unusual enough most people will at least have to ponder how to attack it, something like writing a function to generate hashes. This time they are free to do web searches (again screen sharing enabled). I’d allow at least 20 minutes and I encourage the applicant to ask questions and talk through their thought process as they go. One of the things I’m interested in is discerning if the applicant tries to clarify or check their understanding of the requirements. It is a fine line—we want developers who can think for themselves, but we also want them be sensitive and committed to unearthing the real requirements whether well-defined or not. IMHO, it is everybody’sjob to define requirements.
   
   I’m an odd duck in that I allow web searches, but it is very artificial to me when we don’t let applicants do what we all do just about every day. The truth of the matter is that, all other things being equal, I’d take somebody who has terrific web searching skills over somebody who does not. I’ve discovered that many of these great engineers at Seeq tend to have one common weakness: They have a wide streak of NIH (not-invented-here). I’m discovering it has cost the company a lot, and will cost them more in the future.
   
   Anyway, this second task varies by language, but it should require something like 20-30 lines of code or so as well as a unit test.
   
   
3. I generally involve the team in the interview process. Their goal is to really probe for “fit”, that is, is this applicant someone they would feel comfortable working with. Someone should always ask questions probing how the applicant deals with disagreements, how they handle a bug in someone else’s code, etc. As an example, I have asked something like this: “You and Joe presented alternative approaches to implementing X, but your approach was not chosen. After a few days, you believe you have discovered a significant flaw in Joe’s approach. What do you do?”
   
   In these questions, my goal is to get a feel for how empathetic an applicant is. You want developers who value good code and cost-saving approaches, but those must be in parallel with considerations for the feelings of others.

 

Two last tips:

 

• Don’t hire for skillset only. I’d rather hire an excellent C# developer for my Java job than a lousy Java dev (or one who is a jerk).
• Take your time. Hiring too fast is a death trap. Consider the hiring process to be a project with scope, schedule, and management just like building out a feature. All too often it is something we just wedge in between everything else.

 

 

Sorry for the length, but I hope this gives you at least one valuable nugget. I’ll be praying for your success, my friend!