What Does It Mean to Be a Senior Engineer?
The senior title isn't assigned by years. What should change from junior to senior, which habits arrive, which behaviors are left behind? Concrete criteria from real production work.
Picture two developers who both answer "8 years" to "how long have you been working?" One is senior. The other is a very experienced junior. The difference isn't years — it's what they learned and how they behave.
This post walks through what's actually under the senior title, and what anyone trying to cross from junior to senior should attend to.
1. Senior thinks before writing
When a junior hits a problem:
"Let me find a library." "Let me look at Stack Overflow."
Senior:
"Do I actually need to solve this?" "If I redefined the problem, would it be easier?"
The senior's first output is often less code — because a senior recognizes a problem that shouldn't be solved at all.
2. Senior asks "why", not "how"
Hand a junior a ticket and they go straight to "how should I build this?" A senior pauses and asks "why is this needed?"
That question can create friction at first but it's a vital filter. Because:
- The business need may be outdated
- The ticket may have been misinterpreted
- A simpler alternative may exist
For every 10 tickets a senior "whys" on, typically 2–3 turn out to be "actually, we shouldn't build this." That's the senior protecting the team's throughput.
3. Senior distinguishes "done" from "really done"
A junior thinks a feature is done when "it works locally and I added tests." A senior in the same position asks:
- How will this behave in production?
- Were edge cases considered?
- Is there monitoring?
- Is there a rollback plan?
- Is the doc up to date?
If 3–4 of those are missing, the feature isn't done. "I built it, we're done" is junior vocabulary. A senior says "I thought it through, tested, planned for maintenance — so it's done."
4. Senior reasons in trade-offs, not perfection
A junior looks for the perfect solution. "The right answer is this," they say.
A senior knows every solution has a cost. "This path is fast but has maintenance burden, this path is slow but clean" — then makes the call and writes the reasoning. They understand it's not the choice but the reasoning behind the choice that matters.
Clearest signal: a senior asks "what are we losing?" in every decision. A junior asks "what are we gaining?" Both questions are right, but each is half the picture alone.
5. Senior pulls others up
Senior-hood is not earned by solo work. It's largely measured by raising the level of the team:
- Teaching comments in code reviews
- Giving juniors room in small decisions
- Simplifying complex topics in explanation
- Shielding a team member's failure while amplifying their success
Senior doesn't say "let me just do it, it's faster." That route is faster for 3 months and leaves the team dependent for 3 years while the senior burns out.
6. Senior is willing to say it's wrong
A junior hesitates to say "this plan is wrong" in a meeting. Agreeing with senior suggestions feels safe.
Senior can say "I disagree, for these reasons." Can push against the flow of a meeting. But constructively — not "you're wrong," but "have you thought about this dimension?"
Combining both: holding your position without breaking the relationship. Very valuable.
7. Senior doesn't make incidents worse
A junior panics in an incident. Random pod restarts, config changes, "let's try and see." Every action extends the incident.
Senior stays calm. Observe first, act second. "What do we know, what don't we know?" During an incident, a senior's most valuable output is steadying the rest of the team: asking the right questions, calling the right person.
8. Senior says "I don't know" comfortably
A junior hides not knowing — speculates, hedges, talks around it.
A senior says "I don't know, give me 30 minutes, I'll come back." In fact the opposite: a senior says it out loud. Because if you answer with false confidence, that answer becomes a decision, and wrong decisions get made.
When do you become senior?
No clean formula. But when three signs appear at once, you're senior:
- In a project you lead technically, others trust your calls
- In incidents, the team turns to you
- Your code reviews have educational value
Years are irrelevant. With those three, you're senior in 5 years. Without them, you're not senior in 15.
Takeaway
Senior isn't "writing better code" like most people assume — it's better decision-making, better communication, better judgment. Code is a byproduct of those skills.
Those skills grow with years but not automatically. Deliberate practice matters. "I've been coding 5 years" isn't enough. "I've been actively observing myself, taking feedback, updating habits for 5 years" is.
Short version: senior isn't a title — it's a cluster of habits.
Long-form notes on distributed systems, production stability, AI-assisted shipping. No spam, easy to unsubscribe.
Comments
No comments yet. Be the first.