I recently read an article, Fifteen ways to kill your job interview, which included an interviewer’s top list of annoyances that ruin the candidates chances in an interview.  Things like “Speak ill of anyone, especially past employers” make sense and are a red flag in an interview.

Reading through the full list, I was struck by how self-centered the post was to employers. Employers and hiring managers seem to think programmers are just desperate for a job.  We have to jump through numerous hoops that are pointless and have nothing to do with doing a good job AND smile while doing it.

Here are a few ways to “kill” your job interview that had me rolling my eyes: “Be unprepared”, “Shake hands like a fish”, “wear a suit”, “Appear desperate”. Keep in mind that each of these was not just “things to avoid”, but is considered something that would “kill” the candidates chances of the job entirely.

Do you have so many brilliant programmers walking through your door that you can’t deal with a weak handshake? Or wearing slacks and a shirt instead of a suit? Anyone who eliminates candidates for every single one of these (irrelevant of technical skill, mind you) will end up with a team of fake, sales-ey, over-groomed and under-talented people who can’t code their way out of a paper bag.

Meanwhile, the employers don’t have to do anything but ask questions and nod sternly.  Interviewers are often not ready right at the interview time.  They often do not prepare by reading the resume or learning anything about the candidate online.  The interviewer rarely wears a suit or any special clothing.  And many many times interviewers leave their phones on, act uninterested, complain, cut the interview short and every single thing on the list.  So candidates are expected to jump through hoops most of which have nothing to do with the ability to do a good job but employers don’t have to do any of them?

The winning line was “Your interview is all about what you can do for the company, not what they can do for you.”

That is NOT what an interview is about.  An interview is the time for both sides to figure out if this is a good fit. Very few employers are willing to setup another hour-long meeting with the manager and team AFTER they’ve made an offer for the candidate to determine if it’s the right fit.  Even if they are candidates don’t have time to re-visit every employer who made an offer.  And why should they?  An interview goes both ways.

Of course, it’s not just him.  This employer-centric attitude is common in the job industry at large.  Just read any major job board blog to find loads of “helpful” advice about putting aside your individuality and personality, how to dress, hire someone to write your resume and cover letter, fake it till you make it.

On the surface it makes sense.  After all, they have the job and programmers want the job, so they have all the power, right?  Here’s an employer-focused argument that is easy to understand: if you treat candidates like they don’t matter, only the desperate ones will want to work for you.

I’ve spoken a lot on the blog about the difficulty in recruiting and hiring great programmers, but that’s all based on the assumption that you’re interested in that sort of thing.  A self-centered approach to interviewing won’t ever attract the really talented programmers. Even if they easily get past these lists, any self-respecting programmer would be turned off by such a myopic approach to hiring.

And the “me me ME” employers won’t mind (and most likely won’t notice) if their approach turns off all the good programmers who will mysteriously disappear or accept other offers.  The lucky programmers may even notice the demeanor in the job post or early correspondence and bail earlier than that.

The programmers that get hired will be the ones who couldn’t get a job anywhere else. If any good ones slip through, the management style probably matches the self-centered hiring style and they’ll leave soon enough too.

Being a self-centered employer is a great way to laser-focus your hiring to the bottom of the barrel.

Unsurprisingly, there were a lot of reactions to my recent article that sounded like:

“Arrogant, condescending and otherwise mean programmers are NOT good hires even if they can code.  I concede that ability to code well is also vital, but you cannot settle on either point.”

And, I agree.

But the fact is that most companies do settle.  The superstar programmer who codes well, is highly productive and gets along with everyone is extremely rare.  And even if you happen to find him, he’s also extremely expensive.  It’s safe to assume that you are not hiring programmers who are both highly skilled and highly personable.

Good or Bad Egg Detector from Willy Wonka

In fact, if you’re a company that’s not well known and paying at-market or below, you’re actually getting the worst programmers.  It’s the ugly reality that most hiring managers would rather ignore than face.  And when you ignore a risk, you cannot mitigate it.

