Blanked’s research sheet contains 15 OpenAI accounts and 13 Anthropic accounts. I reviewed them to answer a narrower question than the careers pages do: what did candidates say the interviews actually rewarded?
I expected the OpenAI accounts to be dominated by technical depth, while the Anthropic accounts would add a clear emphasis on mission and values. Practical engineering was prominent in both sets. The divergence appeared in the judgment around that work.
My read is that the engineering bar overlaps. In the OpenAI accounts, candidates repeatedly described being pushed on scale, failure modes and operational correctness. The Anthropic accounts contained those concerns too, but more often connected them to values, misuse and decisions made with incomplete information. That is the pattern I examine below.
01
What I looked at
I reviewed detailed process summaries, assessment themes, round counts and preparation advice from 28 public candidate accounts. For every finding, I used only the experiences containing the relevant detail and kept the supporting count visible.
That matters because these accounts are not uniform. One person may describe the assessment themes in depth but omit the total number of rounds; another may provide a round count without much preparation advice. Keeping the denominator beside each finding lets the interview fingerprints be compared without flattening different evidence into one generic score.
Exponent supplied 18 of the 28 accounts. That concentration is important when interpreting a pattern that appears several times.
- Exponent18
- LeetCode5
- Glassdoor3
- Medium2
Of the 25 accounts with an interview year, 23 were from 2025 or 2026. I treat the results as recent, source-concentrated observations rather than estimates of the full candidate population.
Experiences vary by role, level, location and year. OpenAI’s set also contains product, growth and data-science roles, while Anthropic’s is entirely software and ML. These counts are planning signals. They are not company-wide probabilities or a promise of what every candidate will encounter.
Read Blanked’s methodology →02
Both sets emphasize practical engineering
I grouped the preparation advice into broad themes. I did not use exact interview questions or copy candidate wording.
Practical or production-focused preparation appeared in 10 of 15 OpenAI notes and 6 of 13 Anthropic notes. Combined, 16 of the 28 experiences pointed toward implementation, debugging, testing, production constraints or realistic engineering work.
Each bar shows the share of notes in that company’s set containing the named theme.
Practical or production-focused preparation
Theme that distinguished each set
The lower pair contains two different codes; it is not a single scale with opposing endpoints. The comparison shows what recurred within each company’s preparation notes.
Algorithm drills alone would therefore be a weak preparation strategy. The data also does not support a technical-versus-cultural framing: technical work is common in both sets, while the preparation notes differ in what surrounds it.
03
What practical engineering meant in these accounts
The coding and design notes were more revealing than the stage names. I grouped the work formats without reproducing exact interview questions.
Accounts described multi-part implementation gated by tests, refactoring existing code and designing services across API boundaries. Follow-up discussion often moved into retries, failure modes, correctness and load.
Accounts described networked implementation, layered requirements, unfamiliar libraries and applied-data tasks. Several then moved into safety, misuse, ethics or trade-offs without a clean technical answer.
Both sets contained applied coding and system reasoning. In the OpenAI accounts, discussion more often moved toward production failure and scale. In the Anthropic accounts, it more often moved toward values, misuse and decisions with incomplete information.
04
What I would prepare for at OpenAI
Coding appeared as a reported stage in 9 of 14 OpenAI experiences with usable stage information. System design appeared in 6 of those 14. The detail inside those labels was more useful than the labels themselves.
System-design trade-offs appeared in 7 of 15 assessment-informed experiences. Operational reliability appeared in 5 of 15. Among the 14 experiences containing system-design information, reliability and scale appeared in 5, while API and service design appeared in 4.
My preparation would centre on explaining how a design behaves under real usage: what fails first, which constraints matter, what I would measure and how I would recover.
Questions I would practise
- What fails first when usage increases?
- Which reliability target matters here, and why?
- What would I measure before releasing this?
- How would I debug a solution that works on the happy path but fails in production?
- Which trade-off would I make if latency, correctness, safety and delivery speed conflicted?
The recurring signal was an ability to make operational judgment visible while building. Reciting Designing Data-Intensive Applications would not demonstrate that skill.
See OpenAI’s published hiring process on Blanked →05
What I would prepare for at Anthropic
Coding appeared as a reported stage in 5 of 12 Anthropic experiences with usable stage information. An onsite loop appeared in 6 of those 12, while system design appeared in 3.
Production-style implementation appeared in 6 of 12 assessment-informed experiences. Values and safety judgment also appeared in 6 of 12. System-design trade-offs appeared in 4 of 12. In the behavioural notes, 7 of 13 mentioned culture and values, while 5 of 13 mentioned motivation or mission.
I would prepare by working through technical decisions with no obviously safe or convenient answer. Rehearsing the company’s mission statement would not be enough.
Questions I would practise
- How would I balance capability, user value and safety?
- What would I do if the fastest product decision introduced a risk I could not fully measure?
- Which guardrails would I put around a powerful feature, and how would I know they were working?
- How would I push back on a decision I disagreed with without stalling the work?
- What trade-off would I make if safety, research speed and operational reliability pulled in different directions?
The accounts repeatedly joined practical engineering with safety judgment. Candidates described having to explain both the mechanism they chose and the risks created by that choice.
See Anthropic’s published hiring process on Blanked →06
Round counts suggest different process shapes
The round counts produced the clearest structural difference between the two sets.
| Company | 1 rounds | 2 rounds | 3 rounds | 4 rounds | 5 rounds | 6 rounds | 7 rounds | 8 rounds |
|---|---|---|---|---|---|---|---|---|
| OpenAI | 2 | 2 | 3 | 0 | 0 | 3 | 2 | 1 |
| Anthropic | 1 | 2 | 1 | 0 | 0 | 1 | 6 | 0 |
Bar labels show the reported number of rounds; accounts marked “so far” or “at least” remain at the number observed when collected.
Seven rounds appeared in 6 of 11 Anthropic experiences containing structured round-count information.
OpenAI’s round counts were much more dispersed in this dataset. Three rounds appeared in 3 of 13 structured records, and six rounds appeared in another 3 of 13. The other OpenAI experiences landed at one, two, seven or eight rounds.
In this sample, Anthropic had a clear seven-round centre of gravity; OpenAI did not.
Before starting either process, I would ask how many stages remain, whether there is a presentation or take-home component and how quickly the interviews can be scheduled. That matters when another offer process is already moving.
07
How I would split my preparation time
Debugging, reliability, scale, API boundaries and explaining what I personally owned in past projects.
Production-style implementation, machine-learning systems, safety judgment and communicating clearly when the answer is genuinely uncertain.
The evidence points to a different allocation of preparation time for each company.
08
What candidate accounts add to official process pages
Most interview comparisons stop at the official list of stages. Candidate experiences reveal something more practical: the evidence people were repeatedly asked to produce, where the process consumed time and how preparation should change between employers.
I deliberately did not compare offer or rejection rates. Public interview posts are a self-selected sample, several accounts stopped mid-process, and the source mix is not balanced. An “offer rate” calculated from these rows would look precise while saying very little.
Keeping a denominator beside each claim is the simplest way to preserve the variation across roles, levels, locations and years.
That is why I am building Blanked. Employer careers pages explain the role from the company’s perspective. Candidates should be able to see what the process may actually involve before committing hours to it.