What to look for when hiring a software developer

Like most people that have been in the industry for a number of years, I’ve been on both ends of the hiring process; both interviewing candidates and being interviewed. Conducting an interview and deciding which candidates to hire is incredibly difficult because there are a multitude of red and green flags to look out for. Hiring a software developer is even more difficult mainly because so much of the value that a developer provides is intangible i.e. their talent and personality are difficult to measure.

There have been cases where I’ve sat on interview panels, where we all thought the candidate was fantastic, but proved to be a nightmare to work with once hired. Obviously a similar situation arises when choosing which company to work for, but that’s a subject for another chapter. Here I’ll cover a few mistakes that I’ve noticed being made during interviews, as well as a few things you should be looking for when hiring.

Mistakes in interview process: here are a few mistakes I’ve seen companies make in the interview process.

• Technical assessment before culture fit/personality interview: as far as I’m concerned, testing someone’s technical abilities before getting to know them is like having sex with someone before even talking to them. Some people might be fine with that but I believe that it might set off a red flag to some candidates and as a result you might lose a few talented ones that could have otherwise been great for the job. As a candidate, this approach would tell me that the company doesn’t care whether they’re hiring Mother Teresa or Adolf Hitler as long as they can get the job done. Chances are that a company like that will already have a few Adolf Hitlers roaming around, and that’s not an environment I would personally work in. Some companies might defend their position by saying that they will still have the culture fit interview after the technical assessment, and they’re choosing this approach in order prevent wasting time on people that are not technically competent. That’s fair enough, but at the same time it clearly exhibits the company’s priorities and as a result some candidates will feel that in a company like that they will be treated as disposable “resources”.
• Theory based technical assessments: I’ve seen software developers (and people in general) that are exceptional at learning theory but are useless at putting it into practice. People that are great at memorising large amounts of theory might excel in some professions like law and maybe even medicine, but software development is not one of those professions. For example, I could take a programming book on C# for instance and give it someone asking them to read through the entire book, perform all the exercises and learn the C# syntax. I could thereafter give the same person a test asking them to write an if statement, while loop, create a class, name all the different accessibility modifiers, tell me the difference between an interface and an abstract class etc. Having read and memorised the book, the person will pass the test with flying colours even though they’ve never developed a complete app in their entire life. When hiring a software developer you shouldn’t be looking for someone that can talk about software, but rather someone that can actually develop software. Moreover, software development is more than just hacking a few hundred lines of code together, instead it’s about developing complete applications that could require thousands of lines of code. Hiring someone simply because they have the knowledge means nothing if they can’t actually put it into practice.
• Skills based technical assessments: the company may be missing out on some really talented candidates if they’re filtering out candidates simply based on a specific skillset. For example, you could have a candidate that’s a genius but they’ve never worked with a specific technology used in the technical assessment. As a result the candidate will be filtered out without being given the opportunity to impress you with their other abilities. For example you could have a software developer that is brilliant at C++ but the interview is for a Java development position. Obviously hiring this candidate will involve a learning curve, but if they’re talented they will learn the Java development stack and become productive relatively quickly. On the other hand if you have a candidate that is an average or poor developer and only knows Java, he/she may be hit the ground running almost immediately but will never learn anything new and the Java code he/she writes will be terrible.

What to look for in a personality interview: knowledge and skills in a specific domain are obviously important and useful for a candidate to hit the ground running. I would definitely look for skills when hiring a contractor for a certain timeframe on a given project. However, when looking to hire someone permanently you are effectively making an investment in this person and expecting to get a return on that investment. If you’re only looking for a specific a skillset the person may deliver on a given project but may not necessarily deliver on the next project if a different skillset is required. For this reason I find it futile to hire people for specific skills and knowledge. More importantly knowledge and skills can be learnt by pointing them in the right direction, giving them a book to read, sending them for training, or even sitting down and teaching them personally. However, there are a few things that you cannot teach or change about a person and so these are some of the attributes I like to look for before I even think about doing a technical assessment:

