Free Full Stack Developer Practice Assessment (2026)

Cohesyve · Practice for candidates

Going for a Full Stack Developer role? Find out how you'd actually score.

Run a Full Stack Developer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.

free assessments a month

no card required

Full

scored report every run

Every

question type included

5 free assessments a month · No card required · Pro from $16/mo

Overview

Full stack assessments test breadth without letting you hide in it. You are usually asked to deliver a thin slice end to end — a schema change, an endpoint, and the interface that uses it — within a fixed window. What is marked is whether the seams line up: whether the contract you designed is the one your interface consumes, and whether the whole path behaves when something fails. This page covers the formats, the scoring, and how to prepare.

Why employers assess this role

The claim of being full stack is easy to make and hard to verify, because most candidates are genuinely strong on one side and passable on the other. Employers assess with an end-to-end task because it exposes exactly where the weaker half is, and because integration defects — a mismatched contract, an unhandled error crossing the boundary — are the ones that surface late and cost the most.

What gets tested

API design and contract clarityData modelling and query correctnessInterface construction and state handlingAuthentication and authorisation across the stackError propagation from database to screenValidation on both sides of the boundaryTesting at the layer that mattersPrioritisation under a fixed time budget

The format

Duration

90–180 minutes

Question types

Build a vertical slice across database, API and interface
Extend an existing full stack application
Debug a defect that crosses the client-server boundary
Written reasoning about design and trade-offs

Levels

Entry · Mid · Senior

What you'll be asked to do

Deliver a feature end to end

The defining format. A single feature that requires a schema change, an endpoint and a screen. Assessors watch how you sequence the work as much as what you produce.

•Add commenting to an existing resource, including the model, the endpoint and the interface
•Build a filtered, paginated view with the server-side query behind it
•Add a status field that is editable from the interface and validated on the server

Define and honour a contract

The seam between client and server is where marks are gained and lost. Assessors check whether the interface handles every response the server can actually return.

•Define the error shape your endpoint returns and consume it properly on the client
•Decide which validation lives on the server, which on the client, and why
•Specify what the endpoint returns on an empty result versus a missing resource

Handle authentication and authorisation

Frequently included precisely because candidates enforce access in the interface and forget the server. Any check that only exists on the client is treated as absent.

•Restrict an endpoint so a user can only read their own records
•Hide an action in the interface and enforce the same rule server-side
•Decide what happens when a session expires mid-request

Debug across the boundary

A defect where the symptom is in the interface and the cause is on the server, or the reverse. You are marked on how methodically you isolate the side at fault.

•A saved value disappears after a page reload; find where it is lost
•A list renders duplicates after a create action
•A request succeeds in the terminal and fails from the browser

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.

Sample tasks — and what strong looks like

Add a feature that lets a user attach a note to a record: design the schema change, expose it through an endpoint, and build the interface for creating and viewing notes.

Mid

What strong looks like: A coherent slice where the server validates, the client reflects the same rules, failures are surfaced to the user rather than swallowed, and the create action cannot be double-submitted. Weak submissions build a polished form against an endpoint that silently accepts invalid input.

A value saved through the interface is missing after the page is reloaded. Find where it is lost.

Entry

What strong looks like: Isolates the layer methodically — inspects the request, then the handler, then what was persisted — rather than editing the client hopefully. Names the actual cause, commonly a field dropped in validation or never included in the write, and fixes it there.

An existing endpoint returns every record in a table and the page has become slow. Make it acceptable without breaking the interface that consumes it.

Mid

What strong looks like: Adds server-side pagination with a defined default, indexes the query behind it, and updates the client to request pages and render a loading boundary. Weak answers paginate only in the client, which moves nothing off the wire.

Restrict an existing feature so users can only see and edit records belonging to their own organisation.

Senior

What strong looks like: Enforcement in the data access layer so no route can bypass it, a deliberate choice between a not-found and a forbidden response, and the interface reflecting the same rule for usability rather than for security. Weak answers filter in the client and leave the endpoint open.

How to prepare

#1
Practise building a complete vertical slice in one sitting, because the skill being measured is finishing a whole path rather than polishing either end of it.
#2
Decide your sequence in advance — schema, then endpoint, then interface, then edge cases — so you are not re-planning while the clock runs.
#3
Rehearse the error path across the boundary until returning a structured error and rendering it usefully takes minutes rather than being cut for time.
#4
Practise enforcing authorisation server-side by default, since any rule that exists only in the interface is scored as a security failure.
#5
Get quicker at the half of the stack you are weaker in, because assessors deliberately look for the imbalance and it is where the marks go.
#6
Run a full timed mock and note where the time actually went, as full stack tasks overrun more often than any other format.

Common mistakes

Spending most of the window on the interface and shipping an endpoint that was never finished.
Validating input on the client only and trusting whatever arrives at the server.
Letting server errors surface as a blank screen or a silent failure.
Designing an endpoint whose response shape the interface then works around with reshaping code.
Ignoring the empty state, so a new account sees a broken page rather than a starting point.
Submitting without running the whole flow once from a clean database.

How it's scored

Criterion	What strong looks like
End-to-end completeness	The feature works from database to screen, including the create, read and failure paths, rather than being finished on one side only.
Contract quality	The endpoint has a predictable shape, defined status codes and an error format the client actually consumes.
Security	Authorisation is enforced where it cannot be bypassed, input is validated server-side, and queries are parameterised.
Balance across the stack	Neither side is obviously neglected, and the weaker half is still competent rather than left as scaffolding.
Prioritisation	The important behaviour was built first, and anything cut was named explicitly with a note on how it would be completed.

Frequently Asked Questions

Which stack will I be assessed in?

Usually the employer's, and normally stated in advance. Where the choice is open, take the stack you can move fastest in — the marking is about the seams and the reasoning, not idiomatic use of a particular framework.

How should I split my time between front and back end?

Build the thinnest working path across both first, then deepen. Candidates who perfect one side and leave the other unfinished score worse than those who deliver a plain but complete slice.

Do I need tests on both sides?

One or two well-chosen tests at the layer carrying the logic is usually enough, and is markedly better than none. Test the validation or the authorisation rule rather than a render that obviously works.

How polished does the interface need to be?

Clean and usable, not designed. Time spent on visual refinement while an endpoint remains incomplete is the single most common way candidates lose a full stack assessment.

Can I try a scored full stack task before a real one?

Yes, and it is the quickest way to find out which half of your stack is slowing you down. Cohesyve gives five free scored assessments a month, with a report and a learning pathway, and asks for no card.

Practise another role

Cohesyve · Practice for candidates

Practise a Full Stack Developer assessment now — free.

Five scored assessments a month, a full report on every run, and a learning pathway built from what you got wrong. No card required.