OpenAI Interview Notes

Alongside the problems, How the loop runs collects what community reports agree on about the process itself: how people get an interview, the shape of the loop, how problems are handed out in a round, and what decides the outcome.

What sets the pages apart:

• Complete statements. Each problem is written out in full, with definitions, function signatures and worked examples, so you can attempt it without guessing what was meant. Most coding problems come in two to five parts that build on each other.
• Solutions you can check. Every coding and system-design solution ends with a collapsed block of runnable checks. For coding, these are asserts on the examples and, wherever one can be written, a brute force built independently from the statement; for system design, the back-of-the-envelope estimates recomputed in code. CI runs the code of all pages on every push.
• Pitfalls where they happen. Instead of a separate list of mistakes, # NOTE: comments sit on the line the mistake would be made.
• Study tracks. The roadmap orders the problems for Research (RS / RE), MLE and SWE / Infra roles.
• English and Chinese. Every page exists in both languages with identical code.

Read how the loop runs once, then start from the track for your role in the roadmap. ★ shows how often a question comes up, from ★★★★★ (again and again) to ★☆☆☆☆ (rarely), and each track is sorted so that the top of the list pays off first.

Coding. Read only the Problem section. Before writing code, note what you would ask the interviewer (edge cases, tie-breaking, input sizes), then compare with the first lines of the reference solution, which list the points worth confirming. Give yourself a time limit for the whole problem and take the parts in order, treating each new part as a change of requirements: extend your code instead of starting over. Run it on the examples, then open the reference solution and compare approach, complexity and the # NOTE: comments. The checks call the functions named in the statement, so if you keep the same names and signatures you can usually run them against your own code.

System design. Give yourself about an hour (the page header shows the length of the round where it is known) and work through the prompt out loud or on paper: requirements, estimates, API and data model, architecture, then two or three deep dives. Then compare with the reference solution: which requirement you missed, where your numbers differ, which failure you did not handle. The estimates are computed in the checks block, so you can change an input and rerun them.

Behavioral. Each page lists what the round probes and how a strong answer is structured, and ends with an outline to fill in with your own stories. Rehearse them aloud, and keep your filled-in version private.

Every page starts with a table (type, priority, difficulty, roles, topics and, where known, format and round) and has exactly two sections:

Roles: RS research scientist · RE research engineer · MLE machine-learning engineer · SWE software engineer · Infra Eng infrastructure engineer · EM engineering manager.

git clone https://github.com/Schuture/OpenAI-Interview-Notes.git
cd OpenAI-Interview-Notes
pip install -r requirements.txt                    # NumPy, SciPy, scikit-learn, PyTorch, Pillow
python scripts/run_snippets.py coding/gpu-credits   # one page
python scripts/run_snippets.py --all                # every page

A page's ```python blocks run top to bottom as one script; ```py blocks are illustrative (bare signatures, code that fails on purpose) and are not executed. CI uses Python 3.11.

Sorted by priority within each section. A dash under Difficulty means it has not been rated.

Corrections, new variants and translations are welcome. Found a wrong answer, a missing edge case or a sentence that does not make sense? Open an issue. For pull requests, see CONTRIBUTING.md.

The text (prose, tables and diagrams) is licensed under CC BY-NC 4.0; the code, both in the pages and under scripts/, under the MIT License.