Updated by OpenAI candidates
Software Engineer, Applied AI Interview Experience
The recruiter said to expect LeetCode medium hard, but I got this very practical Excel problem around formulas, caching, and invalidation. The most unique part was the project deep dive where they really tried to cut through the BS and ask what I actually did.
Interview process
I got sourced by a contractor first and then handed off to an actual OpenAI recruiter, which was a little unusual but pretty smooth. The process was a recruiter screen, then a first technical screen with one system design and one coding round, then a virtual onsite with only two more technicals plus behavioral, cross-functional behavioral, and a project deep dive. What stood out most was that the coding wasn't really LeetCode-shaped even though that was the prep guidance I got. The whole loop felt much more practical and scale-heavy than expected, and the project deep dive was easily the most probing part because they kept asking what I actually did and why. My main takeaway was that they want strong generalist problem solvers more than people who just memorize interview patterns.
- Recruiter screen
- Phone interview
- Final round
Interview tips
I'd prep practical coding problems, not just classic LeetCode medium/hard. For system design, be ready for pretty normal prompts, but expect them to keep pushing on scale and pressure-testing your assumptions. For coding, start with a complete working solution, talk through edge cases early, and don't over-optimize too soon because they may save that for later in the round. For behavioral and project deep dive, know your projects cold. A clean STAR summary is not enough if they keep drilling into what you actually owned, why it mattered, and how you worked with other people.
Company culture
They seem to be hiring pretty broadly through Applied AI, which seemed to cover a huge part of the company outside the core modeling and research work. The process felt less standardized than big tech. The interviewers seemed free to ask whatever they wanted, and some of the prompts felt like things people probably brought over from prior companies. At the same time, there was a very consistent signal in what they cared about: practical problem solving, scaling instincts, and whether you can explain real work without hand-waving. I also got the sense they want generalists who can code, think from first principles, write things down, and work cross-functionally, not just specialists who are good at one narrow interview style.
Questions asked
Overview
The virtual onsite was four or five rounds total with only two technical rounds, plus a standard behavioral, a cross-functional behavioral, and a surprisingly deep project deep dive that was way more probing than a normal STAR interview.
Question types asked
Specific questions asked
What does a standard day of you as a software engineer look like?
I got the sense they were trying to understand how I work, not just why I wanted the company. I talked through my motivations and what my day-to-day actually looks like, and my read was that they want generalists who can write docs, solve problems, and code well, not people who are just heads-down coding all day.
This round felt specifically cross-functional rather than generic conflict resolution. The emphasis was on how I work with other teams, how I navigate situations when things get messy, and what steps I take to move something forward when the dependency isn't fully in my control.
Implement Excel-like formulas across cells so updates propagate correctly to dependent cells.
How would you handle cells that depend on other cells?
What would you cache, and when would you invalidate it?
I had to model the cell notation and how formulas like one cell depending on another should update when upstream values change. It felt more like practical problem solving than LeetCode. The interesting part was deciding where caching helped versus where caching every value would just slow things down, so I spent most of my time on dependency handling and cache invalidation tradeoffs.
How do you handle different frame rates?
How do you handle users across the world?
What changes when usage goes up 10x, 100x, or 1000x?
I started with a standard streaming design and then got pushed deeper and deeper on scale. The pattern was similar to the first system design: get a reasonable solution in place, then pressure test it. Most of the discussion was about global scale and operational assumptions, not some niche OpenAI-specific system.
Why did you do that project in the first place?
What did you actually do versus the rest of the team?
What was the impact?
What were the technical challenges?
What were the stakeholder or non-technical challenges?
Who were you working with, and what was that relationship like?
This was the most unique round. I gave an outline first, but they immediately drilled into what I personally did, why the project existed, what changed because of it, and how I worked with other people. A normal polished STAR answer wasn't enough here. They were really trying to cut through the BS and see whether I actually understood the work at a deep level.
Get full access with a membership, or share your experience to try it free.
