I kept seeing two opposite takes:

• “Top-company interviews are still mostly LeetCode.”
• “LeetCode is becoming less useful because companies now test practical engineering.”

After structuring 229 candidate experiences across 41 companies, my takeaway is that both statements are true — depending heavily on the company.

For this post, I filtered the data to 74 engineering and technical interview experiences from 2024–2026 across:

• Google
• Meta
• Amazon
• Microsoft
• LinkedIn
• OpenAI
• Anthropic
• Stripe

TL;DR

• Google, LinkedIn and Microsoft still showed the clearest algorithm/DSA signal.
• Meta looked increasingly hybrid: traditional DSA, system design, behavioural evaluation and newer AI-assisted coding rounds.
• Amazon still used DSA, but design depth and Leadership Principle discussions appeared just as consistently.
• Stripe was the clearest practical-coding outlier: multi-part implementation, integrations, debugging, validation and business rules.
• OpenAI and Anthropic leaned more toward implementation and systems depth than short puzzle solving.
• Anthropic also had the strongest explicit values, safety and judgement signal in this dataset.

The two bars are not mutually exclusive. An interview experience can contain both a DSA problem and a practical implementation task.

The company-by-company preparation map

Company	Strongest preparation focus	What repeatedly appeared
Google	DSA plus clear verbal reasoning	Graphs, DP, heaps, custom problems, follow-ups and Googliness
LinkedIn	DSA, system design and engineering excellence	Multiple coding rounds, concurrency, large-scale design, project and leadership depth
Microsoft	DSA plus LLD/OOP	Trees and graphs, concurrency, low-level design, system design and project discussion
Amazon	DSA, system design and technically deep LP stories	Coding, HLD/LLD, ownership, trade-offs and repeated Leadership Principle follow-ups
Meta	DSA speed, product design and AI-output verification	Two-problem coding rounds, system design, behavioural pressure and newer AI-assisted rounds
OpenAI	Practical implementation, refactoring and end-to-end design	Building working systems, unfamiliar code, reliability, project deep dives and product judgement
Anthropic	Practical coding, systems depth and values/safety judgement	Debugging, infrastructure, AI-system trade-offs, culture, ethics and constructive disagreement
Stripe	Multi-part practical coding and integration work	APIs, parsing, validation, debugging, tests, reconciliation and business rules

1. LeetCode is still the correct base for some companies

Among the recent experiences containing coding detail:

• LinkedIn: DSA or algorithmic work appeared in 8 of 8
• Microsoft: 5 of 6
• Google: 7 of 9
• Amazon: 6 of 8
• Meta: 6 of 10

This does not mean grinding tagged questions is sufficient.

Across these companies, candidates repeatedly described being evaluated on:

• explaining the approach before coding;
• handling follow-up constraints;
• producing complete code within time;
• testing edge cases;
• adapting after hints;
• communicating trade-offs clearly.

For Google in particular, several experiences described custom or unfamiliar problems where structured clarification mattered as much as recognising a pattern.

2. Stripe is the biggest mismatch for a pure LeetCode preparation plan

Every one of the 10 recent Stripe technical experiences in this cohort explicitly contained practical implementation work.

The recurring themes were:

• extending an API or existing system;
• parsing and validating data;
• implementing several requirements sequentially;
• finding bugs in an unfamiliar codebase;
• integration work using documentation or SDKs;
• modelling payment, invoice or reconciliation rules;
• writing maintainable code and tests under time pressure.

Only 1 of 10 explicitly resembled a conventional DSA-heavy exercise.

If I had a Stripe interview, I would spend less time trying to memorise another 100 patterns and more time practising:

1. reading a long requirement carefully;
2. implementing it in clean stages;
3. debugging existing code;
4. handling malformed input and edge cases;
5. explaining business rules and correctness.

3. OpenAI and Anthropic reward a different kind of technical depth

OpenAI

Within the 11 recent technical experiences:

