The Impact of the Best Software Developers
A good software developer adds significant value to an organization. But a great software developer adds more than 11 times their salary in economic value.1 This guide will offer you advice you can implement right away in your upcoming search for the best software developers.
Prescreening
If you plan on hiring the best software developers, you will need to understand candidates on a deeper level. Unfortunately, it is often impractical to grant every potential candidate an interview, let alone a paid, week-long trial. Prescreening candidates with a simple, objective test can help you identify the ones that are worth a closer look.
Enter the tried-and-true “FizzBuzz test”…
The FizzBuzz Test
Question Type: Technical Skill, Expertise, and Experience
FizzBuzz Test: “Write a program that prints the numbers from 1 to 100. But for multiples of three, print fizz instead of the number, and for the multiples of five, print buzz. For numbers that are multiples of both three and five, print fizzbuzz.”
Though simple, this test will screen out a surprisingly large number of candidates.
Depending on the role you’d like to fill, you can try a couple variations. For instance, you can use a FizzBuzz test on each language required for the position.
In addition, it is easy to test if FizzBuzz code works. For example, in Python, you can find an online REPL and use it to run a candidate’s code, which may look something like this:
for fizzbuzz in range(1, 101):
if fizzbuzz % 3 == 0 and fizzbuzz % 5 == 0:
print("fizzbuzz")
continue
elif fizzbuzz % 3 == 0:
print("fizz")
continue
elif fizzbuzz % 5 == 0:
print("buzz")
continue
print(fizzbuzz)
If the output is correct, then they passed the test:
1
2
fizz
4
buzz
fizz
7
8
fizz
buzz
11
fizz
13
14
fizzbuzz
... etc.
Now, since FizzBuzz is a pretty well-known test, you may want to develop your own, similar test.
Another option is to incrementally introduce new requirements.
Interviewers could also make it less free-form by asking candidates to implement their FizzBuzz solution using your team’s particular software engineering architecture. This takes the FizzBuzz test to another level, screening out expert beginners, not just non-coders.
Once you have narrowed down your applicant pool through prescreening, you can begin assessing the remaining candidates’ traits to find the best developers.
What Makes a High-quality Software Developer?
What makes a software developer great? The best developers will have a combination of the following traits:
- Technical skill, expertise, and experience
- Leadership and initiative
- Dedication
- Team spirit
To help you assess these in your candidates, we have compiled a list of guidelines you can follow.
Pose Past Problems or Abstract Versions of Current Problems
Question Type: Technical Skill/Expertise/Experience
The best assessment of whether a candidate’s skills are a good fit to your organization is to see how the candidate approaches questions that your organization is currently working on or has encountered in the past.
Make a list of important current or past problems your organization has encountered. Remove details from these problems that are overly specific to your organization and/or cannot be concisely explained, so that a candidate can reasonably understand the core of a given issue. Pose these problems to candidates to see how they will perform on actual problems.
For example, imagine that you are developing a product for IT security managers. Your organization has spent several months creating a portal for these IT security managers to manage the product in their organization. You likely know the ins and outs of designing such a portal.
Ask candidates how they would go about designing such a portal, for example:
- Which language or framework would they use?
- How would they make the portal display in real time?
- How would they architect the relevant databases?
- What are some security considerations and how would they tackle these?
…while selecting the questions that are relevant to the candidate’s desired position. This allows a great understanding of your candidate’s technical acumen. Because you are experienced with this problem, you will be able to assess the quality of the candidates’ solutions and determine who is legitimately knowledgeable and skilled.
It’s worth taking the time to focus on a core architectural problem to see which algorithms and data structures the candidate would find appropriate, and why. General knowledge of the performance and storage characteristics of these choices is critical. Even if the developer will rely on standard library implementations in most cases, knowing the “big O” classifications of what’s executing behind the scenes will mean the difference between their work scaling—or failing.
Another important aspect of a technically proficient candidate is their ability and desire to mentor. Some software developers have great knowledge but are unable or unwilling to mentor others. They are apt to become overloaded with requests and can become a single point of failure to your organization since if they leave, it might be very difficult or impossible to pick up their work where they left it.
Assessing Coaching Ability
Question Type: Technical Skill/Expertise/Experience
Ask the candidate to explain a concept to you that you already understand.
The reason you should use a concept you already understand is that you will know if the explanation is helpful and correct. On the other hand, if you ask for an explanation of a concept you do not understand, you have no way of determining whether the concept is difficult, the explanation is poor, or worse, if it’s incorrect.
Are Their Goals Limited or Visionary?
Question Type: Leadership/Initiative
A key aspect of leadership is vision. Does the candidate have a direction and goal they wish to accomplish by joining the role you are offering? And is the candidate’s vision broader than themselves, e.g., encompassing the team or company? For instance, they might seek to solve a problem they themselves have encountered and look to make the world a better place. Having clear, big-picture goals makes individuals inspiring and magnetic.
Vision manifests itself in concrete ways in leaders—for example, in clearing the way for the engineering team to succeed by streamlining processes and managing bureaucracy. The engineering team can then focus on producing code and delivering an outstanding software solution.
Also, visionary leadership is often related to dedication: A software developer who exhibits the qualities of a leader will go the extra mile to overcome hardship and will boost team morale if hardship arises.
Outside-of-work Involvement
Question Type: Dedication
A great software developer doesn’t consider their job to be a chore. To them, it’s fun, challenging, and interesting. And that’s what you want from your developer—natural dedication and engagement. To get a sense of that, you’ll want to assess whether the candidate has the desire to go above and beyond the minimum requirements of the job.
Looking at their resume, is the candidate showing involvement and interest relevant to the job outside of their professional experience? For example, does the candidate contribute to open-source projects relevant to the position? Are they actively engaged in a meetup group related to the position they are interviewing for?
Another very important aspect to good hiring is for the hiring manager to take interest in the candidate’s goals and interests and make sure those align and expectations are met. Instances where an employee leaves soon after joining are all too common and usually a result of not understanding the interests of the employee.
Learning Your Candidate’s Goals and Interests
Assessment Type: Dedication
Since your goal is to hire software developers who will bring high-quality results to your development team, it’s important that their aspirations, goals, and interests are reasonably met so that they can be motivated and dedicated to the project. Note this carefully, because your goal is not to hire software developers who will do the minimum until a better opportunity comes along but ones who will be passionate about the job.
On the same point, there are well-documented cases in which hires have quit in a matter of months, with the hiring manager left confused. In such cases, both parties could have done a better job communicating their desires and listening to each other.
Evaluating a Candidate’s Approach to Teamwork
Assessment Type: Teamwork
Nowadays, participation in the broader online development community is standard fare for almost every developer. In many cases, this may mean collaboration on open-source projects (even just reporting issues), or helping other developers on Stack Overflow and dedicated programming forums.
Before the interview stage, it’s standard fare to google a candidate to find out a bit about their background. When hiring software engineers, it’s worth taking this a step further by exploring the public online communication history of a candidate:
- How do they formulate requests for help, or answers to them?
- When they leave comments, do they keep any criticisms constructive?
- How do they tend to approach disagreements?
If they’re often abrasive and burn bridges in how they talk online, is there a good reason to believe they won’t do the same within your organization? Assuming they’re still a candidate after this exploration, any yellow flags discovered here are worth asking about in the interview to help understand the candidate’s perspective.
The rare developer who isn’t active in online communities may still be a good team player. Straightforward interview questions will help you judge in this case:
- What are some past examples of development teamwork that they felt positive about?
- What are some that went awry, and how did they learn and grow from them?
The anecdotes that arise from these questions will give you an opportunity to gauge how the candidate might fit into—and affect—your team dynamic.
Tips
The following tips can greatly enhance your interviewing success.
Tip #1: Ensure Relevant Questions and Avoid Technical Minutia
Screen for effectiveness in the task you need completed, rather than breadth of knowledge. The basic rule of thumb for determining if something is technical minutia or a critical technical detail is the combination of importance and frequency; if a detail is expected to come up frequently or will have a huge impact, then it’s worth focusing on. Otherwise, a detail that is unlikely to ever come up—or even if it does, won’t matter much—is best kept out of the interview rounds.
Make sure your technical questions are as relevant to the position as possible. For example, if seeking a data scientist (who will mainly work in R or Python), it is best to not ask questions about the technical aspects of pointers and C++. Even though such questions might offer an indirect assessment of a candidate’s technical knowledge, they are more likely to screen for the wrong qualities. In addition, elite candidates may wonder why you are asking interview questions that have little relevance to the job position and if you understand what the work entails.
It’s also best to avoid programming language headscratchers and “gotchas.” These types of puzzles may stump even the best of developers and have little bearing on real-world work, especially when best practices are followed. Such questions are engaging academic exercises, but they don’t belong in an interview as a pass/fail test, where they will certainly put a barrier between your organization and great developers—even ones who can successfully answer them.
In today’s software development space, even specialized roles can involve knowledge of dozens or even hundreds of pieces of technology. Define a set of crucial elements in consultation with your current team, but don’t be deterred by the fact that candidates won’t have encyclopedic knowledge of your entire development stack. For example, it’s not important that they know the name and function signature of every date-handling function in the standard library of your main language. What is important is that they’re aware such things exist and that they should default to using them whenever working with dates. Besides, every software engineering role will involve some amount of on-the-job training and ongoing learning as the software landscape continues to evolve.
It’s not worth focusing on easily-looked-up syntax, either. If a compiler or linter will catch it, an interview shouldn’t. Instead, present the candidate a fully functional development environment and some simple code with a mistake in it. Then, ask them (without a visible time limit) to walk you through the steps they take as they debug it. Whether they need to google the docs is much less relevant than whether they succeed.
After all, even basic operators like ->, &, and . can have wildly different meanings between languages; developers who are expected to work with multiple languages are unlikely to keep these meanings straight 100 percent of the time, especially in the stressful context of an interview. The bottom line is, a simple hands-on debugging exercise will give you a much better sense of their basic abilities than a closed-book quiz.
Remember, your goal is to find great software developers. If a question or detail can be easily looked up or has no bearing on actual software development, it’s best not to use it to screen candidates.
Tip #2: Offer a Trial Period
A trial period is certainly an added expense that we would all prefer not to have, but it pays itself in dividends. In this era of remote work, a trial is easier than ever using effective remote tools like Slack and Zoom.
Start with the smallest tasks that require the least institutional knowledge, and therefore the least lost time for the new hire and the rest of the team. Assign aesthetic tweaks, minor bug fixes on low-risk, isolated parts of the codebase. If the relevant internal documentation is lacking, the new hire will likely find it; if the knowledge gap isn’t too large, they may even be able to help improve it.
Let new hires be part of code reviews, too. Their opinions in this context should highlight what they’re bringing to the team. But it can also reveal areas where their practices or personality may not be the best fit for your team, and how likely it is that that can be rectified.
Having to cut losses at this point is never an easy choice, but with carefully selected tasks for a trial period, your team and organization should at least come away with some work completed, plus increased self-knowledge that can be used for the next trial. Successful trials will also have partially onboarded the new hire and put them on firm footing to start ramping up their contributions.
Tip #3: Get as Many Opinions as Possible
Get as many opinions from your team as possible about your hire. Sometimes, it’s the quiet ones that have the most insightful things to say!
The reason for this is, it’s natural for people to relate to various individuals differently—and this is especially true here. For example, a nervous candidate might avoid conflicting opinions with those who will decide whether to hire them but be a little more comfortable being open with their future colleagues.
Whatever the dynamics may be, collecting as many people’s impressions as possible will more than likely help to reveal nuances about the candidates’ experiences and communication patterns. Either way, you’ll benefit from a more accurate picture of your candidates, and that will help you make the best selection when hiring software engineers.
Hiring the Best Developers for Your Software Development Team
You now have a great template to start with for looking for the best software developers. The most important idea to learn from this guide is that finding great employees requires being proactive and attentive. But like all worthwhile things, the prize is worth the effort.
1: Spencer, L.M. “The Economic Value of Emotional Intelligence Competencies and EIC-Based HR Programs.” In The Emotionally
Intelligent Workplace: How to Select for, Measure, and Improve Emotional Intelligence in Individuals, Groups, and Organizations,
eds. C. Cherniss and D. Goleman, Chapter 4. San Francisco, CA: Jossey-Bass/Wiley, 2001.
In a productivity study of computer programmers, above-average performers were 320% more productive than average programmers. Top performers were 1,272% more productive, adding economic value more than 11 times their salary.
