Software Engineering · Chapter 8 of 31
Backend, frontend, full-stack, mobile — and where the demand is
What the corpus says about each track, and what that means for how you position yourself.
Of 2,609 software engineering postings, the split by named specialism is uneven and worth knowing before you decide what to call yourself.
| Track | Roughly | What it changes about your prep |
|---|---|---|
| Backend | The largest named specialism | System design carries the loop; know your datastore deeply |
| Full-stack | Strong and growing | Breadth is the point — but have one side you are genuinely deep in |
| Frontend | Smaller than its visibility suggests | Performance, accessibility and state management are the differentiators, not framework familiarity |
| Mobile | Concentrated in consumer companies | Platform depth matters more than in web; releases are slow and unrollbackable |
| Embedded / systems | Small and durable | Least substitutable skill set here; debugging depth is the currency |
| ‘Agent’ engineer | Growing fast from nothing | See the AI field — this is now a distinct archetype |
On calling yourself full-stack
It is honest and it can read as shallow. The version that works: name the side you are deep in and describe the other as working competence. “Backend-leaning full-stack — I have shipped production React and I would not claim to be the person you want designing your design system” is far stronger than an unqualified claim to both.
The positioning that gets interviews
Specialism plus a domain beats specialism alone. “Backend engineer” competes with thousands; “backend engineer who has built payments at scale” or “…who has worked in a regulated environment” competes with far fewer and matches what enterprise postings actually ask for.
The domain does not need to be glamorous. It needs to be specific, and true.
How to choose a track, and when
The decision is usually framed as a preference between technologies. It is better framed as a bet on three things: what you will be doing daily, how substitutable you will be, and how quickly the specific knowledge decays.
| Track | The daily work is really | Substitutability | How fast the specifics decay |
|---|---|---|---|
| Product / full-stack | Deciding what to build as much as building it | High — the largest pool, so the most competition | Fast on frameworks, slow on the judgement |
| Backend / distributed | Correctness under failure, and capacity | Moderate | Slow. Consistency, partitions and queueing have not changed in decades |
| Data / platform | Moving and modelling data other teams depend on | Moderate | Fast on vendors, slow on modelling and semantics |
| Infrastructure / SRE | Operating things you did not write, at 3am | Lower | Moderate — Kubernetes will not be forever, but operating discipline is |
| Security | Being wrong in only one direction, and saying no usefully | Lowest. Small pool, high trust barrier | Fast on tooling, slow on adversarial reasoning |
| Frontend / mobile | Perceived performance, accessibility, and platform rules | High on frontend, lower on mobile | Fastest of all. See the framework chapters in this book |
| Embedded / systems | Constraints that do not move | Least substitutable skill set in the field | Slowest |
The two errors
Specialising too early narrows you before you know what you like, and the first two or three years are the cheapest time you will ever have to try things. The people who commit to a track at eighteen months are usually committing to whatever their first team happened to do.
Specialising too late is the more common and more expensive error. A generalist with eight years of experience competes on breadth against people with twelve, and the interview loop has no round that rewards breadth directly.
The practical shape that works: broad for the first few years, then deep in one thing while staying literate in the adjacent ones. ‘Deep in one, literate in three’ is the profile that both interviews well and survives a market shift.
And note the asymmetry that makes this decision less frightening than it feels: depth transfers better than breadth does. Someone who has been genuinely deep in one area learns the next one much faster, because they know what deep feels like and what questions to ask. Breadth does not confer that.
On timing a switch: the cheapest moment to change track is inside a company that already trusts you, because you are being assessed on your record rather than on the specialism you do not yet have. Switching track and company simultaneously means competing against specialists on their own ground with none of the context that would let you win.
Check yourself