Interviewing a Technical Candidate - Revision history

Strattonbrazil: /* Forty Minutes of Coding */

2014-08-26T14:45:11Z

‎Forty Minutes of Coding

Strattonbrazil: /* Forty Minutes of Coding */

2014-08-26T14:41:59Z

‎Forty Minutes of Coding

Strattonbrazil: /* Forty Minutes of Coding */

2014-08-26T14:40:49Z

‎Forty Minutes of Coding

Strattonbrazil: /* Time Management */

2014-08-26T14:30:50Z

‎Time Management

Strattonbrazil: /* The First Ten */

2014-08-26T14:27:11Z

‎The First Ten

Strattonbrazil: /* The First Ten */

2014-08-26T14:25:46Z

‎The First Ten

Strattonbrazil: /* The First Ten */

2014-08-26T14:25:26Z

‎The First Ten

Strattonbrazil at 14:21, 26 August 2014

2014-08-26T14:21:41Z

Strattonbrazil: /* Anatomy of a Perfect Technical Hire */

2014-08-26T14:18:04Z

‎Anatomy of a Perfect Technical Hire

Strattonbrazil: /* Anatomy of a Perfect Technical Hire */

2014-08-26T14:16:57Z

‎Anatomy of a Perfect Technical Hire

← Older revision		Revision as of 14:45, 26 August 2014
Line 37:		Line 37:
	When programming I generally try to let the candidate program in whatever language they want including pseudocode. For both my jobs out of college I had to learn the company's principle language on the fly so in general I don't care whether they know language X or library Y. If they do decide to use some esoteric language like Haskell that I don't know as well, I expect them to be able to explain to me very carefully what the program is doing. Similarly, if they claim proficiency in a language on their resume, I expect them to use it well. I've seen people who have worked with C++ over ten years and struggle with pointers. This is a bit of a red flag that they haven't been able to understand the fundamentals of the technologies they've worked with.		When programming I generally try to let the candidate program in whatever language they want including pseudocode. For both my jobs out of college I had to learn the company's principle language on the fly so in general I don't care whether they know language X or library Y. If they do decide to use some esoteric language like Haskell that I don't know as well, I expect them to be able to explain to me very carefully what the program is doing. Similarly, if they claim proficiency in a language on their resume, I expect them to use it well. I've seen people who have worked with C++ over ten years and struggle with pointers. This is a bit of a red flag that they haven't been able to understand the fundamentals of the technologies they've worked with.

−	Most important with any technical interview is to never let the candidate get stuck for extended periods of time. It is only time wasted when I could be learning more about them. Sometimes a particularly smart candidate might ~~just~~ not get a particular part of the problem. Make a small note and move on. Give hints, point out bugs, and during long periods of silence ask the the candidate what they are thinking. I want to see their thought process as well as give them more opportunities to prove their capable.	+	Most important with any technical interview is to never let the candidate get stuck for extended periods of time. It is only time wasted when I could be learning more about them. If the candidate goes silent for more than twenty seconds I ask them what they are thinking. If a candidate gets stuck it can quickly eat through the valuable interview time. Give hints and point out bugs. It's just as important to know how they think. Sometimes when listening to the candidate I've realized they don't understand the problem and by rephrasing my question I can get them back on track. Sometimes even a particularly smart candidate might not get a particular part of the problem. Make a small note and move on.

← Older revision		Revision as of 14:41, 26 August 2014
Line 37:		Line 37:
	When programming I generally try to let the candidate program in whatever language they want including pseudocode. For both my jobs out of college I had to learn the company's principle language on the fly so in general I don't care whether they know language X or library Y. If they do decide to use some esoteric language like Haskell that I don't know as well, I expect them to be able to explain to me very carefully what the program is doing. Similarly, if they claim proficiency in a language on their resume, I expect them to use it well. I've seen people who have worked with C++ over ten years and struggle with pointers. This is a bit of a red flag that they haven't been able to understand the fundamentals of the technologies they've worked with.		When programming I generally try to let the candidate program in whatever language they want including pseudocode. For both my jobs out of college I had to learn the company's principle language on the fly so in general I don't care whether they know language X or library Y. If they do decide to use some esoteric language like Haskell that I don't know as well, I expect them to be able to explain to me very carefully what the program is doing. Similarly, if they claim proficiency in a language on their resume, I expect them to use it well. I've seen people who have worked with C++ over ten years and struggle with pointers. This is a bit of a red flag that they haven't been able to understand the fundamentals of the technologies they've worked with.

−	Most important with any technical interview is to never let the candidate get stuck for extended periods of time. It is only time wasted when ~~you~~ could be learning more about them. Sometimes a particularly smart candidate might just not get a particular part of the problem. Make a small note and move on. Give hints, point out bugs, and during long periods of silence ask the the candidate what they are thinking. ~~You~~ want to see their thought process as well as give them more opportunities to prove their capable.	+	Most important with any technical interview is to never let the candidate get stuck for extended periods of time. It is only time wasted when I could be learning more about them. Sometimes a particularly smart candidate might just not get a particular part of the problem. Make a small note and move on. Give hints, point out bugs, and during long periods of silence ask the the candidate what they are thinking. I want to see their thought process as well as give them more opportunities to prove their capable.

← Older revision		Revision as of 14:40, 26 August 2014
Line 33:		Line 33:
	====== Forty Minutes of Coding ======		====== Forty Minutes of Coding ======

