How to get a job at OpenAI: what your resume needs

What does OpenAI's reported $30B raise change for job seekers?

In late September 2026, OpenAI was reported to be in talks to raise at least $30 billion at a valuation of roughly $1.4 trillion — a bridge round ahead of a public listing that has now slipped to 2027. Here's why that lands on your desk rather than just your newsfeed: money at that scale buys compute and people. Earlier in the year, reporting put the company's plan at growing from around 4,500 employees toward roughly 8,000 by the end of 2026, with new roles concentrated in research, engineering, product and sales. That's thousands of open requisitions. But more openings does not mean an easier screen — it means a much bigger pile of applications behind each one.

The uncomfortable arithmetic is this: hiring at that speed forces a lab to standardise its first filter. Reviewers cannot read 4,000 resumes per role with the care they'd give 40. So they define criteria against the job post and check each application against them, one line at a time. OpenAI's applications run through Ashby, which keeps your uploaded file for the recruiter but also parses it into structured fields — name, roles, dates, education, skills — and supports AI-assisted review that marks each stated requirement as met or not met, citing the text it found. Your document has two audiences, and the machine reads first.

The bridge from a funding headline to your CV is short and practical. Every new team that gets funded writes a job description, and that description is the rubric. A resume that was strong for a generic backend role in 2023 is now competing against candidates who have rewritten their file specifically for post-training, evals, or inference infrastructure. If you're applying to a frontier lab this quarter, you need two things before you hit submit: a file that parses cleanly, and content aimed at one posting rather than twelve. The rest of this article covers how to build both.

What does OpenAI actually screen a resume for?

OpenAI screens for demonstrated ability to ship technical work, not credentials. Its published interview guidance says plainly that the company isn't credential-driven, and its research postings back that up: qualifications appear as "you might thrive in this role if you…" rather than a list of hard requirements. A chip-design research engineer posting asks for strong programming and debugging with a track record of turning technical ideas into working software, experience with reinforcement learning or post-training, and the ability to work independently on ambiguous problems. Not one of those is a degree. A reviewer is looking for evidence you've already done a smaller version of the job.

In practice that means artifacts a stranger can verify in under a minute. A merged contribution to a library the team actually uses. An eval suite you designed, and the failure mode it caught. A fine-tune you ran, with the benchmark delta and the compute it took. A paper, a technical write-up, a released model card. These beat five years of tidy job titles because they answer the only question the screen cares about: what happens after we hire you? Titles describe where you sat. Artifacts describe what you produced. When space is tight, cut the title padding and keep the artifact.

Here's my contrarian read, and I'll defend it: a PhD is the single most overrated line on an AI-lab resume. It's genuinely valuable for interpretability and theory-heavy research, where postings do ask for research experience at that depth. For almost everything else — post-training engineering, evals, inference infra, applied product work — a public track record of shipping beats a thesis nobody will open. OpenAI's residency explicitly recruits people without formal ML credentials who can build and learn fast. What does get people screened out is being a generalist with no visible engagement with the field. Nobody at a frontier lab is hiring you to learn the domain on the job.

How do you write research and infra bullets with measurable impact?

Write every bullet as: what you changed, how you measured it, what moved, and at what scale. "Worked on model training infrastructure" tells a reviewer nothing. "Cut checkpoint restore time from 14 minutes to 90 seconds across a 512-GPU training cluster, recovering roughly 6% of wall-clock time per run" tells them you understand where the cost actually sits. The scale number is doing as much work as the improvement. Frontier labs care about behaviour at size, because plenty of approaches that look elegant on one node fall apart on a thousand. If you have the scale, name it. If you don't, name what you do have honestly and precisely.

Research bullets follow the same spine with a different currency. State the hypothesis, the experiment, and the finding — including the ones that came back negative, which signal rigour rather than failure. "Ran an ablation across three reward-shaping variants on a 7B model; the sparse-reward variant improved pass rate on held-out tasks by 11 points, and I wrote up why the dense variant regressed" reads like someone who's done real science. Postings for training and long-context roles ask for exactly this: forming clear hypotheses, distinguishing meaningful results from noise, and preferring simple experiments in tightly controlled settings. Also be scrupulous about credit — say "my contribution" when a result belonged to a team, because interviewers will drill straight into whatever you claim.

