What separates a junior from a staff engineer in an interview

It is not how much technology you know. It is what you do with the problem.

When I started interviewing, I struggled to assess a candidate’s level. I could not find objective criteria to say whether someone was junior, mid-level, or senior.

It went on like that for years. Me looking for a metric, a system to look at a candidate and pin down the level. Until I started noticing a pattern in the interviews.

The pattern I began to see

The ones I considered junior did not have much awareness of the problem. They skipped that stage and went straight to the solution. Common early in a career.

The mid-level engineer (Pleno on the Brazilian ladder, the rung between junior and senior) was already aware of the problem, but worked with one or two possible solutions. They knew what needed solving and raised a few hypotheses about how.

The senior was aware of the why. Why they were solving that, and why each solution made sense. It is what O’Reilly captures well in the article “Seniors and Juniors” (2025): understanding a problem is not finding an algorithm, it is knowing who wants it solved, why they want it, who is paying, and what has already been tried. Complex architecture or simple, it made no difference: the senior was clear about what needed solving and about the right solution for that deadline, that scope, that delivery.

And there was a level above senior, very clear in interviews: the candidate reasoned in trade-offs. They knew what to do, how to do it, why they would do it, and what they would be losing and gaining by adopting each solution. It is no accident that Tomasz Lelek and Jon Skeet devoted an entire book to this, “Software Mistakes and Tradeoffs” (Manning, 2022): almost every engineering decision is a balance between opposing forces, and the cost of choosing wrong usually shows up only much later.

How this became my interview method

Once I saw the pattern, I started using it deliberately.

Junior. In a junior role, I expected the candidate to know what to do. A service, a database, a queue, something along those lines. Even without understanding why that choice. They would take the solution they already had in mind and break it into components, and that alone indicated the level. Decomposing the problem, before picking the solution, is another story.

Mid-level. Here I expected them not only to know what to do, but to bring more than one solution to the same problem. At this level I did not press on the why or on trade-offs. I wanted to see more than one option on the table.

Senior. I expected the what, the how, a few options, and above all the why of choosing one over another. Not necessarily what they would gain or lose, but the reasons behind the choice. Some already identified trade-offs, but I did not demand depth on gains, losses, and business impact. Being able to explain the why already signalled the level.

Specialist/Staff. Here was the big difference. The candidate knew what to do, how to do it, why to do it, and explained what they would gain and lose in each solution, including from the business side. Will Larson describes this territory well in “Staff Engineer” (2021): part of staff-plus work is dealing with a lot of ambiguity and connecting technical decisions to organisational impact, whether as the “Solver” of the thorniest problems or as the leadership’s right hand.

And often the chosen solution was the simplest one possible. The problem looked complex, but analysed deeply it did not require anything so structured, so full of technology. It was about solving it in the simplest way available. Rich Hickey had already named this in “Simple Made Easy” (Strange Loop, 2011): we confuse the simple with the easy and end up paying in complexity. The senior chooses the simple even when the easy path would be to pile on technology.

The more senior the professional, the simpler the solution tends to be.

Senior does not mean knowing less technology

An important caveat: this does not mean seniors and specialists need to know less about technology. Quite the opposite. They know far more.

The difference is that they do not go applying every technology at once, to every problem. They see the problem, decompose it into parts, and decide where to apply a given technology and where to simply ignore it, because leaving it out is often what serves the problem best.

It is no coincidence that Sijin Joseph’s classic “Programmer Competency Matrix” has an entire row devoted to problem decomposition: it is one of the competencies that most separates the levels. It is also what the Dreyfus model pointed at back in 1980: the novice clings to rules and tools, while the expert operates by context and trained intuition. At the process level, the same logic appears in maturity models such as the SEI’s CMM and its evolution into ISO/IEC 33000, which describe the passage from chaotic to predictable to optimised.

At bottom, it is a shift of focus: from the technology to the problem, the business, and the impact.

An example. Hire a junior and it is common to see them apply complex solutions to small problems, leaving the system hard to maintain and evolve. The specialist, in the end, asks something else: will this off-the-shelf solution cost more or less than a custom one?

What gives away the junior and the mid-level engineer is the attempt to show they know many technologies, thinking in complex systems, without looking at the problem that needs solving and at how to decompose it.

Seniority is a relationship with the problem

None of this is about how many technologies someone has mastered. A junior may know more frameworks than a senior. What separates the levels is each one’s relationship with the problem: the junior runs for the solution, the senior stays with the problem until they understand what it really is.

Maybe that is why junior, mid-level, and senior mean such different things from one company to the next. We insist on measuring seniority by tenure, by stack, by title. In an interview, when you pay attention, what shows up is something else.

Your level is not in the stack you name. It is in the problem you understand.

References and further reading

Dreyfus, Stuart E. & Dreyfus, Hubert L. “A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition” (University of California, Berkeley, 1980). Expanded in Mind Over Machine (1986).
O’Reilly Radar. “Seniors and Juniors” (2025).
Lelek, Tomasz & Skeet, Jon. Software Mistakes and Tradeoffs (Manning, 2022).
Larson, Will. Staff Engineer: Leadership beyond the management track (2021).
Hickey, Rich. “Simple Made Easy” (Strange Loop, 2011; video on InfoQ).
Joseph, Sijin. “Programmer Competency Matrix”.
SEI/CMM (Capability Maturity Model) and ISO/IEC 33000 (software process maturity models).