If you’re a software development team lead or project manager, hiring a new developer can be a hassle. If it doesn’t go well, it can not only cost you time and money, but it can also bring down your existing team’s morale and make some surprise withdrawals on your sanity savings account.
This article gives you a brief survey of some wisdom collected from the perspectives of both sides of the hiring coin. The software developer, your strategies, and perhaps most importantly, how the two fit together—these are the sources to watch.
Before you even start thinking about hiring a software developer, there are a few pitfalls you can already prepare against, which we cover in “The Experience.”
Once your organization is prepared for success with a software developer, we look at some potential “gotchas” you can avoid in the hiring process in “The Developer.”
But the bulk of the advice isn’t so one-sided: It has to do with the dynamic between the software developer and your organization, covered in “However the twain shall meet.”
So consider this list, for the sake of not only the success of your project and your organization, but also you and your hired gun as individual people. Let’s dive in.
The Experience
1. No Useful Trial Period
You and the software developer you hire both benefit from the additional screening of a paid trial period. Make sure they understand that you expect them to dive in just as they would if it were not a trial period, but that you also want to use the time for both of you to understand as much as possible about whether they will ultimately be a good fit. Give meaningful software development work and appropriate support, and keep your instincts active as you monitor their progress.
Along the way and/or at the end, have them evaluate their experience in a blame-free setting. Whether you hire them or not, this will be valuable information for both of you, going forward.
2. Poor Onboarding
The easiest way to get a software developer off on the wrong foot is to throw them into software development blindly, without support. Sometimes, to some extent, you might expect to be able to do this—in which case, it should be made clear before you even interview them. But even then, give as much support as you are able to, because this is an investment that immediately pays off in productivity and morale. (The flip side of this is that if your onboarding is lax enough, even small mistakes can turn into disasters. Even an expert software developer will need some time to get properly oriented to your environment, even if it’s less than what a junior developer would need.)
Give them a good sense of your work culture and expectations. Give an overview of workflows, team responsibilities, boundaries, and so on. Give them enough information and/or mentoring to get them working with the actual code base as soon as possible. Give them all the documentation you have, and where you don’t have it, use their experience as an opportunity to create some.
Find low-hanging fruit in your project to get the ball rolling for them. If possible, have someone review their code on these tasks as well–since they’re simple tasks, this should not be an undue burden on your team, but will provide invaluable information about any gaps between the work the software developer is doing and your expectations. It’s much easier to address such things sooner than later, and even with the most extensive instructions, every new hire is likely to need some time to get into the groove of your team and/or code base.
3. Unclear Requirements
The biggest hurdle you can avoid in the software engineering game is undue imprecision. Chances are slim that you will get what you want when you hire software developers if you are not clear about what that is. They are even slimmer if you yourself don’t even know.
So, communicate what you know with as much detail as you can. This helps developers better predict whether they have or can learn the right skills for the job. And make sure you know as much as you can to start with: Interview your main developers to find out what the key technologies and techniques are. Know at what level of detail they will need to work, from tiny code touch-ups to architectural changes. If your key developers left before you hired replacements, maybe some hints can at least be found on their resumes.
This may all seem like a bit of a pain, but it’s definitely worth keeping your stakeholders on the same page.
This is all assuming your candidate is approaching you honestly, which you hope you can assume most of them will be. But, this charitable assumption can sometimes be a pitfall, too, as we’ll find out in the next section…
The Developer
4. Resume Padding or Copying
This one’s not always easy to detect, but a little bit of internet searching can go a long way. If you find another resume out there with the same text, it’s not necessarily your person who is the copycat! There’s a great article about this on the Toptal Blog; particularly, we recommend the section “What if I hire contractors?” The advice there applies equally well to non-freelancer resumes.
Copying entire resumes is not the only problem. Some resume-padders are more subtle than that. Fact-check what you can. Any confirmed resume plagiarism or over-the-top exaggerations (e.g., if they claimed to have written a much higher percentage of a project’s code than they did) should be considered a major red flag at best.
5. Lack of Empathy
It can be a bit difficult to pick up on this in an interview, but a trial period should afford some opportunities to see how well a person relates to coworkers and/or clients.
In fixed software engineering jobs, this might be something that some workplace training could improve, but budgets don’t usually cover that sort of thing for freelance software developers.
Regardless, you’ll want to hire software developers who already have a decent amount of this sort of soft skill. Otherwise, be prepared to spend time helping iron out extra wrinkles in the social dynamics of your organization.
6. Lack of Temet Nosce
“Know yourself” is a pretty important meta-skill for a software developer. Of course, nobody knows everything, and the more you know, the more you know how little you know—so, to some extent, this is not a show-stopper. But a software developer should at least have an inkling of how capable they actually are of accomplishing a given task. (How long it should take is another story altogether.)
If you’re asking them to do something they’ve done before, ask what they would have done differently if they could have done it again. If it’s a new task for them, ask for their approach, and get a second and third opinion on it if it’s too technical for you to comment on yourself. Either way, ask them to “think out loud” as much as possible for this, and pay attention to their thought process. This can be a good way to glean whether a software developer has illusions of grandeur.
Leave open the possibility of a follow-up explanation, though. Software experts are human, too, and it’s natural to be nervous during an interview. Some who would do an excellent job might make some obvious mistakes during an interview, but would be more than comfortable and capable once on the job. That’s where the next pitfall comes in…
However the Twain Shall Meet
7. Ignoring Your Instinct
It’s a well-studied fact that our guts are worth listening to, whether or not there’s something definitive and factual to corroborate with. That’s not to say we shouldn’t analyze our own biases to keep them in check. If you have a strong feeling about a software developer not being a good fit, and this isn’t coming from a stereotype or preconceived notion, then you are doing everyone a favor to take it seriously.
(If you’re looking for some great stories exploring how the mind’s epic brilliance and horrendous failure can both be found in experiences of intuition, you won’t regret checking out Malcolm Gladwell’s book, Blink.)
8. Incompatible Expectations
Make sure you clearly agree on prioritization and other work boundaries, making your assumptions known. If you assume a new hire is on call for software development 24x7, and they assume they have weekends off, there will soon be unnecessary conflicts.
Before you hire a developer, talk it through. Be clear what’s no problem, and what’s a concession; invite this from them, too.
9. Consistently Poor Communication
No act of communication between any two people is ever 100% perfect. That said, if you notice that misunderstandings between your software developer and others on your team (or even just you, at the interview stage) are more common than average, and that they’re not tending to decrease with time, this may be an indicator of a bad match.
In most cases, it’s not a matter of fault, but of fit. If you’re able to address it with them, and they’re adaptable enough, it may improve—but chances are, finding someone who fits your communication style more readily will save you both a lot of headaches over the course of the contract.
10. Shoehorning
It can be tempting to hire software developers who are perfectly wonderful and capable candidates, even if they are terrible matches for the particular context where you need someone. This will likely help neither of you in the end. They would simply fit better elsewhere: maybe in your organization, but maybe not. The pitfall here is assuming that the candidate wants to and will be able to adapt themselves so drastically. It’s possible, but unlikely–so it’s very much worth asking further questions about this to give more opportunity for your instincts to chime in.
11. Excluding Good Generalists
On the flip side of the previous pitfall, this can happen if you obsess too much over finding the perfect candidate. Clear requirements are still important, as mentioned earlier, but insisting on finding someone who has experience in every last specialization, especially nowadays, is pure folly. Sometimes it will make it simply impossible to find anyone. Even if you do find some candidates, though, you may have excluded the best ones from consideration.
Sometimes a good renaissance developer will learn quickly and ultimately do a better job than a seasoned specialist. Not always, but don’t preemptively deprive yourself of a potentially better option.
12. Assuming Money Is the Only Factor
The wily economy, such as it is, sometimes tricks us into equating money with power. There’s some truth to it, of course, but money is definitely not the only factor driving software engineering. Will someone work 5x better for 5x the wage? Maybe, but not likely sustainably, if they also have to work in a toxic environment.
When you hire software developers, what exactly do you expect for your money? And what else do you offer, besides it?
Flexibility can mean a much happier software developer, but others may prefer a set structure. Work culture can make the difference between getting paid to do what you love, and the daily grind from Hell. Organizational values (expressed on numerous levels) can also be significant. After all, not-for-profits sometimes can attract great developers more affordably, because such work can give a greater sense of purpose.
12½. Neglecting to Learn from the Pitfalls Most Applicable to You
We hinted at this in the trial period section, but it also applies beyond that, to ongoing contracts: Provide a safe space and dedicated time for your developers to take a step back, evaluate their experience, and share about it honestly. Do this regularly (even if infrequently) and/or as needed (e.g., following an incident.)
Especially do this whenever someone will be leaving your software engineering team. Exit interviews are your opportunity to get the most candid and valuable feedback possible, provided they know that any criticism they give will not come back to bite them later. This can be one of the best ways to learn which software developer hiring pitfalls dog you and your team the most.
May the Workforce Be with You
Hiring a software developer can be a very effective way to throw money at a problem, but it certainly isn’t foolproof.
Sometimes the experience and environment you provide a developer just isn’t conducive to their productivity, nor to even noticing that anything is amiss. Other times, you’ll need to be on your guard against some undesirable qualities and practices in your potential hire.
Mostly, though, it’s a matter of continuing to hone your managerial instinct while keeping your biases in check. Does the software developer in question honestly fit the role and fit your team? It’s your call.