Confidentiality trips people up, and it's fixable. If you can't disclose absolute revenue, latency or model details, use ratios, percentages and orders of magnitude: "reduced p99 inference latency by 38%", "served roughly 2 billion requests a month", "managed a low-nine-figure annual compute budget". That's specific enough to be credible and vague enough to be safe. Keep each bullet to two lines, put the number early rather than burying it at the end, and start with a verb that names the work rather than a phrase like "responsible for". If drafting these from scratch is the blocker, the HRLens CV builder works as a chat — paste your old file or just describe what you built, then tighten each bullet until the numbers carry it.

Which keywords should you pull from OpenAI's job posts?

Pull them straight from the posting you're applying to, and nowhere else. OpenAI's research and engineering descriptions are unusually specific about vocabulary, and the terms repeat: reinforcement learning, post-training, evals, reward functions, tool-using agents, experiment orchestration, distributed training, transformer efficiency, mechanistic interpretability. Those aren't decoration — they name the actual work of distinct teams. A resume aimed at a post-training role should sound different from one aimed at inference infrastructure, even when the underlying skills overlap heavily. Read the post twice, list every technical noun in it, then check which ones your experience genuinely supports. That list is your outline.

Mirroring language is not stuffing it. Because AI-assisted review at this stage cites the source text it found in your document, a floating keyword block with no supporting bullet actively hurts you — a reviewer sees the term claimed and nothing behind it. White text and invisible keyword tricks are worse than useless: the parser strips the file to text anyway, and a human opens the same PDF. The reliable move is to make each important term earn its place in a bullet that shows the work. Mention RLHF once in the skills line and once in the bullet where you actually built a reward model, and you've said it convincingly twice.

Structure matters as much as wording. Use a single-column layout with conventional headings — Experience, Projects, Skills, Education, Publications — because sidebars and two-column grids get read out of order and split dates from the roles they belong to. Export a text-based PDF rather than a flattened image, skip icons, and keep a short link line for GitHub, Scholar or a personal site where the artifacts live. Engineers who want a parser-safe starting point can use a CV builder made for software engineers and keep the stack section where a parser will actually find it. Then tailor the file per posting; one master document sent everywhere is the most common self-inflicted rejection.

Does your current resume clear the bar, and what should you fix first?

Run this test: hand your resume to someone technical for 30 seconds and ask what you personally built and how big it was. If they can't answer both, you won't clear the screen at a frontier lab — and no amount of polish fixes that, because the problem is content, not design. Most resumes that fail here aren't badly written. They're evenly written: every role gets the same three vague bullets, so nothing stands out as the thing you're known for. Pick your strongest two pieces of evidence, give them real estate at the top of the relevant role, and let the older jobs shrink to one line each.

Then check the mechanics, in this order. Does the PDF select as text when you drag your cursor over it? Do your dates sit beside the right employers after parsing? Is the layout a single column? Is there a link to something a reviewer can open? Have you removed the objective statement and the skills bar charts, which claim proficiency without evidence? Are the pay expectations and location realistic — most of these research roles are San Francisco on-site or hybrid, with posted bands on research engineering running from roughly $360,000 into seven figures on specialised teams? Small mismatches here quietly end applications that were otherwise competitive.

Finally, test the file against the actual job description rather than against your own intuition. Paste the posting text into HRLens's free CV analysis — paste the text rather than a link for boards that block fetching — and you'll get a score out of 100, five category scores including ATS compatibility, a visual layout check and the skills the posting asks for that your CV doesn't mention. Every analysis also produces ATS-friendly rewritten versions in six templates that mirror the posting's own language. Do that once per team you apply to. Thousands of roles are opening at these labs this year; the candidates who win them are the ones who treat each application as its own document.

Frequently asked questions