−	I always start with a relatively easy question like reversing a string. This allows the candidate to relax a bit and get into programming mode.	+	I always start with a relatively easy question like reversing a string. This allows the candidate to relax a bit and get into programming mode. Again, questions are prepared beforehand. I've been tempted to use questions without trying them on others, but I try to stick with questions I'm very familiar with. For every question I ask I should already know common bugs people run across, edge cases, and variety of questions to dig deeper into their code. Once they complete the problem, I try to dig deeper by adding additional features or changing the scope to see how they can adapter and generalize their code.
		+
		+	When programming I generally try to let the candidate program in whatever language they want including pseudocode. For both my jobs out of college I had to learn the company's principle language on the fly so in general I don't care whether they know language X or library Y. If they do decide to use some esoteric language like Haskell that I don't know as well, I expect them to be able to explain to me very carefully what the program is doing. Similarly, if they claim proficiency in a language on their resume, I expect them to use it well. I've seen people who have worked with C++ over ten years and struggle with pointers. This is a bit of a red flag that they haven't been able to understand the fundamentals of the technologies they've worked with.
		+
		+	Most important with any technical interview is to never let the candidate get stuck for extended periods of time. It is only time wasted when you could be learning more about them. Sometimes a particularly smart candidate might just not get a particular part of the problem. Make a small note and move on. Give hints, point out bugs, and during long periods of silence ask the the candidate what they are thinking. You want to see their thought process as well as give them more opportunities to prove their capable.

@@ Line 25: / Line 25: @@
 ====== The First Ten ======
-After a quick introduction I start going over parts of the candidate's resume with them.  I've already gone over the resume beforehand and highlighted specific sections I want to talk about.  Roseman suggests focusing on percentages in particular.
+After a quick introduction I briefly mention the schedule of the next hour so the candidate knows what to expect.  I start by going over parts of the candidate's resume with them.  I've already highlighted specific sections I want to discuss beforehand.  Roseman suggests focusing on percentages in particular.
 <blockquote>They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. -Roseman</blockquote>
 If they say they've designed an architecture, have them diagram it on the board.  Ask them what part of the design they did and dig deep to determine whether they were actively shaping in the process or just a participant.

← Older revision		Revision as of 14:27, 26 August 2014
Line 27:		Line 27:
	After a quick introduction I start going over parts of the candidate's resume with them. I've already gone over the resume beforehand and highlighted specific sections I want to talk about. Roseman suggests focusing on percentages in particular.		After a quick introduction I start going over parts of the candidate's resume with them. I've already gone over the resume beforehand and highlighted specific sections I want to talk about. Roseman suggests focusing on percentages in particular.

−	<blockquote>They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. </blockquote>	+	<blockquote>They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. -Roseman</blockquote>
		+
		+	If they say they've designed an architecture, have them diagram it on the board. Ask them what part of the design they did and dig deep to determine whether they were actively shaping in the process or just a participant.

← Older revision		Revision as of 14:25, 26 August 2014
Line 27:		Line 27:
	After a quick introduction I start going over parts of the candidate's resume with them. I've already gone over the resume beforehand and highlighted specific sections I want to talk about. Roseman suggests focusing on percentages in particular.		After a quick introduction I start going over parts of the candidate's resume with them. I've already gone over the resume beforehand and highlighted specific sections I want to talk about. Roseman suggests focusing on percentages in particular.

−	<~~quote~~>They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. </~~quote~~>	+	<blockquote>They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. </blockquote>

← Older revision		Revision as of 14:25, 26 August 2014
Line 24:		Line 24:

	====== The First Ten ======		====== The First Ten ======
		+
		+	After a quick introduction I start going over parts of the candidate's resume with them. I've already gone over the resume beforehand and highlighted specific sections I want to talk about. Roseman suggests focusing on percentages in particular.
		+
		+	<quote>They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. </quote>

← Older revision		Revision as of 14:21, 26 August 2014
Line 18:		Line 18:
	* Create core competences for your company. Make sure candidates measure up well.		* Create core competences for your company. Make sure candidates measure up well.
	* Make it tough but fun. Good developers want to know they’re talking to smart folks.		* Make it tough but fun. Good developers want to know they’re talking to smart folks.
		+
		+	== Time Management ==
		+
		+	As I said, I feel like time goes by so fast in an interview. It's important to keep a good schedule so you get what you want out of the candidate and also the candidate gets what he needs out of the interview (they need to get sold on your company during the interview). For an hour long meeting I like to use the first ten minutes introducing myself and going over their resume. This is followed by about forty minutes of coding starting with an easy problem and getting harder and deeper as they progress. The last ten minutes of the interview is strictly for the candidate to ask me questions.
		+
		+	====== The First Ten ======

@@ Line 7: / Line 7: @@
 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.
+* Don’t forget to introduce yourself to help work out everyone’s nerves.
-* 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.
+* “Tell me about your background” is not a useful question for a tech 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.
+* Pick specifics out of a resume to determine what the candidate actually did. Remember, you want people who get stuff done. Period.
-* You should always take copious notes during interviews so you can make a cogent argument for or against a candidate.
+* Probe when you see a resume with a long list of skills. Separate the truth from filler.
-* 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.
+* Don’t “try out” new questions on candidates. Know what a good answer sounds like.
-* 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.
+* Make sure you have them write code! This is too often skipped.
-You want to hire people who are smart, that get stuff done and have the functional set of skills you need for the role.
+* Dig into algorithms, data structures, code organization, simplicity.

← Older revision		Revision as of 14:16, 26 August 2014
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.