Walk me through how you would design a payments-reconciliation service.

System design is where Backend Engineer offers are won and lost. The panel wants to see structured thinking on a finance-grade problem. Strong candidates clarify requirements first: payment volume, source systems (card, bank transfer, wallet), reconciliation cadence (real-time, end-of-day), error tolerance, audit requirements. They then walk through ingestion (idempotent, exactly-once where required), matching logic (rule-based or fuzzy), exception handling, double-entry ledger pattern, and the regulatory/audit log. Mention specific technologies (Postgres for the ledger, Kafka for ingestion, dedicated reconciliation service). Weak candidates skip clarification or design without idempotency. The kill-shot is forgetting the financial-correctness primitive: every transaction must be traceable, immutable and auditable.

Explain database indexing and when you would choose a B-tree vs a hash index vs a GIN index.

Database depth is non-negotiable for senior Backend Engineer roles in 2026. Strong answers cover: B-tree for range queries and ordered scans (default for most), hash for equality lookups only (rare in practice), GIN for full-text search and JSONB containment queries, BRIN for very large append-mostly tables. Mention covering indexes, partial indexes and the cost of writes (every index added slows inserts and updates). Strong candidates know how to read EXPLAIN ANALYZE output. Weak candidates say 'I just add an index when queries are slow' without understanding the trade-off. The kill-shot is not knowing what a covering index is. UK panels at fintech and high-volume e-commerce dig deep here.

Walk me through handling a production incident where p99 latency suddenly spiked from 80ms to 800ms.

Operations instinct. The panel wants method, not heroics. Strong answers go: check dashboards (CPU, memory, GC, DB connection pool, downstream service health), check recent deploys for rollback candidates, isolate by region/instance/route, look at error rates and slow query logs, form a hypothesis (DB index missing on a new query, GC pause, downstream timeout, connection-pool exhaustion), test it, and either fix or rollback. Mention runbook discipline and post-incident review. Weak candidates say 'I would scale up the servers'. The kill-shot is admitting you would push a hotfix without rolling back first. Senior Backend Engineers know rollback is the first-resort, not the last-resort.

How do you handle eventual consistency in a distributed system?

Distributed-systems literacy. The panel wants to hear that you understand eventual consistency is a trade-off, not a bug. Strong answers cover: CAP theorem in plain English, why you choose AP over CP for some flows (cart, view counts) and CP over AP for others (payments, account balance), patterns like read-your-writes, monotonic reads, session consistency. Mention idempotency keys, sagas, and the outbox pattern. Weak candidates conflate consistency with reliability or describe everything as 'we use Kafka'. The kill-shot is recommending strong consistency for everything. Distributed-systems-literate Backend Engineers earn the senior premium in 2026; the question filters for that.

Tell me about a time you optimised a slow database query.

Behavioural with technical depth. Strong answers are specific: 'The query was 4.2 seconds on a 50M-row table. I ran EXPLAIN ANALYZE, found a sequential scan on a non-indexed FK. I added a composite index on (user_id, created_at DESC), the query dropped to 18ms. I also identified that the application was issuing N+1 queries and refactored to a single JOIN, cutting overall request time from 6 seconds to 200ms.' Weak answers describe generic optimisation without numbers. The kill-shot is having no story at all. Senior Backend Engineers in 2026 should have at least three database-optimisation war stories ready, with measurable before-and-after.

How do you choose between SQL and NoSQL for a new service?

Architecture decision. Strong answers reject the false choice: 'It depends on the data shape and the query patterns.' SQL for relational data with ACID needs (financial, user accounts, anything with joins). NoSQL document for hierarchical data with low join needs (catalogues, content). Key-value for cache and session. Wide-column for time-series and analytics. Graph for relationship-heavy domains. Mention that most services in 2026 are polyglot persistence — different stores for different jobs. Weak candidates pick one and defend it ideologically. The kill-shot is recommending NoSQL because 'it scales' without understanding the consistency cost. UK panels at scale-ups test this question constantly.

Walk me through how you would migrate a 100-million-row table to a new schema with zero downtime.

Senior question that filters out engineers without production experience. Strong answers: dual-write pattern. Add the new schema, write to both old and new on every change, backfill historical rows in batches with throttling, switch reads to new once parity is verified, then deprecate the old. Mention monitoring the lag, having a rollback plan, and using a feature flag for the cutover. Weak candidates suggest a single ALTER TABLE or 'we would put up a maintenance window'. The kill-shot is not knowing the dual-write pattern. UK fintech and high-volume e-commerce panels test this scenario specifically because zero-downtime migrations are a senior-level requirement.