• Personality: when given the choice between working with a highly talented asshole versus working with a nice guy that needs a bit of training, I would chose the nice guy over the asshole every time. The reason being that you can teach skills but you can’t change an asshole. It’s that simple. Test: This is obviously something that is very difficult to test, but through experience in dealing with people you can get a pretty good idea of the kind of person you’re dealing with by simply having a casual chat and asking about specific cases in which they dealt with conflicts in the workplace and how they handled it. If budget allows, you could even ask them to complete an aptitude test with a qualified psychologist.
• Analytical: a person can have all the knowledge in the world but if they are not able to logically analyse a problem, troubleshoot and come up with solutions, they will never make it as a software developer. Being analytical is something you’re born with; you either have it or you don’t. Test: The first thing I look at are their exam results from school and/or university, specifically on subjects that required logic reasoning. I wouldn’t care too much about their test results on theory based subjects such as Geography, History or even certain IT related subjects like Databases, Operating Systems, Networks etc. Instead I would specifically look at their results for Maths, Physics, Programming and other subjects that required solving equations like Electrical Engineering, Electronics, Digital Systems etc. If I had to chose between a candidate that had below average school results with two years experience in C# versus a guy that has never written code in his life, but was an A student in Electrical Engineering, it would be a no brainer i.e. I would hire the Electrical Engineer to work as a Software Developer. The reason being that Electrical Engineering is an incredibly tough course and completing it with As tells me beyond a shadow of a doubt that the he/she could learn to code relatively quickly and will deliver excellent results.
• Inquisitive: in the world of software and technology things move very fast, with new technologies popping up every day. It’s obviously impossible for a software developer to know everything, but what you should be looking for is a candidate that is inquisitive and enjoys learning new things all the time i.e. as opposed to someone that sees learning as a burden/work. Test: if you do a bit of research you will find that there are various ways of assessing whether someone is curious or not. The easiest way is to ask them at the end of the interview whether they have any questions for you. People that are inquisitive will ask a lot of questions, while others might only ask one or two questions just to show interest.
• Quality of work: there are certain jobs that require people to complete a set of tasks to be productive. Some examples include a warehouse worker who moves boxes around the warehouse, a driver who has to do deliveries, a cashier in a store, an accountant who needs to process salaries, or even a businessman/salesman who needs to make X number of calls per day, close deals and reach a target by the end of the quarter. What all of these jobs have in common is that it doesn’t matter how the job gets done as long as it gets done. Software development and engineering in general is not one of these jobs. As an engineer you are not just performing a list of tasks, but creating products. The products created will be used by endusers who expect and are willing to pay for a certain level of quality. Therefore how you do the job and the quality of your work is not just important but critical. Obviously there are times when engineers work under financial constraints which limit the time required to achieve excellence. Nevertheless, you should look for candidates have some of the following attributes, which I believe makes them produce quality work:
  - Pride: nothing irritates me more than an engineer that has an “it’ll do” or “it’s good enough” attitude. When you’re creating products “it’ll do” is just not good enough. There is no substitute for people that put pride in their work and that’s not something you can teach i.e. you’re either born with it or you’re not. Ownership: a simple telltale sign that someone puts pride in their work is to ask the candidate how they feel about code sharing i.e. someone taking over their code and/or modifying it. People who put pride in their work take ownership and accountability for their work, and generally have an emotional attachment to what they produce i.e. it’s like their baby. Having someone come in and take over and/or “damage” their “work of art” infuriates people that take pride in their work. People that do not take pride in their work are quite happy to let someone else deal with their mess. I know that many managers actively encourage code sharing in their teams mainly because they see the developers as just “resources” which they allocate to projects and codebases. I think that’s a terrible mistake on the manager’s part because it discourages ownership, accountability and above all reduces the quality of the code. Neat & tidy: I’ve seen software developers in interviews that are incredibly bright, knowledgeable, confident, well spoken etc. But when you look at their code it looks worse than a dog’s breakfast. They simply don’t care how the code looks, they only care whether it works or not. If these people leave their job and someone else needs to takeover their codebase it will be a nightmare for the next developer who needs to deal with the mess. The only way to test for this attribute is to look through some of their existing code.
  - Eye for detail: a software developer that doesn’t have an eye for detail is like a blind sniper i.e. they will create a ton of bugs and produce shockingly bad quality software. You cannot teach someone to have an eye for detail so don’t bother hiring such a candidate into a developer position. You could instead put them in a support role. Present a vague problem: the easiest way to test for this attribute is to verbally present the candidate with a feature request or a problem to be solved. They need to provide you with a solution of how they would solve the problem. Your description of the feature/problem needs to be quite vague with limited context. Ensure that you provide at least some sort of context. A candidate that has an “eye for detail” or detailed oriented will begin by drilling down into the problem asking you a million questions for clarification. You should obviously be prepared to provide those details. Pay careful attention to the level of detail they provide when proposing the solution. Give them the opportunity to write down the proposal since most people cannot present a long but structured solution verbally. A candidate that doesn’t ask for a lot of details will not able to provide details in their proposal, and will obviously only reply with vague solutions to your problem. Email exchange: if working through a recruitment agent, you may not always have the opportunity to exchange emails with candidates. If however you do have a few email exchanges, pay careful attention to the length of their emails and the level of detail they provide in their replies. In my experience, people that write long winded but coherent emails are generally very detail oriented. Obviously it depends on the subject of your emails, therefore try and ask some detailed questions, which would required detailed responses. People that consistently reply with a single sentence to your emails are not detail oriented and probably never will be.

