Confluent VO Interview Experience: From a Data Structure Question to Evaluating Infrastructure Readiness

From a Data Structure Question to“Are You a Fit for Infrastructure Work”

The interviewer was an engineer working on Kafka / streaming infrastructure, and the style was very clear from the beginning:
they were not rushing you to write code, and they were not looking for a“perfect solution in the first minute.”
Instead, the interview kept moving forward through follow-up questions, gradually pushing the discussion closer to real systems.

The interview starts with a“clean-looking”data structure problem

The interviewer opened with a problem that sounded simple at first:

The system continuously inserts key → value pairs, and each key is associated with a timestamp when it is inserted.
There is a fixed expiration window (expiry time).

You need to support one operation:

getAverage()
Return the average of all values that have not expired.

Then the interviewer added one extra sentence:

getAverage will be called frequently.

That sentence was already a hint.

First approach: time order and a sliding window

I first clarified the assumptions:

• Keys and values are integers
• Expiry time is fixed
• Expired data should not be included in the calculation

Then I proposed a straightforward solution:

• Use a HashMap to store key → value
• Use a queue ordered by insertion time to store (key, timestamp, value)
• Maintain two variables:
  • the sum of all non-expired values
  • the count of all non-expired keys

Before each call to getAverage(), clean up expired keys starting from the head of the queue.
Because keys are inserted in time order, once the first key is not expired, everything after it is safe.

After cleanup, simply return sum / count.

The interviewer focuses on complexity

The interviewer did not immediately move on.
Instead, they asked:

What is the time complexity of your getAverage?

I answered honestly:

In the worst case, a single call could be O(n),
but each key is only expired once, so over time the amortized complexity is O(1).

They followed up:

What is n here?
Why do you believe this is amortized O(1)?

I explained the sliding window intuition:
the slow call is essentially paying off work accumulated earlier.
Once expired keys are removed, the queue becomes shorter.

At this point, the interviewer seemed satisfied — but clearly not done.

The first critical follow-up: does access refresh time?

Just when I thought the problem was wrapping up, the interviewer added a new condition:

Let’s add another API:
get(key)
If a key is accessed, its timestamp should be refreshed.

That single sentence exposed a flaw in the original approach.

Realizing the queue is no longer sufficient

If access refreshes time, then:

• A key might be in the middle of the time-ordered queue
• We would need to move it to the“most recent”position
• Removing an element from the middle of a queue or deque is O(n)

I did not try to defend the original structure.
I acknowledged directly that the original design no longer worked under this requirement.

The interviewer guides toward the intended solution

The improved design was:

• HashMap: key → node
• Doubly linked list ordered by time
  • head = oldest
  • tail = newest

With this structure:

• put is O(1)
• get(key) with time refresh is O(1)
• Expiration only removes nodes from the head
• getAverage remains amortized O(1)

I summarized it as:

This problem is essentially
a sliding-window / LRU-style structure with statistics.

The interviewer nodded, and this question was done.

The remaining questions move faster, but follow the same pattern

The rest of the interview followed a similar rhythm:
present a problem, observe your first instinct, then see whether you can adapt your design under more realistic constraints.

Flattening a multi-level linked list

Next was a multi-level linked list problem.
Each node has not only a next pointer, but also a down pointer.

The requirement was to insert each down list between the node and its original next, eventually flattening everything into a single list.

What the interviewer cared about was not the syntax, but whether you noticed:

• whether node order is preserved
• recursion depth and stack safety
• whether you implicitly assume the structure is shallow

I discussed both recursive and iterative (explicit stack) approaches, and mentioned how deep recursion can become a real risk in production systems.

Recursive traversal of CSV files

Then came a more engineering-oriented question:

Given a directory, recursively traverse all CSV files and sum all integers in the second column.

This was less about algorithms and more about practical correctness and clarity.

Bus tracker / station distance: modeling ability

Another problem involved a one-directional chain of stations and multiple buses currently stopped at some stations.

Given a station, return how many stops ahead the nearest bus is.

This question mainly tested modeling and how you structure data for fast queries.

Calendar Busy View

The final technical question was interval merging:

Given a list of event time intervals, output the merged busy time slots.

The solution is classic sort-and-merge, but the interviewer was very sensitive to details:

• what counts as overlapping
• whether adjacent intervals should be merged
• whether the output is ordered

BQ questions woven throughout the interview

Throughout the process, the interviewer kept inserting questions such as:

• If this were a production system, what would you worry about most?
• Have you ever seen design assumptions break under real traffic?
• Do you prefer shipping quickly, or thinking everything through upfront?
• Have you ever taken on more ownership than you should have?

None of these were asked as formal“BQ questions.”
They were embedded naturally into the technical discussion.