Time-Based Key-Value Store (extended). Implement a KV store that stores values with timestamps and supports retrieving the value most recently set at or before a given timestamp. Follow-ups add custom serialization without built-in JSON libraries, file-system persistence and restoration, and thread-safe multi-writer access with lock-comparison trade-offs. Equivalent to LeetCode 981 as a starting point, but significantly extended.

Start with a map from key to a sorted list of (timestamp, value) pairs; binary search on get for O(log n) retrieval. The key insight for the serialization extension is length-prefix encoding (similar to the Redis protocol) to handle arbitrary characters including the delimiter. For persistence, flush state to a file with a defined binary format and reconstruct on startup. For the concurrency follow-up, discuss per-key read-write locks vs. a global lock vs. optimistic locking, noting that per-key locks maximize write throughput for independent keys. Likely follow-up: 'How would you handle clock skew between writers?' Correctness of the binary search boundary condition, clean separation of serialization logic, and the ability to reason about lock granularity trade-offs rather than just naming one approach.

Spreadsheet Cell Dependencies (OpenSheet). Implement a simplified spreadsheet API with setCell and getCell where cell values can be either literals or formulas referencing other cells (e.g., =A1+B2). Part 1: correct evaluation with real-time dependency resolution. Part 2: optimize getCell to O(1) by proactively propagating updates through dependents during setCell. Detect and handle circular dependencies.

Model cells as nodes in a directed dependency graph. For Part 1, topological sort (or DFS) on each getCell call works but is O(n) per call. The key insight for Part 2 is to flip the propagation direction: when a cell is set, walk all downstream dependents and update their cached values eagerly, keeping a dirty flag. Circular dependency detection uses a visited set during DFS; return an error or sentinel value on cycle detection. Follow-up: 'What if the formula language includes range functions like SUM(A1:A10)?' Correct dependency graph construction, understanding of the push vs. pull evaluation model trade-off, and cycle detection that does not infinitely recurse.

In-Memory Database with SQL-like Operations. Implement an in-memory database supporting insert, delete, and a select(table_name, where=None, order_by=None) interface. The WHERE clause supports AND logic with comparison operators; ORDER BY supports multiple columns with direction. No SQL string parsing is required — the API takes structured arguments.

Model each table as a list of row dictionaries keyed by column name. For select, filter rows by iterating and evaluating the structured WHERE conditions, then sort using Python's sort with a multi-key comparator. The key insight is that the interface is already parsed, so the challenge is clean data modeling and correct multi-column sort stability. Follow-up: 'Add a transaction layer with rollback.' This shifts the problem to maintaining a write-ahead log or snapshot-based undo. Clean abstraction (table class vs. nested dicts), correct handling of None vs. missing WHERE, and type-safe comparisons across column values.

Design Slack. Design a real-time team messaging platform supporting channels, direct messages, presence indicators, message history, and push notifications at a scale of hundreds of millions of users.

Start by clarifying functional scope (channels, DMs, threads, search) and non-functional requirements (latency under 100ms for message delivery, strong eventual consistency for history). Key components: WebSocket gateway for real-time delivery, fanout service that pushes a message to all channel members, message store (append-only log per channel, similar to Kafka partitions), presence service with heartbeats, and a notification service for offline users. The critical trade-off is read-path vs. write-path fanout: at Slack's scale, write-time fanout to individual mailboxes is too expensive for large channels, so a hybrid approach (push for small channels, pull for large ones) is expected. Follow-up: 'How do you handle a channel with 100,000 members?' Ability to identify the fanout bottleneck unprompted, correct data model for append-only message logs, and a concrete proposal for the presence subsystem that does not require a single coordination point.

Design GitHub Actions. Design a distributed CI/CD workflow execution system where users define pipelines as YAML, triggers fire on code events, and jobs run on ephemeral compute with dependency ordering between steps.

Key components: event ingestion (webhook receiver from GitHub events), a workflow parser that converts YAML to a DAG of jobs, a job scheduler that topologically orders jobs respecting dependencies, a runner pool (ephemeral VMs or containers spun up per job), a log streaming service for real-time output, and a status store. The hardest design decision is the job scheduling layer: a push model (scheduler assigns runners directly) vs. a pull model (idle runners poll a queue) — pull scales better and is fault-tolerant since a crashed runner simply leaves the job unacknowledged. Follow-up: 'How do you handle a job that exceeds its timeout?' and 'How do you support matrix builds (same job across N OS/language combinations)?' DAG representation of job dependencies, the pull-based runner model for fault tolerance, idempotent job execution (re-running a failed job should be safe), and artifact storage between dependent jobs.

