Free Backend Developer Practice Assessment (2026)

Cohesyve · Practice for candidates

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

Run a Backend 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

Backend assessments test judgement more than syntax. You are typically given an API to extend, a schema to design, or a broken service to diagnose, and scored on whether your solution holds up under conditions the prompt did not spell out — concurrency, failure, and scale. This page covers the formats, the scoring, and how to prepare.

Why employers assess this role

Backend mistakes surface late and cost a great deal — a race condition or an unindexed query on a hot path can survive code review and fail in production. Employers assess up front because interview conversation reliably distinguishes people who can talk about correctness from people who can talk about it, but not implement it.

What gets tested

API design and clear contractsData modelling and schema designQuery correctness and performanceConcurrency, idempotency and race conditionsError handling and failure modesTesting strategySecurity fundamentals — authorisation, injection, secret handling

The format

Duration

60–120 minutes

Question types

Extend or fix an existing service
Design a schema and the queries against it
Debug a failing or slow endpoint
Written design reasoning

Levels

Entry · Mid · Senior

What you'll be asked to do

Design an endpoint or a service

Given a requirement, define the contract and implement it. Assessors look at the shape of the interface as much as the code behind it.

•Design and implement an endpoint that transfers a balance between two accounts
•Add pagination to a collection endpoint that currently returns everything
•Expose a resource with filtering, and define what happens on an invalid filter

Model the data

Schema tasks reveal whether you think about constraints or only about columns. Uniqueness, nullability and foreign keys are all scored.

•Model a booking system where a resource cannot be double-booked
•Design a schema supporting soft deletes without breaking uniqueness constraints
•Add an index for a stated query pattern and justify the column order

Handle concurrency and failure

The distinguishing section at mid and senior level. The naive solution usually passes the happy path and fails under two simultaneous requests.

•Make a payment endpoint safe to retry without double-charging
•Prevent two concurrent requests from both claiming the last unit of stock
•Decide what happens when a downstream call times out halfway through a write

Diagnose something slow or broken

You are given a failing test, a slow query, or an error log, and asked to work back to the cause.

•An endpoint degrades badly as a table grows; find out why
•A background job occasionally processes the same record twice
•A query is fast in development and slow in production

Cohesyve for candidates

Practise a Backend 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

Implement an endpoint that deducts stock when an order is placed. It must be safe when two requests arrive at the same moment.

Mid

What strong looks like: Recognises the race condition without being prompted and handles it deliberately — a transaction with appropriate locking, a conditional update, or a unique constraint. Weak submissions read the stock, check it in application code, then write, which fails under concurrency.

A list endpoint takes 4 seconds. Diagnose and fix it.

Mid

What strong looks like: Measures before changing anything, identifies the actual cause (commonly an N+1 or a missing index), fixes that specifically, and confirms the improvement. Weak answers add a cache over the top and leave the underlying problem.

Design the schema for a system where users belong to multiple organisations with different roles in each.

Entry

What strong looks like: A join table carrying the role, correct composite uniqueness, and a clear answer for what happens when a user is removed from one organisation but not another.

Make a webhook receiver safe to call repeatedly with the same event.

Senior

What strong looks like: Uses an idempotency key persisted with a unique constraint, decides deliberately between ignoring and re-processing duplicates, and handles the case where the first attempt failed midway.

How to prepare

#1
Practise writing the failure cases first. Concurrency and retry safety are the highest-signal sections and the ones most candidates skip.
#2
Be able to read an execution plan and explain why a query is slow. This comes up constantly and is quick to learn.
#3
Rehearse stating a contract precisely — status codes, error shapes, and what happens on invalid input.
#4
Write at least one test in every submission, even a small one. Its absence is noticed.
#5
Know the security basics cold: parameterised queries, authorisation checked server-side, and secrets kept out of the repository.
#6
Time a full attempt end to end. Backend tasks run longer than people expect and pacing is a common failure.

Common mistakes

Solving only the happy path and never considering two requests arriving together.
Checking authorisation on the client and assuming the server can trust it.
Building string-concatenated queries out of user input.
Adding caching to hide a performance problem rather than fixing it.
Submitting with no tests at all.
Designing for imagined future scale instead of the requirement actually stated.

How it's scored

Criterion	What strong looks like
Correctness under load	The solution holds when requests overlap and when they are retried. This separates mid from entry level more reliably than anything else.
Data modelling	Constraints enforced in the database rather than only in application code, with sensible nullability and indexing.
Error handling	Failures are explicit and actionable, partial writes are avoided, and the caller can tell what went wrong.
Testing	Tests cover the meaningful edge case rather than only the path that obviously works.
Security	Input is validated, queries are parameterised, and authorisation is enforced where it cannot be bypassed.

Frequently Asked Questions

Which language will I be assessed in?

Usually your choice, or the stack the employer runs. The scoring is generally about design and correctness rather than idiomatic use of a specific language, so pick the one you are fastest in unless told otherwise.

Do I need to write tests?

Write at least one meaningful test even when it is not explicitly required. Its absence is one of the most commonly noted weaknesses, and one test covering the tricky case demonstrates more than several covering the obvious one.

How much should I optimise?

Fix the thing the task points at, and say what you would do next. Premature optimisation of the parts nobody asked about tends to cost marks rather than earn them.

What if I cannot finish?

Make what you have correct and leave a short note on what remains and how you would approach it. A working subset with clear reasoning outscores a broken whole.

How can I find out where I stand before a real one?

Run a scored practice assessment. Cohesyve includes five free assessments a month with a full report showing exactly which criteria you lost marks against.

Practise another role

Cohesyve · Practice for candidates

Practise a Backend 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.