Backend & API Engineering: SFIA levels and developer seniority
Fennec team · 9 Feb 2026 · 4 min read
Backend engineering is mostly invisible work. Users never see the service layer directly, they only feel it when an endpoint is slow, an API returns the wrong data, or something fails silently at 3am. It is a discipline judged by correctness, resilience, and how well a system behaves under conditions nobody explicitly designed for.
SFIA levels here track a shift from making an existing endpoint work, to deciding how an entire system should be built. The confusion most backend engineers run into is that 'senior' means something different at every company. The level descriptions below cut through the title and look at what you actually own.
1
Level 1: Follow
“I understand server-side concepts and can make basic changes to existing code following clear instructions.”
Evidence at this stage is modest and that's expected: a small bug fix pull request with heavy review comments guiding your approach, a certificate from a Node, Python, or Go fundamentals course, or notes from a pairing session where someone senior walked you through a request end to end, from handler to database to response.
The quickest way forward is reading an existing service before you touch it, not after, and asking someone to walk you through a full request cycle if nobody's offered yet. Practice writing a basic test for an endpoint that doesn't have one, it's a small habit that pays off fast.
2
Level 2: Assist
“I build simple endpoints and work on existing services with guidance. I can write basic tests for my own code.”
Look for the moments you needed help only on the hard parts: a pull request for a new endpoint built to an existing pattern, a basic test suite you wrote for your own code unprompted, or a bug you diagnosed using logs and reasoning rather than asking someone where to look.
From here, make testing the default rather than the exception, write tests for every endpoint you touch, not just the happy path. Learn to read the query plan for one slow endpoint you own, and take an on-call shadow shift so you see what actually breaks in production before you're the one holding the pager.
3
Level 3: Apply
“I design and ship APIs and services end-to-end without supervision. I write tests, handle errors properly, document my work, and review other people's code. I've been doing this confidently for a while.”
This is where ownership becomes real: a service or API you designed and shipped end to end without supervision, a contribution to an incident postmortem that included an actual fix, or documentation you wrote that other teams rely on to use your API correctly.
The next step usually comes from owning a service's edge cases and errors as much as its happy path, not just the feature work. Start writing a short design doc before a significant change, and volunteer for on-call and actually carry the pager rather than shadowing someone else's.
4
Level 4: Enable
“I'm the technical authority for backend decisions in my team. I design service boundaries, lead technical discussions, own the quality of backend systems, and help other engineers level up.”
By this point your decisions outlive your own tickets: a service boundary or API contract you defined that other teams built against, a technical RFC you authored that got adopted, or engineers crediting you specifically for unblocking them on a hard backend problem.
What tends to move things forward is writing the design doc for the next big change instead of reacting to someone else's, setting a testing or error-handling standard your team actually follows, and using code review as a teaching tool, not just an approval gate, deliberately making space for others to grow.
5
Level 5: Ensure & Advise
“I define how backend engineering works across the organisation: the standards, the patterns, the toolchain. My decisions ripple across teams.”
The evidence here reaches past your own team: a backend-wide standard, an API style guide, service template, or observability standard, that other teams adopted, being the escalation point for cross-team backend incidents, or a golden-path template other teams copied directly from your work.
Getting further means writing and socialising a standard that spans more than your own team, building a template other teams can build on directly rather than reinvent, and mentoring other tech leads, not just individual engineers, since your job is increasingly about multiplying other people's judgement.
6
Level 6: Initiate & Influence
“I set engineering direction for backend systems at an organisational or industry level.”
At the top of this ladder, the evidence is organisational: a backend strategy or platform whose direction you set, external talks or writing that shaped how other engineers build backend systems, or a roadmap for backend engineering across the company with your name on it.
From here, the work is publishing your architecture thinking beyond your own team, owning the organisation's backend roadmap, and representing backend engineering at the table where the business makes its bets.
Go deeper
Widely cited writing on software design, refactoring, and enterprise patterns.
Real-world architecture write-ups on how large systems handle scale.
A podcast on backend engineering and the Go ecosystem.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log backend & api engineering evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.