Question 1

Given a stream of integers, implement a data structure that returns the median after each insertion in O(log n) time.

Accepted Answer

Use two heaps: a max-heap for the lower half and a min-heap for the upper half. On each insert, push to the appropriate heap, then rebalance so heap sizes differ by at most 1. Median is either the top of the larger heap or the average of both tops. Walk through the rebalancing logic carefully and handle even/odd size cases explicitly. What interviewers look for: Whether you reach the two-heap solution without heavy hints, implement heap operations correctly in your language (e.g., Python's heapq is a min-heap, so negate values for a max-heap), and handle edge cases like a single element or two elements.

Question 2

Write a function that parses a raw HTTP query string (e.g., 'foo=1&bar=2&foo=3') into a map, correctly handling repeated keys, URL encoding, and empty values.

Accepted Answer

Split on '&', then split each token on the first '=' only (not all '='). URL-decode keys and values using your language's standard library. Store values as lists to handle repeated keys. Explicitly handle tokens with no '=', tokens where value is empty string, and malformed input. Don't roll your own URL decoder. What interviewers look for: Attention to edge cases that mirror real backend work (repeated keys, encoding). Shows whether the candidate thinks about RFC correctness and defensive input handling rather than only the happy path.

Question 3

Given a list of API log entries each with a user_id and timestamp, find all users who made more than k requests in any sliding 60-second window.

Accepted Answer

Group entries by user_id. For each user, sort by timestamp and use a sliding window (two-pointer or deque) to find the maximum count within any 60-second span. Time complexity is O(n log n) for sorting. Discuss tradeoffs: if data is already sorted by time, you save the sort. For very large datasets, mention processing per-user in a streaming fashion. What interviewers look for: Ability to map a practical backend problem to a sliding-window algorithm. Interviewers watch whether you sort first, choose the right window mechanism, and recognize that grouping by user_id is the necessary first step.

Question 4

Design a rate limiter that can enforce per-user request limits (e.g., 100 requests per minute) for a REST API with multiple backend servers.

Accepted Answer

Start by clarifying: exact vs. approximate limiting, burst tolerance, failure behavior. Present at least two algorithms (token bucket vs. sliding window log vs. sliding window counter) with their tradeoffs. For distributed enforcement, use Redis with atomic Lua scripts or Redis's INCR+EXPIRE for fixed windows, or a sorted set for sliding windows. Discuss the race condition in naive increment-then-check, clock skew, and what happens if Redis goes down (fail open vs. fail closed). Keep the scope tight — one service, not global infra. What interviewers look for: Whether you know more than one algorithm and can articulate tradeoffs. Redis atomicity (Lua or transactions) is a key signal. Interviewers want to see operational awareness: what breaks in production, not just the happy path design.

Question 5

Design the data model and core API for a simple job queue where producers enqueue tasks and workers claim and process them exactly-once.

Accepted Answer

Define the jobs table: id, payload, status (pending/claimed/done/failed), claimed_at, retry_count, worker_id. Use a SELECT ... FOR UPDATE SKIP LOCKED query (PostgreSQL) to atomically claim a job — this is the key insight. Discuss visibility timeout: if a worker crashes, a background sweeper reclaims jobs where claimed_at is stale. Cover idempotency on the worker side since exactly-once delivery is hard; at-least-once + idempotent processing is the realistic contract. Optionally mention why a dedicated queue (SQS, RabbitMQ) is better at scale. What interviewers look for: Knowledge of database-level locking primitives (SKIP LOCKED is a strong signal), understanding that exactly-once is nuanced, and practical schema design. Interviewers want to see you reason about failure modes, not just the sunny-day flow.

Question 6

You have a Postgres table with 50 million rows. A query filtering on a non-indexed column is running slowly. Walk through your full diagnosis and remediation process.

Accepted Answer

Step 1: EXPLAIN ANALYZE to see if it's a seq scan and where the time goes. Step 2: Check if an index would be selective enough (low-cardinality columns like boolean flags don't benefit). Step 3: For a high-cardinality column, add a B-tree index (or partial index if you only query a subset). Step 4: Check for table bloat, analyze vacuuming, and confirm statistics are fresh. Step 5: If the query is complex (joins), check join order and consider composite indexes. Mention that adding an index on a live table uses CREATE INDEX CONCURRENTLY to avoid locking. What interviewers look for: EXPLAIN ANALYZE is the mandatory starting point — candidates who jump to 'add an index' without mentioning it are penalized. Interviewers look for awareness of index selectivity, partial indexes, and operational safety (CONCURRENTLY).

Question 7

Explain the difference between optimistic and pessimistic locking. When would you choose each, and what are the failure modes?

Accepted Answer

Pessimistic: lock the row on read (SELECT FOR UPDATE), block other writers until transaction commits. Good for high-contention writes where conflicts are frequent. Failure modes: deadlocks, lock timeouts, reduced throughput. Optimistic: no lock on read; on write, check that a version/timestamp column hasn't changed (UPDATE ... WHERE version = $old_version, check rows affected). Good for low-contention reads. Failure modes: high retry rate under contention, stale reads between check and update. Give a concrete example: bank account transfers (pessimistic) vs. updating a user profile (optimistic). What interviewers look for: Concrete tradeoffs, not just definitions. Interviewers want to hear about contention characteristics as the selection criterion, and that you know optimistic locking requires application-level retry logic.

