A full-stack Software Engineer decides every day where responsibility sits between browser, server, API and data, without sacrificing the reliability of the product to delivery speed.
A full-stack Software Engineer is not defined by frontend skills plus backend skills. What makes the role is the ability to reason about end-to-end behaviour: what the user sees, what the server guarantees, what the database keeps, and what happens when the network, a third-party service or a deployment does not behave as expected.
Someone executing can work on both sides of the application. Someone genuinely holding the role understands the boundaries between those sides. They can determine which layer is the source of truth, how an API contract can evolve without breaking its consumers, where an access check has to be applied, and how to make a process observable and repairable after an incident.
The difficulty specific to this job comes from permanent tensions: perceived smoothness against data consistency, delivery speed against reversibility, a shared abstraction against team autonomy, a local fix against future running cost. A solution that is technically valid in one layer can create a more expensive problem in another. The assessment therefore rests less on the number of technologies known than on how the candidate establishes facts, ranks risks and owns their choices.
Market benchmarks
The French market has plenty of people carrying a full-stack title, but that title covers very different realities: a frontend developer who occasionally works server-side, a backend specialist autonomous on a few screens, or a genuine engineer able to reason about the full journey of a piece of data.
The scarcity is sharpest on genuinely balanced profiles. People who combine technical breadth, depth in at least one area, and operational maturity remain rare. That diversity makes comparisons based on technology lists alone particularly unreliable.
Context
In an IT services firm, the assessment pays particular attention to the full-stack engineer's ability to get into an inherited estate, to understand responsibilities split across several parties, and to make their decisions explainable within a contractual frame. The candidate has to make a change safe without full ownership, work with imposed architectures, and hand over something maintainable once they leave.
Level 1
Junior
A Junior can deliver a scoped change and solve a local problem when the path is identifiable. They reason mainly at the level of the component, the endpoint or the query they have been given. They can make things work, but still find it hard to tell the visible symptom from the mechanism that produced it.
Click to read
Level 2
Mid-level
A Mid-level engineer owns a feature end to end. They can investigate, compare several options, plan for error states and check the interactions between frontend, backend and data. They become autonomous within the usual scope, but may still treat separately problems that in fact come from one design or operational choice.
Click to read
Level 3
Senior
A Senior engineer reasons in total cost. They do not only look to fix: they distinguish what has to be restored immediately from what has to be redesigned, account for production, and protect consumers from a change. They can defer a desirable improvement, cut scope, or choose an imperfect solution when risk, deadline or team capacity demand it.
Click to read
Level 4
Expert
An Expert is not the person who knows more libraries or patterns. They settle a trade-off by naming explicitly what they agree to give up: some perceived speed to guarantee consistency, work already done to protect a deadline, architectural elegance to limit organisational cost, or part of the scope to keep a reliable signal. They then turn that one-off decision into a convention, a guardrail or a shared direction.
Click to read
This category carries the highest weight because asynchrony, error handling, the execution model and how server code is structured determine the reliability of everything else. A weakness in these fundamentals produces silent effects that travel through every layer.
The frontend weighs almost as much as the JavaScript and Node foundation, because it is not merely a presentation layer. State management, perceived performance, loading and failure states, and accessibility determine what the user can actually understand and get done.
This category measures how solid the system's boundaries are: API contracts, persistence, application decomposition and security. It weighs heavily because a bad decision at a boundary usually spreads across several teams, several consumers and several versions of the product.
The weight is lower than for the building categories, but this skill is a guardrail. A system never stays in its nominal state: you have to observe an incident, test a hypothesis, restore the service without making things worse, and understand what will make the next occurrence detectable.
This category does not measure how well someone speaks. It measures the ability to explain a risk, deliver bad news, challenge a technical decision without turning disagreement into conflict, and lay out understandable options for whoever has to decide.
The method in action
The scorecard at a glance — hover an axis
Software development & engineering