What I Look For when Hiring Senior Software Engineers

A couple weeks ago I shared what I think about when hiring junior engineers. Truth be told, it’s been a while since I made the final decision about a junior hire; for the last dozen or so junior engineers I interviewed, I was more of a vibe check¹ at the tail end of the interview process. The bulk of my decision-making time went to candidates on the senior staff side of things.

Hiring senior folks entails accounting for some of the more disheartening truths about the industry in which our profession tends to be employed. When hiring juniors, it’s easy to give people leeway under the generally accepted principle that anyone is teachable and most people want to learn. Senior talent, however, involves a candidate pool saturated with what are, in my mind, two of the worst phenomena in our field: job-hoppers and ladder-climbers.²

Job-hoppers are people uninterested in any kind of commitment to your team or organization. Their goal is to project competence and confidence at producing the outcomes desired by the organization’s roadmap, complete those outcomes in a way that directly reflects on their ability to do such work, then use their position at your organization to pivot to a higher-paying position at another company. It’s been my experience that most companies on the quarterly revenue growth grind end up hiring a lot of these kinds of people because the short-sightedness of chasing projects that can be associated with a quarter’s balance sheet lends itself to shallow hiring practices that actively reward job-hopping behavior over long-term commitment. These people may appear invested in the projects they’re on, but it’s readily apparent to an interested manager that they often lack motivation for solving problems beyond those that directly affect their own self-interests.

Ladder-climbers project a sense of commitment to your team or organization, but the foundation of that commitment is not on a genuine desire for support and growth. Rather, these people identify opportunities to bring attention to themselves by seeking out and prioritizing high-visibility tasks over high-impact ones. When working with a team, these people seek to delegate work to their peers rather than collaborate with them. Owning workstreams is less relevant to their goals than showcasing work output; they hope to be noticed and subsequently associated with the output of a whole team, rather than seen as one component of a larger picture. These people are everywhere and a lot of organizations get a lot of work done with these people up and down the ranks. Unfortunately, in my experience that output never did outweigh the socioemotional cost of having to work with people like this; the damage to interpersonal trust and overall morale far outlasts the work they’re involved in. You’re free to hire these kinds of people—I can’t stop you—but you will introduce interpersonal frictions into your organization that will be difficult to root out—especially as these people climb to higher positions of greater authority.

Not only is the candidate pool for a senior position different from the pool for a junior position, but the attitude requirements of the people doing the interviewing and hiring are different as well. Hiring seniors involves more than just identifying whether a candidate has demonstrated the technical aptitude to complete whatever tasks are involved with the job; senior engineers bring both domain-specific experiential knowledge as well as social-organizational navigation habits that will affect people around them. (If you’re hiring for a senior position and you feel confident the person you hire will have no effect on those around them, that’s a serious indicator of the need for more internal reflection on why that role needs to be filled now). Considering how they will augment capacity on their team and in their organization is part and parcel of the difference between bringing on juniors and bringing on seniors.

With all this in mind—and the caveat that your organization and goals may vary from my own—here’s generally what I’m looking for when hiring senior engineers:

# Written communication

The first thing I assess in senior talent is how they write. With such ubiquitous access to text-generation tools, it can be hard to develop intuition about a candidate’s writing skills from just their cover letter, resume, and any application prompts³ you require. From the prompts that I ask all candidates to fill out as well as early conversations about work habits, I’ve found it most useful to probe professional communication with questions like:

• Have you written a design doc that changed a decision?
• Can you explain a technical tradeoff to a non-engineer without condescension?
• Have you written a postmortem that led to a systemic change (not an action item)?

# Organizational navigation

Closely related to written communication is how someone has worked in and among the usual bureaucratic and corporate machinery that we find in greater density as an organization grows. A senior person is still a person—they will need onboarding and guidance when they first start working—but my expectations for their ability to seek orienting input to guide their output are higher than for a junior:

• Have you built consensus among people who initially disagreed with you?
• Have you influenced a decision made by someone senior to you?
• Have you said no to a director-level or higher request and kept the relationship?
• How do you know your company’s priorities are what they are?

# Scope of impact

Since we’re interested in bringing on someone who already has knowledge, skills, and abilities to contribute, it’s natural to spend some time assessing their understanding of their scope of impact:

• Have you driven work that spanned multiple teams, not just your own?
• Have you owned a problem that had no clear owner and no one assigned it to you?
• Have your technical decisions shaped work you weren’t personally executing?
• Have people outside your team routed architectural questions to you by default?

# Technical judgment

Hiring senior engineers means you’re bringing on new habits of technical judgment and decision-making. Senior staff are going to be less supervised than their junior counterparts, and ought to be empowered to make decisions that shape a project’s direction and scope. They should form their own opinions of how things work now and how they ought to work going forward, and this mindset—curiosity about what they’re working on and opinions about how they should implement changes—is the mindset I like to learn about:

• Have you made a call where both options were defensible and owned the outcome?
• Have you killed your own proposal after new information?
• Can you articulate the second-order costs of the last three big decisions you made?
• Have you prevented an expensive mistake before it was made (not after)?

# Tolerance for ambiguity

While every organization has different expectations for how people communicate and plan, more often than not we find ambiguously shaped edges of projects everywhere we go. The conversation about whether ambiguity is a problem of clarity and communication aside,⁴ senior members of technical staff are both empowered and expected to be familiar enough with ambiguity that they can still be productive:

• Have you turned a vague business complaint into a concrete technical roadmap?
• Have you decided not to build something and defended it with data?
• Have you broken a multi-quarter problem into shippable increments others executed?
• Have you been handed a problem statement rather than a solution spec?

# Force multiplication

Empowering individuals to do great work is part of the equation of a well-run team. The other part is empowering interpersonal cooperation and collaboration. When we augment a team with a senior engineering hire, one of the primary effects of this new role is to accelerate the work of those around them. This is sometimes called collaboration and teamwork, but to me, the real way of measuring this is to develop intuition about how they talk about their colleagues and peers through the lens of collaboration and teamwork:

• How do you mentor other engineers?
• Have you written something (doc, framework, standard) still in use after you stopped maintaining it?
• Would your absence for two weeks slow work down or stop it?
• Have you made someone else’s project succeed without taking credit for it?

I don’t want to complicate this with too many sections, so I did my best to distill the ones that, in my experience, have always been relevant in any senior engineering hire across different teams, companies, and kinds of products. Your experience may be different! If it is very different from mine, and you have strong objections to what I have shared here, I would very much like to hear what you have to say. Tag me on Bluesky and let’s talk!