Design a Payment Processing System (similar to Stripe). Design a system for accepting payments from merchants, processing card transactions through card networks, handling webhooks, and ensuring exactly-once transaction semantics.

Core components: API gateway with idempotency key enforcement, a payment intent state machine (created, processing, succeeded, failed), an integration layer to card networks (Visa, Mastercard), a ledger service for double-entry bookkeeping, a webhook delivery system with retry and delivery guarantees, and a reconciliation job. The central insight is the idempotency layer: every payment API call should carry a client-generated idempotency key stored in a persistent map; duplicate requests return the stored result rather than charging twice. Follow-up: 'How do you handle partial network failures between your system and the card network where you don't know if the charge went through?' Correct idempotency design, the state machine approach to payment status, recognition that double-charging is worse than under-charging so the system should err toward at-most-once charging at the network boundary, and a reconciliation process.

Tell me about a time you disagreed with your manager or a senior technical decision. How did you handle it and what was the outcome?

Use STAR. The key is to pick a situation where you had substantive technical grounds for disagreement (not a preference), took a constructive approach (gathered data, proposed an alternative rather than just objecting), escalated appropriately if needed, and either changed the decision or accepted it professionally after being heard. Conclude with what you learned. Avoid stories where you were simply overruled with no explanation — OpenAI wants evidence of productive pushback. Intellectual honesty, willingness to challenge authority with data, and the maturity to commit to a decision even after disagreement. Screens for engineers who can hold a position without becoming obstructionist.

Describe a project you were involved in that didn't meet expectations. What went wrong and what did you learn from it?

Pick a real failure with meaningful scope (not a trivial bug). Be specific about what the expectation was, what actually happened, and the root cause (your own decisions, external factors, communication failures). The answer should demonstrate genuine reflection — not deflection onto teammates or circumstances — and a concrete change in behavior or process that resulted from it. Growth mindset, accountability, and self-awareness. OpenAI explicitly screens for candidates who treat failure as data rather than as an identity threat.

Tell me about the most difficult technical challenge you have faced and how you solved it.

Choose a problem that required sustained effort over weeks or months rather than a clever one-day fix. Structure the answer to cover why it was hard (novel constraints, missing prior art, cross-system complexity), the approach you took and why, key decision points, and what the resolution looked like. Follow-ups will push on alternatives you did not choose and the residual risks of your solution. Depth of technical reasoning, persistence under uncertainty, and the ability to articulate complex technical narratives clearly to a non-specialist audience.

OpenAI Interview Questions

OpenAI's SWE interview loop typically spans 3 to 4 weeks and consists of a 30-minute recruiter screen, two 60-minute technical sessions (coding + system design), and a final virtual on-site loop of 4 to 6 rounds covering additional coding, system design, a project deep-dive, and behavioral. The loop is the same for L4 and L5 but the bar is calibrated differently; L5 questions emphasize organizational influence and large-scale system ownership. Unlike classic FAANG loops, OpenAI strongly de-emphasizes pure algorithm puzzles in favor of multi-part, production-flavored problems that require significant code volume, state management, and concurrency reasoning — candidates who try to pattern-match to LeetCode easy/medium are frequently caught off-guard.

19 real questions across 3 rounds

Reported via HelloInterview blog 'OpenAI Coding Interviews 2025: Real Questions from Real Candidates', HelloInterview L5 guide (2026), linkjob.ai OpenAI coding question bank (2026), Medium/@anqi.silvia '8 Coding Questions from the 2025 OpenAI Interview', Medium/@fuji246 'OpenAI coding question: OpenSheet', Exponent OpenAI interview process blog, coditioning.com OpenAI SWE coding questions, 1Point3Acres GPU Credit Tracker + Resumable Iterator + Distributed Machine Cluster posts, interviewing.io OpenAI guide, igotanoffer OpenAI coding interview, LeetCode discuss 'open ai interview experience' (post 7334602).

7 more coding questions OpenAI actually asks, each with how to approach it and exactly what the interviewer is evaluating. Unlock the full set across every round.

Continue with Google

Or run a OpenAI mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews