How to Interview Software Engineers and Grow Teams

Over my career, I've had the opportunity to help grow and scale many software engineering teams. Part of this has been conducting a lot of interviews, and the other part has been mentoring and facilitating growth among individual team members, and then pairing engineers together, into teams.

Over time, I've discerned a pattern that outlines the sorts of skills I look for in individual engineers, and how this translates into building engineering teams that are productive, healthy, and foster growth. I've distilled this into a simple, easy-to-remember, approach.

When it comes to Software Engineering:

• A Junior Engineer should understand the "what"
• A Mid Engineer should understand the "how"
• A Senior Engineer should understand the "why"
• An Architect/Principal/Lead Engineer should understand the "when"

The short of it is:

Junior Developers ought to be able to take existing code, understand its functionality, and then replicate it.

Mid Developers ought to be able to take requirements and then independently develop a solution that fulfills the requirements.

Senior Developers ought to be able to build things, but also understand the architectural implications of a particular solution – how a solution scales, and then match that solution for a given use-case.

Architects ought to focus on the timing of critical software design decisions – when a decision must be made (and at what cost – what is being given up, and what burden is being accrued aka. "technical debt") and when a decision can be deferred or avoided entirely.

Indeed, every decision in Software Development ought to be understood as a set of constraints. Adaptability – the ability of a disparate pieces of software to change over time, while minimizing "blast radius", is the core concern of software architecture.

Each level of focus moves from the more concrete -> more abstract.

"More Senior -> More Code, Right?"

A common misconception is that more "senior" translates directly to more "code"; Senior writes 10x more code than Mid, that writes 10x more code than a Junior, etc. In some situations, this is a case – a project is being stood up, or a new integration. But often, it is the opposite case; seniors and architects will typically write LESS code than the juniors and mids on their teams.

This makes sense when the focuses of each role are laid out in the above framework. In other words, an engineer's contributions start as being purely additive – 100 lines of code is 100 lines of contribution. As an engineer becomes more senior, and their focus begins to shift onto higher levels of abstraction, their contributions tend to be more multiplicative – 10 lines of code (or better yet 10 lines removed or entirely avoided), results in a 10x productivity boost to other engineers on the team.

You Benefit From Having Them All

Another concept to intuit from this framework: your team benefits from having engineers at each level of focus!

A team of all seniors and architects can result in 10 different abstractions all trying to play nice with each other, resulting in over-engineered code.

On the other extreme, a team of all juniors and mids can result in spaghetti code, with no logical boundaries and tight coupling throughout.

You need Seniors and Architects to provide guard rails, sound abstraction, and constructive feedback to Juniors and Mids, while you need Juniors and Mids to bring the software designs to life as actual working code. The most productive, and fun, teams are the ones that have a mix of engineering focuses.

A corollary of this is that your organization ought to strive to foster an environment that is conducive for Junior and Mid level engineers to join the team and be productive. This is a decent heuristic for code quality; if your software, throughout the entire stack, requires a senior level of expertise in order to grok it, you might be solving really really hard problems that no one else is solving (good for you and godspeed!) – or more likely take it as a sign to look where documentation could be improved, "happy path -> correct path" abstractions/patterns can be added, tests can be written, or esoteric process can be eliminated (ideally replaced with automation), such that a Mid level engineer could come in, grok it, and start contributing.

The Best Part

It turns out that each level's responsibilities are precisely what the engineer needs in order to grow to the next level:

⚡️ Juniors need to write lots of code, to understand the "how".

⚡️ Mids need to write code and decipher requirements, and recognize design patterns, to understand the "why".

⚡️ Seniors need to hear problems, and cross-cutting team concerns, to understand the "when".