Copy<\/button><\/div>\n\nimport bisect\n\nfrom collections import defaultdict\nclass TimeMap:\n\n def __init__(self):\n\n self.store = defaultdict(list) # key -> [(timestamp, value)]\n def set(self, key: str, value: str, timestamp: int) -> None:\n\n self.store[key].append((timestamp, value))\n def get(self, key: str, timestamp: int) -> str:\n\n if key not in self.store:\n\n return \u201c\u201d\n\n pairs = self.store[key]\n\n # binary search for rightmost timestamp <= query\n\n lo, hi = 0, len(pairs) \u2013 1\n\n result = \u201c\u201d\n\n while lo <= hi:\n\n mid = (lo + hi) \/\/ 2\n\n if pairs[mid][0] <= timestamp:\n\n result = pairs[mid][1]\n\n lo = mid + 1\n\n else:\n\n hi = mid \u2013 1\n\n return result\n<\/code><\/pre><\/div>Implement encode() and decode() for a list of strings, where strings can contain any characters including the delimiter<\/span>Strings<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Length-prefix encoding: for each string, write its length as a fixed-width integer followed by a separator character, then the string. On decode, read the length, skip the separator, read exactly that many characters, repeat. This avoids any dependency on a specific delimiter being absent from the input.<\/p>\n
Reported by Exponent and Hello Interview as a common phone screen problem. The naive approach of joining with a rare separator (e.g., “#”) breaks the moment a string actually contains that character. Interviewers push on this edge case immediately. If you can defend your encoding as correct for arbitrary string contents, you pass this gate.<\/p>\n
python<\/span>Copy<\/button><\/div>\n\ndef encode(strs: list[str]) -> str:\n\n result = []\n\n for s in strs:\n\n result.append(f\u201d{len(s)}#{s}\u201d)\n\n return \u201c\u201d.join(result)\ndef decode(s: str) -> list[str]:\n\n result = []\n\n i = 0\n\n while i < len(s):\n\n j = s.index(\u201c#\u201d, i)\n\n length = int(s[i:j])\n\n result.append(s[j + 1 : j + 1 + length])\n\n i = j + 1 + length\n\n return result\n<\/code><\/pre><\/div>Design and implement a resumable iterator that maintains state across calls and can be paused and resumed<\/span>Design \/ Iterators<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Wrap the underlying iterable in a class that stores the current position. A next() method advances and returns the current element. A save() method returns a snapshot of the position. A restore() method resets to a saved snapshot. For lazy iterables (generators), you can’t index directly, so you need to either convert to a list up front or track elements consumed and replay from the beginning on restore.<\/p>\n
Reported from Hello Interview’s OpenAI question breakdown. The “resumable” requirement is the distinguishing element. Candidates who implement a standard iterator fail the third part of the problem. The interesting design question is whether save\/restore requires full state serialization (for crash recovery) or just an in-memory checkpoint, ask the interviewer before diving into implementation.<\/p>\n
<\/div><\/div><\/div>\n
Given a list of meeting times as [start, end] pairs, find the minimum number of conference rooms required<\/span>Heap \/ Intervals<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Sort meetings by start time. Use a min-heap of end times (one entry per currently occupied room). For each meeting, check if the earliest-ending room is free (heap top end time is less than or equal to current start time). If yes, pop and reuse it. If no, allocate a new room. The answer is the heap size at its maximum.<\/p>\n
Reported from the TechPrep OpenAI question bank and the Hello Interview onsite list. Clean O(n log n) solution. Interviewers often ask for the follow-up: “return which room each meeting is in,” which requires tracking room identifiers in the heap, not just end times.<\/p>\n
<\/div><\/div><\/div>\n
Design and implement an LRU (least recently used) cache with O(1) get and put<\/span>Data Structures<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Combine a hash map with a doubly linked list. The hash map gives O(1) lookup from key to a node in the linked list. The linked list keeps recency order: the head is most recently used, the tail is least recently used. On get(), move the accessed node to the head. On put(), insert at the head, and if the cache is over capacity, evict the tail node and remove its key from the map. Both operations touch a constant number of pointers, so both stay O(1) regardless of cache size.<\/p>\n
Reported across nearly every OpenAI phone screen account as either the primary problem or a warm-up before a harder follow-up. The distinguishing extension here is usually “now make it thread-safe” or “now add a per-entry TTL,” both of which build on the same node structure.<\/p>\n
python<\/span>Copy<\/button><\/div>\n\nclass Node:\n\n def __init__(self, key, value):\n\n self.key = key\n\n self.value = value\n\n self.prev = None\n\n self.next = None\nclass LRUCache:\n\n def __init__(self, capacity: int):\n\n self.capacity = capacity\n\n self.cache = {} # key -> Node\n\n self.head = Node(0, 0) # dummy, most-recent side\n\n self.tail = Node(0, 0) # dummy, least-recent side\n\n self.head.next = self.tail\n\n self.tail.prev = self.head\n def _remove(self, node):\n\n node.prev.next = node.next\n\n node.next.prev = node.prev\n def _insert_at_head(self, node):\n\n node.next = self.head.next\n\n node.prev = self.head\n\n self.head.next.prev = node\n\n self.head.next = node\n def get(self, key: int) -> int:\n\n if key not in self.cache:\n\n return -1\n\n node = self.cache[key]\n\n self._remove(node)\n\n self._insert_at_head(node)\n\n return node.value\n def put(self, key: int, value: int) -> None:\n\n if key in self.cache:\n\n self._remove(self.cache[key])\n\n node = Node(key, value)\n\n self.cache[key] = node\n\n self._insert_at_head(node)\n\n if len(self.cache) > self.capacity:\n\n lru = self.tail.prev\n\n self._remove(lru)\n\n del self.cache[lru.key]\n<\/code><\/pre><\/div>Find the top K most frequent elements in a continuous stream of items, without storing the entire stream<\/span>Heap \/ Streaming<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Maintain a hash map of item to count, updated as each new item arrives. To get the current top K without re-sorting the whole map on every query, keep a min-heap of size K holding the current top candidates. When a count changes, check whether the item belongs in the top K: if the heap has fewer than K items, push it; if the item’s new count exceeds the heap’s minimum, pop the minimum and push the updated item. For unbounded streams where even the hash map grows too large, switch to an approximate approach like Count-Min Sketch paired with a heap of candidates, trading exact counts for bounded memory.<\/p>\n
Reported from Hello Interview’s OpenAI question set as a phone screen problem that starts simple, top K in a static array, and becomes a streaming problem as a gate extension. The interesting follow-up is memory: what happens when the number of distinct items is itself unbounded, which is where Count-Min Sketch becomes the expected answer at the senior level.<\/p>\n
python<\/span>Copy<\/button><\/div>\n\nimport heapq\n\nfrom collections import defaultdict\nclass TopKTracker:\n\n def __init__(self, k: int):\n\n self.k = k\n\n self.counts = defaultdict(int)\n\n self.heap = [] # min-heap of (count, item)\n\n self.in_heap = set()\n def add(self, item) -> None:\n\n self.counts[item] += 1\n\n count = self.counts[item]\n\n if item in self.in_heap:\n\n self.heap = [(c, i) for c, i in self.heap if i != item]\n\n heapq.heapify(self.heap)\n\n if len(self.heap) < self.k:\n\n heapq.heappush(self.heap, (count, item))\n\n self.in_heap.add(item)\n\n elif count > self.heap[0][0]:\n\n _, evicted = heapq.heapreplace(self.heap, (count, item))\n\n self.in_heap.discard(evicted)\n\n self.in_heap.add(item)\n def top_k(self) -> list:\n\n return [item for _, item in sorted(self.heap, reverse=True)]\n<\/code><\/pre><\/div>How would you detect embedding drift in a deployed retrieval system, and what would you do about it?<\/span>ML Systems<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Embedding drift happens when the statistical distribution of embeddings in your index diverges from the distribution the query encoder produces, often because the underlying model was updated or the data distribution shifted. Detection: monitor cosine similarity between recent queries and their top retrieved results. A drop in average similarity over a rolling window signals drift. You can also monitor retrieval success rate (whether retrieved results were clicked or marked useful). Root cause: check whether the embedding model was updated without re-indexing, whether incoming queries have shifted vocabulary significantly, or whether the corpus has grown stale relative to current user intent.<\/p>\n
Reported from a 2025 ML engineer interview account on Medium (Sammi Cox, “Would You Pass an OpenAI ML Engineer Interview in 2025?”). Remediation options: re-index with the current model version (expensive but clean), add an adapter layer that maps old embeddings to the new distribution (faster, imperfect), or dual-index and blend results from old and new models during a transition period.<\/p>\n
<\/div><\/div><\/div>\n
How does FlashAttention reduce memory usage in transformer attention, and what's the actual implementation insight?<\/span>ML Systems<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Standard attention materializes the full NxN attention matrix in HBM (high bandwidth memory), which is O(N^2) in memory and the bottleneck for long sequences. FlashAttention avoids this by computing attention in tiles that fit in SRAM (the on-chip fast memory), never writing the full attention matrix to HBM. The implementation insight is tiling with online softmax: you compute the softmax normalization factor incrementally across tiles using a numerically stable running maximum. The result is attention output computed in a single pass, with only O(N) additional memory. For GPUs, this means attention can stay in SRAM (which has 100x lower latency than HBM) for the compute-intensive reduction step.<\/p>\n
The mathematical core is not the hard part. The hard part is explaining why the tiling works numerically, specifically that the softmax denominator can be accumulated correctly across tiles without having seen all inputs first. If you can explain the online softmax trick clearly, you’re ahead of most candidates who just say “it avoids materializing the attention matrix.” Reported as an expected topic for ML systems roles by multiple prep sources.<\/p>\n
<\/div><\/div><\/div>\n
Explain mixed precision training and why loss scaling is necessary<\/span>Distributed Training<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Mixed precision training runs the forward and backward pass in FP16 or BF16, half the memory and roughly double the throughput on modern GPUs, while keeping a master copy of weights in FP32 for the optimizer update, since FP32 has more precision for the small gradient updates that would otherwise underflow. FP16 has a narrow representable range, so small gradient values can round to zero before ever reaching the optimizer, silently stalling learning on some parameters. Loss scaling fixes this: multiply the loss by a scale factor before backpropagation so gradients land inside FP16’s representable range, then divide the gradients by that same factor before the optimizer step. BF16 shares FP32’s exponent range, so it skips loss scaling entirely, which is one reason most large model training moved to BF16 once hardware supported it.<\/p>\n
This one shows up in almost every ML infra phone screen. The tell for a strong answer is explaining why BF16 skips the loss scaling step instead of just describing FP16 mechanically.<\/p>\n
python<\/span>Copy<\/button><\/div>\n\nimport torch\n\nfrom torch.cuda.amp import autocast, GradScaler\nscaler = GradScaler()\n\nfor batch in dataloader:\n\n optimizer.zero_grad()\n\n with autocast():\n\n loss = model(batch)\n\n scaler.scale(loss).backward()\n\n scaler.step(optimizer)\n\n scaler.update()\n<\/code><\/pre><\/div>Tell me about a time you pushed back on a technical decision for ethical reasons<\/span>Behavioral \/ Safety<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
This is one of the most commonly reported behavioral questions in the OpenAI loop, documented by Coditioning, TechPrep, and Exponent. The setup tests whether you have genuinely held ethical positions in engineering decisions, not whether you can describe OpenAI’s values back at the interviewer. Strong answers: describe the specific decision (what was being built or shipped), what the ethical concern was (not vague “it didn’t feel right” but a concrete risk to users or downstream impact), what you said and to whom, and what happened. The outcome doesn’t have to be a win. “I raised the concern, the team decided to ship anyway, and here’s what I observed afterward” is a credible and interesting answer.<\/p>\n
Interviewers flag candidates who either have no example at all (suggests they haven’t engaged with the ethical dimension of their work) or who have an example that’s really a technical disagreement dressed up as ethics. “I pushed back on a data schema decision” is not this question.<\/p>\n
<\/div><\/div><\/div>\n
Describe a project that failed. What happened and what did you learn?<\/span>Behavioral<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Interviewers probe for epistemic honesty, not good storytelling. The trap is a sanitized failure where everything you did was correct and the outcome was just circumstance. That doesn’t land here. Interviewers want to see where your judgment was wrong, not just what went wrong around you. The best answers identify a specific decision you made that turned out to be incorrect, explain why it seemed correct at the time (what information you had, what assumptions you were making), and describe what you actually learned rather than what sounds like a good lesson.<\/p>\n
Plan for follow-ups: “If you’d known what you know now, what specific decision would you have changed?” and “Have you been in a situation since where you applied that lesson?” If you can’t answer both, your failure story isn’t deep enough yet.<\/p>\n
<\/div><\/div><\/div>\n
Tell me about a time you changed your mind about something significant because of new information<\/span>Behavioral<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
This question tests epistemic humility directly. Reported from Coditioning’s OpenAI behavioral guide. The quality of the answer depends on the quality of the original belief: a strong answer has you holding a confident technical or product position, encountering evidence that contradicted it, and updating. Weak answers change a minor preference or have you changing your mind because someone more senior said so, without the candidate engaging with the underlying argument.<\/p>\n
OpenAI puts explicit weight on intellectual honesty in candidates. Interviewers flag people who can’t recall changing a significant opinion: it suggests either that they haven’t held strong opinions (unlikely but possible) or that they don’t update beliefs when they should (a real concern for a company building systems that can shape how millions of people think).<\/p>\n
<\/div><\/div><\/div>\n