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.