Backend Developer interview questions (India, 2026): what to ask and what to listen for

12 interview questions for a Backend Developer role, grouped by what each round should establish, each with what a strong answer contains, plus a five-point scorecard so every interviewer rates the same things.

Last updated 3 September 2026. Competitor pricing and plan limits are re-verified against each vendor’s own pages.

Interviewing a Backend Developer well means asking about work the candidate has actually done, listening for specifics, and scoring every candidate on the same five criteria. The questions below are grouped by what they establish; each one comes with what a good answer contains, which is the part most question lists leave out.

A Backend Developer builds the services, APIs and data layer behind the product — the schema, the business logic, the integrations with payment gateways and third parties, and the reliability and performance of it all — in a small team where the backend is also the production system you get paged for.

Use the screening questions on the job description page to filter before anyone reaches an interview, and the scorecard at the end so a panel can compare candidates rather than impressions.

What they have built and run

Walk me through a system you built and operated: the architecture, the data model, the hardest bug in production, and what you changed after it.: A strong answer: End-to-end ownership including operation. The production bug and the change afterwards separate builders who run systems from those who hand them over.
Describe an integration you built where money or state could go wrong. How did you handle duplicates, failures and reconciliation?: A strong answer: Idempotency keys, retries with backoff, webhook verification, a reconciliation job — and a real incident where it mattered.
Tell me about a slow query you fixed. How did you find it and what did you do?: A strong answer: Read the query plan, added or changed an index, restructured the query or the schema — with numbers before and after.
What did your last incident look like from page to post-mortem?: A strong answer: Composure, a diagnosis method, communication, and a post-incident fix that addressed the cause.

Technical depth

Design the schema and API for [a feature in your domain — e.g. orders with partial refunds]. Think aloud.: A strong answer: Asks clarifying questions, models state transitions explicitly, chooses keys and constraints deliberately, handles the edge cases (partial, repeated, out-of-order events).
Two requests try to update the same record at the same time. What can go wrong and how do you prevent it?: A strong answer: Understands transactions, isolation, optimistic or pessimistic locking, and picks one with a reason.
How do you store and handle personal data — phone numbers, IDs, addresses — in a way that would survive a security review?: A strong answer: Least privilege, encryption at rest for sensitive fields, secrets management, access logging, retention — practical, not theoretical.
A background job processes ten thousand records nightly and now takes three hours. Where do you start?: A strong answer: Measures first, then batching, indexing, parallelism, or moving work out of the hot path — with awareness of memory and database load.

Working in a small team

The frontend developer wants an API that would be awkward for the data model. What do you do?: A strong answer: Understands the UI need, proposes a shape that serves both, explains the trade-off — collaboration over gatekeeping.
How do you decide what deserves a design note versus just doing it?: A strong answer: Proportionate judgement — schema changes, integrations and anything hard to reverse get written down; small changes do not.
How do you keep infrastructure cost visible and under control?: A strong answer: Awareness of what costs money — instances, storage, egress, third-party calls — and habits like reviewing the bill and right-sizing. Relevant to any SME.
What do you want to get deeper in, and does this role offer it?: A strong answer: A direction — distributed systems, data, infrastructure, a domain — the role can plausibly serve.

Scorecard for Backend Developer interviews

Score each candidate on these five criteria, one to four, straight after the interview and before talking to the other interviewers. Written scores taken independently are what make a panel decision defensible; a discussion first produces one opinion with several signatures.

Ownership including operation: built, ran, and fixed a production system.
Integration correctness: idempotency, failure handling, reconciliation from experience.
Data modelling and SQL: sound schema, understands plans, locks and transactions.
Security and cost awareness: practical handling of personal data and infrastructure spend.
Collaboration and judgement: API shapes, design notes, learning direction.

Screen before you interview

Most Backend Developer interviews that go badly were avoidable at the application stage. The job description template for this role carries five screening questions that settle the deal-breakers — notice period, location, the one or two hard requirements — before anyone books a slot.

How many years of professional experience do you have building production backend services in [language / framework]? — knockout
Have you built or maintained a production integration where correctness mattered — payments, messaging, KYC — including its failure handling? — for context
Are you able to work [from our City office X days a week / remote with overlap hours] and take part in an on-call rota? — knockout
What is your current notice period, in days? — for context

Questions, answered straight

What is the best Backend Developer interview question?

Ask about an integration where money or state could go wrong — how they handled duplicates, failures and reconciliation. It tests correctness thinking, operational experience and honesty about incidents in one answer, and it is specific to the kind of work an SME backend actually does.

Should a backend interview include system design?

A small one, sized to your product: the schema and API for one feature with awkward edge cases, thought aloud. Large-scale distributed-systems design rounds test for a job you are not hiring for.

How do I assess SQL skills?

Ask about a slow query they fixed and how, then give them one of your own tables and a query to improve. Candidates who read query plans and reason about indexes are the ones who will keep your database healthy.