Confluent

Confluent Software Engineer Phone Screen Questions

13+ questions from real Confluent Software Engineer Phone Screen rounds, reported by candidates who interviewed there.

13
Questions
7
Topic Areas
10+
Sources

What does the Confluent Phone Screen round test?

The Confluent phone screen typically lasts 45-60 minutes and evaluates core Software Engineer fundamentals. Candidates should expect 1-2 algorithmic problems, basic system design discussion at senior levels, and questions about relevant experience. The goal is to confirm technical competence before bringing candidates onsite.

Top Topics in This Round

Confluent Software Engineer Phone Screen Questions

The original poster (OP) interviewed with Confluent and reviewed interview experiences and questions from other users. They expressed gratitude and offered some information to help others. The coding

This post was last edited by leehen on 2025-10-09 15:04 Please give me points!!! It was a fellow countryman who interviewed me. He was very nice, explained things very clearly, was very patient, and e

Phone Screen: Implement a data structure to store key-value entries within a time-based interval. Slight variation to LRU Cache. Round 1: Implement a Word Search Engine, given a list of documents with text,...

Coding round 1 ---------------- you\'re given k v pairs funA: [\'int\',\'bool\'] funB: [\'int\',\'int\'] and queries like [\'int\',\'int\'] return all functions that match the description follow-up you\'re also given a flag is variadic funA: [\'int\',\'bool\'] , isVariadic: true funC: [\'int\',\'int\']...

Phone Screen - Modified LRU Cache - Implemented a working solution using map + pair data structure. Coding Round 1 [Hire] - Word Search in a List of Documents - Implemented a working...

exp - 5.5yrs current company - product based MNC college - Tier 3 Screening Round- Design a cache with time based eviction policy \t Expectation Implement get(), put(), getAverage() methods Onsite : Round 1 :...

## Round 1 - Coding ## Problem Design and implement a food ordering system for a single restaurant. Your system must support: 1. A `Menu` that holds `Item(name, price, category, available)`. Items can be enabled/disabled. 2. A `Cart` per user: `add_item`, `remove_item`, `update_quantity`, `get_total`. 3. An `Order` created from a cart: transitions through states `PLACED -> PREPARING -> OUT_FOR_DELIVERY -> DELIVERED`. Cancellation only allowed before `PREPARING`. ```python class Item: def __init__(self, name: str, price: float, category: str): ... class Cart: def add_item(self, item: Item, qty: int) -> None: ... def remove_item(self, item_name: str) -> None: ... def get_total(self) -> float: ... class Order: def advance_state(self) -> None: ... def cancel(self) -> bool: ... def get_receipt(self) -> str: ... ``` ``` Item("Burger", 9.99, "Mains") cart.add_item(burger, 2) cart.get_total() -> 19.98 order = Order(cart) order.advance_state() # PREPARING order.cancel() -> False (too late) ``` ## Follow-ups 1. How would you apply a discount code that takes 10% off orders above $30? 2. Support multiple restaurants — how does your design change? 3. Where would you add tax calculation, and should it live in `Cart` or `Order`? 4. How do you handle an item becoming unavailable after it's already in a customer's cart?

## Problem You are given a list of function definitions, each with a name and a typed parameter list. You are also given a list of call expressions, each with a function name and argument types. Implement a matcher that returns, for each call, the best matching definition — or `"NO_MATCH"` if none apply. Matching rules (in priority order): 1. Exact type match on all positional arguments. 2. A parameter typed `"any"` matches any argument type. 3. If multiple definitions match, prefer the one with fewer `"any"` parameters. ```python def match_function( definitions: list[dict], # [{"name": str, "params": [str]}] calls: list[dict] # [{"name": str, "args": [str]}] ) -> list[str]: # definition id or "NO_MATCH" per call ... ``` ``` Definitions: {"id": "f1", "name": "foo", "params": ["int", "str"]} {"id": "f2", "name": "foo", "params": ["any", "str"]} Calls: {"name": "foo", "args": ["int", "str"]} -> "f1" (exact beats any) {"name": "foo", "args": ["float", "str"]}-> "f2" (any matches float) {"name": "foo", "args": ["int", "int"]} -> "NO_MATCH" ``` ## Follow-ups 1. Add support for variadic parameters (`*args`) that match zero or more trailing arguments. 2. How do you handle ambiguous matches where two definitions tie on specificity? 3. Support subtype relationships: `int` is a subtype of `number`. How does this change your matching logic? 4. What data structure would you precompute to make repeated matching fast?

## Round 1 - Coding (Frontend/JS) ## Problem Implement a `memo` function that wraps any pure function and caches its results. The cache key should be derived from the serialized arguments. Support an optional `maxSize` to limit cache entries (evict least-recently-used when full). ```javascript function memo(fn, { maxSize = Infinity } = {}) { // Your implementation } // Usage const expensiveAdd = memo((a, b) => { console.log('computing'); return a + b; }, { maxSize: 3 }); ``` ``` expensiveAdd(1, 2) -> 3 // logs "computing" expensiveAdd(1, 2) -> 3 // cache hit, no log expensiveAdd(2, 3) -> 5 // logs "computing" expensiveAdd(1, 2) -> 3 // still cached // With maxSize=2: memo(fn, {maxSize:2}) fn(1) fn(2) fn(3) // fn(1) evicted; fn(3) miss -> recomputes ``` ## Follow-ups 1. Your key serialization uses `JSON.stringify`. What breaks for functions, circular refs, or `undefined` args? How do you fix it? 2. Add a `maxAge` option (in ms) after which a cache entry is considered stale. 3. How would you make this work for async functions that return Promises, avoiding thundering-herd on concurrent calls with the same args? 4. Where in a React component tree would you apply memoization, and how does `useMemo` differ from this implementation?

