Technical Phone Screen: Five Rapid-Fire Questions in 30 Minutes

Format. A live technical screen where every answer is spoken: no code is written. Seven reports put it at about 30 minutes, and one describes about 50. The interviewer works through about five short questions and you answer as many as you can before time runs out. A candidate who answered only three did not pass, and a reply on another failed report says there are about five and you reportedly need about four (hearsay, not confirmed). The set and the order vary, but since June 2026 the same five questions keep coming back.

1. Sorting: faster than O(n²), then the slowest possible sort (6 reports)

• Name a sort faster than O(n²) and explain how it works: merge sort (O(n log n) in the worst case) or quicksort (O(n log n) on average). One interviewer followed up with quicksort's worst case (already-sorted input with a bad pivot gives O(n²)).
• Then reverse it: what is the most inefficient way to sort deterministically? There is no true slowest, since you can always add pointless work; the interviewer wants a deliberately bad but sensible algorithm. The reported answer is to try every permutation until one is sorted, which is O(n·n!). One interviewer led there by asking how many non-empty subsequences an array has (2ⁿ − 1) and how many permutations (n!).
• Shuffling until sorted has no upper bound, which is why the question says deterministic.
• An earlier version (March 2026) asked instead why a comparison sort cannot beat O(n log n).

2. Coffee-shop probability (4 reports) Two equally good coffee shops, A and B. You buy two drinks from each, every drink gets an independent random quality score, and ties never happen. What is the probability that both A drinks score higher than both B drinks?

• Only the ranking matters, and because the shops are equally good, all 4! = 24 orderings are equally likely. The two A drinks take the top two places in 2! × 2! = 4 of them, so the answer is 4/24 = 1/6.
• One report got a follow-up with three shops: the probability that the best drink comes from A and the worst from C. Assuming two drinks per shop, the same counting gives (2 × 2 × 4!) / 6! = 2/15 (our working; the report does not give a final answer).
• One candidate describes this as reusing the first question: counting permutations is the whole technique.

3. Code review: a cache in front of an expensive function (4 reports) "If someone sent you this in a code review, what would you say?" The Python version, as one candidate posted it:

cache = {}

def compute(x):
    if x in cache:
        return cache[x]
    result = expensive(x)
    cache[x] = result
    return result

What interviewers pushed on, roughly in order:

• Two threads that miss on the same key both run the expensive computation.
• Add a lock. Then: how do you guarantee the work runs only once? Check the cache again after acquiring the lock (double-checked locking), and keep holding the lock until the result is stored.
• Where does the lock go? A lock around the whole function serializes every call, cache hits included.
• How does a Python dict behave under concurrent reads and writes, and will a reader see the old value or the new one?
• There is no eviction policy or size limit, so memory grows without bound.
• What happens if the expensive computation raises? Is the input validated?

You can choose the language. One interviewer said they have versions in 12 languages, but the topics stay the same: race conditions, mutexes, threading, garbage collection and eviction. A candidate who got the JavaScript version found it awkward for a round about threads and switched to explaining it with C++ mutexes. (Our note: the same race exists in JavaScript between two async calls that both miss before either finishes.)

4. Code review: building a CSV (3 reports) "Spot the issues with this code":

def to_csv(table):
    output = ""
    for row in table:
        for cell in row:
            output += cell
            output += ","
        output += "\n"
    return output

• Every row ends with a trailing comma. (A June report lists missing commas between cells instead, so the snippet may differ.)
• Concatenating strings in a nested loop: Python strings are immutable, so collect the pieces in a list and join them.
• output += cell raises TypeError when a cell is not a string, such as a number.
• A cell that contains a comma, a quote or a newline breaks the format. It must be quoted and escaped, which the csv module does.

One report remembers this as code that reads or processes a CSV file rather than writing one.

5. Payments: calling an external provider (3 reports) You are given code that charges a customer through an external provider such as Stripe, then writes a record to your own database. What can go wrong, and how would you fix it?

• The charge succeeds but the database write fails. Or the provider times out and you do not know whether it charged, so a blind retry can charge twice. Your database transaction cannot roll back a charge made at the provider.
• Generate an idempotency key once per payment request, store it, reuse it on every retry, and send it to the provider.
• Write the payment record (status pending) before calling the provider and update it afterwards. Resolve uncertain outcomes by querying the provider or from its webhook.
• Where would you hold a lock, and should you hold it across the external call?
• What goes in the data model, and which database would you use? Fields such as payment_id, amount, currency, status, idempotency_key, provider_charge_id and timestamps. One report justified a relational database (MySQL or Postgres) on ACID guarantees and strong consistency, at the cost of some availability and scale; another lists ACID and availability as the trade-offs discussed. (Our note: DynamoDB also offers transactions and strongly consistent reads, so justify the choice from what the payment flow needs rather than dismissing a store outright.)

Also reported in this screen (one or two reports each): a LeetCode problem described out loud, where you explain the optimal algorithm and why; preventing duplicate usernames, first with plenty of RAM, then with limited RAM and a large disk; the hard parts of matching projects to contractors; and, for a full-stack candidate, designing an API that copies a dataset together with its tasks, model responses and grades.

Other roles get a different screen. An Applied AI candidate was asked to debug an async refund function that retries a Stripe call three times and then marks the record done, followed by rapid questions: what idempotency is and why it matters, RAG versus fine-tuning, handling an exceeded context limit, making a stateless LLM application stateful, and defending an agent against prompt injection. An infra candidate had 45 minutes of about 20 conceptual questions: what happens when you type a URL into a browser, process versus thread, streaming frameworks, at-least-once versus at-most-once delivery, Kubernetes autoscaling, traffic routing and ReplicaSet versus StatefulSet, VPCs and private versus public networks, and one-way functions.