Cohesyve · Practice for candidates
Preparing for a Full Stack Developer role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
Full stack processes test breadth without letting you get away with shallowness anywhere. Employers want someone who can take a feature from schema to interface, so the assessment usually spans both sides and the interviews probe where your depth actually sits. The common failure is a candidate who is genuinely strong on one side and vague on the other, and never says which is which. This page sets out the stages, the topics that recur, and how to prepare honestly for a role that spans the whole stack.
The hiring process, stage by stage
Application and CV screen
Reviewers try to work out whether you are genuinely full stack or a specialist with adjacent exposure. They look for features you owned end to end rather than a list of technologies on both sides.
How to prepare: Describe two or three features by their whole journey: the data change, the API, the interface and what shipped. Name your stronger side explicitly rather than presenting an implausibly even profile. Link one repository where both layers are visible.
Recruiter screen
A short call confirming stack, level and expectations, and often clarifying how the company splits work between frontend and backend in practice.
How to prepare: Ask what proportion of the role is each side, and whether there are dedicated specialists. Prepare a plain-language description of one feature you shipped end to end. Have your range and notice period ready.
Practical assessment or take-home
Usually a small feature crossing the stack: a data model, an endpoint and an interface that consumes it. Scoring rewards a coherent whole over polish on one layer.
How to prepare: Practise building a thin but complete vertical slice against a timer. Decide in advance where you will spend your remaining minutes if you run short, and make it functionality rather than styling. Include a README stating scope and cuts.
Technical interviews on both layers
Often two sessions, one leaning backend and one leaning frontend, or a single session that deliberately crosses the boundary — for example, how a schema change reaches the interface.
How to prepare: Rehearse one feature end to end in enough detail to answer either side's questions about it. Practise saying where your depth ends without undermining yourself: name the boundary and how you have handled it before.
Final interview with the hiring manager
Covers prioritisation, working across the stack in a small team, and how you decide what is good enough given a deadline.
How to prepare: Prepare a story about cutting scope deliberately, one about a bug that crossed the boundary and was blamed on the wrong layer, and one about picking up something outside your comfort zone quickly.
What to study
Vertical slice delivery
The whole reason a team hires full stack is to move a feature through every layer without a handoff, so interviews test that path directly.
Data modelling and persistence
Full stack candidates are most often weak here, and interviewers know to check it.
API contracts across the boundary
You are both producer and consumer, so bad contracts hurt you twice and interviewers use them to test your judgement.
Interface behaviour and state
A weak frontend answer will cap your level even if the backend work is strong.
Deployment and debugging end to end
Small teams expect full stack engineers to trace a problem across layers without escalating at the first boundary.
Cohesyve for candidates
Practise a Full Stack Developer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Your preparation plan
Four weeks out
Shore up your weaker layer, since that is where the process will find you.
- •Decide honestly which side is weaker and give it two thirds of your study time
- •Build one complete vertical slice from schema to interface, with tests
- •Practise reading a query plan and fixing an N+1 pattern if backend is the weak side
- •Rebuild a component with proper state and error handling if frontend is the weak side
Two weeks out
Practise crossing the boundary in conversation, not just in code.
- •Rehearse one feature end to end until you can answer questions from either direction
- •Do two timed cross-stack exercises, stopping strictly at the limit
- •Write two-minute stories about scope cutting and a cross-layer bug
- •Prepare a clear sentence about where your depth ends and how you compensate
The final week
Simulate the assessment and remove setup cost.
- •Run one full mock assessment covering both layers under real time pressure
- •Prepare a project skeleton with both layers wired so you start on the feature
- •Re-read your submission and list the three things a reviewer would question
- •Draft your questions for the panel about how work is split across the team
The day before and the day of
Settle your plan for allocating limited time.
- •Decide your time split across layers in advance and write it down
- •Test tooling, screen share and any shared environment the company uses
- •Re-read the job advert and identify whether the role leans one way
- •Plan your opening: clarify the brief, agree the scope aloud, then build the slice
Questions to expect
“Take a feature you shipped and walk me through it from database to screen.”
What they're really asking: Is your full stack claim real, and where does your depth actually sit?
How to answer: Pick one feature and go layer by layer: the data change and why, the endpoint and its contract, the interface state, and how it was released. Include one decision you debated at each layer. Be honest about which part you found harder.
“Where do you put validation — client, server or database?”
What they're really asking: Do you understand that these serve different purposes, or do you treat them as interchangeable?
How to answer: Answer all three, with distinct reasons: the client for immediate feedback, the server as the only trustworthy boundary, the database for invariants that must never be violated. Then give an example of a rule you deliberately enforced in only one place and why.
“A user reports a bug. How do you work out which layer it is in?”
What they're really asking: Can you debug across a boundary without bouncing the problem to someone else?
How to answer: Describe a narrowing sequence: reproduce, inspect the network request and response, check whether the server returned wrong data or the client rendered it wrongly, then move down to the query if needed. Mention the trap of fixing the symptom in the interface when the data is wrong.
“How do you decide what is good enough when the deadline is fixed?”
What they're really asking: Do you cut scope deliberately and communicate it, or quietly ship something half-finished?
How to answer: Give your ordering: correctness of data first, then the paths users will actually hit, then polish. Describe a real case where you named the cut in advance, who you told, and what the follow-up was. Make clear that the cut was a decision, not an accident.
“What is the most complex thing you have built alone?”
What they're really asking: What is your genuine ceiling without a specialist beside you?
How to answer: Choose scope over glamour: something with real constraints, several moving parts and consequences if it broke. Explain the hardest decision and what you did when you got stuck. Say what you would seek help with next time rather than claiming it was smooth.
“How do you keep from being mediocre at both sides?”
What they're really asking: Are you self-aware about the central risk of this role, and do you manage it?
How to answer: Name your deeper side and the reason for it. Describe how you keep the other side current — reviewing code there, taking specific tickets, following a small number of sources. Give a concrete example of something you learned in the last six months on your weaker side.
What to bring as evidence
A repository containing one feature implemented across both layers, with tests
A short diagram of a system you built showing the data, API and client layers
A live URL for something you shipped, with a note on what you owned
One measurement of an improvement you made, on either side of the stack
Two references who can speak to your delivery across a whole feature
A written summary of a cross-layer bug you diagnosed and fixed
Common mistakes
Claiming even depth on both sides when the interview will quickly show otherwise
Spending the assessment perfecting the interface while the data layer stays incomplete
Treating client-side validation as sufficient and leaving the server unguarded
Describing features by technology used rather than by the problem and the outcome
Handing a cross-boundary bug to someone else at the first sign of difficulty
Building an ORM-driven feature without ever looking at the queries it produces
Questions to ask them
- ?
How is work actually split here — does one person carry a feature across the stack?
- ?
Which layer of the codebase causes the most rework at the moment?
- ?
Who owns the API contract when the frontend needs it to change?
- ?
How does a change reach production, and how long does that usually take?
- ?
What does the team do when a bug sits ambiguously between two layers?
- ?
Where would you want this role to specialise over the next year, if anywhere?
Frequently Asked Questions
Is it a problem if I am clearly stronger on one side?
No, and most working full stack engineers are. It becomes a problem only when you present an even profile and the interview exposes the gap. Name your stronger side, describe how you cover the other, and give a recent example of learning on the weaker one.
How deep should my database knowledge be?
Deep enough to design a sensible schema, write a query without an ORM, read an execution plan and recognise an N+1 pattern. You are not expected to tune a database engine, but a full stack engineer who cannot explain why a query is slow will usually be levelled down.
Do full stack roles pay less than specialist roles?
Compensation depends far more on company, level and location than on breadth. What breadth changes is where you are most valuable: small teams and early products reward it heavily, while large organisations with dedicated specialists may value it less. Choose the environment accordingly rather than expecting a fixed answer.
What should I do if the assessment covers a framework I have not used?
Say so early and ask whether you may use an equivalent. Most teams allow it, because they are testing whether you can build a coherent slice. If you must use the unfamiliar one, spend the first minutes on the parts you know and be explicit in your notes about what you would verify with the documentation.
Should I rehearse the practical stage before the real one?
It helps particularly for full stack roles, where the difficulty is allocating limited time across two layers rather than the code itself. With Cohesyve you can import the job advert, run a simulation matched to the role, and get a scored report plus a learning pathway pointing at your weaker layer. The free tier covers three scored assessments without a card.
Practice
What a Full Stack Developer assessment tests, and how it's scored →
Career guide
What a Full Stack Developer actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a Full Stack Developer role? See how your applicants perform before you spend interview time.