At Arc90 we’ve been incredibly fortunate to find and hire the amazing people we now have on our team. Here are a few open secrets that I’ve found vital in finding the right technical people for the roles we’ve had and getting them to join Arc90.
It’s important to note: I’m not a business manager. I’m a developer and also a partner. At Arc90 we all wear a lot of hats, and one of mine is interviewing and hiring new developers. This is what works for our company. We have a specific (smaller) team size, expectation of capability, and company vibe. It might not be the perfect fit for yours.
Overall
1. HR should not be hiring.
The person in charge of hiring should be the most technically talented, passionate, and effectively communicative person on your team. This is never HR. Regarding a particular need, HR only knows what you tell them, and while they may be passionate and communicative, they are never as connected to the role as the people actually involved in making the product.
This almost certainly will change from role to role. Choosing carefully here is absolutely vital. It will color every step of the process from here on out.
The Req
2. Know what you want!
Be clear about what you’re looking for, and be succinct about it. A req with a soup of tech keywords spilled all over it will get you a similarly broad spectrum of applicants, and likely turn away the candidates who are the best fit for your specific needs.
3. You’re pitching them.
Here’s the truth: You want to hire someone that’s out of your league. The people you hire have a direct correlation to the quality of your company’s work, of course you’d want to hire the absolute best person you can afford. Do not be condescending in your req! These are incredibly talented people who have a choice to go to any number of companies. They can walk if they want to. You need to convince them that your company is the best place for them.
3a. But be genuine.
Here is what I know already about the role you are hiring for: You do not want an actual ninja, or an actual rock star. If you did, you’d be posting on shurikens-and-heroin.com rather than the 37signals job board.
You must give a genuine representation of the vibe of your company if you want this person to work for you. If you play up an inaccurate angle, they’ll sniff it out the minute they come in for the interview. You want them to be doing the work you’ve got waiting for them, and be happy about it.
4. Hand write your req, carefully, and proofread it.
For the love of god, make sure your req is well written! Spelling and grammatical errors can immediately sour candidates. If you’re expecting them to put the effort into putting their best foot forward, shouldn’t you? Avoid any Job IDs, ALL CAPS, or unnecessary boilerplate information. This should feel like hand crafted, thoughtful communication.
The Filtering Process
5. Reject poor communicators immediately.
Absolutely vital, this. Proper use of language and being able to quickly and accurately get your point across is the keystone of an effective team.
Additionally, programming is an exercise in semantics. If a person cannot clearly communicate in language, the odds of them being able to effectively communicate the intricacies of technical language are small.
6. Require code samples up front.
This is the fastest way to winnow the pool of candidates, aside from spelling and grammar. Many candidates will just not attach or link to any code samples, which means you can ignore that applicant immediately: They don’t follow directions well. Many other candidates will just have poorly written code. I’m often able to cut about 90% of the remaining candidates just by using code samples as a metric.
There’s also a number of potential bonus points here. Links to github, or other open source projects, can show a commitment to teamwork or open collaboration.
Here’s another tip: We’ve gotten a small number of candidates who have sent in plagiarized code samples over the years. Using something like google code search can help sniff them out, and we’ve outed a number of them that way before.
7. Myth: You’ll only find top tier talent on top tier job boards.
It is absolutely true that you’ll have a higher signal/noise ratio by spending the money and posting on top tier boards like 37signals and Stack Overflow, etc, but that doesn’t mean you can’t find excellent candidates in other places.
For example, when hiring, while we almost always post on some premium boards, we also regularly post on craigslist, and some of our best people have come through it. Your bullshit filter must be incredibly high, and you should include some bozo filtering (requiring code samples is great for this), but that doesn’t mean that talented people don’t occasionally lurk there for one reason or another.
8. Go with your gut, with a bias towards rejection.
Interviewing is expensive. It’s important in this phase to reject early to save yourself time down the line. Trust yourself, as the person most knowledgeable about this role (see point 1), to know what is a good fit and what isn’t, and save both you and the candidate some time if it just doesn’t feel right.
9. Myth: “Smart People are Language-Agnostic”
This is something we’ve wrestled with at Arc90. Often our impulse is to hire people purely because they are effective communicators, and they are great coders, and who cares if they don’t yet know Scala because they can learn it, right?
This is a mistake. The missing piece here is that humans have predispositions, and this particular human may not be predisposed to enjoy Scala as a language. As I’m sure you know, programming in a language you do not enjoy can be a soul crushing experience.
If you find a good candidate who you think is a potentially great fit, but doesn’t know the domain at all, have them spend a few days getting to know it before either of you make a decision. It’s valuable information for both of you.
The Interview
10. You’re still pitching them.
So you’ve filtered your candidates, and found a few that you’d like to talk to in person. Don’t blow it. Don’t forget that this is still an opportunity for you to hire someone smarter than yourself, who will make your team and your company better. Go into every interview thinking of it as an opportunity to find a good match, not an opportunity to grill someone to see if they’re good enough to join the ranks of your hallowed organization.
Additionally: This is really the first impression they’ll have of you. Try to be at least decently dressed for your role, but dressed indicative of it. If you wear a t-shirt every day, at least wear a clean one.
11. Converse, don’t interrogate.
This is not a test.
Well, okay, it is a bit, but it shouldn’t feel like one. This is a time to get to know each other, to assess cultural fit, and to assess communication skills and their ability to speak technically. By now you should have already seen a good deal of their code, at this point you just want to see if they’re sharp with a time limit, and you can talk to them.
12. Be up front about sticking points.
If you’re uncomfortable about an aspect of this candidate and their fit, now is the time to say it. It will be far more uncomfortable if you make them an offer, and they accept, and your fears become reality.
13. Puzzles don’t solve anything.
At this point you should already be familiar enough with the candidates code samples that you can discuss it without having to look at it. For example, you should remember that they used class inheritance in an interesting fashion, and be able to discuss it with them. You’ll learn far more from something like this – real world code with real world reasoning – than you’ll learn from “there’s a bus travelling 50mph with a quarter tank of gas left and how fuel efficient will it have to be to get to Boise, Idaho”?
–
Hopefully all of this has been pretty obvious. When it comes to the hiring process, a lot of it just follows the golden rule. Were you on the other side of the table, how would you want this interview to be conducted so that you’d get maximum value out of the position long term? You would want to be somewhere where you’re providing value, and be happy doing it. Luckily this is exactly what the company wants. The rest is just fit and numbers.
Looking for examples of carefully crafted job reqs? Luckily, there are a few right over here: Arc90 is hiring.