Company Brief — Mission, Charter, and Talking Points

Purpose: to walk into the recruiter screen having read the primary documents, with a defensible forward-looking position and three questions sharp enough that the interviewer has to think.

⚠️ Verification gate. openai.com/charter returns HTTP 403 to automated fetching. The structure below is corroborated across independent mirrors, but you must open the Charter in a browser and read the primary text before your recruiter call. Fill the quote slots marked [VERIFY] with the actual sentences. A second-hand summary defeats the entire purpose of the question.

Table of Contents

• The Verification Gate
• The Charter: Four Pillars
• What the Charter Actually Commits To
• Reading the Charter Like an Engineer
• Published Engineering: What They Have Told Us
• Talking Points: One Page
• Where Is AI Headed: The Answer
• Three Sharp Questions to Ask Them
• Adapting This Brief to Other Labs
• Rehearsal Protocol
• References

The Verification Gate

Before this brief is usable, complete these four steps and record the date in ../STATE.md:

Why this is a gate and not a suggestion: the reported recruiter-screen advice is literally read the charter before that call. If you paraphrase a summary of a summary, it will show in the follow-up, and the follow-up is the actual test.

The Charter: Four Pillars

Published 2018. Four commitments, headings corroborated across the MIT CyberIR index and the ETO AGORA instrument database:

1. Broadly Distributed Benefits

Commits to using any influence obtained over AGI's deployment for the benefit of all, and to avoiding uses of AI or AGI that harm humanity or unduly concentrate power.

[VERIFY] — paste the actual sentence here.

2. Long-Term Safety

Commits to doing the research required to make AGI safe, and to driving broad adoption of such research across the AI community rather than treating safety work as proprietary advantage.

Contains the merge-and-assist clause: if a value-aligned, safety-conscious project comes close to building AGI before OpenAI does, OpenAI commits to stop competing with it and start assisting it.

[VERIFY] — paste the merge-and-assist sentence verbatim. It is the single most quotable line in the document and the one most likely to come up.

3. Technical Leadership

Asserts that policy and safety advocacy alone are insufficient — to be effective at addressing AGI's impact on society, the organization must be at the frontier of AI capabilities.

[VERIFY]

4. Cooperative Orientation

Commits to actively cooperating with other research and policy institutions, and to seeking to create a global community working together to address AGI's global challenges.

[VERIFY]

What the Charter Actually Commits To

Read as an engineer, not as a reader of mission statements. A charter is a constraint document: it says what the organization will refuse to do. Three constraints are load-bearing:

1. A stopping condition. The merge-and-assist clause is a pre-commitment to abandon a competitive position under a specified trigger. That is unusual and it is checkable.
2. A non-concentration constraint. "Unduly concentrate power" is a constraint on deployment, not on research. It is the pillar most in tension with commercial reality, and the one a thoughtful candidate can discuss honestly.
3. A capability-is-prerequisite-to-safety argument. Pillar 3 asserts that you cannot steer what you cannot build. This is the claim that draws the most external criticism and the one you should be able to argue both sides of.

This is the depth the question is actually probing. Anyone can say "I love the mission." The signal is whether you have read it closely enough to notice that pillars 2 and 3 are in productive tension, and whether you can hold that tension without either dismissing it or being naive about it.

Reading the Charter Like an Engineer

The recruiter screen question is "where do you think AI is headed?" — asked by someone who has heard four hundred answers. Here is what separates the tiers:

The strong version requires having an actual position. That is what Where Is AI Headed below and the technical-opinion essay in ../projects/README.md exist to produce.

Published Engineering: What They Have Told Us

You cannot claim knowledge of their internal stack. You can reason from what they published — and doing so is far more impressive than speculation.

Scaling Kubernetes to 7,500 nodes

A genuine OpenAI engineering post, following an earlier 2,500-node post. Documented content:

• Networking: Flannel could not sustain the required throughput at that node count. They moved to native pod networking using Azure VMSS IP configurations and the corresponding CNI plugins.
• Node health: at that scale, automated detection and eviction of malfunctioning nodes is mandatory. They built health-check systems for it.
• Thesis: one very large cluster keeps researcher-facing infrastructure simple — scale up without changing your code — and they judged that simplicity worth the operational cost of pushing a single cluster past its comfortable envelope.