Technical assessment: once the candidate has passed a personality interview and you’re happy to take it further, you can then conduct a technical assessment. As mentioned previously I’m not a fan of theory and/or specific skills based interviews. Here are some of the best approaches I’ve seen in technical assessments.

• Develop an app: a great option is to give the candidate a set of requirements to develop a full application. It doesn’t need to be anything complicated or incredibly time consuming, but it should require them to spend a few or more hours writing enough code that you can see their coding habits. The requirements must be such that it will require writing more than just a single function or algorithm. Also do not force them into writing in a specific programming language or technology stack, since you want to them to use whatever they feel most comfortable with, which will enable them to showcase their skills as opposed to have to learn a new language just to complete the assessment. The requirements for the app should also not be too constraining since you’ll want to give the candidate the opportunity to demonstrate their creativity. Since this exercise might take more than an hour or two, you can let the person develop the app in their own time and submit it when they’re done, which could be even a week later. To ensure that they did in fact write the code themselves without help from others, you could ask them to come back for code review.
• Code review: the easiest way to ensure someone can actually code is to look at their code. One option is ask them to develop an application as mentioned above and then do a code review on that. However that can prove to be very time consuming for both you and the candidate, especially if you’re interviewing multiple candidates at the same time. An easier method could be to ask the candidate to take you through one of their existing code bases. Some candidates will say that their code is owned by their current or previous employers and cannot be shared with you. If that’s the case, don’t bother hiring the person because any developer worth his salt will have their own code that they work on in their spare time. Once they have agreed to show you their code, you could of course just look through it by yourself, but to ensure that it was written by the candidate and not someone else, it would be wise to have a code review either face-to-face or via a conference call. Ask them as many questions as you can, paying careful attention to how they’ve structured their code, whether it’s object oriented or procedural, the design patterns used (if any), whether it’s neat and tidy, easy or difficult to read, and ask them specifically about which parts of the code they struggled with the most.
• Pair Programming: there’s a quote attributed to Plato where he said that “You can discover more about a person in an hour of play than a year of conversation.” I wholeheartedly believe in this. The quickest way to get to know a person is by working with them as opposed to just talking to them. The surest way of seeing the how someone works is to work with them even for just an hour or two. Give them a problem to solve or a feature to develop and then sit with them working through the problem together. You will immediately see their personality coming to light as well as their many other attributes such as troubleshooting and communication skills, work ethic, perseverance and ability to come up with new ideas. In the process, the candidate will also have the opportunity to learn something about you and what it would be like to have you as a colleague and/or manager. In the end if you extend the job offer and they accept, you’ll know that the decision was based truth and not merely on perceptions you have of one another.

In summary, you should always aim to hire software developers for talent and train for skills as well as paying careful attention to personalities.