Ask HN: How to Hire Hackers
We're about to conduct some interviews and are still receiving applications. Honestly, this would be our first time bringing folks in. We don't know how to go about this the right way, so we wanted to seek out HN advice advice about Dos and Don'ts in the world of hiring and share with everyone.
Since we've just begun our process, we've come upon some tips on HN and elsewhere that we thought would be nice to share. See the comments below separated by stage (sorting resumes, interviewing, puzzles, etc.). We'd really appreciate the help because we want to make sure we're bringing on the right people.
Edit: I took off links so I'm not hawking my wares like a Chinese DVD merchant, we're honestly interested in getting advice on how to hire correctly.
33 comments
[ 1964 ms ] story [ 193 ms ] threadAnti-rockstar thread: http://news.ycombinator.com/item?id=255587
The ultimate secret to hiring: http://www.netjeff.com/humor/item.cgi?file=hire.txt
We've been told to give simple puzzles during the interview (intro CS) and to not make puzzles a requirement to apply. Nevertheless, here were some prominent ones we found
- Justin.tv puzzles: http://jtvproblems.weebly.com/ (problems for flash developers too...) - FB Puzzles: http://www.facebook.com/careers/puzzles.php - Meebo puzzles: http://www.meebo.com/jobs/#web - ITA Puzzles: http://www.itasoftware.com/careers/puzzles07.html - ICFP contests
As for in-interview questions, Joel also had some good advice (http://www.joelonsoftware.com/articles/GuerrillaInterviewing...), use two types of questions: (1) softballs, and (2) complex questions requiring a grasp of multiple layers of abstraction, like C pointers or recursion. With type 1, he recommends caring more about how quickly they do it than if they eventually get it right. For type 2, the goal is more to see how they think, and you're free to help them along with the trivia that is easy to forget but easy to find on Google in 15 seconds.
http://news.ycombinator.com/item?id=89615
Joel Spolsky's Guerilla Guide to Interviewing Developers: - Version 3.0: http://www.joelonsoftware.com/articles/GuerrillaInterviewing...
We honestly don't know what were great interview questions or were terrible ones. For example, google asks "can you teach us something?" while James Hong of HotorNot said once that he would have loved to asked the question "If you had to rob a bank, how would you do it?"
Joel Spolsky's Field Guide to Developers (or what a developer wants) - http://www.joelonsoftware.com/printerFriendly/articles/Field...
Joel Spolsky's Sorting Resumes - http://www.joelonsoftware.com/articles/SortingResumes.html
http://inter-sections.net/2007/11/13/how-to-recognise-a-good...
Take the feedback of everyone who interviewed (your team) into consideration and either offer the position because you feel they are motivated and technically sound or you can fly them in for a 3-4 hour person-to-person after a phone screen or two.
This is what Slide, Facebook, Google, etc. do. None of them mandate puzzles, seems like they use them as a way to "Wow" them.
In the past, I've seen companies give "quizzes" they can do in a limited amount of time. Generally 10-15 question quizzes as a quick way to judge, without wasting your own time, if they are competent enough but hopefully a resume is enough.
Disclaimer: This isn't necessarily my opinion of how it should be done, just how companies that have been around the block do it.
Incidentally, depending on the position, during the interview Google has questions that are similar to puzzles, but relate more directly with the position. e.g. instead of estimating how many gas stations there are in the US, it will be estimate something to do with a Google product.
And... what is your opinion of how it should be done?
You do not have to fly people out, Google/hi5/Ning don't seem to do this but Slide/Facebook still do. It's clearly how convinced you and your team are of this person. You can try and make video conferencing part of the phone screen process of course.
I am no expert on how interviews should be done and it depends on the kind of intern you want: Someone who can learn fast? Someone who is already skilled with your stack? Someone purely motivated?
Ideally all, I'd pick one and base your questions accordingly. Companies I mentioned above let potential hires code in any language and simply check that they know the fundamentals: recursion, data structures. Gauging their passion/motivation/drive is done through their resumes and side projects like others have mentioned.
My personal opinion, you want to pick someone who is capable of learning most things without asking you otherwise it's going to be a struggle of he/she constantly asking you questions.
After going through thousands of resumes, and conducted probably 100 interviews, we finally brought on-board our first couple of team members. Some tips to share from my experience:
1. Don't bother with job boards, such as Craig's list, Dice, etc. In this economy, there are too many resumes floating around, and reviewing them is an incredibly time consuming process when you can spend the time building the product. Negotiate a low rate with a recruiter and outsoruce that process. We wasted over a month using job boards, and got tons and tons of junk resumes. Probably only 1% of the candidates we got from job boards were interview-able. We got fed up, so we engaged about 5 recruiters simultaneously, and within the first week we got the perfect guy. If you really want to use job boards to try your luck, I had the best experience with Startuply though it still didn't result in a hire.
2. Be extremely selective, if there's something that doesn't seem right, it's probably your gut telling you he/she isn't the right person. For hackers -- my favorite question to ask is "when did you first started hacking?". I have found most great hackers started hacking when they were very young (middle school to high school time frame). I found most people who started hacking in college is because they were forced to, not because they are interested in it. Of course this doesn't apply to every case.
3. Do reference checks. In fact, ask the references for additional references. A candidate can master the art of interview, but reference check may tell a totally different story.
Also, I don't recommend technical puzzles. I recommend you to just ask a technical challenge you are facing right now. e.g. How would you architect JamLegend? How do you solve so-and-so problem? etc. While puzzles can test brain power, I think it's much more practical to have them solve a real problem that you face on a daily basis specific to your product.
Hope that helps, by the way, if you get referrals from personal network you can probably skip a tons of things I mentioned above, and they are usually the best early hires. Good luck with your hiring process!
We like to do all of our interviews in 1 day, and when the candidate is in his/her last interview, we will all gather and make a decision right on the spot. If we like the candidate, we will make an offer when the candidate is on the way out. You can say this offer stands pending all reference checks went through. But this serves two purposes:
1. You show you have strong interest and is willing to make decisions quickly.
2. You lower the risk of the candidate going to another interview and receive another on-the-spot offer, and take that offer on the spot.
Great candidates are very hard to come by, and they are in very high demand. So realize your offer won't be the only one they receive. If you are unable to make a decision on the spot, he/she is probably not the right person.
This: In fact, ask the references for additional references.
... is actually pretty damn scummy. The candidate has no way of knowing who his shadow references are, and could get unfairly burned and left with no idea why. It'd only be morally acceptable if you asked the candidate for permission to call these second-degree references, but that would defeat the purpose of snooping.
First degree references usually have nothing but good things to say about the candidate, but you will get a much much more accurate picture from talking to someone who isn't on your candidate's top list.
I understand you are currently seeking summer interns, no problem. Today, young people that are proven achievers have much to examine:
1) Projects they've built or been a part of--just because they were curious if they could do it.
2) What are they passionate about: who have they read/studied in the area?
3) Are they aware of market leaders in your sector and can they discuss what they believe is right/wrong in their model.
4) Extra-Curricular's (speaks to buy-in of culture)
5) How do they define providing value/work ethic?
The above represent top 5. Be certain that when you find a candidate you'd like to hire that you can articulate the value proposition you offer to them. Be prepared to demonstrate how being a part of your team will benefit them. Don't bullshit, anybody smart enough that you want to hire can smell it a mile away. Be Good. Absolute best of luck.
As a small startup looking to hire hackers, you obviously want the best. You want experienced hackers who already know how to code and perhaps have experience on a project before (e.g. open-source). Of course, you want the brightest.
But this is always a challenge because the smarter, more experienced, and more valuable a hacker is, the rarer they are and--odds are--the less likely they are willing to work for you because they're less desperate for an internship; they can afford to shop around, or may even just decide to do their own projects for a summer.
So here's how you can try to attract those people.
1. Pay decently. A lot of companies like to pay interns nearly nothing these days (or in some particularly obnoxious cases, actually pay them nothing). This of course doesn't mean pay them as much as a full employee, but it does mean they should not feel insulted by the amount of money you're offering. If they could earn more than 5x your pay as an independent contractor, you're doing it wrong. While not all hackers do internships for the money, it's definitely a huge plus. And if you don't think you're going to get enough out of your intern to justify the pay, don't hire them; you should not hire an intern unless you have no doubts about their ability to produce significantly more value through their work than you're paying them.
2. Deal with the interns' practical issues with regards to working for you. For example, if they're coming from out of town, deal with their housing and flights. Hackers dislike dealing with bureaucracy--you'll save your intern's time and effort and sanity by dealing with these issues.
3. If your interns' time is so much less valuable than your employees' time that you cannot spare significant employee time to helping the intern with what he is doing (in the same way they would help another employee), don't hire an intern.
In terms of picking an intern, often you have to actively seek them out to be successful, especially if you're looking for the kind of hacker that doesn't go around applying to every internship he sees. For example, if your company makes very significant use of open source software, you can look through those open source projects for potential interns.
This means a number of things:
1. Give them at least one project to work on with specific things that need to be done. Don't necessarily have a hard deadline unless there actually is one for the project; as long as your intern has work to do he clearly can't justify goofing off, so always make sure he has work to do.
2. Have at least one project available for him to brainstorm on. Any good hacker is going to have loads of good ideas; the best way to waste these is to throw the hacker onto a project that doesn't need them. Your hackerf is not just a codemonkey. When you have your hacker dropping by your office or pinging you on office IM about a really cool idea he had for Project X, listen to him; it just might be a good one.
3. Ideally, hire an intern who has a skill set or knowledge base that nobody in your company has. I don't need to describe the value of this.
While Frocer touched upon a majority of what we did, I'll throw in my interviewing experiences. We are partly in the video game industry so my #1 requirement was the applicant MUST have video game playing experience (of the 'core' variety) and the more the better. I just couldn't see anyone who only played Wii Sports or Bejeweled on the iPhone could comprehend what we do and therefore unable to help the team in any sort of discussion beyond the technical. So that was what was most important to me and that was what I filtered on and not surprisingly, I had a good feeling immediately after each interview on whether or not I wanted them.
My interview consisted of no stupid puzzles or whatever cause it was of no use to me. Show me you are technically proficient (of which a lot were, otherwise why waste time applying for the job) and then show me you understand video games by carrying an intelligent conversation with me about let's say your favorite xbox 360 game, which smash bros was the best, or why world of warcraft is both the greatest and worst game ever, etc. You'd be surprised on how many people couldn't do that.
Also I'm seconding the reference/portfolio thing. The more you can find about their past, the better the idea you will have about their future.
The problem is, trying to talk to someone who's only knowledge of gaming is Wii and iPhone about traditional gaming tends to go nowhere in my experience, whereas talking to a traditional gamer about the Wii and iPhone still leads to interesting conversation and ideas as those "casual" games are pretty much small extensions of traditional gaming.