Phase 0 Research — Findings

Captured 2026-07-30. Everything below is stamped with what it is: confirmed, reported, or inference. Read the epistemic labels before you act on any line of it. A prep program built on a confidently-wrong model of the loop fails in a way that is invisible until the day itself.

Table of Contents

• How to Read This Document
• The Epistemic Ladder
• Confirmed
  • C1. Python free-threading status
  • C2. vLLM serving mechanics
  • C3. OpenAI Charter exists and has four named pillars
  • C4. OpenAI has published real infrastructure engineering
  • C5. GPU hardware numbers
  • C6. AI-assisted and agentic coding rounds are a real industry-wide format
• Reported by Candidates and Prep Vendors
  • R1. Loop shape
  • R2. The progressive gate format
  • R3. Recurring coding problems
  • R4. The take-home
  • R5. System design
  • R6. Behavioral and mission fit
  • R7. Levelling
  • R8. AI tool policy varies by lab
• My Inference
• Source Quality Assessment
• What I Could Not Verify
• How This Changes the Program
• References

How to Read This Document

The originating artifact for this program is a single candidate's account of an OpenAI software-engineering loop, posted to a subreddit and roughly four days old at time of capture. That is one unverified source. The loop varies by team, by level, and by quarter. Treating it as ground truth would be a methodological error, and building six months of training on top of it without corroboration would be a worse one.

So Phase 0 did two things:

1. Corroborate — go find independent, dated sources that agree or disagree with each reported claim.
2. Bound the blast radius — where corroboration is impossible, mark the claim as reported and make sure the program does not become so narrow that an unexpected round is a surprise.

The result is the three-tier ladder below.

The Epistemic Ladder

A hard rule for the whole program: you never say to an interviewer "I heard your process does X." Reported material shapes what you practice. It is not conversational material.

Confirmed

C1. Python free-threading status

Status as of Python 3.14 (released October 2025): the free-threaded build is officially supported but not the default. PEP 703 laid out a three-phase plan; PEP 779 defined the criteria for moving from "experimental" (Phase I, Python 3.13) to "officially supported" (Phase II, Python 3.14). Phase III — free-threading as the default build — has not happened and is not scheduled for the near term.

Reported performance characteristics of the 3.14 free-threaded build: single-threaded overhead down to roughly 5–10% (from ~40% in the 3.13 experimental build), multi-threaded CPU-bound speedups in the ~4x range on suitable workloads, and a memory footprint roughly 15–20% higher than the GIL build.

Why this matters for the loop: "Is the GIL gone?" is exactly the kind of question that separates someone who read a headline from someone who tracks the runtime. The correct answer has three parts — which build, which phase, and what it actually costs. This is Track B material, and the drill for it is a runnable script that reports sys._is_gil_enabled() and measures the overhead, not a memorized sentence.

Verification: python3.14 -c "import sys; print(sys._is_gil_enabled())" on a python3.14t build. The Track B experiments directory includes this as a runnable check.

C2. vLLM serving mechanics

The four techniques that define modern open-source LLM serving are documented in vLLM's own material and are verifiable by reading the source:

• PagedAttention — KV cache stored in fixed-size non-contiguous blocks with a block table per sequence, rather than one contiguous pre-allocated buffer per sequence. Removes internal fragmentation and the need to reserve for max sequence length.
• Continuous (in-flight) batching — scheduling at iteration granularity rather than batch granularity. A finished sequence's slot is refilled on the next forward pass instead of the batch idling until its slowest member completes.
• Chunked prefill — splitting a long prompt's prefill across multiple scheduler steps so decode iterations for other sequences are not blocked for the full prefill duration. Trades a small amount of prefill throughput for materially better TTFT tail latency.
• Prefix caching — reusing KV blocks for identical prompt prefixes across requests (system prompts, tool definitions, few-shot blocks).

Confirmed mechanism; the magnitudes are vendor-reported. Claims like "3–5x more traffic than a naive PyTorch loop on the same H100" come from blog benchmarks, not from a measurement you have made. The program's rule (see Operating Rules) is that any performance number you quote in an interview must either be one you measured or one you attribute. Track D includes the measurement harness.

C3. OpenAI Charter exists and has four named pillars

The OpenAI Charter (published 2018) is organized around four commitments, whose headings are quoted consistently across independent mirrors and academic indexes:

1. Broadly Distributed Benefits
2. Long-Term Safety
3. Technical Leadership
4. Cooperative Orientation

