Hiring Software Developers... You're Doing It All Wrong

Short blog post on some of the most common mistakes I’ve experienced with the recruiting and hiring of top talent engineers. Although there are many articles written on how to attract and hire great talent, seldom is there word shared over the silly things companies do to shoot themselves in the foot during the hiring process.

“If you think it’s expensive hiring great engineers to build your software, wait and see how expensive it gets with bad engineers.”

If you’re looking to hire A Player Software Developers, this article is for you. If you’re looking for advice on hiring B players, on a C-Player budget, I wish you luck on the “Bozo Explosion” you’re about to embark on, but this article isn’t for you… Read this instead.

Don’t Skimp on Talent

Your $90,000 BMW is in need of repair. Do you take it to el-cheapo Pep Boys, or do you take it to the (omg, that’s how much money for a spark plug?!) BMW repair center?

After all… a mechanic is a mechanic, right? So an engineer is an engineer, right?

Wrong

You wouldn’t trust your luxury car with just any mechanic, so why on Earth would you trust the people in control of your IP, your company’s core competencies, and competitive advantage to a mediocre gaggle of keyboard jockeys with Nerf guns? Good Engineers are expensive. Get over it.

You aren’t Google.

Nerf guns and scooters are cool… for my 5 year-old. And if you try to lure candidates with toys, you’ll end up with an engineering team of… 5 year olds!

Companies like Google offer toys, but they don’t lead with them. They lead with what matters to me… my day-to-day world. Leave the cute toys as background props. They won’t keep an employee around, and putting them in the fore-front makes you look like a desperate Google-wannabe.

GitHub is the Interview Question

Nothing makes you look dumber to me than getting me on an interview panel and asking me to code a Bubble Sort routine or some other algorithm you pulled from the April 1989 issue of Commodore 64 magazine. Not only is the question irrelevant to what an engineer would be doing within your company, but you’re likely going to end up with a company of great sorters and no one to actually build and deploy software.

For engineer interviews, my own preference is to deep-dive in to technologies they’ve used in the past and you may use here. I want you to get a sense of how well I know my field, and I get a sense of how will you know your work. This is about selling each other to each other, right?

On GitHub

GitHub offers you an open and unashamed view in to your candidate’s coding abilities. As no one believes a prospective employer will judge them one day on their GitHub projects, their code is often raw and unfiltered. You’ll get a sense for how they will code, while at your company. It also gives you a reference point to ask questions from during the actual interview, ie. “Why didn’t you use a Bubble Sort in this Java class?”

Don’t be a Bozo

I cannot stress how small Engineering circles are. Even in the largest of cities and tech hubs, we are all connected. We know who the power-players are in the community. We know who’s a good engineer and who’s bad. Likewise, we know the good companies from the bad.

We gossip like teenage girls about the companies we work for. Really. You can fear GlassDoor reviews all you want, but they’re really graffiti boards for angry clowns with crayons.

The real story from your most prized employees and engineers, the people we respect as peers, is dished out among the tech meetups and conferences. In fact, every city has a list of places no engineer worth his salt would step foot in, because his peers have spoken ill of it.

How you treat your candidates and current employees will shape your brand for years to come, thereby affecting the quality and cost of the talent you seek.