Hire Full-Stack Developers Who Are Actually Full-Stack
It is the most abused title in software hiring. Plenty of people who use it are frontend developers who have written a few endpoints. This page explains how we tell the difference, and when you should not hire one at all.
- Tested on both halves, not one
- 2–3 profiles in 3 business days
- Replacement free inside two weeks
Why the Title Tells You Almost Nothing
Nobody polices the word. A developer who spent three years on React and wrote some endpoints in a side project will put full-stack on a profile and mean it sincerely. So will somebody who has designed a schema, run migrations against a live database on a Tuesday afternoon and been paged when the queue backed up. Those are not the same hire, and an interview built around the frontend will not distinguish them.
The practical definition we use: can this person take a feature from an empty ticket to production across both sides of the network boundary, and be trusted with the half they touch less often. Not expert in everything. Competent enough on the weaker side that their decisions there do not create problems somebody else has to find later.
That means the interview has to be weighted towards the side people fake. In practice that is nearly always the backend, so that is where we push hardest.
Following a Bug From Click to Query
One exercise separates the two groups more reliably than anything else we have tried. A user reports that saving occasionally does nothing.
They start where the evidence is, not where they are comfortable
A weaker candidate begins in the component because that is familiar ground. A real full-stack developer opens the network tab first, finds the request, checks the status and the response body, and only then decides which side of the boundary the problem is on. Choosing where to look is the skill.
They read the server logs as fluently as the console
They correlate the failing request by identifier, find the log line, and notice that the handler caught an error and returned a success status anyway. Someone who has only consumed APIs tends to stall here and start theorising about the client.
They get to the data layer without flinching
The write failed on a constraint, or the transaction rolled back, or two concurrent requests raced and the second one lost. Getting there means reading the query, understanding the constraint and knowing what a rollback does to everything else in that transaction.
They fix it in the right place, and say what they did not fix
The fix might be a unique constraint plus proper error mapping, or making the operation idempotent, or a retry with a sensible boundary. The senior signal is also naming what they left alone and why, and adding the log line that would have made this a five-minute investigation instead of an afternoon.
The Backend Questions That End the Conversation Early
None of these are trick questions. They are things anyone who has genuinely owned a service has had to deal with.
Shipping a Schema Change
Add a required column to a table in use, with the application running. What order do the migration and the deploy go in, what do in-flight requests see in between, and what is the plan if the migration has to be reversed at a bad moment. Anyone who has only ever run migrations locally goes quiet here.
Finding the Slow Query
Given a list endpoint that has become slow, we want to hear about the query plan, the missing index, the join that multiplies rows, or the pattern where the framework issues one query per item in a loop. Guessing and adding a cache in front of the problem is the answer we are screening out.
Auth Beyond the Login Form
Where the session lives, what the token contains, how it is revoked, and the difference between hiding a button in the interface and actually enforcing permission on the server. A surprising number of otherwise strong candidates have only ever implemented the client side of this.
The Same Request Twice
A user double-clicks submit, or a client retries after a timeout that the server did not honour. Do you get two orders. The answer involves idempotency keys or a uniqueness constraint, and the good version of the answer also covers what the interface should do while it waits.
Work That Takes Ten Seconds
Report generation, a bulk import, a set of emails. Keeping it in the request handler is the wrong answer, and knowing that is easy. The useful part is what they say next about job state, retries, and how the interface tells the user that something is still running.
One Contract, Two Sides
How do the client and the server stay in agreement about the shape of a response, and what happens when one changes. Shared types, generated clients, schema validation at the edge — the specifics matter less than whether they have ever felt the pain of a silent mismatch and done something structural about it.
Depth on either side is covered separately in hiring React developers and hiring Node developers.
Owning a Feature End to End
The efficiency of a full-stack developer is not that they type faster. It is that the handoffs disappear.
The contract gets agreed in a meeting, then changes once the interface is real. The frontend developer builds against a mock, the backend developer builds against an assumption, and the two meet three days later with different ideas about what null means in that field. Nobody did anything wrong. The feature still took a week longer than the sum of its parts.
This overhead is fixed per feature, which is why it hurts most on small features and barely registers on large ones.
The contract is decided once, by the person on both ends of it, and revised the moment the interface shows it was wrong. The response shape matches what the screen needs because the same person needed it. When it breaks, one person debugs the whole path instead of two people each proving it is not their side.
On small and mid-sized features that is a genuine speed advantage. On a large workstream it becomes a bottleneck, because one person is now the critical path for everything.
A comparison of working patterns, not a performance claim. Which shape is faster depends entirely on the size of the work.
When You Should Hire Two Specialists Instead
We would rather tell you this now than staff a role that is quietly two roles.
What a Good Full-Stack Brief Looks Like
The single most useful thing you can tell us is which half is the hard half. It changes who we put forward.
Tell us this
- Both stacks as they exist: framework, database, styling, data layer, hosting
- Which side is heavier this quarter, honestly, and whether that flips later
- Who reviews the backend work and who reviews the frontend work
- Whether they own deployment or hand the change to someone who does
- The first three tickets, with at least one that crosses the boundary
- Whether the role includes talking to users or product people directly
- Engagement shape and overlap hours — part-time works well for this role
Watch out for this
- A role description that is a frontend job with two backend bullet points bolted on
- Infrastructure duties appearing halfway down a list without being named as a requirement
- Expecting design work because one person is already doing two jobs
- A mid-level budget against a role that has nobody senior to check the decisions
- Both halves described as critical, which usually means this is two hires
Hiring Full-Stack Developers
How do you tell a real full-stack developer from a frontend developer who has seen an API?
We make the backend half of the exercise the hard half. The candidate has to change a schema and write the migration, explain what happens to in-flight requests during the deploy, and find a slow query using the query plan rather than guesswork. Someone who is really a frontend developer will write a working endpoint and then have nothing to say about indexes, transactions or what the service does under concurrent load. That gap shows up within twenty minutes.
Is one full-stack developer as productive as one frontend plus one backend developer?
No, and anybody selling that is selling you a headcount saving that will not survive contact with your roadmap. What one full-stack developer removes is coordination cost: no waiting for an endpoint, no contract renegotiated over three days, no ticket bouncing between two boards. That makes them faster per feature on small and mid-sized work. It does not make them faster than two people on two workstreams.
Where is a full-stack developer genuinely the better hire?
Small teams, early products, internal tools, and any feature where the interface and the data model are being decided together. They are also the right hire for work that is mostly plumbing between an existing frontend and an existing backend, and for teams too small to keep either a frontend or a backend specialist busy for a whole week.
When should we hire two specialists instead?
When either side of the stack has genuine depth to it. A complex design system, heavy data visualisation, offline support or serious accessibility requirements make the frontend a full role on its own. High traffic, intricate data modelling, payments, or a queue-driven architecture make the backend a full role. If both are true you do not have one job for one person, you have two jobs and a communication problem you are trying to solve by hiring.
Does full-stack mean they can do devops and design as well?
No. In this market the title means application code on both sides of the network boundary. Most of our full-stack developers can work a CI pipeline and deploy a service, and many can implement a design well, but neither infrastructure engineering nor product design is included by default. Put it in the brief if you need it, and we will match on it explicitly rather than hoping.
What seniority makes sense for a full-stack role?
Higher than you would need for a single-side role, in most cases. Owning a feature end to end means making decisions without a specialist to check them, and a mid-level developer working alone across both halves tends to produce a frontend that is fine and a backend that is fragile in ways nobody notices for months. If your budget only stretches to mid-level, a narrower role with proper review is usually the better trade.
Rates per developer are on the pricing page. The process itself is in how hiring works.
Tell Us Which Half Is the Hard Half
Send both stacks and the first three tickets. If the role is really two roles, we will say so before we send anybody.