Lesson 18 · Senior Kafka practice

Mock senior Kafka interview pack

A retrieval-first mock pack for turning the whole Kafka course into clear, interview-grade answers you can say under pressure.

Your win: run a realistic senior Kafka mock interview on yourself, score your answers honestly, and turn weak spots into a focused review plan.

In plain English Plain English: answer out loud before checking the answer points. Recognition is not recall.

Why this page matters

The last mile of Kafka prep is rarely one more article. It is retrieval under pressure. That is why this page exists.

The goal is not to memorize my sentences. The goal is to train yourself to produce a strong answer shape when you are cold, timed, and being interrupted by follow-up questions.

The answer checklist A strong answer should usually include: (1) the model, (2) the main trade-off or risk, and (3) a repo-grounded consequence or example.

The format

This page works best if you treat it like a real interview. Answer first. Then check the points. Then answer again more cleanly.

Round 1 · Core model and reliability

  1. Why is Kafka best understood as a log?
  2. Why do partitions matter for both ordering and parallelism?
  3. What does acks=1 buy and what does it give up?
  4. How do at-most-once and at-least-once differ in practice?
  5. Why does this repo rely on idempotent handlers instead of Kafka transactions?
  6. What does ISR mean and why does it matter?
Round 1 · Strong answer points
  1. Log. Producers append durable ordered records that consumers can read independently over time.
  2. Partitions. They create the unit where order holds and where group parallelism is possible.
  3. acks=1. Faster and lighter than stronger durability settings, but weaker if the leader dies before replication fully catches up.
  4. Semantics. Commit timing is the core difference; commit-after means replay-safe but duplicate-prone.
  5. Idempotent handlers. Simpler path to exactly-once effect without the cost and complexity of Kafka transactions.
  6. ISR. The caught-up replicas trusted for safe leadership and stronger durability coordination.

Round 2 · Scaling, lag, and contracts

  1. Why doesn’t adding partitions always solve throughput pain?
  2. What does consumer lag really tell you?
  3. Why are repeated rebalances expensive?
  4. How can a hot key become a system bottleneck?
  5. Why are JSON event changes riskier than they look?
  6. What is the safest mental model for evolving Kafka contracts?
Round 2 · Strong answer points
  1. Partitions aren’t magic. Key skew or one hot tenant can still pin too much load to one partition.
  2. Lag. Offsets are falling behind arrival rate; diagnose handler speed, partition blockage, churn, or under-capacity.
  3. Rebalances. They pause useful work while partitions are reassigned.
  4. Hot key. Order-preserving routing can also concentrate traffic.
  5. JSON risk. Producer and consumer deploy at different times, so payload changes are distributed-compatibility changes.
  6. Contract model. Prefer additive, tolerant changes and manage semantic breaks explicitly.

Round 3 · Senior design judgment

  1. Why is AlwaysCommit() a trade-off rather than a bug?
  2. What is the real purpose of a DLQ?
  3. When should you retry in place versus escalate to a DLQ or retry topic?
  4. How would you review whether a Kafka design is overclaiming reliability?
  5. What questions would you ask about a proposed priority-lane pattern?
  6. How would you summarize this repo’s Kafka philosophy honestly?
Round 3 · Strong answer points
  1. AlwaysCommit(). It buys liveness and avoids stuck partitions, but accepts potential loss of a failed message.
  2. DLQ. Preserve evidence and let the main partition keep moving.
  3. Retry decision. Retry only if the failure is plausibly transient; otherwise park or drop deliberately.
  4. Review reliability claims. Check whether acks, commit mode, idempotency, and failure paths actually support the language being used.
  5. Priority lanes. Ask what fairness, ordering, consumer duplication, and operational complexity trade-offs the split introduces.
  6. Repo philosophy. Simple wrapper, kafka-go, JSON payloads, RequireOne, app-layer idempotency, lane-based prioritization, and honest trade-offs around liveness vs loss.

Self-scoring rubric

ScoreMeaning
0I could not explain it without notes.
1I gave fragments, but the answer was incomplete or fuzzy.
2I explained the main idea, but missed the trade-off, risk, or repo consequence.
3I gave a strong, clear answer with model + trade-off/risk + repo consequence.
Recovery map — where to go next Missed Kafka foundations? Revisit Lessons 1–4. Missed reliability semantics? Revisit Lessons 5–8. Missed repo application and failure behavior? Revisit Lessons 9–11. Missed senior judgment? Revisit Lessons 12–17.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into interview recall.
What are the three ingredients of a strong senior Kafka answer?
recall, then click to reveal
A clear Kafka model, the important trade-off or failure risk, and a repo-grounded consequence or example.
If you want, I can now run this as a live mock senior Kafka interview and grade you answer by answer. Ask me.

Sources. This pack synthesizes the whole course into retrieval practice.