## Problem You have a list of monsters, each with `(health, attack)`. Two monsters fight: each round, both deal their attack value to the other simultaneously. A monster dies when its health reaches 0 or below. Given your monster and a list of opponents, return how many you can defeat. For a follow-up variant: you can choose the fight order. You keep your current health between fights. Determine the maximum number of monsters you can defeat before dying. ```python def fights_won( my_health: int, my_attack: int, opponents: list[tuple[int, int]] # (health, attack) ) -> int: ... ``` ``` Input: my_health=10, my_attack=3, opponents=[(6,2),(15,1),(4,4)] Vs (6,2): I deal 3/round -> 2 rounds to kill. I take 2*2=4 dmg. Survive (6 HP left). Vs (15,1): 5 rounds. I take 5 dmg. Survive (1 HP left). Vs (4,4): 2 rounds. I take 8 dmg. Die. Order: fight in order given -> 2 wins. Optimal order might differ. ``` ## Follow-ups 1. Prove or disprove: greedy (fight lowest-attack opponents first) always maximizes wins. 2. What if you have a one-time shield that blocks all damage in one round — when should you use it? 3. Extend to a tournament bracket: monsters fight each other, not you. Who wins? 4. How would this change if attack values can vary randomly each round (dice roll)?

## Problem Resolve service startup order respecting dependency constraints, a topological sort on a directed acyclic graph. ## Tags graph, sorting

## Problem Implement wildcard pattern matching where '?' matches any single character and '*' matches any sequence. ## Likely LeetCode equivalent LC 44 - wildcard-matching ## Tags dynamic_programming, strings

## Problem Maintain a sliding window map tracking key-value pairs within a moving time or index window. ## Tags sliding_window, hash_table

What to Expect in the Confluent Phone Screen Round

The Confluent Software Engineer Phone Screen round has a specific calibration purpose distinct from other rounds in the loop. Across 13+ verified reports on LeakCode for this exact round type, the consistent expectations: clear scoping of the problem before diving into a solution, explicit reasoning about complexity, structured handling of edge cases, and the ability to discuss trade-offs between two reasonable approaches.

Reports tagged with the Phone Screen round at Confluent show recurring patterns in difficulty and topic distribution. The Phone Screen round is typically 45-60 minutes; the interviewer is calibrated against a specific rubric. The discriminator between candidates who advance and candidates who do not is rarely the final correctness of the answer. It is the path: did you clarify, did you verbalize your approach, did you handle edge cases, and did you communicate throughout.

How To Prepare for This Specific Round

Filter the questions below to the most recent reports (past 6-12 months). Questions tagged for this exact round type from this exact company at this exact role level are the highest-signal data available. Older reports may reference questions that have since rotated out of the company's pool.

Practice 4-6 representative problems from this set under timed conditions. The goal is not memorization (companies rotate questions); the goal is to internalize the patterns the interviewer typically reaches for and the depth of follow-up to expect. Reports on LeakCode also tag the typical follow-up depth at this round type, which is the discriminating signal between hire and no-hire calibration.

Phone Screen Round Timing and Format

The Phone Screen round at Confluent typically runs 45-60 minutes. Use the first 2-3 minutes to clarify requirements; you should never start coding or designing without verifying the input/output format, constraints, and edge cases out loud. Use the next 5-7 minutes to verbalize your approach before writing any code. The middle 20-30 minutes are implementation. Reserve the final 10 minutes for testing with concrete examples and discussing optimization or trade-offs.

Time budget discipline is one of the most reliable senior-vs-junior discriminators in this round. Strong candidates verbalize where they are in their budget out loud ("I've used about 20 minutes, I have 15 minutes left for testing and one optimization"). This signals engineering maturity to the interviewer and creates positive feedback they can capture in writing.

Common Failure Modes in This Round

Reports tagged "no hire" at Confluent Software Engineer Phone Screen commonly cite: coding silently without verbalizing approach, jumping to implementation before clarifying requirements, missing edge cases (empty input, single element, very large input), producing working code that the candidate cannot refactor when asked, and failing to test their solution with concrete examples before declaring done.

The single most predictive failure mode in 2025-2026 reports: not asking clarifying questions. Interviewers at all FAANG companies are explicitly trained to weight this dimension. Strong candidates ask 3-5 clarifying questions even on problems that look obvious; weak candidates dive into code immediately. The clarifying-question check is often the first signal recorded in the interviewer's notes.

See All 13 Questions from This Round

Full question text, answer context, and frequency data for subscribers.

Get Access