I’m going to ask a simple question and I want you to pay close attention to how you react, your anxiety level, and whether a welt grows in your throat: Have you ever tried to hire a software developer?

As an entrepreneur or CTO, it can be very stressful hiring developers because it can feel like you are betting the entire future of your business on the skill level of a sole developer or a small team (budget willing). Shouldering a fledgling business with that kind of risk is akin to flying the company to Las Vegas and betting the entire business on a single all-in hand of Texas Hold’em. This sounds like a crazy idea, but this kind of bet happens more often than most entrepreneurs would like to admit. Without first learning how to recognize good developers from the rest of the lot, any entrepreneur is bound to select the wrong developer then end up behind schedule and with an inferior product. So how can you identify the good from the bad? Continue reading and we’ll explore just that. You’ve got a business idea and maybe you even convinced a VC to give you some money, but now its time to put rubber to the road and begin building your product and finding the right developer to hire. Recruiters can help find talent, but at the end of the day you are left with a stack of resumes, LinkedIn profile, and referrals. How do your sort through it all to find the diamond in the rough? There are developers who name drop every hot technology and look amazing on paper, but can’t coherently get through a technical pre-screen. There are developers who write code that looks like this. Then there are the Good Developers ™ out there who love writing code, love learning new technologies, and take pride in their work. Since we’re talking mainly about trying to avoid hiring the wrong candidate, lets focus on some common developer personalities that should be avoided.

The Search Engine Robot

This developer will tell you things like “let me get back to you on that” and then prompty jump onto their favorite search engine or coding community. This activity isn’t enough to merit an outright rejection because no developer can possibly know everything, but just be wary if a pattern emerges. Let’s say you’re in an interview situation and ask a question like “What is an Object in Ruby” the candidate should know this off of the top of their head. When asking high level questions, if a candidate does not know how to answer basic questions without the use of the internet, be cautious. At best it means this candidate just didn’t prepare well for the interview. Far more likely, this candidate doesn’t know the technology very well and is probably not a good technical fit. Be careful when hiring Search Engine Robots.

The Non-Tester

Unless your organization makes a culture out of not writing tests and shotgun coding, this developer will not be a good fit. That being said, I am horrified and amazed at how many software development shops, including very large companies, still do not make automated testing a part of the software development process. I know from personal experience because I have had to rescue my fair share of fairly large Rails projects where there wasn’t a test suite at all. I have worked with teams where I wrote tests for my code, but was constantly fixing the test suite because other developers write their own tests and would routinely introduce errors. In short, if a candidate can’t write coherent tests or express that they like to manually test code, you are talking to a Non-Tester. Make sure to cut the conversation short and keep them very, very far away from your business.

The Ugly Coder

Code doesn’t have to look pretty to be functional, but it sure is helpful when another developer comes along and needs to make modifications or debug the system. A high quality candidate understands that following Best Practices is an integral part of building a code base that is maintainable, scalable, and can be transitioned to other developers at any time. However, if you hire a developer who writes code that is difficult to understand and ignores common conventions, its just going to cause issues down the line. This is why highly effective development teams rely on Pair Programming, Code Review, and Pull Request based workflows…to insulate the mainline code from the whims of The Ugly Coder (or just a naïve Junior Developer, to be fair).

The Protester

This particular personality trait won’t appear until after the offer letter has been signed, but it is possible to catch before its too late. So how can you spot this type of person ahead of time? The best way is to sit this particularly fine specimin down and ask them to fix someone elses code. Most systems have a bug backlog, so why not throw one at them in the interview? You get a bug potentially fixed and also get to see the candidates trouble shooting process. If at any point this developer says negative phrases like “who did this?” or “how could so-and-so release this code this way,” you are dealing with a Protester. A developer is not sitting down at the keyboard to pass judgement on others. Perhaps there has just been an honest mistake or a junior developer just didn’t know any better? Either way, looking in the rear view mirror trying to place blame is a quality that will be toxic to any team environment. Quickly take note of this personality trait, and make sure that it doesn’t get out of hand. No one likes “That Guy” on their team and hiring a Negative Nancy could mean the exit of your more skilled, more easy going, and less troublesome employees.

The Perfectionist

My way or the highway. This is all they know and they sing it all day long. Their idea versus your idea. Their architecture versus yours. This person will not relent until they are validated as being right and their ego is properly placed on the pedastal it deserves. Pull Requests will never get merged because there will always be something that needs to be changed. Remember, with the Perfectionist its less about the customers, the business, or the stakeholders. It’s about winning every philosphical battle, ensuring that no one deviates from their way of doing things, and feeding their ego. Avoid the perfectionist at all costs. Odds are this person will ace all technical interviews and deliver amazing code, but it will take them twice as long as it should. They will become a drain on the bottom line and will be the first person to crumble under deadline pressure. This person is not good for the team, regardless of how much experience they bring to the table.

The Good Developer

A good developer has a combination of traits, including learning ability, curiosity, desire to help others, and consistently delivering business value. The good developer knows the importance of testing, soliciting feedback from others, and is generally a team player. If any developer in an interview begins to talk about business value, keeping customers first, and treating their fellow coworkers with respect, lean forward in your chair and pay very close attention to this candidate. This is a rare specimin indeed and should be paid very close attention.

Are there any other traits I missed? How do you hire developers?