How do you decide between async messaging (Kafka, NATS) and synchronous request/response?

Architecture instinct. Strong answers: synchronous when the caller needs an immediate result and the path is simple. Async when the caller does not need immediate result, when you need decoupling, when you need replay, when you need fan-out to multiple consumers, or when load profiles between producer and consumer differ. Mention specific patterns: command vs event vs query, exactly-once semantics, dead-letter queues. Weak candidates default to 'use Kafka for everything' or 'avoid async because it is hard'. The kill-shot is not understanding why async helps with scale-out and resilience. Senior Backend Engineers in 2026 are expected to know both patterns deeply.

Tell me how you handle observability in production services.

Operations question. Strong answers cover the three pillars: logs (structured, searchable, with request/trace IDs), metrics (RED method — rate, errors, duration; or USE method — utilisation, saturation, errors), distributed tracing (OpenTelemetry as the standard in 2026), and SLIs/SLOs/error budgets. Mention real tools you have used (Datadog, Grafana, Prometheus, Honeycomb). Weak candidates name-drop tools without explaining the data model. The kill-shot is admitting you do not look at production dashboards regularly. UK fintech and AI infra panels expect senior Backend Engineers to be on-call-fluent and observability-fluent; the question screens for both.

Tell me about a time you led a technical decision that turned out to be wrong.

Self-awareness question, weighted heavily. The panel wants a real wrong call with reflection. Strong answers: 'I picked DynamoDB for our user-events service because we expected huge scale. The actual scale never materialised, the access patterns drifted, and we spent six months working around DynamoDB constraints that Postgres would have handled trivially. I learned to size the database for current and 12-month projected scale, not 5-year fantasy scale, and to favour Postgres unless there is a hard reason not to.' Weak answers describe a decision that was actually fine. The kill-shot is denying you have ever been wrong. Senior Backend Engineers self-correct openly; juniors do not.

Walk me through how you would build an LLM-powered feature with cost and latency in mind.

AI integration is a regular Backend Engineer topic in 2026. Strong answers: cache prompt outputs at multiple levels (exact match, semantic similarity), use smaller cheaper models for routing, route to the expensive model only when needed, stream responses to reduce time-to-first-byte, batch where possible, monitor token costs as a first-class metric alongside latency, use evals not just unit tests for quality. Mention RAG with vector DB for grounding. Weak candidates describe a single-call OpenAI API integration with no caching. The kill-shot is not knowing what eval engineering is. AI integration is 2026's most-asked-about scenario in Backend Engineer interviews; if you have not built one, build one before applying.

Why are you leaving your current role?

Standard closer, important for senior backend hires where retention costs are high. Strong answers are forward-looking: you have hit the ceiling of technical complexity at your current company, you want to work on a harder distributed-systems problem, you want a stronger engineering culture, you want to ship in a faster cycle. Weak answers blame your manager, your tech stack, or your salary. The kill-shot is naming a specific colleague negatively. UK backend engineering at senior level is a small world; everyone interviewing you knows the engineer or manager you are complaining about. Stay forward-looking. The panel wants reassurance you will not be making the same complaint about them in 18 months.

Interview Q's · Tech · UK 2026

Backend Engineer Interview Questions UK

Backend Engineer interviews in UK 2026 weight technical depth heavily. Senior Backend Engineers in London earn £105–140k base, and the bar reflects that. Panels test system design, distributed-systems literacy, database deep knowledge, async/concurrent reasoning and production-operations instinct. The 12 questions below are the ones I see in real loops at UK fintech, AI infra, scale-ups and US-tech London offices. I have written each answer from the recruiter's side: what the panel is testing for, what a strong response looks like, and what mistake immediately ends the conversation. Read these even if you are confident; senior Backend Engineer interviews are won on preparation more than raw talent.

By Alex · 12-year UK recruiter · 12 questions + recruiter answers

Question 1

Walk me through how you would design a payments-reconciliation service.

