Ask HN: What's your hiring process like?
Hiring people can be a risky thing. You're bringing someone in the family and hoping they can deliver. What are some things you do to minimize that risk? Do you contract first? Coding challenge? I'm curious what others do to minimize the risk when you haven't worked with someone before.
5 comments
For questions like these, I like to quote a story I once read about dating in New York City:
"I have a female friend. She asks every guy she meets at a bar two questions:
1. Do you have a passport?
2. Do you have a Kindle/Nook/library card?
Why does she ask these questions? If the answer to 1 is no then he doesn't like to travel abroad and if the answer to 2 is no then he doesn't like to read."
In essence, she determined two quick filters that were the most important to her.
I had a manager who had a similar test for candidates. He would give them a 5 question tech test where the first question had a "trick" item. Specifically, sort multiple 5GB+ files on a box with 1GB of RAM but 100GB of disk space. If the candidate got the first question wrong, that was the end of the line for the candidate. Why? It showed that they:
a. Didn't have attention to detail
b. Didn't fully understand basic technical constraints e.g. in this case RAM is limited but disk is not.
One other point I always like to make is to screen candidates in parallel. For example, if your process is to bring someone in to the office and then give them a tech test, that's a serial process.
On the other hand, if you give the tech test to recruiters and say "Have candidates fill this out and then send it in", you just created a parallel process to screen candidates.
I've also heard people say "What if they look up the answers?" to which I reply: if you give someone a test with google-able answers and they still get it wrong, you just filtered out a pretty bad candidate. Win for you.
"I have a female friend. She asks every guy she meets at a bar two questions:
1. Do you have a passport?
2. Do you have a Kindle/Nook/library card?
Why does she ask these questions? If the answer to 1 is no then he doesn't like to travel abroad and if the answer to 2 is no then he doesn't like to read."
In essence, she determined two quick filters that were the most important to her.
I had a manager who had a similar test for candidates. He would give them a 5 question tech test where the first question had a "trick" item. Specifically, sort multiple 5GB+ files on a box with 1GB of RAM but 100GB of disk space. If the candidate got the first question wrong, that was the end of the line for the candidate. Why? It showed that they:
a. Didn't have attention to detail
b. Didn't fully understand basic technical constraints e.g. in this case RAM is limited but disk is not.
One other point I always like to make is to screen candidates in parallel. For example, if your process is to bring someone in to the office and then give them a tech test, that's a serial process.
On the other hand, if you give the tech test to recruiters and say "Have candidates fill this out and then send it in", you just created a parallel process to screen candidates.
I've also heard people say "What if they look up the answers?" to which I reply: if you give someone a test with google-able answers and they still get it wrong, you just filtered out a pretty bad candidate. Win for you.
Parallelization is a very good advice, I am going through a hiring process right now where the company employs this method and according to them it has made their lives alot easier.
The take home code test they use is totally googlable, however there are multiple ways to solve the problem and they ask candidates to provide tests for their solutions. If they are happy with the solution and find it distinctive the candidate gets to explain the solution during the onsite interview.
I found the whole process very relaxed and enjoyable.
The take home code test they use is totally googlable, however there are multiple ways to solve the problem and they ask candidates to provide tests for their solutions. If they are happy with the solution and find it distinctive the candidate gets to explain the solution during the onsite interview.
I found the whole process very relaxed and enjoyable.
It also forces the candidates to invest their own time and brainpower before you expend resources to screen/interview them. Helps cut down on individuals who are interviewing only to test the market and may not be really serious about the position.
At Forter (www.Forter.com) a big part is the screening of CVs. HR and RnD work closely to contact only relevant candidates, and when we a CV could be relevant the RnD manager or the lead developer calls the candidate for 15 minutes focusing on a key strength that makes the candidate relevant and why working at Forter is so great. The first interview is about the candidate's comfort zone. You would be amazed how many people don't know what they were working on about the past few years... plus a hands on algorithmic coding task that does not require experience (we hire also coders before college). The rest of the process (usually three more interviews) are mixed. Include technical, personal discussion. We try to fit all interviews into one day. Even though Israel is small and travel is non issue , there is a strong psychological effect if the candidate gets an offer after one visit. This might require in some cases talking with the candidates recommenders while she is interviewed in the next room.
Here are some general principles and tests I accumulated over a long career, mostly gotten from managers a lot better at hiring that I was ^_^:
If you have doubt over a certain low threshold about the candidate, don't hire. A bad hire, especially in a startup, is terribly expensive.
Testing coding is mandatory. Back in the '90s when C/C++ were the game, we used two tests, write code to create a doubly linked list, and look at a small function we'd put up on the white board and find problems with it. Both were graded generously, it was pretty clear if the candidate had a clue or not.
Then general problem solving, i.e. some design problems, perhaps including a big/relatively difficult one, and have the candidate describe some design solutions they were proud of.
Code samples were very welcome if available, of course.
In all of this, you'd get a pretty good sense of whether you'd like to work with this person. You'd also use the whole process to sell the company/project to the candidate, and see how they responded to that, they had to show either some interest in it, or for the more professionally oriented, something like an attitude that it would be no problem in due course and they would like the work.
Ah, especially for startups, get across the concept that "you can't be too proud to not sweep floors" if needed, but that each engineer would be allocated both some of the less interesting work that just has to be done, and the interesting work.
If you have doubt over a certain low threshold about the candidate, don't hire. A bad hire, especially in a startup, is terribly expensive.
Testing coding is mandatory. Back in the '90s when C/C++ were the game, we used two tests, write code to create a doubly linked list, and look at a small function we'd put up on the white board and find problems with it. Both were graded generously, it was pretty clear if the candidate had a clue or not.
Then general problem solving, i.e. some design problems, perhaps including a big/relatively difficult one, and have the candidate describe some design solutions they were proud of.
Code samples were very welcome if available, of course.
In all of this, you'd get a pretty good sense of whether you'd like to work with this person. You'd also use the whole process to sell the company/project to the candidate, and see how they responded to that, they had to show either some interest in it, or for the more professionally oriented, something like an attitude that it would be no problem in due course and they would like the work.
Ah, especially for startups, get across the concept that "you can't be too proud to not sweep floors" if needed, but that each engineer would be allocated both some of the less interesting work that just has to be done, and the interesting work.
When we started hiring about 6 months ago at our startup (groopic.com), here's what my thought process was:
We need great people that we want to work with - Incubators and Accelerators invest in people - They know how to judge them - World's best accelerator (YC) asks the founders a few questions and short lists companies on the basis of the answers - There must be something in those questions - Adapt them for you hiring to screen the pool of applicants. In our case, it has worked like magic. We are able to filter about 65% of the applicants. For the rest, we call them for first interview, only 10% left after that. They are the ones we spend a lot of time on, and we hired 5% of the applicants in the last 6 months.
I prefer the contract-to-hire model, but I say this as an employee. It's hard to know whether I'll like a place, but if the place is open to 3-6 month contracts, I can find out and can make it work. Unfortunately, this isn't the way things seem to work.
Also, the duration of 6 month is short enough that, even if I don't like the place, the incentive is there to put the best foot forward to get the best recommendation possible to go somewhere else.
Also, the duration of 6 month is short enough that, even if I don't like the place, the incentive is there to put the best foot forward to get the best recommendation possible to go somewhere else.