Difference between revisions of "Interviewing a Technical Candidate"

From strattonbrazil.com
Jump to: navigation, search
(Anatomy of a Perfect Technical Hire)
Line 5: Line 5:
 
== Anatomy of a Perfect Technical Hire ==
 
== Anatomy of a Perfect Technical Hire ==
  
[http://firstround.com/article/the-anatomy-of-the-perfect-technical-interview-from-a-former-amazon-vp The Anatomy of a Perfect Technical Hire]
+
Neil Roseman, previously a VP at Amazon, wrote [http://firstround.com/article/the-anatomy-of-the-perfect-technical-interview-from-a-former-amazon-vp The Anatomy of a Perfect Technical Hire], what he believes to be some good rules.  While I don't agree with everything the article as a whole provides some great pointers. 
 +
 
 +
* You should come out of every interview with a clear sense of whether the person could improve the probability of your company’s success.
 +
* Great interviewing is work. It takes time to prepare, conduct the interview and then de-brief in an effective way. If you don’t want to do the work, don’t interview.
 +
* Once you form an initial impression of someone - which usually happens within the first 60 seconds - you should spend the rest the interview trying to invalidate that impression.
 +
* You should always take copious notes during interviews so you can make a cogent argument for or against a candidate.
 +
* In most cases, the “best and the brightest” already have jobs, so you’re really just on the lookout for the best available. Plus there’s no way to prove that your hiring process resulted in the right people because you can’t A/B test hiring decisions.
 +
* Always strive to hire superstars but realize that not all hires need to “walk on water.”  This person should be better along some dimensions than a majority of the current staff and have the potential to have a long-term impact.
 +
You want to hire people who are smart, that get stuff done and have the functional set of skills you need for the role.

Revision as of 14:16, 26 August 2014

I've become involved in the interview process at my company. It's been fun to learn the general guidelines we've setup for each other, but on thing I've learned is that interviewing is hard. It frustrates me how little I seem to know about a candidate after an entire hour of time with him and although we have four employees interview each candidate, I'm not confident the sum of parts is a complete picture.

I've tried to be proactive learning more about technical interviews. Time management is especially important. Having only an hour with the candidate I've found some questions can eat up a lot of time without telling me much about the programmer's coding ability or their fit on the team.

Anatomy of a Perfect Technical Hire

Neil Roseman, previously a VP at Amazon, wrote The Anatomy of a Perfect Technical Hire, what he believes to be some good rules. While I don't agree with everything the article as a whole provides some great pointers.

  • You should come out of every interview with a clear sense of whether the person could improve the probability of your company’s success.
  • Great interviewing is work. It takes time to prepare, conduct the interview and then de-brief in an effective way. If you don’t want to do the work, don’t interview.
  • Once you form an initial impression of someone - which usually happens within the first 60 seconds - you should spend the rest the interview trying to invalidate that impression.
  • You should always take copious notes during interviews so you can make a cogent argument for or against a candidate.
  • In most cases, the “best and the brightest” already have jobs, so you’re really just on the lookout for the best available. Plus there’s no way to prove that your hiring process resulted in the right people because you can’t A/B test hiring decisions.
  • Always strive to hire superstars but realize that not all hires need to “walk on water.” This person should be better along some dimensions than a majority of the current staff and have the potential to have a long-term impact.

You want to hire people who are smart, that get stuff done and have the functional set of skills you need for the role.