What Kafka interview questions should I expect?

You already know Kafka is a distributed log, and you are worried the interviewer will go one level deeper than your daily usage. That is exactly where these questions go, so this section walks the vocabulary in the order interviewers usually take it, and flags the follow-up behind each term.

• Topics and partitions. A topic is split into partitions, each an append-only, ordered log. Follow-up: why does Kafka scale writes by adding partitions rather than by making a single log faster?
• Offsets. A consumer's position in a partition. Follow-up: who stores committed offsets, and what happens if a consumer crashes before committing?
• Consumer groups. Consumers in a group share a topic's partitions, one partition to at most one consumer in the group at a time. Follow-up: what happens to throughput if the group has more consumers than partitions?
• Brokers and the controller. Brokers store partitions; the controller handles leader election and metadata. Follow-up: what changed when Kafka moved metadata from ZooKeeper to KRaft?
• Producers and keys. A message with a key lands on a partition chosen by hashing the key; a message without a key is spread across partitions. Follow-up: which of those two preserves ordering for one customer's events?

Answer these with the mechanism, not the slogan. Saying that partitions give parallelism is table stakes; explaining that ordering exists only inside a partition, and that the key therefore decides the ordering domain, is the answer that moves you to the next round.

This is the layer where most candidates lose points, because the words are easy and the trade-offs are not. Expect the interviewer to state a guarantee and ask you to build it from settings.

• At-most-once vs at-least-once. Commit the offset before processing and you can lose a message; process first and commit after and you can process it twice. Say which failure each order tolerates and which your system prefers.
• Idempotent producers and exactly-once. An idempotent producer deduplicates retries within a partition; transactions extend that across partitions and to consumer offsets in a consume-transform-produce loop. Be ready to say what exactly-once does not cover: a downstream database write outside the transaction is still your problem.
• acks, replication factor, and in-sync replicas. acks=all waits for the in-sync replica set; min.insync.replicas sets how small that set may shrink before writes are refused. Interviewers often ask what you trade for durability here: latency and availability during broker loss.
• Retention and compaction. Time or size based retention deletes old segments; log compaction keeps the latest record per key. Follow-up: which one backs a changelog for a key-value store, and why?
• Rebalancing. When a consumer joins or leaves, partitions are reassigned. Follow-up: what does a long rebalance do to a latency-sensitive service, and how do cooperative rebalancing and static membership reduce the pain?

A useful habit: for every setting you name, say the failure it prevents and the cost it adds. That structure answers the question and the follow-up in one breath.

Senior loops replace definitions with a scenario and watch you reason. A typical prompt: a backend engineer interviewing for a platform role at a payments company is asked to design an event pipeline where every transaction for one account must be processed in order, throughput must grow with traffic, and a broker outage must not lose data. The strong answer keys messages by account id so one account's events share a partition, sizes partitions for the expected peak with headroom for growth, sets replication and acks=all for durability, and explains how consumers commit offsets so a crash replays rather than skips.

Other scenarios that recur: a consumer that falls behind and how you detect lag and catch up; a topic whose partition count you regret and why repartitioning breaks key ordering; a poison message that crashes the consumer and the dead-letter pattern that isolates it; schema changes across producers and consumers and what a schema registry buys you. The interviewer is not looking for one right architecture. They want you to name the constraint, choose a mechanism, and state the trade-off out loud.

Practice these aloud before the interview rather than only reading them. Rehearsing scenario questions with an AI interviewer that pushes on follow-ups is what the practice mode on the mock interview page is for, and the wider set of role and topic banks sits under interview questions by role and topic.

In a conversational round, yes, within honest limits. SubcueAI's native macOS and Windows desktop app captures the interviewer's audio and your microphone and shows short answer suggestions in a local overlay, so when the interviewer asks what min.insync.replicas protects against, the mechanism is on your screen while you explain it in your own words. The browser extension does the same for browser-tab calls, capturing only the meeting tab's audio. Neither adds a bot to the call and neither injects anything into the meeting page; the setup walkthrough is on the tutorial page.

The limits matter more than the pitch. A proctored coding test, a recorded screen, or a company-managed laptop is out of scope, and a live coding exercise where you must implement a consumer under observation is your own work. The assistant is strongest for the terminology and trade-off questions above, weakest for anything typed into an assessment platform. Before you rely on it, feed it your resume so suggestions reflect the Kafka work you actually did; the resume builder is where that profile lives.