• practical implementation appeared in 6 of 11;
• system or architecture design appeared in 8 of 11;
• project or technical deep dives appeared in 5 of 11.

Reported tasks included broader implementation, refactoring, APIs, reliability, distributed systems and end-to-end product design.

The recurring preparation lesson was:

Be able to build and reason about a working system, not only derive an algorithm.

Anthropic

Within the 12 recent technical experiences:

• practical implementation appeared in 8 of 12;
• system or architecture design appeared in 9 of 12;
• behavioural, culture or values evaluation appeared in 11 of 12;
• project or technical deep dives appeared in 6 of 12.

The technical side often involved debugging, infrastructure, operational trade-offs and AI-system design.

The non-technical side was unusually substantive: mission, safety, ethical disagreement, judgement under ambiguity and willingness to challenge a decision constructively.

4. Meta’s AI-assisted rounds are additive — not a replacement for DSA

In the Meta cohort:

• DSA appeared in 6 of 10 experiences;
• practical implementation appeared in 6 of 10;
• system design appeared in 6 of 10;
• an explicitly AI-assisted stage appeared in 4 of 10.

The important point is that the newer AI-enabled coding work did not remove conventional coding or design.

Candidates described needing to:

• inspect generated suggestions rather than trust them blindly;
• debug and extend imperfect code;
• explain why a suggestion was accepted or rejected;
• preserve standard coding speed and DSA fundamentals;
• still complete product/system design and behavioural rounds.

So “AI is allowed in the interview” does not necessarily mean the interview becomes easier. It introduces another skill: verification.

5. Amazon is the clearest warning not to neglect the non-coding rounds

In the eight recent Amazon engineering experiences in this cohort:

• DSA appeared in 6 of 8;
• explicit system or architecture design appeared in 5 of 8;
• Leadership Principle / behavioural evaluation appeared in 8 of 8.

Several candidates reported strong coding performance but rejection or downlevel outcomes after weaker design or broader evaluation.

The useful preparation lesson is not “memorise STAR stories.”

It is:

Prepare behavioural examples with enough technical depth to survive several follow-up questions about your decisions, trade-offs, ownership and actual contribution.

What I would change in my preparation

Google / LinkedIn / Microsoft

Keep DSA as the foundation, but practise it in interview conditions:

• explain before coding;
• ask clarifying questions;
• finish the implementation;
• test edge cases;
• handle a follow-up;
• prepare behavioural and design depth appropriate to level.

Meta / Amazon

Do not separate “coding prep” from the rest of the loop.

Prepare:

• timed DSA;
• system or product design;
• one technically deep project;
• conflict and ownership stories;
• AI-output verification where relevant.

OpenAI / Anthropic

Practise larger, messier engineering work:

• implement a feature from a long prompt;
• refactor unfamiliar code without breaking tests;
• debug a pipeline or service;
• reason through reliability and operational constraints;
• present one project deeply;
• defend decisions under ambiguity.

Stripe

Practise the work around the algorithm:

• parse;
• validate;
• integrate;
• debug;
• model business rules;
• write tests;
• complete incremental requirements cleanly.

Methodology and limitations

• The full dataset contains 229 candidate experiences across 41 companies.
• This post uses 74 engineering/technical experiences dated 2024–2026 from the eight companies above.
• A theme was counted only when the structured experience explicitly mentioned it.
• Categories overlap.
• Missing detail can undercount a theme; absence from the chart does not prove a company never tests it.
• These are candidate experiences, not official fixed processes.
• The outcome mix is self-selected and should not be interpreted as an acceptance rate.

I put the employer-level process breakdowns and candidate findings into a searchable version here:

https://www.blanked.work/employers

I would genuinely like corrections from people who interviewed recently:

1. Which company does this map get most right?
2. Where is it wrong or already outdated?
3. Which company should I break down next?

The goal of blanked is to have a total transparent hiring process for each employer which is crowd sourced and free so you can see what you are getting yourself into, its totally anon and free.