Why this is the right post to have read. It is a tradeoff post, not a victory lap. They chose one big cluster over many small ones and paid for it in networking and node-health engineering. That choice is arguable, which makes it a real question to ask about — see Q1.

What is not public

There is no current, dated OpenAI publication describing their inference stack in the detail that vLLM or TensorRT-LLM describe theirs. Do not pretend otherwise. The correct framing in a design round:

"I don't know how you do this internally, so I'll reason from the public systems I've read — PagedAttention, continuous batching from Orca, chunked prefill from Sarathi-Serve — and you can tell me where that diverges from your reality."

This is a strength move, not a hedge. It shows you know the literature, you know the boundary of your knowledge, and you can be corrected without losing the thread.

Talking Points: One Page

Compress to this. Rehearse until it is conversational, not recited.

On the mission (30 seconds). Four pillars: broadly distributed benefits, long-term safety, technical leadership, cooperative orientation. The structurally interesting part is that it is a constraint document with a stopping condition — the merge-and-assist clause pre-commits to abandoning a competitive position under a specified trigger. Pillars 2 and 3 are in real tension: capability is argued as a prerequisite for safety. I find that argument mostly persuasive and I can say where I think it strains.

On why this company (30 seconds). Ground it in the work, not the brand. Your honest version: you have spent a decade on retrieval, ranking, and serving systems where the constraint was always "make this sub-100ms and cheap at scale." The serving layer around a frontier model is the same problem with a harder cost structure and a memory-bandwidth wall instead of an I/O wall. That is a continuation of your career, not a pivot.

On what you would work on (30 seconds). Inference serving and the retrieval systems around it. Be concrete: continuous batching and scheduler policy, KV cache and prefix reuse, admission control and fairness under non-stationary load. These are queueing and scheduling problems, and you have shipped queueing and scheduling systems.

On their hardest unsolved engineering problem (60 seconds). Your defensible answer: serving cost per useful token under adversarial, non-stationary, multi-tenant load, with a latency SLO that users can feel. Decode is memory-bandwidth-bound (the H100→H200 comparison is the clean proof: identical compute, ~43% more bandwidth, materially faster decode). So throughput comes from batching, and batching fights latency, and latency is the product. Every technique — continuous batching, prefix caching, speculative decoding, chunked prefill — is a different point on that curve. Meanwhile agentic workloads make traffic burstier and less predictable, so autoscaling signals that were fine for request-response chat degrade badly. Be ready to be told you are wrong and to incorporate the correction.

On safety posture (30 seconds, honest). Have a real read. Note the tension between pillar 3's capability-first argument and pillar 2's safety commitment; note that the merge-and-assist clause has never been triggered and its trigger conditions are not operationally defined. State that you find the "you can't steer what you can't build" argument credible while thinking the non-concentration commitment is the hardest one to keep. Do not perform either enthusiasm or skepticism. Interviewers at these companies have finely tuned detectors for both.

Where Is AI Headed: The Answer

Full written answer lives in ../tracks/behavioral/README.md and gets a rehearsal slot every week. The structure it must have:

1. A specific claim, not a trend list. Example shape: "The binding constraint on useful AI over the next two years is not model capability, it is the cost and latency of inference under agentic workloads, where one user turn becomes fifty model calls."
2. Evidence you can cite or have measured. Arithmetic intensity of decode; the H200's bandwidth-only advantage; what continuous batching does to the throughput-latency curve; what a tool-calling loop does to token volume per user action.
3. What would change your mind. "If speculative decoding acceptance rates hold at high ratios on real agentic traffic, or if a genuinely different serving architecture lands, the cost curve moves faster than I'm assuming and the constraint shifts back to capability." Stating a falsifier is the single strongest signal in the answer.
4. The connection to what you would build. Ties directly to the talking points.

Length: 90 seconds. Then stop and let them push. The push is where the points are.

