← Back to Directory

OpenAI interview notes, page 33 of 67

Mid-sized

Most of these OpenAI write-ups come from Software Engineers (460), then Machine Learning Engineers (137) and Backend Engineers (23). The most reported rounds are the technical phone screen (335), the system design round (229), the onsite coding round (32) and the behavioral / leadership round (22).

667 interview notes · updated Jul 2026

OpenAI·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at OpenAI for a software engineering role. The whole thing was one big open-ended question about building a recommendation system from scratch, which sounds manageable until you realize they want you to cover basically everything.
  • Design a complete machine learning system for a real-time recommendation product, covering data collection, feature engineering, model training, serving infrastructure, monitoring, and scalability.

“This is the kind of question where you nod confidently and then immediately realize you have six different topics to cover and maybe 45 minutes.”

View Post

OpenAI·Software Engineer·Onsite - Coding / Algorithms

May 2026
OpenAI SWE coding round, and it's a lot. Two main problem families in rotation: a version dependency resolver with four sub-parts, and a binary-search-over-versions problem that tests how carefully you handle lexicographic vs numeric ordering. Time is tight and the consensus seems to be just keep typing.
  • Given a set of packages with version dependencies (e.g. 'package A v1 requires B >= 2.0'), implement a parser, dependency query system, and a conflict resolver across four sub-parts.
  • Parse a version string like '103.003.02' into a comparable numeric tuple, and explain why lexicographic sorting of raw version strings is unreliable.
  • Given a sorted list of version strings and a black-box isSupported() function, find the earliest version that supports a feature, assuming support is monotone (once true, always true).
  • Same setup as above, but support can regress (True then False then True again). Find the absolute earliest version that ever returns True.
  • isSupported() is now rate-limited. Redesign find_earliest_supported_version to minimize API calls using the hierarchical structure of major.minor.patch versioning.

“This is the big one.”

View Post

OpenAI·Software Engineer·Technical Phone Screen

May 2026
OpenAI SWE interview with a coding problem centered on building a spreadsheet engine from scratch. The problem sounds deceptively simple but the dependency tracking piece is where it gets real.
  • Implement a spreadsheet cell system that supports Excel-style formula notation (e.g. a cell value defined as the sum of two other cells). How do you handle cascading updates when a dependency cell changes?

“The basic parsing part I got through fine.”

View Post

OpenAI·Machine Learning Engineer·Technical Phone Screen

May 2026
OpenAI ML Engineer technical screen focused almost entirely on building neural net components from scratch. No LeetCode, no system design fluff, just raw backprop math and NumPy. Felt like a grad school exam more than a job interview.
  • Implement forward and backward passes for a small two-layer MLP with ReLU activations and softmax cross-entropy loss using only NumPy. Derive the gradient formulas analytically.
  • Verify your manually computed gradients against PyTorch autograd on the same input tensors. Walk through how you'd do this and what discrepancies you'd look for.
  • Implement a basic SGD optimizer step and run several training iterations on a small toy dataset.
  • How would you handle batched inputs in your MLP implementation, and what changes are needed in the backward pass?
  • Explain the numerical stability issue with softmax and cross-entropy, and describe how the log-sum-exp trick addresses it.
  • What are the memory and compute trade-offs in backpropagation, and when does gradient checkpointing make sense?

“This was the bulk of the interview.”

View Post

OpenAI·Software Engineer·Technical Phone Screen

May 2026
Coding round at OpenAI for a Software Engineer position. The question was a deep dive into serialization design, not just slapping a map together, and they wanted the full picture: error handling, binary format justification, complexity analysis, and tests.
  • Build an in-memory key-value store in C++ with put, get, and erase operations, plus serialize and deserialize methods that encode and restore the full store state using only provided byte I/O helpers. Your binary format must handle arbitrary bytes and Unicode, be versioned and length-prefixed, and gracefully reject malformed or truncated input. Also explain your complexity, format trade-offs, and provide unit tests.

“This looked like a straightforward map wrapper until the serialization constraints hit.”

View Post

OpenAI·Machine Learning Engineer·Technical Phone Screen

May 2026
Got a coding question for an ML Engineer role at OpenAI that was more software design than anything ML-related. Basically had to implement a small type system with nodes and functions and get the toString rendering right for nested types.
  • Design Node and Function classes to represent a toy type system, and implement toString so that primitive types print as their name, tuple types print as a parenthesized comma-separated list, and function types print as `(params) -> return_type`, all recursively expanded for nested types.

“My first instinct was to just make everything a string field and call it done, which would've totally broken the recursive nesting.”

View Post

OpenAI·Software Engineer·Technical Phone Screen

May 2026
Interviewed for a software engineering role at OpenAI and got hit with a pretty gnarly algorithmic problem that built on a grid simulation. The core challenge was around optimal burn decisions to minimize plant deaths, and the discussion went deep into state space complexity and whether any exact polynomial solution even exists.
  • You have a grid simulation where plants can infect, recover, or die each day. At the start of any day, you can burn an entire row or column, removing all plants on it permanently. Design an algorithm to minimize the total number of plant deaths across the full simulation and return that minimum count.

“This one took me a minute to even parse.”

View Post

OpenAI·Backend Engineer·Onsite - System Design / Architecture

May 2026
System design round at OpenAI for a backend role. The question was one big compound problem that kept expanding the longer we talked, which I was not fully prepared for.
  • Design an in-memory key-value store from scratch. Start with basic get, set, and delete, then extend it to support TTL-based expiry, atomic transactions with commit and rollback, and full snapshot and restore functionality. Walk through your data structure choices, time complexity, and how you'd handle concurrent access.

“I started with a plain hashmap and felt good for about two minutes.”

View Post

OpenAI·Software Engineer·Onsite - Behavioral / Leadership

May 2026
Behavioral round at OpenAI for a software engineer role, focused on a pretty specific scenario: a project you finished but chose not to release. The whole conversation seemed to orbit around ownership of that call rather than what you actually built.
  • Tell me about a project you completed (or nearly completed) but ultimately decided not to ship. What was the project, why did you pull the plug, how did you communicate that decision, and what came of it?
  • How did people who wanted to ship react, and how did you handle the disagreement?
  • Looking back now, was not shipping the right call? What would you do differently?
  • How did you figure out where the threshold was between 'not good enough' and 'too risky to ship'?
  • How do you generally balance moving fast with the risk of shipping something flawed?

“The part I underestimated was how much they wanted to see that I personally owned the no-ship call, not just that I was present when someone else made it.”

View Post

OpenAI·Software Engineer·Onsite - Coding / Algorithms

May 2026
OpenAI coding round for a software engineer role, basically one meaty problem the whole time. The problem was interesting but the scope negotiation with the interviewer was a bit stressful since the requirements weren't fully defined upfront.
  • Design and implement a GPU credits accounting system that handles a stream of operations: granting credits with an expiration time, consuming credits for a user, and querying a user's current balance. Then write end-to-end tests covering the main scenarios.

“The core logic wasn't the hard part.”

View Post