What I’ve learned about the hiring process

6 months ago, when I started my Indy game company Jenkins Software, I had virtually no interviewing experience and made some hiring mistakes. Here’s what I’ve learned, now that I know a bit more about the process. I can’t go back in time to send this to myself, but hopefully others starting companies can learn from my mistakes.

It takes time and costs money to find the good people.

Originally, I thought posting a job ad on Gamasutra would net me hundreds of applications, of which some small percentage (5%) would be great guys. And I’d hire those guys.

As it turns out everyone wants the great guys, not just me, and the other companies have a lot more money and perks to offer than I do. So great guys are rarely on the market, and when they are they tend to be snatched up very quickly. The only reason I’m competitive at all is that I offer telecommuting, which is such a perk that it outweighs everything else for many people. On my own resume I offer to work for $10K less a year if I am allowed to telecommute. I also allow everyone in the company to have a say in the game design, another huge perk most other companies do not offer.

My job ad on Gamasutra only got me 8 resumes in the end, only 1 of which I would say is a professional level candidate (where I was expecting hundreds of professional level candidates) and even then I don’t know if he was one of those top 5% great guys I was looking for.

I’m starting to understand the recruiter market. Because the pool of great candidates is so small, recruiters are there to pull people away from their existing companies and not so much to search for people who are already available. They charge a ridiculous amount for that small service (15%-50% of the first year’s salary) and I’d never use one for that reason but I can at least see the theoretical point now.

In 6 months of looking, I only ever found one good guy and just hired another, who will hopefully turn out to be good – we’ll have to see.

If I could do things over again, I’d start the hiring process about 1 month before I even started the company. Get some names down, some people to sign up for you for a start date two weeks later. And I’d continue hiring and looking, because some of those people won’t work out anyway.

A bad hire can ruin the company

Before I started the company I read a lot of management books and spent a lot of time trying to motivate the people I did hire. So when people didn’t perform, I tried to be a better manager, and blamed myself for their failings, so would respond with motivation and help, and kept giving more time, and more chances. As it turned out, the problem wasn’t bad management but a lack of raw talent – the bad management part was in hiring the wrong people to begin with. I confused inexperience with incompetence. The first is easily fixed, and in a way is positive because you can get someone cheaper and train them. The second is impossible to fix and will only drag your company down. If someone says “I don’t know how to …” this is OK – spend a day training them and you have a more valuable worker. If someone says “I can’t …” and they actually can, this is incompetence and you might have made a hiring mistake. For new hires, this is very important to watch for.

Hiring the wrong people is a triple whammy. You waste your time training, they waste your money learning, and you end up even later and more behind schedule.

This may sound harsh, but it’s true. There is a 100X difference between the best and the worst programmers and the curve is towards the bad end. So there’s a lot more bad programmers looking for jobs than good ones, and it makes it very important to not keep the bad ones.

You won’t know who is a bad hire until after you hire them

Maybe I’m not good enough at interviewing, but some people are good at interviewing but bad at programming. It takes me between a week and a month to sort out the difference. So when you hire, you should overhire, because some of the people you hire aren’t going to work out anyway.

Quality is more important than cost

With 100X the difference between the best and worst programmers, it’s worth paying double for someone 10X better. Of course it’s always a risk – say you hire a guy at double the cost, he doesn’t work out after a month, and now you are out 2 months of salary. But generally speaking, if you find a great guy just take him right away, despite the extra cost. This will save you money in the long run. Plus, the good programmers know they are good and tend to ask for more money. A very low asking price is a warning sign.

One of the mistakes I made early on was to pass up a very experienced guy in the US because he was slightly too expensive. As it turned out, I ended up paying far more in the long run because of this, and had to hire people nearly as expensive anyway.

Get the money straightened away first

Once I interviewed with a company that spent probably $1000 on the interview. They flew me in, put me up at a nice hotel, spent a lot of time on interviews, had a producer drive me around showing me the local area, and spent time doing paperwork. Their final offer was 20% below my best offer, and was also below the minimum I put on my resume. The offer was fair for the area, but was too low for me to accept given the number of other companies that also had offers for me.

To a lesser degree I had the same problem, spending a lot of time interviewing guys that wanted double what I could afford to pay. I may have liked them in the end, but it was a waste of time nonetheless.

Setup interviews in stages, and don’t be afraid to cut an interview short

Similar to above, a lot of guys just can’t cut it and it’s not worth the time to do a 2 hour interview with a weak candidate. It’s not rude, it’s business, if you have to just cut an interview off after a short time.

Go with your gut instincts

Lastly, if someone gives you a bad feeling but you can’t say exactly why, no hire. Every time I’ve hired someone because I had no other reason not to, I regretted it a few weeks later.