If you’re reading this, you’re probably a development lead or someone else in charge of interviewing or hiring development staff. This article is based on my experience, what has worked for me, and what I’ve noticed other people doing that doesn’t seem to work. I’m not going to pretend that I’m an expert on this topic, but I feel as though I’ve got some thinking to add to this topic, and hopefully, this will strike a chord with people who are trying to find talented developers.
What Makes a Good Software Developer?
The question can only be answered subjectively. Everyone who attempts to answer this question will bring biases to the table, and I’m not exempt. However, I notice a pattern in the way most interviewers think about this question. The most common things that I see interviewers focus on in interviews are:
- Knowledge. How much has the person committed to memory, and how many different technologies have they used?
- Use of common patterns. How closely do they follow prevailing patterns habitually?
- Performance under pressure. How does the person perform in a stressful situation?
- Ability to argue a point. How effectively does a person defend and justify their choices?
- Speed. How quickly can the person punch out a task?
When we look over this list, it doesn’t seem to fit the bill for a way to determine whether or not someone is a good developer. Most of these questions are going to be somewhat relevant to how good a developer someone is, but a person could nail all these areas and still be a lousy developer. Conversely, someone who only ticks a few of these boxes could be an excellent developer.
I’ve worked with talented developers that don’t perform well under pressure, shy away from debate, are slow, or do not stay updated with the latest technologies and patterns. The qualities that I’ve noticed in good developers are a passion for development, attention to detail, ability to take an idea from conception to fruition, critical thinking, open-mindedness, ability to learn, and the ability to work well with others. Good developers may not know everything, but they are determined to learn as much as possible. They may not memorize every pattern by rote, but they can weigh up the pros and cons of new patterns when they encounter one. They may not be able to solve a problem on the spot, but given a chance to think and research, they will come back in a day or two with well-considered potential solutions.
If I’ve lost you here, and you disagree with this sentiment, then perhaps the rest of this article is not for you. You won’t be alone. For others who think I might be on to something, please read on.
My Process
This isn’t meant to be an authoritative guide. This process works for me and has helped me find good developers. Some developers get overlooked, so this process may help to find people who are just waiting for their opportunity to shine.
The Resume
A resume should not be given too much weight. It should be clear, concise, and should highlight experience and skills. Taking the time to format the document and correct grammar and spelling shows that the person cares about what they are submitting, but it could be misleading to place too much emphasis on this. Some people may not have experience with writing resumes. Look for how they express their desire to build software. Do they want to be a developer because they are passionate? Or are they driven by career only? Passion shines through on some resumes, and this tends to indicate a good developer.
Look At Their Work
I’m convinced that this is the single most overlooked part of the hiring process. I cannot believe how many hirers ignore Github pages. A developer’s Github page can give you a wealth of information about the developer. What work do they choose to do? How do they decide to go about it? How much care and attention do they pay to their work? How do they present it and respond to feedback? Look for developers who pour passion into their work, pay attention to feedback, and spend time improving their code. These are the people you want on your team.
Informal Chat
Recruiters almost always do this, but hiring staff often skip this step. Candidates often find themselves in interviews where their goals do not match the needs of the team. Simple questions like “Do you like working in a small team?” or “Are you happy to work with Scrum?” can save hours at the interview stage if the candidate does not want to work in such an environment. I’m consistently stunned at how often candidates are called in for an interview when they are looking for a work culture that the team cannot offer, or will not be happy with the technologies used. Ask them open-ended questions about what they want to do and how they want to work. Look for people whose answers sound like your team and tech stack. If they don’t fit, then politely tell them that and end the process.
Assessment
Assessments are certainly not mandatory. They can come before or after the interview, but an assessment before the conversation can provide an opportunity to discuss the work. Assessments may be necessary for candidates who have less experience or don’t use technology that your team uses. I like take-home assessments with reasonable turnaround times. Some interviewers want to put pressure on the candidate during the interview, but this doesn’t seem fruitful to me. Look for the thought process and attention to detail.
Interview
By this point, you should be going into the interview with the impression that all things being equal, this person will become part of your team. If the person is a sloppy coder or doesn’t seem interested in the way your team works, then you should have been able to figure this out by now. If you weren’t impressed by their assessment, they probably shouldn’t be having an interview with you.
My two cents are that interviews should be friendly, and you should allow the candidate to talk as much as possible. Try to rid yourself of preconceptions of what the candidate should say, or what they should know. Listen to their story and focus on what they can bring to the organization.
Many interviewers deliberately make the interview adversarial. For example, a common first question is what the candidate knows about the company. This question can be framed in a friendly way or an adversarial way.
Friendly (friendly tone) :
“Have you had time to look into what we do?”
Adversarial (rough or aggressive tone):
“What do you know about us?”
When interviews take the adversarial route, they are setting up the tone for the whole interview, and expressing a sentiment. If the first few questions have a rough or aggressive tone, the message is “We’ve taken time out of our busy schedule to talk to you, have you paid the courtesy of researching us?”. This doesn’t send a good message about your team or the organization as a whole. This may be the candidate’s first impression of the organization. They may instantly develop a bad impression and lose interest in the interview before it even starts. I have no idea why interviewers would want to send this message, but they regularly do.
On the other hand, a friendly chat could open up a conversation about what the team does and how the candidate feels that they can fit in. If they are invited to speculate about how they think the team works, this is a good chance to see if their expectations match reality. Look for responses that show the candidate understands what you do, and is able to ask the right questions to increase their understanding.
Talking about the candidate’s assessment is a good idea during the interview. Look for an understanding of the problem and a decisive solution. This can elucidate their thought process further and may reveal that they had to take shortcuts for particular reasons. Attacking them, or dragging their decisions through the mud based on your preferences is a pointless endeavor. You may ask the question because you want to hear the candidate tell you what you want to hear - that they prefer the pattern that you love, but in this case, they weren’t able to use it for some good reason. Again, this is pointless.
People can’t always elucidate why they made a particular decision, but one surefire way to prevent them from doing so is to make it sound as though you have already made up your mind, and what they have to say is wrong. However, a good list of questions may include “If I asked you to solve the problem with x, how would you feel about that?”. This would tell you if the candidate is open-minded and willing to learn new ways of doing things. This is far more important than whether or not they can confirm your biases about how software should be built.
Pressure
It’s worth contemplating pressure in interviews. It is ubiquitous, and interviewers seem to want to ratchet it up rather than remove it. Why? You’re always going to hear the same tired response “Because we need people to be able to think on their feet.” But is it really so important that developers be able to solve a problem on the spot? If anything, I’d encourage developers to go home and think about complex problems before attempting to solve them.
Do you tell people in your team to smash out code after thinking about the problem for a couple of minutes? If the answer is yes, then I doubt your team is producing a quality product. If the answer is no, then I have to question the wisdom of expecting someone to produce something under pressure in an interview. What is it supposed to prove? Just because someone can perform under pressure, it doesn’t mean that they will solve the problem in the best way. Many good developers flounder under pressure, and by putting them through the wringer each time they show up for an interview, you are discouraging them and probably missing an opportunity.
Wrap Up
Interviewers regularly surround themselves with people who think as they do. This is a horrible feature of the software industry, and I feel as though it is one of the biggest obstacles for diversity. There are plenty of talented people out there that think very differently to you and the people you’ve surrounded yourself with. Have an open mind when hiring and treat people with respect. It’s not just about making them feel good - it’s about the impression of the organization that you give them. It’s also about finding the diamonds in the rough that can contribute a lot to your organization over the long run.