So what are your options?  The most obvious options are to require strong technical skill but settle on less-than-ideal soft skills, or to hire a great culture fit who can’t code well.  It’s not a black and white option, but a spectrum in which most people fall in the middle.

I’d recommend hiring on the side of “codes well” every single time but that’s not what companies do. Instead, they screen for the ability to write buzzwords and communicate in the cover letter and resume.  And then they screen for culture fit and background fit in the phone screen.  And then they screen for culture fit in the interview.  And then they ask a few open-ended technical questions and call it a day.

In depth verification of technical skill is extremely rare and is usually implied from past experience. The hiring process is setup to allow in programmers who are a good culture fit but who cannot write code.

There is another option of hiring a promising bright CS grad and grow them into a superstar which is used by most of the big software players.  The downside of this approach is that takes a great deal of time and money to identify them, recruit them, train them and then keep them once they’re extremely valuable on the market.  The majority of companies cannot pull this off.

The very last option is to wait and hire no one until that perfect someone comes along even if that means postponing work.  It’s what most programmers claim they would do, but it’s not what they actually do as managers.

And as a manager, it makes sense.  You’ve got work to do.  Deadlines to meet.  Hiring requisitions to fill.  Impending hiring freezes to beat.  When you’re in the hot seat, there is pressure to hire and not making a hire can appear like a failure on your part. Unless the organization is setting incredibly high standards from the top, you will appear unreasonable and will likely be superseded.

If you want to wait for the perfect fit, I applaud your stand, for however long you get to keep it.

If you want to build an expensive programmer garden to grow your own, go for it.

If you want to only hire for well known companies and ones that pay out the wazoo, you may not experience this problem (but don’t count on it).

But if you’re like most hiring managers, your pool of candidates, your hiring time line, the work they will do and their salary range are all fixed, known quantities over which you have little control.  What you can do is structure your hiring process so that it favors programmers’ technical skill over culture fit.  What you can do is hire programmers who can write good code.

When hiring a programmer, the only thing that really matters is their ability to write good code. Finding people who can do this are so rare that it’s generally preferable to excuse any personality quirk or deficiency they have.

As soon as I say that, a huge number of people will comment that it’s wrong, wrong, WRONG. Good programmers need to have communication skills and be able to work with others.  There is no I in TEAM! In fact, they would argue that it’s better to compromise your skill requirements in order to find the right culture fit.

It would be nice if we could say: don’t hire until you find someone with both great technical skill AND great culture fit.  Except very few of us have that luxury, except maybe Google, and even they are in a constant state of desperate-to-hire-programmers.  If you decide to wait, expect to wait for a very long for each hire, even while your businesses crashes and burns in need of a programmer.

So, which is it?

Let’s consider the mediocre to poor programmer who is amiable and works hard. His code isn’t good – it doesn’t really do what it’s supposed to do and even when it does, it’s sloppy and hard to maintain.  He struggles with basic functionality and is not able to tackle complex problems at all.  But he does get along with the team and the project tracking tool is always up to date and he gives plenty of butt in seat time.  You’ll be alright for a while because your managers will be happy to see such a smooth-running team.

When releases are slipping and the product is too buggy to use, people will lament that software is just so hard and throw more mild-mannered mediocre programmers at the problem. And we all know how this story ends.

For programmers, there is no amount of nice that makes up for getting things done.  A friendly mediocre programmer can become a business analyst or a technical salesperson or some other thing where he can leverage his friendliness and his bit of technical knowledge.  Working with them may be pleasant but it is a tea party, not a smart way to build good software.

The other option is a programmer who delivers great code and maybe doesn’t get along so well with others or comes in late or whatever. He builds an application that does what it is supposed to do and abstracts complex problems into simpler ones.  The software works and is maintainable enough to change it when needed.

This is the real world and there are plenty of ways that things may still get all screwed up, but at least you have a chance.  Good presentation skills are nice.  Team building is nice.  Employees working long hours for you is nice.  Plenty of businesses don’t do these things and still succeed, but no one succeeds at building great software with crappy programmers.

The proof is in the code. That is all.