The Charter includes the well-known merge-and-assist clause: a commitment to stop competing and start assisting if a value-aligned, safety-conscious project comes close to building AGI before OpenAI does. It also commits to using any influence obtained over AGI deployment for the benefit of all and to avoiding uses that harm humanity or unduly concentrate power.

Caveat, and it matters: openai.com/charter returned HTTP 403 to automated fetching during this research pass. The four headings and the merge-and-assist clause are corroborated across the MIT CyberIR index and the ETO AGORA instrument database, both of which catalogue it as a 2018 document. Before your recruiter screen, open the Charter in a browser yourself and read the primary text. Do not walk into that call with a second-hand summary — the whole point of the question is that you read the actual document. Treat company-brief.md as a scaffold you fill in from the primary source, not as a substitute for it.

C4. OpenAI has published real infrastructure engineering

"Scaling Kubernetes to 7,500 nodes" is a genuine OpenAI engineering post (a follow-on to an earlier 2,500-node post). Documented content includes: replacing Flannel with native pod networking via Azure VMSS IP configurations and the corresponding CNI plugins, and building automated health-check systems to detect and evict malfunctioning nodes at that scale.

Why this matters: the "Reading and rebuttal" differentiator in this program requires you to ask a specific question about a specific design choice they published. This post is a concrete target. See company-brief.md.

C5. GPU hardware numbers

Specifications (vendor datasheet figures, stable and citable):

Cloud hourly pricing is volatile and provider-dependent — figures in the ~$1.49–2.99/hr (H100), ~$3.80/hr (H200), ~$6.50/hr (B200) range were reported in 2026 sources. Treat prices as order-of-magnitude anchors with a date attached, never as facts.

The load-bearing insight, and the one to actually internalize: H200 has identical compute to H100 but ~43% more bandwidth and 76% more memory, and it is meaningfully faster for LLM decode. That is the cleanest available proof that autoregressive decode is memory-bandwidth-bound, not compute-bound. If you can derive why from arithmetic intensity — one weight load per token per parameter at batch size 1 — you have the core of the "design ChatGPT" round. Track D builds this from first principles.

C6. AI-assisted and agentic coding rounds are a real industry-wide format

Independently corroborated beyond the source report: Meta began rolling out AI-enabled coding interviews in late 2025; Google is piloting a Gemini-assisted coding format; CodeSignal shipped agentic coding assessments as a product. Reported formats center on a 60-minute session against a multi-file codebase, progressing through phases (bug fix → core implementation → optimization), with the assistant confined to a chat panel rather than given direct file-edit authority. Stated evaluation criteria across these programs converge on AI fluency: prompt construction, output validation, and debugging the assistant's work.

This is the single most important corroboration in the whole research pass. The source report describes the agentic round as beta and not universally administered — which invites you to skip preparing for it. The independent evidence says the format is becoming an industry standard. Track G is therefore not optional.

Reported by Candidates and Prep Vendors

Everything in this section comes from candidate accounts and prep-vendor guides. Sources disagree with each other in places, and I have flagged where.

R1. Loop shape

The most common reported shape for mid-to-senior SWE:

1. Recruiter screen (~30 min)
2. Technical screen (~60 min live coding, CoderPad)
3. System design screen (~60 min, Excalidraw) — sometimes combined with (2) into one day
4. Take-home / work trial — 48-hour window, reported as paid and under NDA
5. Onsite loop — reported variously as 4 rounds, 4–6 rounds, or 6 components

Disagreement between sources, and it is worth naming: the source report says "4 rounds" onsite plus a beta agentic round. Aggregators list up to six onsite components including a technical presentation and a separate team-fit conversation. Two independent corroborations of the same-day two-round screen exist, which matches the source report.

Two claims corroborate the source report's most distinctive details: that the screen is two 60-minute rounds on the same day, and that the take-home is a 48-hour "build something real" project. One vendor source reports a flat payment for the trial (~$1,000, early 2026) — unverified, and irrelevant to preparation.

R2. The progressive gate format

Multiple independent prep sources describe OpenAI's coding assessment as a progressive obstacle course: each problem has roughly four gates of increasing difficulty, and the reported pass bar is clearing two. Clearing all four is reported as rare.

One source contradicts the leniency: it reports the bar as not passing candidates at "2/4 or a low 3/4." Assume the stricter version. Preparing for a 3/4 bar and encountering a 2/4 bar costs you nothing. The reverse costs you the offer.

