Brainstorming: How to hire a dude
I’m not an HR admin, a recruiter, or in any position to hire anybody unless they want to work for half a pack of Jolly Ranchers. What I am is a junior programmer who’s worked at a couple of companies, and read a metric ton of developer / tech blogs (Hacker News ftw). With this limited knowledge in mind I’d like to present my hypothetical hiring process. This probably pokes holes at my own profile, but I want to hire someone who’s BETTER then me, not another me. I’m not going to discuss how to lure in candidates, that’ll be for another time.
1. Before the interview
Cover letter: The story, or content doesn’t matter; we are looking at formatting, grammar, and typos. Developers tend to communicate a lot via email, IMs, comments, variable naming, ect. So we need to make sure they can wield the english language pretty well. Humor in a cover letter is always plus. I’m not interested in people who take themselves too seriously.
The resume: What that matters here are code samples. Bonus points for code samples that are live on a server, or I can run. I should be able to go and browse the git or hg history. GitHub, BitBucket, git repo in a folder via a dropbox link, w/e. Formal education is overrated, and I actually think it’s cooler if someone is self taught. Shows moxie, see?
The beauty of a repo history is that you get to see the candidate’s commit messages, how their code changes over time, how long it took them to figure out and implement various features. It’s a play by play of how they work.
####2. Personality interview / is this guy a jerk? I rank this higher over raw coding competence, skills can be learned, but personalities for the most part are immutable. You can’t tell someone to change their personality, but you can tell them to do some studying and come back.
This interview should be conducted in two places (coffee shop and desk side) with no less than 4 programmers (separately). If you don’t have that many coders then use all of your coders. Take a couple junior or mid level coders and a couple seniors, have each one spend a little one on one time with the candidate. Try to pick people they’ll end up working with. We want to know a few things:
- How well do they communicate technical discussion and problem solving discussion.
It helps if they’re allowed to talk about actual work. Hypothetical is usually too lofty and results in more questions than answers (unless it’s a REALLY well defined hypothetical, but at that point you might as well have just given them a problem you’re actually working on).
How well do they get along?
Do they care about what we’re building here?
This might sound like a waste of man hours, I’d say you are wrong. This industry has a HUGE issue with turn over, and I believe this is partly because we don’t take the time to get to know our candidates before we hire them. You may say, ‘but we have a three month probation period, surely that’s better than this’. The problem with a probation period is that by the time three months comes and goes you’ve become comfortable with the dude. It’s a lot harder to say we’re not interested in working with you after three months. So hard you probably won’t let them go till the situation has deteriorated significantly.
I’m not saying don’t have a probation period, just don’t think it gets you out of getting to know your candidates.
####3. Project test We’ve seen git logs from personal, self initiated projects, we’ve had a good talk. Let’s see if the guy or gal can just write some code. Have them do a small project, something real, have them write some code that you’ll be able to ship if it’s good enough (pay them for this work). Try to choose a project that’s open ended and doesn’t need a briefing. It can last anywhere between a couple hours and a week, depending on what your needs are, or what your comfortable with.
This is a good opportunity to have the candidate work on something using some of their weaker skills. This will show how well they handle learning as they go. It can also force them to study up on some skills that you need them to have.
DO NOT run them through a puzzler gauntlet. Many of these questions are issues that were open in the software engineering community for years before they were solved. So either you have a real genius on your hands, or they’re just regurgitating information. This does not test their ability to solve problems, think creatively, communication, or any other skill that might be useful. Problems like these can be just Googled in the real world. So even if the candidate knows the answers, it’s not that great or useful. Geek at best.
So hopefully with this I’ll be able to pick a pretty good employee when the time comes. In pretty much every job I worked, it hasn’t mattered how awful, or how much fun the work is. What does matter are the people you work with, when you enjoy being with them and pulling together to make things happen, you do better work.
It’s like the difference between high school and college. High school is mostly kids who just want to get by, they just want to do the bare minimum and get out. All the sudden, in college, you’re working along side with people who chose to be there, they want to be there, and have the same mission as you. It’s a world of difference in terms of motivation and getting things done.
This is why I think the personality test is leaps and bounds more important than the skills test. Skills can be learned. The right personality is a much rarer thing.