System design is where Backend Engineer offers are won and lost. The panel wants to see structured thinking on a finance-grade problem. Strong candidates clarify requirements first: payment volume, source systems (card, bank transfer, wallet), reconciliation cadence (real-time, end-of-day), error tolerance, audit requirements. They then walk through ingestion (idempotent, exactly-once where required), matching logic (rule-based or fuzzy), exception handling, double-entry ledger pattern, and the regulatory/audit log. Mention specific technologies (Postgres for the ledger, Kafka for ingestion, dedicated reconciliation service). Weak candidates skip clarification or design without idempotency. The kill-shot is forgetting the financial-correctness primitive: every transaction must be traceable, immutable and auditable.
Question 2

Explain database indexing and when you would choose a B-tree vs a hash index vs a GIN index.

Database depth is non-negotiable for senior Backend Engineer roles in 2026. Strong answers cover: B-tree for range queries and ordered scans (default for most), hash for equality lookups only (rare in practice), GIN for full-text search and JSONB containment queries, BRIN for very large append-mostly tables. Mention covering indexes, partial indexes and the cost of writes (every index added slows inserts and updates). Strong candidates know how to read EXPLAIN ANALYZE output. Weak candidates say 'I just add an index when queries are slow' without understanding the trade-off. The kill-shot is not knowing what a covering index is. UK panels at fintech and high-volume e-commerce dig deep here.
Question 3

Walk me through handling a production incident where p99 latency suddenly spiked from 80ms to 800ms.

Operations instinct. The panel wants method, not heroics. Strong answers go: check dashboards (CPU, memory, GC, DB connection pool, downstream service health), check recent deploys for rollback candidates, isolate by region/instance/route, look at error rates and slow query logs, form a hypothesis (DB index missing on a new query, GC pause, downstream timeout, connection-pool exhaustion), test it, and either fix or rollback. Mention runbook discipline and post-incident review. Weak candidates say 'I would scale up the servers'. The kill-shot is admitting you would push a hotfix without rolling back first. Senior Backend Engineers know rollback is the first-resort, not the last-resort.
Question 4

How do you handle eventual consistency in a distributed system?

Distributed-systems literacy. The panel wants to hear that you understand eventual consistency is a trade-off, not a bug. Strong answers cover: CAP theorem in plain English, why you choose AP over CP for some flows (cart, view counts) and CP over AP for others (payments, account balance), patterns like read-your-writes, monotonic reads, session consistency. Mention idempotency keys, sagas, and the outbox pattern. Weak candidates conflate consistency with reliability or describe everything as 'we use Kafka'. The kill-shot is recommending strong consistency for everything. Distributed-systems-literate Backend Engineers earn the senior premium in 2026; the question filters for that.
Question 5

Tell me about a time you optimised a slow database query.

Behavioural with technical depth. Strong answers are specific: 'The query was 4.2 seconds on a 50M-row table. I ran EXPLAIN ANALYZE, found a sequential scan on a non-indexed FK. I added a composite index on (user_id, created_at DESC), the query dropped to 18ms. I also identified that the application was issuing N+1 queries and refactored to a single JOIN, cutting overall request time from 6 seconds to 200ms.' Weak answers describe generic optimisation without numbers. The kill-shot is having no story at all. Senior Backend Engineers in 2026 should have at least three database-optimisation war stories ready, with measurable before-and-after.
Question 6

How do you choose between SQL and NoSQL for a new service?

Architecture decision. Strong answers reject the false choice: 'It depends on the data shape and the query patterns.' SQL for relational data with ACID needs (financial, user accounts, anything with joins). NoSQL document for hierarchical data with low join needs (catalogues, content). Key-value for cache and session. Wide-column for time-series and analytics. Graph for relationship-heavy domains. Mention that most services in 2026 are polyglot persistence — different stores for different jobs. Weak candidates pick one and defend it ideologically. The kill-shot is recommending NoSQL because 'it scales' without understanding the consistency cost. UK panels at scale-ups test this question constantly.
Question 7

Walk me through how you would migrate a 100-million-row table to a new schema with zero downtime.

Senior question that filters out engineers without production experience. Strong answers: dual-write pattern. Add the new schema, write to both old and new on every change, backfill historical rows in batches with throttling, switch reads to new once parity is verified, then deprecate the old. Mention monitoring the lag, having a rollback plan, and using a feature flag for the cutover. Weak candidates suggest a single ALTER TABLE or 'we would put up a maintenance window'. The kill-shot is not knowing the dual-write pattern. UK fintech and high-volume e-commerce panels test this scenario specifically because zero-downtime migrations are a senior-level requirement.
Question 8