This directly corroborates the source report's central claim — the progressive multi-part format, with each stage gated on the previous one working — and it is the reason the progressive harness is the highest-priority build in this program.

R3. Recurring coding problems

Reported patterns, aggregated across sources and deduplicated:

• Time-based / versioned key-value store — reported by several sources independently. This corroborates the source report's screen question directly.
• LRU cache from scratch
• Resumable iterator with state serialization — note how precisely this targets the reported Python-internals emphasis on iterators and generators.
• Rate limiter (token bucket or sliding window)
• KV store serialize/deserialize with delimiter-bearing keys and values
• In-memory database with SQL-ish operations
• Unix cd with symlink resolution
• Spreadsheet formula evaluation with dependencies and cycle detection
• Multithreaded web crawler
• Meeting rooms / interval scheduling

Reported emphases: write substantially more code than in a typical FAANG interview; production-quality, maintainable solutions with real edge-case handling; practical problems over algorithmic tricks. One source states flatly, "you're not going to get questions on string manipulation."

Also reported: occasional math-flavored problems (KL divergence for continuous distributions, expected-iterations problems, cross-entropy minimum error) — more likely on research-adjacent teams. Not corroborated by the source report; the program includes a short optional module rather than ignoring it.

R4. The take-home

Corroborated: 48-hour window, "build something real," reported as paid and under NDA. Reported evaluation criteria converge tightly and are worth taking literally:

• Code quality
• Test coverage
• A written design doc explaining tradeoffs
• How you handled the deliberately under-specified parts of the brief

One source states the principle directly: a working solution with a thoughtful README beats a clever solution with no docs. Another notes the 48 hours include sleep and suggests roughly 4h understanding + design draft, 24–30h implementation and tests, 6–8h polish and writeup, remainder as buffer.

The source report's specific example — a distributed webhook delivery system with retry logic and dead-letter queues — is corroborated by at least one independent vendor source describing a webhook delivery system as a work-trial project. That is meaningful corroboration of an unusually specific detail.

R5. System design

Reported prompts span both conventional systems (Yelp, Twitter, notification systems) and the AI-native ones. The source report's "design ChatGPT" prompt with an interviewer focused on GPU allocation, autoscaling under non-stationary traffic, and distributed coordination is consistent with published treatments of the problem and with the SageServe / ENOVA line of academic work on forecast-aware autoscaling for LLM serving.

Job scheduler with fault tolerance is reported both as a screen question and as a component inside larger architecture prompts (webhook listener → API service → workflow engine → job scheduler).

Reported anti-pattern, and it is a real one: name-dropping technologies without being able to defend the tradeoff. Saying "I'd use Kafka" and being unable to explain the alternative you rejected is worse than proposing a queue you can actually reason about.

R6. Behavioral and mission fit

Reported emphasis on ethics and safety reasoning, and on cross-functional collaboration with researchers, PMs, and safety teams — not only with engineering peers. For Anthropic specifically, multiple sources report the culture/values round as the most common failure point, which is a striking claim for a set of companies whose technical bars are this high.

This corroborates the source report's recruiter-screen question about where AI is headed, and raises its weight. See Track F.

R7. Levelling

Reported, with real disagreement in the details but consensus on the shape: OpenAI runs L3–L7 on the IC track, and its levelling is compressed relative to Google/Meta — an OpenAI level maps to roughly one level higher elsewhere. Multiple sources describe L5 as carrying Staff-equivalent scope despite a "Senior" title.

Practical consequence, and this is the one that changes how you prepare: if you are targeting senior/staff at an AI lab, calibrate your behavioral stories and system-design altitude to Staff at a big-tech company, not Senior. Cross-team architectural influence, not "I owned a service." Every rubric in this program therefore scores at two levels and tells you which one you hit.

R8. AI tool policy varies by lab

Reported: Anthropic prohibits AI tool use in live interviews, and candidates have reportedly been removed from processes for using it. Meanwhile Meta and Google are actively piloting AI-assisted rounds, and OpenAI reportedly runs an agentic round in beta.

These are opposite policies at companies you may interview at in the same month. Ask the recruiter explicitly, per company, per round. Never assume. This goes on the pre-interview checklist in STATE.md.

My Inference

Clearly labelled. None of this is sourced; it is my reasoning from the material above.

