Backend Developer Assessment

Why Backend Developers are hard to hire well

Backend mistakes are quiet. A badly built interface is obvious within a day because somebody looks at it. A badly designed service can run correctly for eighteen months and then fail on the afternoon the load doubles, or the day a retry arrives twice, or the moment a second consumer starts depending on a field that was never meant to be public. The feedback loop between the decision and the consequence is long enough that neither the engineer nor their references ever connects the two.

That has a direct effect on hiring. A candidate can point to services they built which are, at the time of the interview, working. They will describe them accurately and confidently. What you cannot learn from that conversation is whether the service is working because it was designed well or because it has not yet been asked a hard question. References tend to be equally uninformative for the same reason.

The role also sits at the intersection of three specialisms that are usually taught separately: application code, data modelling, and operational behaviour. An engineer who is strong at two of the three is common and can look excellent throughout a hiring loop. The failure mode is specific and predictable. Strong on code and data but weak operationally produces elegant services that nobody can diagnose at two in the morning. Strong on code and operations but weak on data produces a schema that becomes the constraint on everything the product wants to do next.

What separates the best from the rest

The best backend engineers design for the second caller. The difference between a competent endpoint and a good one is almost always in the parts that only matter to somebody else: the error model, the pagination contract, the versioning story, the behaviour when the same request arrives twice. Weak candidates optimise the happy path and treat everything else as an exception to handle later. Strong ones start from the failure cases, because in a distributed system the failure cases are the system.

They also have a healthy fear of data. Code can be rolled back; a migration that has already run against production cannot be, not really. The engineers worth hiring know the expand-and-contract pattern by instinct, batch their backfills, and never make a schema change that requires two services to deploy at the same instant. This is not advanced knowledge, but it is knowledge that is almost always acquired through one bad experience, and you would prefer that experience did not happen on your data.

The third marker is instrumentation. Weaker candidates add logging when something breaks. Stronger ones instrument as they build, because they assume they will be asked a question about production behaviour that they cannot anticipate today. When something goes wrong in a service built by a good engineer, the answer is already in a trace. In a service built by a weak one, the first hour of the incident is spent adding the logging that should have been there.

Why interviews alone fall short

The classic backend interview is a system design conversation, and it has a well-known failure: it rewards vocabulary. A candidate who says “we would put Kafka in front of it for durability, shard on tenant, and add a read replica” sounds authoritative, and the format makes it difficult to establish whether they have ever operated any of those things or are reciting a diagram from a blog post. The whiteboard cannot show you what they would do when the sharding key turns out to be wrong.

Coding screens fail in the other direction. They test whether a candidate can write a correct function, which almost every employable backend engineer can do, and they never touch schema evolution, contract design or debugging a system where the bug is a race between two services. Situational scenarios cover the ground both formats miss. Every candidate faces the same migration with the same row count and the same awkward downstream team, and their answer tells you what they will actually do when the same situation arrives in your codebase in month three.

Common hiring mistakes in backend recruitment

• Screening on language rather than reasoning - a strong engineer moves between Java, Go and TypeScript in a matter of weeks, and a weak one is weak in all three
• Never asking about migrations - it is the highest-risk routine activity in the role and it appears in almost no interview loop
• Confusing system design fluency with operational experience - the ability to draw the architecture and the ability to run it are separate skills that correlate less than expected
• Skipping the on-call question - if the role carries a pager, ask what the candidate did in their last incident, because that answer is difficult to fabricate convincingly
• Treating API design as an implementation detail - once external consumers exist, a poor contract is close to permanent, and it constrains the product long after the engineer has moved on

The work this role is assessed against

• Build and refine REST, gRPC, and GraphQL endpoints and background jobs
• Design schemas, write queries, and create and execute database migrations
• Containerise services and deploy to Kubernetes or a cloud PaaS
• Integrate third-party services (payments, auth, messaging) securely
• Instrument services with logs, metrics, and traces, and resolve production incidents with root cause analysis

Tools and outputs this role works with

Java and Kotlin (Spring Boot), Node.js and TypeScript (Express, NestJS), Python (Django, FastAPI), C# (.NET), PostgreSQL and MySQL, MongoDB, Redis, Kafka and RabbitMQ, gRPC, REST and GraphQL, Docker, Kubernetes, AWS, GCP and Azure, GitHub and GitLab with CI (Actions, Pipelines), Jenkins and CircleCI, OpenAPI and Swagger, Postman and Insomnia, Terraform and Helm, Prometheus and Grafana, ELK and OpenSearch, Datadog, New Relic and Sentry, and IntelliJ IDEA or VS Code.