← Back to Directory

Confluent interview notes, page 2 of 4

Large Enterprises

Most of these Confluent write-ups come from Software Engineers (35), then Data Scientists (2) and Product Managers (1). The most reported rounds are the technical phone screen (24), the system design round (11), the onsite coding round (2) and the behavioral / leadership round (1).

38 interview notes · updated Jul 2026

Confluent·Software Engineer·Technical Phone Screen

May 2026
Confluent SWE interview with a meaty design problem around function signature matching. The question kept expanding with follow-ups and I felt like I was always one step behind where they wanted me to be.
  • You have a registry of functions, each with a name and a parameter list that may include positional types, optional parameters, and a variadic tail. Given a query with a function name and a sequence of argument types, determine whether any registered function can be called with that query. Walk through how you'd handle exact matching, optional arguments, varargs, and multiple candidates with a tie-breaking rule. Also discuss data structures and complexity.

“Started okay with the basic case, just check name and count and types.”

View Post

Confluent·Software Engineer·Technical Phone Screen

May 2026
Confluent SWE interview with a permutation/subset-sum problem dressed up as a warehouse robot scenario. Took me a minute to see past the story and recognize what was actually being asked.
  • You have a robot that starts at load 0 and processes N integer operations (positive to load, negative to unload). The order of operations is unknown. Can you determine whether any ordering of these operations produces a running total equal to a given target weight at some point during processing?

“Took me longer than it should have to strip away the robot framing and see this as a subset-sum reachability problem.”

View Post

Confluent·Software Engineer·Technical Phone Screen

May 2026
Confluent software engineer interview that went deep on variadic functions across multiple languages, type safety, and a real implementation exercise. Pretty technical and unforgiving if you don't know the low-level stuff cold.
  • Explain what variadic functions are and how they work in two different languages, covering calling conventions and how the callee accesses the arguments.
  • Compare type-safety mechanisms for variadic arguments: templates or generics versus raw varargs. What are the tradeoffs?
  • What are the performance and memory implications of variadic functions, specifically around stack versus heap allocation?
  • How do you forward variadic arguments from one function to another? Walk through the mechanics in your chosen languages.
  • Implement a type-safe variadic logger that accepts key-value pairs and formats them efficiently. Discuss pitfalls like format-string vulnerabilities and boxing overhead.
  • Analyze the time and space complexity of your variadic logger implementation.

“I went with C and Python.”

View Post

Confluent·Product Manager·Onsite - System Design / Architecture

May 2026
Interviewed for a PM role at Confluent and got hit with a system design question that felt more like something you'd throw at an engineer. Not what I expected going in.
  • How would you design a distributed database system similar to Kafka?

“I fumbled the opener pretty badly.”

View Post

Confluent·Software Engineer·Technical Phone Screen

May 2026
Two coding problems in what felt like a single session at Confluent. One was a classic unix-y file utility, the other a grid traversal with a cost twist. Not the hardest interview I've done but the follow-ups on both kept things interesting.
  • Implement a tail(filePath, n) function that returns the last n lines of a file in their original order, handling edge cases like fewer than n lines, n=0, and trailing newlines. Also discuss how you'd handle very large files without reading everything into memory.
  • Given a 2D dungeon grid with a start cell, exit cell, walls, empty cells, and monster cells that cost 1 to enter, find the minimum total monster cost to travel from start to exit. Return -1 if unreachable. Follow-ups: return an actual path, and handle arbitrary non-negative costs per monster cell.

“The basic version I got through fine, create a small test file, read lines, slice from the end, done.”

View Post

Confluent·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at Confluent for a software engineer role, focused entirely on building an RSS feed aggregator. The interviewer kept steering things toward API design and client heterogeneity, which I wasn't fully prepared for.
  • Design an RSS feed aggregation system where users can subscribe to feeds, the service periodically crawls them, and serves each user a personalized merged timeline.
  • How would you design the API layer for this system, and when would you choose REST over something like gRPC?
  • How do you expose the same backend to different client types like a web app, mobile app, and third-party developers?
  • How would you schedule and manage the crawler to periodically fetch subscribed RSS feeds without redundant or duplicate work?
  • How would you store and manage per-user read/unread/starred state at scale?

“I started with the usual stuff: subscription storage, a crawler pool, a feed item table.”

View Post

Confluent·Software Engineer·Technical Phone Screen

May 2026
Confluent SWE interview that focused on designing a token management service from scratch. The core challenge was picking the right data structures and justifying the time complexity tradeoffs, which sounds straightforward until you're actually on the spot defending your choices.
  • Design a token management service where each token has a creation time and a value. It needs to support registering a token and retrieving all currently active (non-expired) tokens. Walk through your data structure choices and the time complexity of each operation.

“My first instinct was a plain hash map and I started talking before thinking it through.”

View Post

Confluent·Software Engineer·Technical Phone Screen

May 2026
Confluent SWE interview that was basically a systems-flavored coding question disguised as a design discussion. They gave you a stripped-down file API and asked you to rebuild Unix tail, then pushed on the trade-offs between two different approaches. More open-ended than I expected for a technical screen.
  • Implement the equivalent of Unix `tail -n` using a minimal file API (read, move_pointer, get_size). Write pseudocode and discuss the trade-offs between a forward linear scan with a rolling buffer versus a backward seek approach.

“The two-approach discussion is where I spent most of my energy.”

View Post

Confluent·Software Engineer·Technical Phone Screen

May 2026
Confluent SWE interview with a pretty involved coding problem around IoT sensor health monitoring. The core challenge was designing a class that could efficiently answer repeated queries about sensor stability across a fixed time window.
  • Design a SensorHealth class that takes a log of IoT sensor pings (each with a sensor ID and timestamp) and answers queries about whether a given sensor is STABLE or UNSTABLE at a given time T. The window starting at T is divided into 5 consecutive 60-second slots. A slot is inactive if no pings fall in it for that sensor, and the sensor is UNSTABLE if there are 3 or more consecutive inactive slots. Optimize for repeated queries.

“My first instinct was to just scan all pings on every query and that obviously wasn't the point.”

View Post

Confluent·Software Engineer·Technical Phone Screen

May 2026
Confluent SWE interview with a sensor monitoring design problem that looked like a coding question but kept expanding into system design territory. Took me a while to realize they wanted both the data structure and the operational thinking.
  • Design a sensor aliveness service that supports record(sensorId, timestamp) and wasAlive(sensorId, t). A sensor is considered down if there are three or more consecutive fixed-length time slots with no ping recorded up to time t.

“I started with a sorted list per sensor keyed in a hashmap, which was the right call, but I fumbled explaining the binary search part.”

View Post