I1. The take-home and the deep dive are one round, not two. The take-home's real function is to generate a personalized interrogation surface. The interviewer reads your code and writes questions from it. That means every decision you make in the 48 hours is a question you will be asked in week three. The optimization target is therefore not "best code" — it is "code every line of which I can defend, plus a written record of the alternatives I rejected." A slightly simpler system you can defend completely beats a sophisticated one with three choices you made on autopilot. This reframing drives Track E entirely: you keep a decision log while building.

I2. "Abstract the model-serving layer unless told otherwise" is a scoping test, not a hint about depth. The interviewer wants to see whether you can identify which component of a system is load-bearing for this conversation and hold the rest at a stable interface. Candidates who immediately dive into PagedAttention are demonstrating knowledge while failing the actual signal, which is judgement. The correct move is to name the abstraction explicitly ("I'll treat the inference engine as a service with these three SLOs and this admission interface — tell me if you want to open it up"), then spend your time on traffic, coordination, and failure. But you must be able to open it on request within seconds. Hence Track D drills both altitudes and defaults to the abstracted one.

I3. The progressive format inverts the standard optimization. In a normal coding round you can spend fifteen minutes designing before writing. In a gated format, time-to-first- passing-stage is the metric that compounds — every minute of upfront design is a minute stolen from stages 2, 3, and 4, and a gate you never open scores zero regardless of how elegant your unwritten design was. This argues for a deliberately different habit: build the smallest correct thing fast, then refactor under the pressure of the next stage. It also argues that your stage-1 code must be extensible, since you will be extending it under time pressure. That tension — fast but extensible — is precisely what the format tests, and it is trainable. Time-to-first-correct is a first-class tracked metric in the harness.

I4. The systems-flavored coding round is where the reported Python-internals questions live. "State management, concurrency, memory efficiency" plus "generators, async constructs, iterators" is not two separate observations. It is one observation: they ask you to build a stateful streaming component, and the internals questions arise naturally from your implementation choices. Preparing internals as trivia is the wrong shape. Preparing them as "why did you choose a generator here, and what does that cost" is the right shape.

I5. Your background is closer to this loop than a generic senior SWE's. Multilingual search and recommendation is retrieval, ranking, embeddings, and index serving — which is structurally the same problem as the retrieval-augmentation and serving layers around a chat product. The gap is not conceptual; it is the GPU-economics vocabulary and the inference-specific scheduling. That is roughly six weeks of focused work, not six months. The genuinely unproven areas are speed under gated time pressure and staff-altitude behavioral narrative.

Source Quality Assessment

Be honest about what these sources are. Most "OpenAI interview 2026" results are SEO content marketing produced by interview-prep vendors, some of which sell products of questionable legitimacy. They recycle each other. Agreement between two such sources is weak evidence, not strong evidence — it frequently means one copied the other.

Rule enforced throughout this program: every performance claim you make in an interview must be one you measured or one you attribute. "vLLM gets 3–5x" is a thing a blog said. "I measured 2.8x on my harness at batch 32 with a 512-token prompt" is a thing you can defend under follow-up. The second is worth ten of the first.

What I Could Not Verify

Listed explicitly, because an unmarked gap becomes a false belief.

1. The source report itself. I could not locate the originating subreddit post. Its contents are treated as reported, and every distinctive claim is separately corroborated or explicitly marked uncorroborated in source-report.md.
2. The Charter's primary text. openai.com/charter returned HTTP 403 to automated fetching. Four pillar headings and the merge-and-assist clause are corroborated across mirrors. You must read the primary source in a browser before the recruiter screen.
3. Take-home payment terms. One low-weight source; unverified; irrelevant to preparation.
4. Exact onsite round count. Sources disagree (4 / 4–6 / 6 components). The program prepares for six components so that a fifth or sixth round is not a surprise.
5. Whether the agentic round is administered to senior/staff candidates specifically. Reported as beta and selective. Prepared for regardless — see C6.
6. Any current, dated OpenAI publication describing their own inference stack in detail. The public serving literature (vLLM, TensorRT-LLM, Triton, Ray Serve, and the arXiv autoscaling work) is the grounding for Track D. Do not claim knowledge of OpenAI's internal stack; reason from public systems and say that is what you are doing.

How This Changes the Program

Six research-driven adjustments to what would otherwise be the obvious plan:

