Cohesyve · Practice for candidates
Preparing for a Backend 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
Backend interviews are less about syntax than about judgement under constraints — data modelling, failure handling, and the decisions that are expensive to reverse. A typical process runs from CV screen to recruiter call, then a practical coding or system exercise, then technical interviews covering design and debugging, and finally a conversation about ownership and on-call. Candidates with strong delivery records often stumble because they have never had to explain their design decisions aloud. This page covers each stage and what to practise for it.
The hiring process, stage by stage
Application and CV screen
A quick assessment of language, scale and domain fit. Reviewers look for the type of system you worked on — transactional, high-throughput, data-heavy, integration-heavy — because that predicts fit better than the language alone.
How to prepare: State the system shape explicitly: request volume, data size, whether it was a monolith or services, and what you personally owned. Replace 'worked on the API' with the specific surface and the outcome. Keep the stack line accurate rather than aspirational.
Recruiter screen
A short call to confirm level, expectations and availability, plus a check that your description of your work matches the advert. Frequently the point where the process structure is explained.
How to prepare: Prepare a short, non-jargon description of what your service did and who depended on it. Have your range and notice period settled. Ask which parts of the stack you would own and whether the role carries an on-call rotation.
Coding or take-home exercise
Usually a small service or endpoint with real requirements — validation, persistence, error handling, sometimes concurrency. Scoring favours correctness, clear boundaries and tests over cleverness.
How to prepare: Practise building a small, complete service against a timer, including input validation, error responses and a handful of meaningful tests. Rehearse the project skeleton so setup does not eat your budget. Write a README covering assumptions and trade-offs.
Technical and system design interviews
One or two sessions covering data modelling, API design, failure modes and scaling. Often includes a debugging or code-reading exercise on an unfamiliar service.
How to prepare: Practise a repeatable design structure: clarify requirements, define the data model, sketch the components, then walk failure cases. Rehearse two systems you have actually worked on to the point where you can draw them from memory and name their weaknesses.
Final interview with the engineering manager
Covers ownership, incident behaviour, how you handle technical debt and disagreement, and whether you operate at the level advertised.
How to prepare: Prepare an incident story with your actual role in it, a story about a design decision you got wrong and what it cost, and a story about pushing back on a deadline. Be specific about what you decided rather than what the team decided.
What to study
Data modelling and databases
The schema is the decision that outlives every other one in a backend system, and interviewers use it to gauge experience quickly.
API design and contracts
Most backend work is defining and maintaining contracts other teams depend on, and breaking one is expensive.
Concurrency and failure handling
Interviewers probe here because production failures come from concurrent access and partial failure, not from the happy path.
System design at your level
The design round is where levelling is decided, and vague answers get read as inexperience even when they are not.
Observability and operations
Teams increasingly expect backend engineers to run what they build, so operational vocabulary signals seniority.
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.
Your preparation plan
Four weeks out
Rebuild your foundations in data and design rather than grinding puzzles.
- •Draw two systems you have worked on from memory and mark their failure points
- •Work through query plans on a real dataset until reading one is routine
- •Build one small service end to end with validation, tests and error handling
- •Read the job advert closely and list the three requirements you can evidence least well
Two weeks out
Practise explaining decisions aloud under time pressure.
- •Do two timed system design walkthroughs a week using a fixed structure
- •Record yourself explaining a schema decision and listen for hedging
- •Prepare an incident story and a wrong-decision story, two minutes each
- •Practise reading unfamiliar service code and summarising what it does in five minutes
The final week
Rehearse the real format instead of adding new material.
- •Complete one full timed coding exercise from a cold start, including tests
- •Prepare a project skeleton so environment setup does not consume your budget
- •Re-read any submission you have already sent and prepare defences for its weak points
- •Draft your questions for the panel, prioritising the ones about how the team operates
The day before and the day of
Reduce friction and settle your opening moves.
- •Test your tooling, screen share and any shared editor the company uses
- •Re-read your own notes on the two systems you plan to reference
- •Plan your first three minutes of any design question: clarify, constrain, then model
- •Write down the two things you most want the interviewer to remember about you
Questions to expect
“Design a service that handles payments retries safely.”
What they're really asking: Do you understand idempotency and partial failure, or do you assume the network behaves?
How to answer: Start by clarifying guarantees: exactly once is not available, so aim for at-least-once delivery with idempotent processing. Describe the idempotency key, where it is stored, how you detect a duplicate, and what happens when a response is lost after the write commits. Name the failure case you cannot fully solve.
“How would you speed up a query that has become slow in production?”
What they're really asking: Do you measure and reason, or do you add an index and hope?
How to answer: Say what you would look at first — the query plan, the row counts, whether it degraded gradually or suddenly. Separate the causes: missing index, changed data distribution, lock contention, N+1 from the application. Then give your fix and how you would verify it under real load.
“When would you introduce a queue between two services?”
What they're really asking: Do you add infrastructure by default, and do you understand the costs a queue introduces?
How to answer: Name the specific problem a queue solves for you: decoupling availability, smoothing load spikes, or allowing slow work to happen off the request path. Then name the costs you accept — ordering, duplicates, delayed feedback, another thing to operate. Conclude with when you would keep the synchronous call instead.
“Tell me about a production incident you were involved in.”
What they're really asking: How do you behave under pressure, and do you take real ownership of what went wrong?
How to answer: Set the scene in a sentence, then focus on your actions: how you detected it, what you ruled out, what you did to stop the bleeding, and what changed afterwards. Include a thing you got wrong. Avoid blaming another team, even when they contributed.
“How do you decide what to test and what to leave untested?”
What they're really asking: Do you have a considered position on testing, or do you follow whatever the last codebase did?
How to answer: State your default distribution and the reasoning: heavy coverage on business rules and data boundaries, thinner coverage on wiring. Give a concrete example of a bug class you write tests specifically to catch. Then say where you accept lower coverage and why that is a deliberate choice.
“Walk me through a schema you designed and what you would change now.”
What they're really asking: Have you lived with your own decisions long enough to learn from them?
How to answer: Draw or describe the core tables and the relationships, then name the constraint that shaped them. Identify one decision that caused pain later — a premature denormalisation, a nullable column that should have been a separate table — and explain what you would do instead and what migrating would cost.
What to bring as evidence
A diagram of a system you owned, drawable in under three minutes
A repository showing a small, complete service with tests and clear error handling
A before-and-after latency or throughput measurement with the change that caused it
A written postmortem or incident summary you contributed to, sanitised if needed
Two references who can speak to how you behave when a system is failing
A short note on a design decision you would now make differently
Common mistakes
Jumping straight into a design answer without clarifying requirements or constraints
Describing what the team did without ever saying what you personally decided
Ignoring failure and retry behaviour in a design that clearly needs it
Submitting a coding exercise with no input validation and no meaningful error responses
Naming technologies as answers rather than describing the problem they solve here
Being unable to read a query plan or explain why an index helped
Questions to ask them
- ?
What is the oldest service still in the critical path, and who understands it?
- ?
How do database migrations reach production, and when did one last go wrong?
- ?
What does the on-call rotation look like, and how many pages fire in a typical week?
- ?
Where does the team currently spend time it wishes it did not?
- ?
How are architectural decisions made and recorded here?
- ?
What would you want the person in this role to have changed six months in?
Frequently Asked Questions
How much system design do I need for a mid-level role?
Enough to design a single service end to end: data model, API surface, failure handling and the obvious bottleneck. You are not expected to design a global platform, but you are expected to notice where your design breaks and say so before the interviewer does.
Do algorithm puzzles still come up?
At some companies, yes, but they are less common than they were and rarely the deciding stage outside large firms. Keep your fundamentals sharp enough to handle a moderate problem calmly, and spend the larger share of your preparation on data modelling and design, which is where most backend decisions are actually made.
Does the language on the job advert matter if my experience is in another one?
It matters more for the CV screen than for the interview. Teams hiring at mid-level and above generally accept a strong engineer from an adjacent ecosystem, provided you can discuss the trade-offs of both and show you have picked up a new stack before. Say so explicitly rather than hoping it goes unnoticed.
How should I handle a design question about a domain I have never worked in?
Ask about the domain rules before designing anything. Interviewers expect questions, and assumptions stated aloud are treated as competence rather than ignorance. Design for the rules you have confirmed and flag which parts of your design depend on assumptions you could not verify.
Is it worth rehearsing the practical exercise stage in advance?
It is, because backend exercises punish slow setup and thin error handling more than they reward clever solutions. Cohesyve lets you import the specific job, run a role-relevant simulation of the practical stage, and get a scored report showing where you lost marks, alongside a learning pathway. Your first three scored assessments are free and need no card, which covers a full rehearsal cycle.
Practice
What a Backend Developer assessment tests, and how it's scored →
Career guide
What a Backend 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 Backend Developer role? See how your applicants perform before you spend interview time.