17
Interview questions with listen-for notes
BACKEND DEVELOPER INTERVIEW QUESTIONS
Backend Developer Interview Questions
Backend interviews go wrong in a predictable way: they test puzzle performance instead of engineering judgment. The developer you need designs data models that survive growth, debugs production at 2 pm on a Tuesday, and tells you honestly when the estimate is wrong. Interview for that.
These questions favor real-system discussion over whiteboard algorithms: architecture decisions the candidate actually made, debugging stories with mechanisms, API and data judgment, and the collaboration habits that make a remote engineer legible. Use the code-review test task at the bottom; an hour reviewing realistic code beats three hours of live puzzles.
- 17 questions
- Employer-side guide
- Includes a paid test task
At a glance
What this backend developer interview kit covers
Every question comes with a note on what a strong answer sounds like, so a non-specialist can run the interview and still read the signal.
4
Interview stages covered
1
Paid test task blueprint
$6,000/mo
Median nearshore backend developer rate
Before you interview
What a backend developer interview has to establish
The real failure mode
The highest-signal backend interview question is some version of: walk me through a system you built, and defend its decisions. Real engineering lives in tradeoffs: what was denormalized and why, where consistency was relaxed, what got queued, what the schema regrets are. Candidates who built the systems they claim can descend fluently from architecture to table design to the specific query that caused the incident, and they volunteer regrets without prompting. Candidates who orbited the work stay at diagram altitude and cannot answer the third why. You do not need to be deeply technical yourself to see the difference, though having your most technical person in the room makes it sharper.
What to test for
For a remote hire, weight communication almost as heavily as engineering. A brilliant backend developer who goes silent for four days is operationally worse than a good one who surfaces blockers in hours, writes readable pull request descriptions, and flags scope surprises early. Probe for the habits directly: how they hand off work, what their PRs look like, how they raise a slipping estimate. Nearshore developers share your working day, which makes the tight feedback loop possible; the interview establishes whether the candidate has the habits to use it.
Stage 1
System deep dive
Pick their most substantial system and descend through it. Depth of ownership is unfakeable at the third level of why.
Describe the most significant backend system you have built or substantially owned: what it did, the stack, the scale, and your specific fingerprints on it.
What to listen for: Concrete ownership markers: components they designed, decisions they argued for, code they would recognize years later. Scale claims should come with numbers: requests, records, team size. This question sets up the whole section; vagueness here means vagueness everywhere.
What part of that system's design would you change today, and what did the original design get wrong?
What to listen for: Unprompted regret fluency: a schema that made a common query expensive, an abstraction that leaked, a queue added too late. Engineers who owned systems accumulate regrets; the quality of the regret is the quality of the engineer. No regrets means no ownership or no reflection.
Walk me through the data model at the heart of it: the main entities, the relationships, and one modeling decision that mattered more than it looked.
What to listen for: Comfort at table-and-index altitude: why something was normalized or denormalized, where uniqueness was enforced, what indexed lookups the access pattern demanded. Backend quality is disproportionately data-model quality, and this is where borrowed systems get exposed.
Tell me about the worst production incident that system had on your watch: detection, diagnosis, fix, and what changed afterward.
What to listen for: A mechanism, not a mystery: how it was detected (ideally by monitoring, not by customers), the debugging path with dead ends included, the actual root cause, and a prevention change like a test, an alert, or a design fix. Engineers tell incident stories with timestamps; performers tell them with morals.
Where did that system hit performance limits, and what did you do about them?
What to listen for: Measurement before optimization: profiling or query analysis identifying the real bottleneck, then a proportionate fix: an index, a cache with an invalidation story, a query rewrite, a queue. Candidates who jump to rewrites and microservices without measurement stories optimize by fashion.
Stage 2
Design and judgment scenarios
Present realistic problems and grade the questions they ask you as heavily as the answers they give.
We need an endpoint that lets customers export all their data, potentially millions of rows. Design it out loud.
What to listen for: Recognition that synchronous is wrong at scale: an async job with status polling or notification, pagination or streaming, file delivery via storage links, rate limiting, and tenant isolation so one export cannot starve the system. Strong candidates ask about data size and freshness requirements before designing; that instinct is the hire.
A previously fast endpoint has degraded slowly over three months and is now timing out for your biggest customer. Walk me through your diagnosis, step by step.
What to listen for: A systematic path: reproduce and measure, check what grew (data volume, payload size), inspect the query plan, look for N+1 patterns introduced by feature changes, check the biggest-customer dimension since size often triggers plan changes. The slow-degradation detail rewards candidates who think in growth terms rather than sudden-breakage terms.
You need to add a breaking change to an API that external clients depend on. How do you ship it?
What to listen for: Versioning discipline: a new version or additive change path, deprecation communication with timelines, usage monitoring to see who still calls the old shape, and sunset only when the data says it is safe. Candidates who would just change it and notify are one incident away from learning this expensively on your customers.
Where do you stand on using AI coding assistants, and what guardrails do you personally apply to generated code?
What to listen for: Pragmatic adoption with ownership: they use assistants for speed but review generated code to the same standard as their own, watch for subtle correctness and security issues, and never ship what they cannot explain. Both extremes are yellow flags: refusal signals rigidity, and uncritical acceptance signals exactly the review laziness that creates incidents.
How do you decide what gets a test? Describe your actual testing practice on your last project, not the ideal one.
What to listen for: An honest, reasoned testing economy: business-critical paths and bug regressions always covered, integration tests where the risk lives, and candor about the gaps and why. The confession version of this answer is worth more than the textbook version; engineers with real practices can describe real tradeoffs.
Stage 3
Collaboration and remote habits
A remote engineer's work is only as good as its legibility. Test the communication layer explicitly.
Show me what a good pull request looks like from you: size, description, and what you write for reviewers.
What to listen for: Reviewer empathy: scoped changes, a description covering the why and the risk areas, self-review comments on non-obvious choices, and test evidence. Engineers who describe thousand-line PRs with one-line descriptions are exporting their review burden to your team.
Your estimate was three days; on day two you realize it is more like two weeks. What exactly do you do, and when?
What to listen for: Same-day disclosure with a diagnosis: what turned out to be different, the new estimate with confidence level, and options like a reduced scope that still ships value. The engineers who damage teams are not the slow ones; they are the ones you find out about at the deadline.
You disagree with a technical decision your lead has made. Walk me through what you do, and tell me about a real time this happened.
What to listen for: Disagreement with evidence and a commit-after-decision ethic: they made the case with tradeoffs, accepted the call once made, and revisited only with new data. Both failure modes matter: silent compliance breeds hidden debt, and relitigating breeds exhaustion.
Working from Latin America with a US team, describe your ideal collaboration rhythm: overlap hours, focus time, and how the team knows what you are doing without asking.
What to listen for: A deliberate structure: core overlap for standups, reviews, and pairing, protected deep-work blocks, and visibility habits like end-of-day updates and tracked tickets. Nearshore engineers share most of the US day, so the failure mode of overnight silence is optional; the candidate's habits determine whether you get the benefit.
Stage 4
Growth and engineering values
Stacks change; values persist. Test what they optimize for when nobody specifies.
What is the last significant thing you learned because a project demanded it, and how did you get competent fast?
What to listen for: A learning mechanism: docs and source over tutorials, a spike project, finding the sharpest available person to interrogate. Backend careers are serial confrontations with unfamiliar systems; the mechanism matters more than the specific technology named.
When is code good enough to ship? Reconcile that with the worst shortcut you have seen come back to bite a team.
What to listen for: A shipping philosophy with a debt ledger: correctness and security non-negotiable, polish negotiable with a payback plan, and a real story of deferred debt collected with interest. Perfectionists and cowboys both fail this question in opposite directions.
What do you want to be doing technically in three years, and what does this role need to give you for the next eighteen months to be worth your best work?
What to listen for: A trajectory your role can actually feed: deeper architecture ownership, a new domain, mentoring. Mismatch discovered now is cheap; discovered at month eight, it costs you a trained engineer.
Beyond the interview
Paid test task: the code review
Pay finalists for a 60 to 90 minute exercise reviewing a realistic pull request you prepare once and reuse: 200 to 300 lines implementing a small feature, seeded with one security issue (say, an injection or missing authorization check), one N+1 query, one race condition or concurrency smell, one misleading name or dead code block, and a design choice that works but will not scale. Ask for written review comments as they would post them, plus a summary verdict: approve, request changes, or block, with reasoning. Score what they catch, how they prioritize it, and the tone of the comments. This tests reading ability, security instinct, performance sense, and collegial communication at once, and it is far closer to daily work than algorithm puzzles.
Red flags
Backend Developer red flags that predict a bad hire
Any one of these is worth a hard second look. Two or more, and the polished answers elsewhere in the interview stop mattering.
Cannot descend below architecture diagrams
Ownership shows at table, query, and incident altitude. A candidate fluent in boxes and arrows who fumbles the data-model follow-ups orbited the system they are claiming.
No production incident stories
Engineers who have operated real systems have been paged, have debugged under pressure, and have prevention stories. A spotless operational history means untested code paths or untested candor.
Optimizes by fashion, not measurement
Reaching for rewrites, microservices, or a trendier stack without a profiling story is expensive taste. The question is always what did you measure, and it should have an answer.
Estimates never miss, or misses surface late
Every real backlog has surprises. The disqualifier is not the miss; it is a candidate whose answer to the day-two scenario involves waiting until they are sure, which in practice means the deadline.
Sloppy or hostile in the code-review exercise
Review comments that miss the security issue are a competence problem; comments that are correct but contemptuous are a team problem. Either one taxes every engineer they work with.
FAQ
Interviewing a backend developer: FAQ
Should I use live coding, take-home projects, or code review to assess backend developers?
Code review plus system deep-dive conversation is the highest signal per hour for most teams. Live algorithm coding selects for interview practice and punishes nerves; long take-homes select for free time and get inconsistent effort. A paid, time-boxed review of realistic code tests reading, security instinct, and communication, which is most of the daily job. Add a short pairing session on real-world-shaped code if you need to see them write, not just read.
How do I interview backend developers if I am not technical?
Borrow depth and structure. Use the system deep-dive questions on this page and grade the qualities that do not require expertise to judge: specificity, willingness to name regrets and tradeoffs, and whether answers get more concrete under follow-up rather than more abstract. For the final round, bring in a technical advisor, a fractional CTO, or use a staffing partner whose vetting includes technical screens. What you can always evaluate yourself: the communication scenarios, which predict remote success as strongly as the technical ones.
What English level does a backend developer really need?
Strong written English is non-negotiable: PRs, design docs, incident notes, and async updates are the work product's connective tissue. Spoken fluency matters at standup-and-discussion level rather than presentation level for most teams. Latin American senior developers overwhelmingly clear this bar, and the interview itself is your test: their answers to the system deep-dive are a direct sample of how they will explain technical reality to your team every week.
How senior a backend developer should a small team hire nearshore?
For a first or only backend hire, pay for senior: the role includes architecture decisions with long half-lives and no one to catch mistakes. Mid-level engineers thrive nearshore when a lead exists to review designs and PRs. The cost gap between mid and senior in Latin America is small relative to the blast radius of unsupervised architecture, which is exactly the math the salary figures on this page let you run.
Keep planning
Tools for the rest of the hire
Budget first? See real backend developer rates across Latin America or browse interview questions for other roles.
Ready To Move
Skip the screening: hire a pre-vetted backend developer
These questions exist because unvetted hiring is risky. LavaStaff runs this screening for you: every backend developer candidate is interviewed, tested, and reference-checked before you ever meet them, with contracting and payroll handled.