Rethink how you screen senior developers to produce better mentors

Common approaches to hiring

Historically, in hiring developers, there have been two main approaches. 

Coding assessments

First and most common is the coding assignment. 

Give the candidate a basic problem to solve in a language that is likely to be used on the job. "Code a basic to-do app in React/Angular/ Vue" is an example. The idea is to see whether the candidate actually has the skills required for the position. This is useful when hiring for entry-level or, sometimes, mid-level developers. 

Abstract questions

The second approach to hiring senior developers has been the one popularized by Google, where interviewers present the candidate with abstract questions to better understand how they think about and approach problems. Example questions from this approach include "Why are sewer covers round instead of square?" or "How many marbles can you fit inside of a school bus"?

What these approaches miss

With senior-level developers, you are looking for a different skillset than those evaluated in coding assessments or even abstract problem-solving questions. It's unlikely that someone with 8 years to 10+ years of experience has gotten that far without basic coding or problem-solving skills. Meanwhile, while abstract problem-solving questions can offer insight, they're more thought experiments than real problems your team is tasked to solve -- with all their necessary tradeoffs, considerations, regulations and standards.

At the senior level, developers need the ability to take on a problem the business is trying to solve, research the tools and frameworks they may use (and the trade-offs of each), and then architect a path forward.

But the most valuable skill -- unaddressed by either common approach -- is the ability to mentor junior- and mid-level developers up to the next level.

The importance of mentoring

Mentoring is one of the most important skills for a senior-level developer to have. The ability to grow the skillsets of developers so you can promote from within -- rather than investing in more expensive external hiring -- saves the company money and lowers the initial barrier to contribution. 

A mid- to senior-level developer who has been with the company for years -- possessing all that institutional knowledge -- is going to be able to make impactful contributions much faster than an external hire. The external hire will need to ramp up in understanding the tech stack, challenges and process.

Trying to devise alternative solutions

I worked for MassMutual as a senior developer for over 7 years. 

Several years into my tenure, a working group was formed to set and standardize how we evaluated senior-level developers during the hiring process. Having been through a fair share of interviews -- from both sides of the table -- I was excited to take on this challenge and volunteered. 

We identified the common approaches above. We collectively commiserated about the inherent problems, specifically with the coding assignment. 

One of the big challenges in hiring for MassMutual was that, although we were a Fortune 100 company and had good pay and benefits, we weren't as exciting as a startup in a cutting-edge field or the FAANG companies. 

One of the main drawbacks with coding assignments is that they can weed out candidates not in aptitude, but using friction. Going through multiple rounds of interviews is a lot to ask of any candidate. Including an assignment that might take several hours, for free, compounds the issue. Some of our members noted assignments they'd been assigned during hiring for other companies that took an entire weekend.

So, imagine you are a talented, highly desirable senior-level developer candidate, and you're presented with an assignment that will take a significant amount of time for a company that isn't that exciting to you or doesn't look as impressive on your resume. It's very easy to just move on to the next opportunity when given that high level of friction to continue. We were worried -- and had some anecdotal evidence -- that we had lost promising candidates exactly this way. While we had strong referral pipelines, we didn't know who else we might be missing out on.

Probing how they think about solving problems

With all this in mind, we began exploring different approaches. One was identifying more directly applicable problems rather than abstract ones and seeing how they would approach it. Below are some examples:

• "Imagine you're building a design system that all application teams at the company will use. What are some challenges you expect around configuration, variants and branding? How do you solve for those? How do you navigate the needs and viewpoints of design, development and business?"
• "Accessibility is required in all our components. What approach would you take to test this? What tools would you use at different steps of the process?"
• "How would you design and build a calculator to determine how much life insurance someone needs? What challenges and tradeoffs would you consider not knowing what type of device they were on (phone, tablet, computer)?"

This idea was useful, and we did come up with a list of questions that teams might use. Out of this, though, came the realization that this approach was only looking at a small part of what a senior-level developer's day might contain.

