The One Kind of Developer You Absolutely Shouldn’t Hire

Hopefully you won’t be able to spot the world’s worst developer the minute he or she walks in the door.

Because being able to quickly form that opinion means that you have been burned too many times by enough people who overpromised and under-delivered, couldn’t or didn’t do the job they were hired for, or did things so badly it made things worse for everyone.

Developers can be tricky positions to hire for – you may not know that someone has great or poor skills until they get immersed in a vital project.

Worse, some non-tech-oriented hiring managers may not ask the right questions or look at someone’s background thoroughly, so people with the wrong skill set may get hired.

To give you clues of what to look for – and sparing your company from discovering that someone wasn’t who they claimed they were – here’s some ingredients which could make up the ideal worst developer.

•   Rock star/ninja/programming god. Only consider hiring this superstar if or when your company is already hugely successful. Until then, it will be overkill. Dan Tynan from InfoWorld describes this as choosing between “bringing in Superman or bringing in the Avengers.” One hero may have mighty powers but the whole less-powered-but-more-cohesive team gets stuff done.

•   Great at old languages, weak at new. The candidate may have been a champ at COBOL long ago. But unless you’re hiring for legacy system knowledge, you should seek fresh knowledge. Even if they say they know a lot of old and new applications and programs, it’s remotely possible. It’s more likely he or she may be good at a few of them but generally familiar with others. It’s also possible they don’t really know many but wanted to include them on a resume/application and hope you wouldn’t check.

•   Iffy academic credentials. Laurie Voss, CTO at npm and a contributor to Quartz, shared that he eventually learned the hard way that advanced degrees from fancy colleges don’t necessarily translate to good developers. What works better, generally, is proven evidence of competence – writing code, shipping software, and completing projects. Bad candidates also could be at the other end – no formal credentials. Some certification programs don’t care whether you took a course or learned yourself. But even so, there is value in learning the foundations of programming.

•   Questionable employment history. A pattern of quick departures and many short-term projects may not look as good as someone who stuck around and worked on multiple achievements and long campaigns. Hiring managers should also not be star-struck by someone who worked at acclaimed places like Apple, Google or Microsoft – perhaps they did, along with thousands of others, or had different responsibilities than what you need.

•   They impressed you. Some candidates may come across as personable and well-spoken when they meet with HR or a potential supervisor. But inviting some or all of your tech team to meet them, look over their portfolio or past work is a good way to get a second opinion and alternate perspective. The opposite can also be true – your team may like someone who creates impeccable code and has designed amazing apps but can be tricky/prickly to work with, and they might not have the social skills you prefer for the local culture.

This is only the starting point, of course, especially if you ask other developers to add to your word picture of the worst developer around. There are clearly some universal traits and behaviors that everyone will be bothered by, and there are also some, well, more technical flaws like sloppy code that can make other better developers cringe — and make the rest of us say “we’ll just have to take your word for it.”