What does a senior developer actually change?
A senior developer is not a fast junior, and buying one to get more code written is the most common way the money is wasted. What seniority actually changes is the amount of work that never happens: features scoped down before they are built, designs that do not need rewriting in a year, and incidents that do not occur. If your problem is throughput on well-specified tasks, seniority is an expensive answer to it.
Is a senior developer just faster?
No. On a clearly specified task with a known solution, the gap between a competent mid-level developer and a senior one is real but modest, and it does not justify the difference in cost. If that is the whole of your work, hire mid-level and be pleased.
The gap opens on ambiguous work. Given a vague requirement, a senior developer spends the first part of the time reducing it: asking what happens in the awkward cases, finding the version of the feature that is a quarter of the work, and noticing that two requests are actually the same one. The output of that hour is often a smaller project, which never appears as productivity in any measurement you have.
The other place it shows is in decisions with a long tail. Choosing how data is modelled, where a boundary sits, what gets a background job. These are cheap to get wrong now and expensive to change later, and experience is mostly a memory of which ones turned out badly.
What does each level actually own?
Levels are best described by what the person can be handed and what they need back from you. Stated that way the differences are concrete, and they make it obvious which level a given piece of work requires.
| Level | Can be handed | Needs from you | Fails when |
|---|---|---|---|
| Junior | A defined task with a known shape | Review, a specified approach, quick answers | Left alone with an ambiguous problem |
| Mid | A whole feature with clear requirements | Requirements, and a decision when two paths appear | The requirement is contradictory or missing |
| Senior | A problem, not a solution | Context, constraints, access to the person who wants it | Given only tickets, with no view of why |
| Lead or staff | An area, including what should not be built | Business context and authority to say no | Held accountable for scope without the authority |
When do you not need a senior?
When the work is well specified and the architecture is settled. A stable product with a clear backlog is a mid-level environment, and a senior hire into it will either reshape things nobody asked to have reshaped or become bored and leave within a year. Both outcomes cost more than the salary saved.
You also do not need one for a first prototype whose purpose is to be thrown away. The decisions that seniority protects against are decisions about longevity, and a deliberate throwaway has none.
The honest exception is that a team with no senior anywhere accumulates decisions nobody is qualified to question. If your entire team is junior and mid, you need senior judgement somewhere, though it can arrive as a fractional arrangement or a regular external review rather than as a full-time hire.
Why is the title uncalibrated?
Because titles are set inside individual companies, usually against that company's own population, and often used in place of money. A five-person startup may call a developer with three years of experience senior because it is free to do so and the alternative is a raise. A large organisation may hold the same title back for a decade.
This means the word on a CV carries almost no information on its own, and screening on it filters approximately at random. The years of experience number is similarly weak, because the same year can be repeated.
The useful substitute is scope of responsibility. Ask what the biggest thing was that the candidate was the person responsible for, what they decided about it, and what they would decide differently now. That question is difficult to answer well without having actually held the responsibility.
How do you recognise seniority in an interview?
Three signals appear consistently. The first is unprompted scope reduction: given a feature description, a senior candidate asks what problem it solves before asking how it should work, and often proposes something smaller. Listen for that instinct rather than waiting for a design.
The second is comfort with having been wrong. Ask about a decision they now regret. The answer should be specific, technical, and free of blame, and it should include what the early warning sign was. Candidates who cannot produce one either have not owned enough or have not reflected on it.
The third is knowing what they do not know and having a route to it. A senior developer given a problem outside their experience says so, then describes how they would reduce the uncertainty in a week. That behaviour is the actual product you are buying, and it is visible in a single conversation.
What does the wrong seniority mix cost?
Too senior, and you pay for judgement that has nothing to decide. The symptom is a well-paid engineer producing refactors and internal tooling nobody requested, because the work available does not use the thing they were hired for.
Too junior, and the cost arrives later and larger. Nothing looks wrong for several months; then the same class of bug keeps recurring, small changes take longer than they should, and the reason is a set of early decisions that nobody in the room was experienced enough to challenge. This is the more expensive failure because it is invisible while it is happening.
A test you can apply now: look at the last five significant technical decisions made in your product, and ask who challenged each one. If the answer is nobody, you have a seniority gap regardless of what the titles say.
Common questions
- What is the difference between a mid-level and a senior developer?
- A mid-level developer can be handed a whole feature with clear requirements and will deliver it. A senior developer can be handed a problem rather than a solution, and will spend the first part of the time reducing it: asking what happens in the awkward cases, finding the version that is a quarter of the work, and noticing when two requests are really one. The output of that is often a smaller project.
- Do you always need a senior developer?
- No. Well-specified work on a settled architecture is a mid-level environment, and a senior hire into it will either reshape things nobody asked to have reshaped or leave within a year. The genuine exception is that a team with no senior judgement anywhere accumulates decisions nobody is qualified to question, though that can be covered by a fractional arrangement or regular external review.
- Why is the senior developer title unreliable?
- Because titles are set inside individual companies, calibrated against that company's own population, and frequently used in place of money. A small company may award it after three years; a large one may withhold it for a decade. Years of experience is equally weak because the same year can be repeated. Scope of responsibility is the better substitute.
- How do you tell if a developer is genuinely senior in an interview?
- Three signals: unprompted scope reduction, where they ask what problem a feature solves before asking how it should work; comfort discussing a decision they now regret, specifically and without blame, including the early warning sign they missed; and a clear route through unfamiliar problems, describing how they would reduce uncertainty within a week rather than claiming they would know the answer.
- What does hiring too junior a team cost?
- The cost arrives late and compounds. Nothing looks wrong for several months, then the same class of bug recurs, small changes take longer than they should, and the cause is a set of early decisions nobody in the room was experienced enough to challenge. A quick test: list the last five significant technical decisions in your product and ask who challenged each one. If the answer is nobody, the gap exists whatever the titles say.