Three Sharp Questions to Ask Them

Not "what's the culture like." Questions that demonstrate you read their work and thought about it. Each names a specific design choice and asks about the tradeoff behind it.

Q1 — On the single-cluster bet

"The 7,500-node post argues that one very large Kubernetes cluster keeps things simple for researchers — scale up without changing your code — and you paid for that with the Flannel replacement and the node-health automation. Now that a large share of the fleet is serving production inference rather than research training, does the simplicity argument still hold? I'd expect serving and training to want opposite things from a scheduler — serving wants fast preemption and tight tail latency, training wants gang scheduling and long uninterrupted holds. How do you keep those from fighting?"

Why it works: quotes a real published choice, understands why they made it, and identifies a specific reason it might have aged. It is a question only someone who has run schedulers would ask.

Q2 — On the serving/latency tradeoff

"Everything in the public serving literature — continuous batching, chunked prefill, prefix caching — is a different point on the throughput-versus-tail-latency curve. Where do you sit on that curve, and is it one curve or several? I'd guess an interactive chat turn, a long agentic tool loop, and a batch API want genuinely different scheduler policies, which implies either separate pools or a priority-aware scheduler with preemption. Which way did you go, and what did it cost?"

Why it works: shows you know the technique inventory and that you understand the techniques are not free wins but positions on a tradeoff. The "one curve or several" framing is the question a serving engineer asks.

Q3 — On the charter under commercial pressure

"The Charter's non-concentration commitment — avoiding uses that unduly concentrate power — is the pillar with the most tension against a commercial deployment business. Is that something engineers encounter as a concrete constraint on design decisions, or does it live at the policy layer? I'm asking because I'd rather know now whether it shows up in code review."

Why it works: takes the mission seriously as an engineering constraint rather than as decoration, and asks a question whose answer actually affects whether you would enjoy the job. Reported sources say values rounds are the leading failure mode at peer labs — demonstrating you engage with the mission substantively rather than reverently is the distinguishing behavior.

Have all three ready. Ask two. Leave one in reserve for the round where the interviewer finishes early.

Adapting This Brief to Other Labs

Tracks A–D and F transfer wholesale. Only this file and Track D's depth emphasis change.

Note the pattern: Cursor, Netflix, and Stripe each map onto something you have already built. Those are your highest-conversion targets, and the webhook project doubles as Stripe-relevant portfolio work.

Rehearsal Protocol

Weekly, 15 minutes. Recorded, then scored against ../mocks/README.md's behavioral rubric.

1. 90-second career narrative — cold, to a timer.
2. "Where is AI headed?" — 90 seconds, ending on a falsifier.
3. "Why us?" — 30 seconds, grounded in the work.
4. "What's our hardest unsolved engineering problem?" — 60 seconds, then defend it against one pushback.
5. Ask your three questions out loud. If any sounds like it came off a list, rewrite it.

Failure mode to watch for: over-rehearsal. These must sound like opinions you hold, not paragraphs you memorized. If a recording sounds recited, cut it to bullet points and re-derive it live next session.

References

• OpenAI. Charter (2018). https://openai.com/charter/ — primary; read in a browser
• OpenAI. Scaling Kubernetes to 7,500 nodes. https://openai.com/index/scaling-kubernetes-to-7500-nodes/
• OpenAI Index (engineering and research posts). https://openai.com/index/
• MIT CyberIR. OpenAI Charter (index entry). https://cyberir.mit.edu/site/openai-charter/
• ETO AGORA. OpenAI Charter (instrument 767). https://agora.eto.tech/instrument/767
• Anthropic. Core Views on AI Safety. https://www.anthropic.com/news/core-views-on-ai-safety
• Anthropic. Responsible Scaling Policy. https://www.anthropic.com/rsp
• Google DeepMind. Frontier Safety Framework. https://deepmind.google/discover/blog/introducing-the-frontier-safety-framework/
• Kwon et al. Efficient Memory Management for LLM 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).
• findings.md — corroboration status for every claim above
• source-report.md — rows 4 and 5 land here