How do you decide between async messaging (Kafka, NATS) and synchronous request/response?

Architecture instinct. Strong answers: synchronous when the caller needs an immediate result and the path is simple. Async when the caller does not need immediate result, when you need decoupling, when you need replay, when you need fan-out to multiple consumers, or when load profiles between producer and consumer differ. Mention specific patterns: command vs event vs query, exactly-once semantics, dead-letter queues. Weak candidates default to 'use Kafka for everything' or 'avoid async because it is hard'. The kill-shot is not understanding why async helps with scale-out and resilience. Senior Backend Engineers in 2026 are expected to know both patterns deeply.
Question 9

Tell me how you handle observability in production services.

Operations question. Strong answers cover the three pillars: logs (structured, searchable, with request/trace IDs), metrics (RED method — rate, errors, duration; or USE method — utilisation, saturation, errors), distributed tracing (OpenTelemetry as the standard in 2026), and SLIs/SLOs/error budgets. Mention real tools you have used (Datadog, Grafana, Prometheus, Honeycomb). Weak candidates name-drop tools without explaining the data model. The kill-shot is admitting you do not look at production dashboards regularly. UK fintech and AI infra panels expect senior Backend Engineers to be on-call-fluent and observability-fluent; the question screens for both.
Question 10

Tell me about a time you led a technical decision that turned out to be wrong.

Self-awareness question, weighted heavily. The panel wants a real wrong call with reflection. Strong answers: 'I picked DynamoDB for our user-events service because we expected huge scale. The actual scale never materialised, the access patterns drifted, and we spent six months working around DynamoDB constraints that Postgres would have handled trivially. I learned to size the database for current and 12-month projected scale, not 5-year fantasy scale, and to favour Postgres unless there is a hard reason not to.' Weak answers describe a decision that was actually fine. The kill-shot is denying you have ever been wrong. Senior Backend Engineers self-correct openly; juniors do not.
Question 11

Walk me through how you would build an LLM-powered feature with cost and latency in mind.

AI integration is a regular Backend Engineer topic in 2026. Strong answers: cache prompt outputs at multiple levels (exact match, semantic similarity), use smaller cheaper models for routing, route to the expensive model only when needed, stream responses to reduce time-to-first-byte, batch where possible, monitor token costs as a first-class metric alongside latency, use evals not just unit tests for quality. Mention RAG with vector DB for grounding. Weak candidates describe a single-call OpenAI API integration with no caching. The kill-shot is not knowing what eval engineering is. AI integration is 2026's most-asked-about scenario in Backend Engineer interviews; if you have not built one, build one before applying.
Question 12

Why are you leaving your current role?

Standard closer, important for senior backend hires where retention costs are high. Strong answers are forward-looking: you have hit the ceiling of technical complexity at your current company, you want to work on a harder distributed-systems problem, you want a stronger engineering culture, you want to ship in a faster cycle. Weak answers blame your manager, your tech stack, or your salary. The kill-shot is naming a specific colleague negatively. UK backend engineering at senior level is a small world; everyone interviewing you knows the engineer or manager you are complaining about. Stay forward-looking. The panel wants reassurance you will not be making the same complaint about them in 18 months.

How to use these answers

Backend interviews in UK 2026 reward depth: distributed-systems literacy, database expertise, operations instinct and shipped-system stories with numbers. The single biggest mistake I see is candidates over-indexing on coding speed at the expense of system-design depth. By senior level, the coding round is a filter; the system-design round is the offer-decider. Prep with at least three real shipped systems you can talk through end-to-end (the why, the trade-offs, the operational learnings). Practise system design out loud, not on paper. And make sure your operations stories include real numbers (latency before/after, error budget burn, incident MTTR). UK senior backend hires get the salary premium because they earn it on operations instinct as much as architecture skill.

Related across UK Rights & Guides

Keep reading

JobLabs UK 215+ guide directory →

Pillars + free tools

Related job-search guides + calculators

Pillars

→ UK Career Change — sector switch + transferable skills — sector-switch playbook
→ UK CV pillar guide — CV format + ATS-safe AI prompts
→ UK Interview Prep pillar — STAR + 4-stage UK process
→ UK Cover Letter pillar — five UK opening patterns

Free recruiter-built tools