How to Find and Hire Amazing People, Part 2
November, 2009
In part 1 of this series we talked about how to find people who might be rockstars. So how can you tell if someone is going to knock balls out of the park for you and your team?
Hard to say. :)
Here's the process we take a candidate through when hiring. Some of what I'm going to say is particular to interviewing developers, which is what I have the most experience with. Most will be general.
Resumes
First, read the resume.
The first thing I look for is experience at a software products company. So the company’s main gig has to be software, and their goods are sold as products not services/consulting. E.g. Microsoft, Amazon, Yahoo, etc. These are the companies that write production code as their core competency.
How long do they stay at jobs? Three or more years at a job is good. One to two is okay provided it's not the pattern. Less than one year is bad.
Next I look at their career trajectory, if they have one.
If they have less than three years of experience, look at their education. Small points for attending a top university for their field. Extra points if they seemed to really push themselves with grad classes, research, etc.
Lots of buzz words or acronyms in a resume is a bad sign.
It's great if they have a list of personal projects. It shows initiative and creativity. It's also good fodder for interviews down the road.
These are just some of my if-then rules. You'll end up growing your own set of rules over time.
Be very picky at this stage if the resume came from a job board or recruiter. You can read 100 resumes in the time it takes you to do a phone interview, so the cost of going to the next stage is quite high. Only do it for great candidates.
Resume Extra Credit
Smg on Hacker News suggested in response to part 1 that you can use online coding problems to help filter through the wave of resumes you'll get from job boards and optionally recruiters.
Justin.tv does this has some pretty neat problems on their jobs page.
Phone Interviews
40-60 minutes.
The most important thing is to have them write code or otherwise demonstrate what they'd actually be doing day to day.
Just to be clear, the most important part of ANY interview is where they demo what they'll be doing every day. It's not their resume, and it's not the stories about their old teams. It's actually asking them to write code, or actually asking a product manager to walk you through a product they've built.
You'd be surprised how many interviews I've been through where the candidate was doing wonderfully, right up to the skill demo where they bomb.
This doesn't mean you can start right off with the coding questions, though. You want the candidate to get comfortable first so they can show you their best colors.
Ergo I split my interviews into three parts: first, I have them walk me through their resume. Then we do "more interviewy type stuff," as I call it. And finally they get to ask me any questions they have about us and what we're up to.
I tell them upfront that's the game plan so they know what to expect.
Having them walk me through their resume helps them settle in. The most important things to dig into during the resume review stage are why they left each position, and try to triangulate what their manager thought of them. This should take about ten minutes.
Then comes the skill demo.
For developers I'll start with something easy like “Are you familiar with the singleton design pattern?" And then go right into my coding question. I have them write their code on a piece of paper, and have them read it back to me token by token when they're done. I copy it down on my end of the phone, and then we talk about it.
The code you have them write should be ten to twenty lines long. They can use any language of their choice, but it should compile. (For all you youngsters, "compile" is something that used to be done to code back in the day.)
It should be one function, with a loop, and have at least one or two edge cases.
It's amazing how much information such a short question can give you. Some candidates will nail the code in 30 seconds, others will take 15-25 minutes. There's at least an order of magnitude difference in the variation of outcomes for a simple 15 lines of code. That's awesome interview power and the most effective signal per minute part of the interview.
On the other hand I haven't found logic puzzles to be useful. I will follow up the coding question with some algorithmic questions if they're doing well.
Third part is where they get to ask you questions. Everyone they talk to should give them this opportunity at each interview. Usually doesn’t take more than 5 minutes.
Score the candidate.
One phone interview should be enough to decide whether to bring them on site, save for extraordinary circumstances.
Onsite Interviews
Three or four interviews, usually three. If an early interviewer gets negative feedback we send the candidate on their way so we don’t tell them up front what their interview schedule will be. Just ask them to be available all day.
Plan the interview loop out beforehand.
We also give the candidates a binder at the beginning with a picture and bio for everyone in the company. That's a great way to help them connect with and understand your team.
Have fun! Start with a big smile! Ask them if they'd like anything to drink. When you're done tell they can take a short break to stretch or use the bathroom. Being interviewed is hard work so try to make it as pleasant as possible. Eat lunch with them. Give them a t shirt!
Have them hack on a 1-3 hour onsite project working on your problems. They are allowed to ask questions, of course. You only want to do this if they’ve done well on the interviews and you expect them to do well.
After the on site interview you should be ready to make a hire / no hire decision.
How do you decide if you should make an offer? The obvious aside, there are a few things you should be aware of.
Setting the bar too high
People often preach the virtues of having high hiring standards. There's lots of theory out there about this but it's true in practice, too. Companies die regularly because they try to "staff up". That's undeniable.
But there is an opposite side of the coin that people don't talk about. 95% of hiring managers need to be told to "have high standards" and they'll iterate into the sweet spot from there.
But 5% of people need to be told to "have lower standards" and iterate into the sweet spot from the too-high direction.
We were one of those five-percenters. Xobni was originally VERY picky. There are a few reasons we loosened up.
The most important reason is that above a certain threshold of signal it's just impossible to predict how well someone will perform on the job.
There are so many random variables like your product, your team, your technology, your culture, their experience, etc that go into success or failure.
I've been surprised in both directions before. There have been people I had high hopes for who didn't work out. We've also hired people who have performed way above expectations.
So if you are too picky you eventually just start measuring noise.
Moreover, your interview time has diminishing returns. If you learn one unit of info during the first 60 minute phone interview, you'll learn only one more unit during the next full day of interviews. The next unit will come from a week of working together. And so on.
If you're interviewing a cofounder by all means spend two months working together before making a call. But otherwise your candidates will expect you to make a decision inside of eight hours of interview time.
Reminder: most people should probably have higher interview standards. Just be aware of pressures in the other direction. They do exist.
Hiring entrepreneurs versus hiring for patience
When we first took money from Vinod Khosla he told us "All of the first 20 employees at Sun went on to start their own companies or become CEOs of major companies. You want to hire those kinds of people."
I agree but disagree.
If you're a Sun or a Google or a Facebook then sure, hire these hyper ambitious folks. Or at least consider it.
But if you're not a rocketship, and most companies aren't, then be careful with hiring someone who's hyperambitious and thinking on short time scales.
The problem is that building a company takes a long time. It's a long haul. And you need the early employees to stick around for the long haul because they understand the broadest breadth of your company's culture, early decisions, code base, customer development, and so on.
So if your first hires want to start their own companies in the next two years you're not optimally set up for success.
Ambition is good in early hires, just not combined with antsy-ness. You want to invest in those people's companies, just not hire them for your own.
Your culture
So you really want ambition combined with patience. How about culture? How do you hire for that?
I'm not sure. I knew from the beginning how to spot great developers and have picked up bits and pieces about identifying other skill sets.
But I'm still working on hiring for culture fit. Here are a few examples I've been learning from.
Example one, just having fun.
Greg Thatcher is one of our many great developers. He runs a web site called gregthatcher dot com. He has several apps on there including a bank routing number lookup utility. Gregthatcher.com often comes up in office jokes.
Now check out gregthatcherdotcomfanclub.com, made by our very own Ryan Gerard. How fun is this stuff?!?!
I don't know the formal definition of company culture but even if this is completely unrelated I still wanted to share it because it's ninja awesome!
And that's part of why I come to work every day.
Example two, traditions. Every Friday we order the best pizza in San Francisco into the office for lunch. It's one of the things I look forward to every week. Yes, I'm that easy folks.
Example three, recognition. Beyond our universal recognition of gregthatcher.com as a jewel given to humanity, every Thursday at our company meeting we give out the Zombie award. It's given to an individual who has done something awesome every week. Everyone is encouraged to email Skyler, who organizes the award, throughout the week when someone does something outright baller. Then the winner is selected through an intricate set of informal procedures -- mostly banter and wit. The award comes with a large rubberish lego brick that the various offices can accrue and assemble.
I know, sounds a lot like the infamous Microsoft Ship-It award. It really is much cooler, though -- trust me.
All of this "culture" creates trust among your team, which is great for productivity, retention, new hiring, karma, fun, and your soul!
How do you build such a culture? Look for people who are passionate, positive, and creative. Then ask them to help you add spice. Empower them where appropriate, and wallah! That seems to be the formula Zappos has followed, anyway.
If you want a recipe for creating mistrust, hire people who are always cynical. That will weaken an organization like nothing else. They will drag down others around them, which gives them positive feedback so they make cynicism a stronger part of their identity, and the spiral downward continues. That won't end well.
Netscape's really-bad-attitude might be a counter example, but I don't think so. It seems to have been more of a way to blow off steam than to fester. Not sure.
Speaking of which, I'd love to hear war stories or lessons from folks in the comments on building culture. I'm very interested in learning more here!
Part 3
...is coming soon! Feel free to subscribe via RSS so you don't miss it!
I'm going to talk about how to woo and close candidates you want to hire, the basics of figuring out compensation, roles, titles, and a couple of other meta details that I hope will be helpful!