The GitHub Job Interview

One interview is never enough

to find if the candidate's up to snuff

takes two or three more

job interviews before

you can tell if the CV's a bluff

How the hell do you interview a start-up CTO? Finding software developers is hard enough, but a start-up founder can't take any chances when it comes to hiring developer #1. So, what, five interviews? How much can you talk to someone before you know what's like to work with them?

It's apparent to anyone who's done this that the marginal value of yet another interview approaches nada after two or three sessions. Some people are just good at being interviewed and can charm the quark off a hadron, but when you start working together all kinds of stuff rises to the surface. None of this is news to experienced hiring managers. Everybody knows that working together with someone is the ultimate job interview. If only you could try people out before hiring...

Bad Solution

Some hiring managers try to do that. Sort of. They hand out programming exercises and expect candidates to not mind wasting their time developing nonsense code just for the sake of the interview. This sucks. I never do that, and I'd never play along if someone asked me to. It's plain unfair. Worse, however, are those that actually offload real work onto candidates. Yea, that happens. People are expected to work for free before being hired. 

You might say, just hire. Let someone work "on probation" for a short period and if it works out, great. If not.. well, it doesn't really work out that great for them. Being rejected after two weeks of work doesn't look good on anyone's CV. Moreover, the time you have to spend with new employees getting them up to speed with your code-base, development guidelines, the product and so on is just too much of an investment. And at the end you're likely facing a disgruntled ex-employee with access to your source-control system. Yikes.

Awesome Solution

That's why I'm advocating the GitHub job interview. Open-Source projects are a fantastic way to collaborate with people you don't know too well. And GitHub in particular, with its ease of forking and pull-requests is just the best (and biggest) platform for open-source collaboration.

Here's what you do. You come up with a cool idea of an open-source project. This becomes your company's development sandbox. Candidates are asked to then contribute to the project in some way. You want to see them code? Ask them to develop a module. You want to see them tackle a bug? Ask them to choose one from the bug-list. This works for every aspect of development work. You can design features together. You can gauge their communication skills. You can see how well they handle reviews. You can ask them to document their work and see how well they can write. But above all, you're not taking advantage of anyone, and true developers probably won't mind investing time into an open-source effort. 

Choose your GitHub project wisely. It should be something relatively fun. It ought to use the same technology stack your company uses. And it should be relatively simple to grasp, because the point is not to be investing too much time training people you're not yet hiring.

Not all developers have existing online projects they can point to when you're interviewing them.  So make one for them. You avoid hiring and firing. You reduce risk by investing less time and not exposing your IP to candidates.

This is what Gignatt will be doing, now that we're hiring our first employees. Stay tuned for details on our open-source project.