1. Track G is not optional. C6 shows the agentic format going industry-wide, not staying a one-lab beta.
2. Assume the strict gate bar (3/4, not 2/4). R2 has sources on both sides. The asymmetry of the error is total.
3. Behavioral weight goes up, not down. R6 reports values/culture as the leading failure mode at a peer lab. Senior engineers systematically under-prepare this. It gets a fixed weekly slot, not a week-eleven cram.
4. Calibrate everything to Staff, not Senior. R7 — compressed levelling means the "Senior" title carries Staff scope. Every rubric scores both and names which one you hit.
5. The volume signal changes coding practice. R3 — write more code than a typical FAANG interview. Typing throughput and clean-first-draft ability are trainable and are trained explicitly, not assumed.
6. Design-doc-writing is a first-class drilled skill. It appears in the take-home criteria, in the deep dive, and in the design rounds. It is drilled to a time budget with a fixed template, not treated as a byproduct.

References

Primary and technical

• OpenAI. Scaling Kubernetes to 7,500 nodes. https://openai.com/index/scaling-kubernetes-to-7500-nodes/
• OpenAI. Charter (2018). https://openai.com/charter/ — read this in a browser; it 403s to fetchers
• Python Software Foundation. PEP 703 — Making the Global Interpreter Lock Optional in CPython. https://peps.python.org/pep-0703/
• Python Software Foundation. PEP 779 — Criteria for supported status for free-threaded Python. https://peps.python.org/pep-0779/
• CPython docs. Python support for free threading. https://docs.python.org/3/howto/free-threading-python.html
• Python Free-Threading Guide. https://py-free-threading.github.io/
• vLLM project. https://github.com/vllm-project/vllm · docs https://docs.vllm.ai/
• vLLM Blog. Inside vLLM: Anatomy of a High-Throughput LLM Inference System (2025-09-05). https://vllm.ai/blog/2025-09-05-anatomy-of-vllm
• Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023). https://arxiv.org/abs/2309.06180
• Yu et al. Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022) — origin of continuous batching.
• Agrawal et al. Sarathi-Serve / chunked prefill. https://arxiv.org/abs/2403.02310
• SageServe: Optimizing LLM Serving on Cloud Data Centers with Forecast Aware Auto-Scaling. https://arxiv.org/pdf/2502.14617
• ENOVA: Autoscaling towards Cost-effective and Stable Serverless LLM Serving. https://arxiv.org/abs/2407.09486
• NVIDIA. H100 Tensor Core GPU. https://www.nvidia.com/en-us/data-center/h100/

Interview process (reported — weight accordingly)

• interviewing.io. OpenAI's Interview Process & Questions. https://interviewing.io/openai-interview-questions
• interviewing.io. Anthropic's Interview Process & Questions. https://interviewing.io/anthropic-interview-questions
• Hello Interview. OpenAI Coding Interviews: Real Questions. https://www.hellointerview.com/blog/openai-coding-questions
• Hello Interview. OpenAI L5 Interview Guide. https://www.hellointerview.com/guides/openai/l5
• Hello Interview. Design ChatGPT. https://www.hellointerview.com/learn/system-design/problem-breakdowns/chatgpt
• Exponent. OpenAI Software Engineer Interview Guide. https://www.tryexponent.com/guides/openai-software-engineer-interview
• Exponent. Google's AI-Assisted Coding Interview (2026 Guide). https://www.tryexponent.com/blog/google-ai-coding-interview
• interviewing.io. How to use AI in Meta's AI-assisted coding interview. https://interviewing.io/blog/how-to-use-ai-in-meta-s-ai-assisted-coding-interview-with-real-prompts-and-examples
• Glassdoor. OpenAI Interview Experience & Questions. https://www.glassdoor.com/Interview/OpenAI-Interview-Questions-E2210885.htm
• CTAIO. AI Lab Levels Explained 2026. https://ctaio.dev/en/salary/ai-lab-levels-explained/

Books that back the design tracks

• Kleppmann, M. Designing Data-Intensive Applications, 2nd ed. O'Reilly.
• Ongaro, D. and Ousterhout, J. In Search of an Understandable Consensus Algorithm (Raft). USENIX ATC 2014.
• Beyer et al. Site Reliability Engineering. O'Reilly, 2016 — chapters on load shedding, cascading failure.
• Ramalho, L. Fluent Python, 2nd ed. O'Reilly — data model, iterators, coroutines.
• Slatkin, B. Effective Python, 3rd ed. Addison-Wesley — concurrency and generator idioms.
• Larson, W. Staff Engineer: Leadership Beyond the Management Track.