11 Confluent Data Infrastructure Engineer (New Grad) Interview Questions (2026)

Outline

STAR. Pick a real moment — race condition, clock skew, consensus edge case, replication divergence. Walk through how you reproduced (often the hardest part), traced, fixed, and verified. Show you can stay calm in the face of nondeterminism.

Outline

Specifics: working on the streaming engine itself rather than just using it, the open-source roots, the depth of distributed-systems problems available (replication, consensus, multi-region active-active, exactly-once semantics). Mention specific papers — the Kafka design paper, Spanner, Raft — that drew you in.

Outline

STAR. Data-infra engineers tune systems against latency, throughput, and memory budgets. Pick a moment when you optimized — profile first, change second. Avoid 'I made it faster' framings without specifics.

Outline

HashMap + doubly-linked list + ReentrantReadWriteLock (or synchronized methods for simplicity). On get, lock, move node to head, unlock. On put, lock, insert at head, evict tail if over capacity, unlock. Discuss why ConcurrentHashMap alone doesn't give LRU semantics — order isn't tracked.

Outline

Fixed-size array, two volatile/atomic indices (head, tail), modular arithmetic. Single-producer single-consumer is lock-free with appropriate memory barriers. Multi-producer needs CAS on the tail index. Discuss why this is a Kafka-relevant pattern (broker write paths use ring-buffer-like structures for batching).

Outline

Partitioned, replicated, ordered log. Invariants: total order within a partition, durability after acknowledged write, replica consistency. Discuss leader election (Raft or ZAB), high-watermark protocol (only ACKed messages visible), unclean leader election tradeoff, ISR shrink/grow under partition. This is essentially asking 'how would you build Kafka' — that's the point.

Outline

Both streams have to be co-partitioned on the join key. For each side, buffer recent events in a state store keyed by join key. On arrival, look up the other side's buffer within the join window. Discuss the tradeoff: buffer size = window length × throughput. Late arrivals beyond the window are dropped or sent to a side-output. This is the heart of Kafka Streams' KStream-KStream join.

Outline

KRaft is Kafka's built-in consensus, replacing the external ZooKeeper dependency. Based on Raft (leader election, log replication, safety guarantees). Metadata events are written to a special __cluster_metadata topic, replicated to all controllers. Why: simpler operations (one system to run), better scalability (millions of partitions vs ZooKeeper's bottleneck), faster failover. Be ready to discuss Raft basics (terms, votes, log matching).

Outline

CAP: a distributed system can choose two of Consistency, Availability, Partition-tolerance under network partition. Kafka picks CP for writes (acks=all blocks until ISR replication, sacrifices availability when ISR shrinks below min.insync.replicas). Producer settings dial the tradeoff (acks=1 picks AP-ish). Discuss why partition tolerance is non-negotiable in practice.

Outline

Processing-time: when the event is processed by the system. Trivial to implement, sensitive to delays and outages. Event-time: when the event actually happened in the real world (carried in the event payload). Correct semantics but requires watermarks for windowing under late arrivals. Kafka Streams and ksqlDB support both; production systems usually want event-time.

Outline

A watermark is a monotonically advancing notion of 'we've seen events up to event-time T.' Used to close event-time windows. Common heuristics: watermark = max_observed_event_time - bounded_lateness. Discuss the tradeoff: aggressive watermarks close windows fast (low latency, more late-data drops); conservative watermarks wait (higher latency, fewer drops).