Question 8

You're designing a REST API for a resource that can be created, but creation is slow (10–30 seconds). How do you design the API to handle this asynchronously?

Accepted Answer

POST /jobs returns 202 Accepted immediately with a job_id and a Location header pointing to GET /jobs/{id}. The client polls that endpoint; response includes status (pending/complete/failed) and, when done, the result or a redirect to the created resource. Discuss webhook callbacks as an alternative to polling. Cover how long you retain job state, authentication on the status endpoint, and idempotency on the POST (use a client-supplied idempotency key to avoid double submission on retry). What interviewers look for: Knowledge of 202 Accepted and the async REST pattern. The idempotency key on POST is a strong mid-level signal. Interviewers check whether you think about the client's retry behavior and resource cleanup, not just the initial response.

Question 9

A deployment you pushed 20 minutes ago is causing a 5% error rate spike in production. Walk me through your response.

Accepted Answer

Immediate: check error rate trend (is it growing or stable?), pull logs and traces to identify the error type and which endpoints are affected. If it's clearly regression and business impact is high, rollback first, investigate second. If impact is low or rollback is risky, add a feature flag to disable the new code path. After stabilizing: root cause in logs/traces, write a postmortem noting timeline, impact, detection time, and what would have caught it in staging. Mention alerting gaps if the spike wasn't caught by on-call. What interviewers look for: Interviewers want the instinct to rollback vs. fix-forward and the triage order (impact assessment before deep debugging). Mid-level candidates should know the difference between investigating and firefighting. Postmortem instinct is a plus.

Question 10

Tell me about a time you disagreed with a technical decision made by a senior engineer or tech lead. What did you do?

Accepted Answer

Use the STAR format. Be specific: name the technology or design decision, articulate why you disagreed (with technical reasoning, not just preference), describe how you raised the concern (written RFC comment, design review, 1:1), and what the outcome was. It's fine if you were overruled — interviewers care about how you communicated and whether you committed once a decision was made. Avoid: making the senior engineer look incompetent or making yourself look like you just complied without engaging. What interviewers look for: Constructive disagreement is a key mid-level signal — interviewers want engineers who push back with data, not ones who silently comply or go rogue. They're evaluating communication quality, technical reasoning, and professional maturity.

Question 11

Describe a project where something went wrong that was your fault. What happened, what was the impact, and what did you change afterward?

Accepted Answer

Pick a real, non-trivial mistake — not 'I had a typo.' Describe the mistake, how it was discovered, the actual impact (downtime, data issue, missed deadline), and what you did to fix it. The most important part: what you changed in your process or thinking afterward (added a test type, changed a deployment process, started reviewing X differently). Avoid over-explaining why the situation was hard — own it cleanly. What interviewers look for: Self-awareness and accountability. Interviewers distrust candidates who can't name a real mistake or who over-qualify everything. The process change afterward shows engineering maturity and that you learn from failures.

Question 12

Explain how your primary backend language handles concurrency (e.g., goroutines in Go, async/await in Python or Node, threads in Java). What are the main gotchas?

Accepted Answer

Tailor to your actual stack. For Go: goroutines are lightweight, scheduled by the Go runtime (M:N), communicate via channels; gotchas include goroutine leaks (channel never closes), data races (use -race flag), and misusing shared state without mutexes. For Python (asyncio): single-threaded event loop, cooperative multitasking; gotchas include blocking the event loop with CPU-bound work or sync I/O, and not awaiting coroutines. For Java: thread pools and the JVM thread model; gotchas include deadlocks, thread starvation, and improper use of synchronized. Name a real bug you've hit or would watch for. What interviewers look for: Depth beyond 'it's fast.' Interviewers at mid-level expect you to know the concurrency model of your stack well enough to debug production issues. Naming a concrete gotcha (goroutine leak, event loop blocking) is a strong signal of real experience.

Mid-Level Backend Engineer Interview Questions

What to expect

12 questions, with how to answer them

1. Given a stream of integers, implement a data structure that returns the median after each insertion in O(log n) time.

2. Write a function that parses a raw HTTP query string (e.g., 'foo=1&bar=2&foo=3') into a map, correctly handling repeated keys, URL encoding, and empty values.

3. Given a list of API log entries each with a user_id and timestamp, find all users who made more than k requests in any sliding 60-second window.

4. Design a rate limiter that can enforce per-user request limits (e.g., 100 requests per minute) for a REST API with multiple backend servers.

5. Design the data model and core API for a simple job queue where producers enqueue tasks and workers claim and process them exactly-once.

6. You have a Postgres table with 50 million rows. A query filtering on a non-indexed column is running slowly. Walk through your full diagnosis and remediation process.

7. Explain the difference between optimistic and pessimistic locking. When would you choose each, and what are the failure modes?

8. You're designing a REST API for a resource that can be created, but creation is slow (10–30 seconds). How do you design the API to handle this asynchronously?

9. A deployment you pushed 20 minutes ago is causing a 5% error rate spike in production. Walk me through your response.

10. Tell me about a time you disagreed with a technical decision made by a senior engineer or tech lead. What did you do?

11. Describe a project where something went wrong that was your fault. What happened, what was the impact, and what did you change afterward?

12. Explain how your primary backend language handles concurrency (e.g., goroutines in Go, async/await in Python or Node, threads in Java). What are the main gotchas?

Study tips