Developer Interview Questions

I would size it before designing it. At 10,000 requests per second the traffic is overwhelmingly reads, so the redirect has to be the fast path. I would generate the short key from a counter encoded in base62 rather than hashing the URL and then handling collisions, keep the mapping in a key-value store, and put a cache in front of the redirect. The strongest answers say what they would do about hot keys, and what happens to the database when a popular key expires and every request misses the cache at once.

I would treat this as a tail problem rather than a slow-service problem. If p50 is healthy then most requests are fine and something is affecting a subset, so I look for what varies between requests: one slow dependency, connection pool exhaustion, garbage collection pauses, or a query that only becomes an N+1 for large accounts. Before changing anything I want per-dependency timings so I can separate our latency from someone else’s. A good answer ends with the evidence that would confirm the cause, not with a guess at the fix.

I would denormalise when a read path is hot enough that the join is the bottleneck and the duplicated value changes rarely — a cached count, a copied display name on a feed row. The cost is that the same fact now lives in two places and can disagree, every write has to update both, and any change to the source column becomes a migration. A strong answer says how the copy stays correct: which code owns the write, how drift is detected, and whether a materialised view or a cache would buy the same speed without adding the invariant.

Optimistic locking assumes conflicts are rare: you read a version number and the write fails if the version has moved, so the caller retries. Pessimistic locking takes the lock up front so nobody else can touch the row while you work. I would pick optimistic for read-heavy work where a conflict is unlikely and a retry is cheap, and pessimistic where losing the conflict destroys real work — inventory, payments, anything where a lost update is a business problem. The best answers name what goes wrong at scale: retry storms on one side, held locks and deadlocks on the other.

I decide by what would actually break. Logic with branches and edge cases gets unit tests, because they are fast and they pin behaviour down precisely. Wiring, serialisation, queries, and anything that crosses a boundary gets an integration test, because that is exactly where a mock will lie to you and still pass. I try not to unit-test code that only forwards a call, since the test then just restates the implementation. A strong answer talks about cost: which layer catches the most real bugs per second of runtime, and which tests they would delete.

I would contain the blast radius first: a timeout short enough that hanging calls cannot pile up and exhaust our workers, retries with backoff and jitter so we do not synchronise a thundering herd, and an idempotency key so a retry is safe to make. Then a circuit breaker so we stop hammering a service that is already down, and a defined degraded response — cached data, a queued job, or an honest error. The part most candidates skip is the product decision: what the user sees when it is down for an hour, not for two seconds.

I read the description first and check the change actually matches it, then read the test diff before the implementation, because the tests tell me what the author believed could break. I separate blocking comments from preferences and label which is which, so the author is not guessing what stops the merge. If the approach itself worries me I raise that first, since there is no point polishing naming in code we might not keep. A strong answer says what they do when they disagree with an approach that already works — that is the review that costs you a colleague if you handle it badly.

I would use expand and contract. Add the new column, write to both old and new, backfill in throttled batches so replication does not fall behind, switch reads once the data matches, and drop the old column in a later release. Every step is reversible on its own, which is the point. The strongest answers name the step that is not reversible, say how long they would sit in dual-write before trusting it, and explain how they verify the backfill actually matched — usually a comparison job on a sample or a checksum, not an assumption.

I would stop trying to reproduce it and start narrowing what is different: data shape, scale, concurrency, configuration, dependency versions, or time. Then I add targeted logging or a flag so I can collect evidence in the environment where the bug actually lives, and I form a hypothesis that predicts something observable rather than changing things and hoping. If it still will not reproduce, I would ship a guard that makes the failure safe and leave the instrumentation in. A good answer includes the point at which they would stop spending on it.

I would keep it in the monolith unless the boundary is real: a different scaling profile, a different release cadence, or data another team genuinely owns. Size alone is not a reason. Extracting buys independence and costs you a call that can fail, a deploy you do not control, and a transaction you no longer have — so the same bug now needs two log sources to diagnose. My default first move is a module with a clear interface inside the monolith, which gets most of the separation and none of the network, and makes the later extraction cheap if it is still warranted.

I would cache the read-heavy things that tolerate being slightly stale, key them by exactly what varies so two callers cannot collide, and be explicit about how entries leave — a TTL, a write-through update, or a bust on the write path. Then I would talk about failure, because that is what interviewers actually probe: what happens when a popular key expires and every request goes to the database at once, whether a stale read after a write is acceptable for this data, and whether the system still stands up if the cache disappears at peak.

I would look for shared mutable state on that path: an object cached across requests, a field on a shared instance, or a check-then-write against a row with no constraint behind it. I would reproduce it by running the operation in parallel rather than by adding general load, and use a request id through the logs to see how the operations interleaved. The fix belongs at the lowest layer that can enforce it — usually a unique index or a database constraint rather than a check in application code. Strong answers say how they would prove the fix, since a one-in-ten-thousand race is not proven by a single green run.

In my last Developer project, I found a repeated bottleneck in architecture, debugging, delivery, and collaboration and turned it into a focused improvement plan. I defined the baseline, aligned the team on the metric, shipped the change in two iterations, and reviewed the result after launch. The strongest version of this answer names the exact metric you moved, the decision you owned, and the tradeoff you made to get the result without hiding team contributions.

I would describe a situation where I needed buy-in from a peer team or senior stakeholder, then show how I earned trust with evidence rather than pressure. A strong answer explains the other person’s concern, the evidence I used to reduce their risk — in Developer work that usually means something concrete drawn from architecture, debugging, delivery, and collaboration — and the compromise that moved the work forward. The outcome should show influence through clarity, not title power.

I would pick feedback that changed a real work habit, not a harmless weakness. For example, I once received feedback that my updates were too technical for business stakeholders, so I started sending one-line context, impact, risk, and next step summaries before deeper detail. For a Developer the feedback worth choosing is one that changed how you handle architecture, debugging, delivery, and collaboration. The answer should end with evidence that the change stuck, such as faster decisions, fewer clarification meetings, or better stakeholder confidence.