9 Things That Turn Off Developer Candidates
Tech hiring is hard. I’m here to share some things that I noticed developers don’t like. I’ve been in the industry for 15 years and have gathered plenty of insights from developers all over the world, and surprisingly, there’s a lot of commonality. Here are some of the biggest mistakes that companies make that result in candidates churning at the screening phase.
Let’s get right into it.
1. Customize “hard skill” assessments to the level of the role
Don’t send a basic level assessment test to a senior candidate. Just like anyone who has tons of experience, they want to have the opportunity to crush a task that is on the edge of their skills—something that’s challenging. Bonus points if you find a task that properly assesses the candidate without involving too much of their time.
I’d like to back-track and encourage you to think about whether a test is needed for the candidate at all. You are actually risking a lot when you assume testing as a next step—candidates can decide not to follow up because other companies will simply not require this for senior candidates. I’ve found that attending a live coding session with the team that you’d be working with is far more valuable.
2. Tailor your process to the type of developer
There are multiple developer roles and thus multiple methods of testing each candidate. All developer roles that have distinguishable differences, here are some of the big ones:
- DevOps developers work with software developers, system operators (SysOps), and other production IT staff to oversee code releases.
- Backend developers build and maintain the technology like the server and database that powers the user-facing side of the website.
- Full stack web developers handle everything from user interface to backend systems.
- Mobile developers specialize in writing software for mobile devices like iPhone and Android.
I recently talked with a front-end developer who verbalized his frustrations around having to implement quicksort algorithm as a recruitment task—something he felt was unrelated to showcasing his full capabilities and skillset. The main point is—a “one size fits all”approach doesn’t work. Choose an assessment that’s appropriate for the candidate’s role.
3. Give feedback, even if it’s an early stage
Hiring teams rarely give enough feedback to candidates, and if they do, it’s for candidates who make it to later stages of the hiring process. Data from our recent Developer Report suggest there is more work to be done to deliver an optimal candidate experience. Candidates are still being “ghosted” and given irrelevant assessments. If your engineers don’t have time to give feedback to each developer applying for the role, consider using an automatic tool that streamlines giving feedback.
Here’s a clip from a recent webinar that sums up this point nicely:
4. Fine-tune the level of difficulty in code testing
Unless you’re organizing the International Olympiad in Informatics, avoid tasks that are knowingly too difficult for your candidate. Task levels are subjective anyways. For some of you, it’s really a matter of filtering out the weakest candidates. Others may want an additional signal that can be cited during the interview. For example, it makes more sense to ask senior developers about real-life problems in a collaborative environment.
Look for contextual data to help with your decision. Deploy an internal test to your development team and see how they score. Ask for their feedback and determine the task difficulty based on research. Is your task supposed to be easy? If so, then about 50% of candidates should score at least 90%. Thresholds will differ based on the level of difficulty.
5. Don’t assume a candidate will accept your offer
I went in for an interview once and everyone treated me like I was already an employee. While it was nice to feel included, they were pushing way too hard. It’s normal to have to compete for talent—there are plenty of impressive teams out there so remember you’re not the only company that a candidate might be talking to. Stay humble.
6. Beware of putting your development team on a pedestal
While it’s good to be confident in your team, too much of it can come off as arrogant. Avoid planting a seed in the candidate’s head that they aren’t good enough to be on your team. Rather, look for ways to ensure their position as an equal. Placing people on a pedestal will only create an inferior/superior relationship dynamic—a major setback in encouraging collaboration.
7. Be authentic and don’t overdo it on the “small talk”
Steer clear of using too many buzzwords. Focus on having a real conversation that has depth to it. Sometimes simple is better.
Don’t waste time talking about random things for long periods of time. A little small talk is fine so long as it’s important to the candidate. For example, it might be worth taking a few minutes to talk about shared experiences and similarities.
8. Try not to have developers interview with non-technical folks pretending to be well-versed
Candidates see right through it. It’s also not a strong filter to distinguish between good and great candidates. A developer once bragged to me about how he fooled a recruiter into thinking he's programming in Dumbledore language. If you’re needing to have non-technical recruiters hire technical roles, make sure they are equipped with the right tools that they need to be successful.
9. Be transparent about what the process looks like and don’t let interviews drag on
Try to shorten your process as much as possible without compromising the quality of your candidates. If you’re telling a candidate that you need seven separate rounds of interviews and that it will take several months, how do you expect them to respond? The minute I hear this I’m out. Sometimes consolidating interviews and scheduling all of them within the same day is the best option. Most importantly, communicate the process to your candidate in a clear and honest way.
To sum it up…
By avoiding some of the mistakes mentioned above, you can plan to deliver the best possible experience for your pool of talent and avoid complaints like this:
For f***'s sake, if you're going to include some kind of take-home coding test in your hiring-process make sure it has been carefully thought out: Narrow scope, don't require > 4 hrs of coding and *always* provide nice, detailed feedback, no matter the outcome.— Hans Westerbeek (@hwstrbk) April 2, 2019
*Posted by a software engineer on Twitter.
The hiring process should be streamlined but informative. Communicate with the candidate each step of the way. If helpful, start by asking yourself these questions:
- What are the different stages of the recruitment process?
- Who are the core people that the candidate should speak to?
- What are your key talking points for discussion?
- How are you scoring candidates?