Software Engineering
Full-Stack Engineer
Breadth is the point, and claiming both ends equally is the mistake. Name the side you are deep in.
Breadth is the point, and claiming both ends equally is the mistake. Name the side you are deep in.
A day that is actually representative
| Time | What you are actually doing |
|---|---|
| 09:00 | A bug that could be either side. Half the value of this role is being able to follow it across the boundary without a handoff. |
| 10:30 | Build a feature end to end — schema, endpoint, state, interface — which is the thing this role exists for. |
| 13:00 | A design conversation where the API shape is really a product decision about what the client should have to know. |
| 15:00 | Performance: the page is slow and the cause is over-fetching, which is a boundary problem rather than a frontend or backend one. |
| 16:30 | Reviewing across the stack, where the useful contribution is spotting the mismatch between what the API promises and what the UI assumes. |
The decisive round
“How deep are you really, on each side?”
Interviewer: “You describe yourself as full-stack. Where are you genuinely strong and where are you not?”
A weak answer. “I'm comfortable across the whole stack — I've built React frontends and Node backends, worked with SQL and NoSQL databases, and deployed to AWS.” An unqualified claim to everything, which reads as shallow because it is unfalsifiable. Interviewers discount it entirely and then probe until they find the floor.
A strong answer. “Backend-leaning. I'm deep on data modelling, API design and the performance characteristics of the datastore — that's where I'd want to be tested and where I'd be the person the team asks.
On the frontend I have shipped production React and I'm competent at state management, data fetching and the performance work that matters at the boundary — over-fetching, waterfalls, caching. What I would not claim is design-system work or deep accessibility; I can implement to a spec well, and I'm not the person you want defining the visual language.
Where full-stack actually earns its keep, in my experience, is at the boundary: the bugs and the performance problems that live between the two and get bounced back and forth when the team is split. Being able to follow one through without a handoff is worth more than being equally strong on both sides, and it's why I've stayed generalist rather than specialising.”
Naming a lean and a genuine limitation. Candidates who claim equal depth get discounted; candidates who name where they are weak get believed about where they are strong.
What to build or bring
- One thing you built entirely end to end, and the decisions at the boundary.
- A boundary bug — a problem that lived between the layers and how you found it.
- A stated lean, and one honest weakness on the other side.
- Product sense, which this role is disproportionately asked for because you see the whole feature.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $140k – $240k base | Slightly below specialist backend at the same level in this corpus |
| India | ₹15L – ₹50L total | Very large market; strongest at product companies and scale-ups |
The book for this field
Software Engineering
What postings now ask for, system design at the level actually assessed, product sense for engineers, code and review, debugging and the coding round, what changes from mid to staff, the loop round by round, and choosing a track.
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 10 Engineering questions → · Back to Software Engineering →