In talking together, we collectively realized there are large parts that are rarely explored. One was working with business analysts and product owners, going through requirements to be laid out in tickets and the technical tradeoffs involved in solutions suggested. The second was code review.

Evaluating their approach to reviewing code

Code review is often an underappreciated task by those outside of the development team. When done correctly, it enforces standards, minimizes tech debt, promotes commenting, which can be invaluable when code is refactored or examined later, and, most importantly, mentors developers.

A good code reviewer understands it's not about making a pull request perfect. That can be frustrating for other developers because "perfect" is subjective. The best way I've heard it explained is to try to bring the code up "one full or partial letter grade". So, if a developer submits a pull request you would perceive as a C, offer suggestions to get it to a B-. Done well, code review is more than just dictating changes. It's asking questions so both you (the reviewer) and the submitter understand why this solution was proposed. For example:

• "Why did you choose X method over Y method here?"
• "Are you familiar with this function that does something very similar, and can that be used instead of writing a new one?"

Sometimes this results in the code being rewritten because the submitter wasn't aware of an alternative solution. Other times they were, but some challenge prevented them from using it. The latter is where commenting becomes useful. A few sentences saying something like, "We had to do X instead of Y because of Z," can help the submitter communicate with the reviewer and prevent future bugs.

Code review is more than just dictating changes. It's asking questions so both the reviewer and the submitter understand why this solution was proposed.

When someone comes back to the code in 6 months and again asks, "Why didn't they just use Y? I'm going to just use Y," without the full context, the comment clarifies that and saves churn for the team, especially QA.

As a result of these discussions, we started to coalesce around the idea that instead of a coding assignment, we present them with a pull request -- along with some basic requirements that the feature was building for -- and see what kind of comments our candidate would give the submitter. We considered the issue we identified of not making it time-intensive to drive them off. The pull requests/features would be relatively simple but have several identifiable areas for improvement. 

What are the benefits that this approach gives you?

This proposal presents several interesting information avenues:

• Do they focus on the same things we expect? 
• Do they see something we don't? 
• How do they approach offering feedback? 
• What "tone" do they adopt? 

It takes a subjective approach to problem-solving

These questions all stem from problem-solving questions. How do they solve a problem rather than just offering a solution? Since code review is more subjective than solving a particular problem or feature, which may only have a small number of solutions, their general approach to problem-solving matters more. On top of that, AI tools like Claude have started to raise the idea that writing code is less valuable than being able to understand, review and edit it -- you are shepherding the agent, just like you would a junior developer. 

It suits legacy application development and maintenance

It's also important to understand that you are not building greenfield projects or applications but are working on mature ones with existing code, features and frameworks. When someone writes a to-do app from scratch, they don't have to consider any of that. By contrast, reviewing a pull request involves trade-offs and constraints that require critical thinking when offering feedback.

Conclusion

So, the next time your company is trying to hire a senior-level developer, instead of the traditional coding assignment, maybe present them with a problem you're trying to solve in an upcoming sprint and ask them how they might approach solving it. Create a dialogue where they can ask questions to get context on what already exists in your application and frameworks. Have another developer pair with them on an open pull request and do the same -- allow them to ask clarifying questions, see what they focus on and what suggestions they offer.

Recruiting is stressful from both sides. Making it conversational, rather than like a test, lowers barriers and builds rapport, allowing both parties to understand each other more deeply. 

This may be a deciding factor in a candidate picking your opportunity over another, which, for a position that is challenging to hire for and expensive to hire poorly for, is incredibly valuable. 

For the interviewer, this approach paints a more authentic picture of the candidate and how they'll interact with their colleagues -- something that doesn't traditionally come across during an interview process.

Eric Rocha is a professional and freelance front-end web developer with over 15 years of experience. He writes extensively on his own site as well as contributing to Informa TechTarget.