The debugging round hands you working-looking code and asks what is wrong. Here are ten Kotlin functions, each with one bug drawn from the gotchas in the earlier posts, the input that exposes it, the fix, and the method that finds bugs like these in under a minute. Every buggy and fixed version was compiled and run to prove the bug reproduces and the fix works.

Kotlin candidates get asked about coroutines specifically: structured concurrency, cooperative cancellation, dispatchers, exception propagation, shared mutable state, and Flow versus Channel. Here are the questions, the mental model, ten compiled snippets, and the gotchas that separate people who have run coroutines in production from people who have read the guide.

Part two of the Kotlin coding round: ten problems covering ten patterns the first post did not, each with an idiomatic solution, its complexity, the per-problem mistake interviewers listen for, and a second set of Kotlin-specific traps, including the JDK 21 removeLast clash.

Architect loops still have a coding screen. Here are the ten problems that cover the ten patterns that matter, each with an idiomatic Kotlin solution, the mistakes interviewers are listening for, and the Kotlin-specific traps that trip up people coming from Java.

The disagreement question tests whether you can push back without caving or fighting, make it about evidence instead of rank, calibrate how hard you push to how reversible the decision is, and commit once it is made. Here is the playbook, the story to choose, and the follow-ups.

The ticket booking question is a contended-writes problem with a peak that dwarfs the average. Here is the full answer: the waiting room, seat holds with TTLs that survive races, the conditional update that replaces locks, the payment saga with a pivot, and how each foundation post plugs in.

No isolation spans services. The outbox solves the dual-write problem that breaks most event-driven designs, and the saga turns a multi-service process into local transactions with compensations. Here is how both work, when to use choreography or orchestration, what you lose in isolation, and why the outbox matters more than the saga.

Isolation is the other axis of consistency, and most candidates cannot say which anomalies their database's default permits. Here are the levels, the anomaly each one lets through, what the major databases really do under the same names, and the toolbox for preventing each anomaly without paying for full serializability.

"Eventually consistent" is not one thing, and "strongly consistent" is three different things depending on who is talking. Here is the ladder of consistency models, the user-visible anomaly each one prevents, the mechanism that enforces each, and the sentence to say in an interview.

The first five minutes decide whether the rest of a system design interview is a collaboration or a rescue. Here is a minute-by-minute script: restate, scope, name the non-functional requirements, estimate three numbers, find the hard part, and get agreement on the plan.