Company: xAI
Role: Software Engineer
Level: Staff-Level
Location: Seattle, WA
YOE: 12
Education: Bachelor’s
Status: Declined

Compensation Breakdown

• Base salary: $200K
• Equity grant: $1.6M over 4 years
• Vesting schedule: 25 / 25 / 25 / 25
• First-year equity: $400K
• First-year total compensation: $600K

Discussion

Curious how people would evaluate this one.

• For a Staff SWE with 12 YOE, does $600K first-year TC at xAI feel strong, normal for top AI labs, or lower than expected?
• Does Seattle make this more attractive compared with Bay Area AI-lab offers, or is location less important at this comp level?

Would love Reddit takes here too. I’m also collecting more detailed comments under the offer page here, so future candidates can compare the raw offer data with real market opinions.

Prepping for xAI's Interviews?

We’ve been tracking xAI's interview experiences at here.

Company: Amazon
Role: Software Engineer
Level: Mid-Level / SDE II
Location: Seattle, WA
Round type: Onsite
Question type: Coding, System Design and Behavior Question
Difficulty: Medium
Duration: Around 4 hours

Overall Format

Each round followed a similar structure. The candidate first spent around 30 minutes answering behavioral questions, mostly around Amazon Leadership Principles. After that, the interviewer moved into the technical portion.

The coding was written from scratch, but there were no provided test cases and no need to actually run the code. The expectation was to explain the approach clearly and write a clean solution within the remaining time.

Coding Round 1: Kth Largest Perfect Binary Subtree

The first coding problem gave a binary tree and an integer k. The task was to find the kth largest perfect binary subtree inside the tree.

The core idea was to traverse the tree and determine whether each subtree is perfect. For each valid perfect subtree, the solution needs to compute its size, collect the valid subtree sizes, and return the kth largest one.

This was not conceptually too difficult, but it required clean recursive logic and careful explanation.

Coding Round 2: Find Conflicting Events

The second coding problem gave a list of events. Each event had:

• User name
• Region name
• Timestamp

Two events were considered conflicting if they had the same user ID, different region names, and timestamps within a threshold K.

The main challenge was organizing the events efficiently. A reasonable approach is to group events by user, sort each user’s events by timestamp, and then check nearby events for region conflicts within the time window.

System Design: Primary DB and Read Replicas

The system design round was about a primary database with read replicas. This did not feel like a generic system design question. Since the team appeared to work on databases, the discussion focused more on real operational issues.

Important topics included:

• Primary DB failure
• Failure detection
• Read replica behavior
• Recovery strategy
• Failover process
• Consistency during failover
• How clients route traffic after primary failure

The round seemed less about drawing a generic architecture diagram and more about reasoning through database reliability.

OOD Round: Snake Game

The object-oriented design round asked the candidate to design Snake Game. The expected design likely needed to cover:

• Snake body representation
• Movement logic
• Collision detection
• Food placement
• Board boundaries
• Game state updates

Since the technical portion was short, the important part was probably structuring the classes cleanly and explaining the core operations.

Prepping for Amazon's Interviews?

We’ve been tracking Amazon's interview experiences at here and Amazon commonly asked coding questions at here

Company: Meta
Role: Software Engineer
Level: Mid-Level (E4)
Location: London, UK
YOE: 6
Education: Bachelor’s
Status: Accepted

Compensation Breakdown

• Base salary: £88K
• Signing bonus: £10K
• Equity grant: £190K over 4 years
• Vesting schedule: 25 / 25 / 25 / 25
• First-year equity: ~£48K
• Annual bonus: £13.2K
• First-year total compensation: £158.7K

Discussion

Curious how people would evaluate this.

• For Meta London E4 with 6 YOE, does £158.7K first-year TC feel strong, normal, or a little underwhelming?
• After UK tax, rent, and cost of living, how attractive is this package in practice?

Would love Reddit takes here too. I’m also collecting more detailed comments under the offer page here, so future candidates can compare the raw offer data with real market opinions.

Prepping for Meta's Interviews?

We’ve been tracking Meta's interview experiences at here.

Company: OpenAI
Role: Software Engineer
Level: Senior-Level
Location: San Francisco, CA
YOE: 4
Education: Master’s
Status: Considering

Compensation Breakdown

Base salary: $325K

Signing bonus: $100K

Equity grant: $2.35M over 4 years

Vesting schedule: 25 / 25 / 25 / 25

First-year equity: ~$588K

First-year total compensation: ~$1.012M

Discussion

Curious how people would evaluate this.

• For a senior SWE with 4 YOE, does ~$1.01M first-year TC feel like the new AI-company market, or is this an outlier?
• Would you take this over a lower but more liquid public-company offer from Google, Meta, Netflix, or Databricks?
• And how much discount would you apply to OpenAI equity when comparing it against public RSUs?

Would love Reddit takes here too. I’m also collecting more detailed comments under the offer page here, so future candidates can see the valuation assumptions next to the actual offer data point.

Prepping for OpenAI's Interviews?

We’ve been tracking OpenAI's interview experiences at here

Tech interviews can get weird sometimes.

Not necessarily the hardest question, but the most random or unexpected thing you were asked.

Could be a coding prompt, system design scenario, behavioral question, brain teaser, recruiter question, or anything that made you think: “wait, why are we talking about this?”

I’ve seen people mention things like debugging a tiny state machine, designing a parking lot for no clear reason, explaining a side project from 5 years ago, or getting a behavioral question that felt way more intense than the technical round.

What was yours?

I also started a longer-running thread here to collect the funniest / strangest interview questions by company and role.

Company: Anthropic
Role: Software Engineer
Level: Staff-Level
Location: San Francisco Bay Area
Round type: Onsite
Question type: Multiple types
Difficulty: Medium
Duration: Around 5 hours
Outcome: Did not pass

Process Overview

The process started with a recruiter call and hiring manager chat. After that, the candidate moved directly into onsite rounds. The onsite had five rounds:

• Coding
• System Design 1
• System Design 2
• Technical project discussion
• Culture round

The candidate felt most technical rounds went reasonably well. Their guess was that the Culture round was probably the weakest signal.

Hiring Manager Round

The HM round was relaxed and mostly covered background, past projects, and standard project-related behavioral questions.

The candidate’s impression was that this round was mainly checking whether their experience matched Anthropic’s Infra org and whether it made sense to move them into the onsite loop.

Coding Round: Repair Bootloader Program

The coding question was the commonly asked Repair Bootloader Program problem. The candidate had a few small bugs early on but debugged them during the round and finished around the 50-minute mark. Overall, they felt this round probably went fine.

The main skill tested seemed to be careful simulation, loop detection, debugging, and making sure the repaired program terminates correctly.

System Design 1: Model Downloader

The first system design round was Model Downloader. The candidate used a chunk-based pipeline design. The discussion went into how chunk size affects the difference between a pipeline approach and a tree-style approach.

Initially, the design used a coordinator to assign chunks and handle recovery. The interviewer then followed up by asking how recovery would work without a coordinator. The candidate felt this round likely passed.

System Design 2: 1:1 Chat System

The second system design round was a 1:1 chat system. This round felt more average. The candidate started with a queue-based design, but got the sense that the interviewer may have expected a Pub/Sub channel-style approach instead.

The interviewer kept pushing on scaling questions, and the discussion did not feel as smooth. The candidate was not fully sure what direction the interviewer wanted.

Technical Project Discussion

This was probably the candidate’s strongest round. The interviewer was very senior, and the candidate walked through a project they had worked on for around two years. The discussion covered technical details, design decisions, trade-offs, and project impact.

One interesting follow-up was about ROI: If the project cost around 50 engineer-years, and each engineer cost roughly $400K per year, would the project justify a $20M investment?

That question stood out because it tested senior-level judgment beyond pure technical implementation.

Culture Round

The Culture round felt rough. The interviewer was not an engineer, so some of the candidate’s technical examples may not have landed clearly. The questions were also more subtle than standard behavioral prompts.

Examples included:

• What kind of work do you dislike most?
• If the interviewer also disliked that work, how would you persuade them to do it?
• Have you ever done anything morally incorrect?

The candidate did not feel well-prepared for these questions and did not have strong answers ready.

Prepping for Anthropic's Interview?

We’ve been tracking Anthropic's interview experiences at here and commonly asked coding questions at here.

I have got offer from Google India and will be joining around mid august.

Details:
Clg: Tier 1
Yoe: 4
Current TC: 55L

Google Offer
Level: L4
Base: 42L
Variable: 15%
Equity: 75k (38%, 32%, 20%, 10%)
Joining Bonus: 5L
Other benefits: 3.3L

I have accepted this offer.

I have few questions, can existing googlers please answer them

1. When is google review cycle and would I be eligible in it? How hard is to get RSU/Raise?
2. How much variable % is given to me, say if I got rating of 4? or 3?
3. What does welcome kit contain? do we get phones as well?
4. How to excel there and difficult is to get promoted to L5 there?

Thanks,

I keep seeing mixed signals about interview prep lately.

Some people say LeetCode is still the fastest way to pass SWE screens. Others say interviews are shifting toward practical coding, debugging, system design, AI tooling, and project depth, especially for infra / AI / senior roles.

For people actively interviewing in 2025–2026:

• Are companies still asking classic LeetCode-style problems?
• Or are you seeing more practical tasks like debugging, data processing, API design, concurrency, system design, or AI-related implementation?

I’m especially curious how this differs by level:

• New grad / junior: still mostly LeetCode?
• Mid-level: coding + system design?
• Senior / staff: more design, debugging, architecture, and tradeoffs?
• AI / ML roles: more projects, model knowledge, or applied AI systems?

I opened a longer-running discussion thread here so people can add company / role / level-specific examples over time.

I’ll summarize the useful patterns back here if people share enough data points.

Company: Anthropic
Role: AI Safety Fellow
Level: Intern
Location: San Francisco, CA
Round type: Full journey
Difficulty: Hard
Duration: Around 3 hours total
Outcome: Rejected
Timeline: Around 2 months

Process Overview

The process had several stages:

• Resume screen
• Online assessment
• Take-home assignment
• Short video interview
• Three references required

The candidate’s impression was that the cohort size was very small. They also felt references may have mattered a lot, especially because even some applicants from top schools appeared to be rejected.

Online Assessment

The OA required both camera and screen recording. One interesting rule: Google search was allowed, but AI tools were not allowed. The OA had two parts.

OA Part 1: Step-by-Step Implementation

The first section asked candidates to implement functionality across multiple stages, roughly from step 0 to step 7. The difficulty increased gradually. Later stages involved more complex topics like:

• Recursion
• Caching
• Concurrency

The candidate scored around 55% on this part.

OA Part 2: Debugging

The second section was a debugging task with around 6 to 8 bugs. The goal was to fix the bugs and pass the tests. The bugs did not seem to be extremely tricky corner cases, but the task still required careful reading and debugging under time pressure.

The candidate scored around 90% on this part. No detailed feedback was provided beyond the approximate scores.

Take-Home Assignment

The take-home assignment gave candidates a few hours to solve an open-ended research question. The submission required both:

• Code
• A written explanation

This part was interesting because AI tools were allowed here. The instructions even suggested using tools like Claude Code, Codex, or similar AI coding assistants. The candidate’s impression was that completing the take-home without AI would have been extremely difficult.

Video Interview

The final interview was online and only around 15 minutes. It had two broad questions, followed by rapid follow-ups. The pace was very fast, and the interviewer also spoke quickly.

The questions were more general problem-solving questions rather than narrow technical trivia. The candidate only had about 1.5 days to prepare after receiving the interview notice, which felt tight given how broad the questions were.

Final Thoughts

This process felt much closer to a competitive research fellowship screen than a regular internship interview. The OA and take-home were demanding, but the final decision still felt opaque because there was no feedback on the take-home or video interview.

The biggest takeaways:

• Expect a highly selective process
• Be ready for both implementation and debugging
• Practice explaining broad research ideas quickly
• Prepare for open-ended questions, not just coding
• References may matter more than in a normal SWE internship process
• The take-home may assume strong AI-assisted workflow skills

Curious if others went through the Anthropic AI Safety Fellow process. Did the final video interview feel like the deciding factor, or do you think the take-home and references carried most of the weight?

Prepping for Anthropic's Interview?

We’ve been tracking Anthropic's interview experiences at here and commonly asked coding questions at here.

I’m a new grad and having a hard time deciding between two verbal offers. I’d appreciate advice, especially from people familiar with Meta PE, Intel software teams, immigration/GC policies, or early-career SWE growth.

Background:

I interned at Meta last year as a PE and got a GE rating. I returned this February as a new grad to my original team, Warm Storage, but was laid off on 5/20 after only about 3.5 months. It was pretty rough emotionally. I started interviewing quickly and now have two verbal offers. One of them is a return offer to Meta.

Offer 1: Meta | Ads Infra PE

Pros:

- Stronger brand name and resume value. During my recent job search, Meta connections definitely helped.

- Ads Infra is a core revenue org. The manager said the team is relatively stable, and only one person was impacted around 5/20.

- The director proactively reached out to me, which feels like a positive signal.

- Mature large-scale infra work, likely a good place to learn.

- Potentially Day 1 green card. I’ve also heard PE cases may be slightly easier for immigration, but I’m not sure.

Cons:

- Package stays around the same: ~133K base + ~32K stock.

- Returning would effectively cost me around $50K due to losing 2 months of severance plus no new sign-on.

- I have some anxiety about going back to Meta after being laid off as a new grad after only 3.5 months.

- Not sure if PE has worse long-term career growth compared with pure SDE.

- Team fit is a question mark. The team has many newer people, with most tenure under 5 months.

Offer 2: Intel | AI Agent SDE

Pros:

- More trendy technical area: Agent Harness / Hybrid Agent, roughly OpenClaw + hybrid model scheduling.

- 30K sign-on.

- Slightly higher level / comp. Current numbers are around 155K base + 28K cash per year + 30K sign-on.

- Expected WLB seems better.

- Team communication/culture fit feels more comfortable to me.

- Because of H1B considerations, I may choose the Oregon office, which seems more favorable and can map to level 3.

Cons:

- The team feels like an internal startup inside Intel, so project stability is unclear.

- Agent Harness sounds exciting, but I’m worried about long-term durability since AI is changing so fast, unless it can tie meaningfully into Intel’s hardware advantage.

- Intel is still primarily a hardware company, so I’m not sure the software engineering process will be as strong as top software companies.

- Initial HR discussion suggests GC may only start after H1B, which is a downside. Would appreciate any Intel folks confirming or correcting this.

My questions:

1. As a new grad, if I want to optimize for stability, future optionality, and career growth, which offer would you choose?
2. How much does PE vs SDE matter early in career?
3. Is Intel’s AI Agent internal startup worth betting on, or is returning to Meta Ads Infra the better long-term move?
4. For immigration/GC, is Meta clearly better here?

Thanks in advance. Any advice is appreciated.

Company: Waymo
Role: Machine Learning Engineer
Level: Senior-Level
Location: San Francisco Bay Area
YOE: 7
Education: Master’s
Status: Accepted
Reported Date: June 24, 2026

Compensation Breakdown

• Base salary: $250K
• Signing bonus: $30K
• Equity grant: $600K over four years
• Vesting schedule: 25 / 25 / 25 / 25
• First-year equity: $150K
• Annual bonus: $37.5K
• First-year total compensation: $467.5K

What Stands Out

The $250K base is strong, while the standard equity schedule keeps compensation relatively consistent after the first year. Excluding the signing bonus, recurring annual compensation is approximately $437.5K before future refreshers or stock-price changes.

The package is competitive for a senior MLE with 7 YOE, although it remains below some of the more aggressive offers coming from frontier AI labs. Waymo may still be especially attractive for someone interested in applied ML, perception, planning, simulation, or large-scale autonomous systems.

Prepping for Interviews?

We’ve been tracking interview experiences of 100+ companies at here.

Problem Summary

You are given shortcut entries in this format: pattern:code. For example: save:10 means if the parser sees "save", it should output "10". Implement: parseCommand(command, shortcuts). It should return a list of command codes and literal characters.

Parsing Rules

At each position in the command string:

• Choose the longest shortcut pattern that matches the current prefix
• If a shortcut matches, output its command code and consume the entire pattern
• If no shortcut matches, output the current character as plain text
• Continue parsing from left to right

Example 1

Command: saveasopen

Shortcuts: save:10, saveas:20, open:30

Output: ["20", "30"]

Why? At the start, both "save" and "saveas" match, but "saveas" is longer, so we output "20". Then "open" matches and outputs "30".

Example 2

Command: runxstop

Shortcuts: run:1, stop:2, xray:3

Output: ["1", "x", "2"]

Why? "run" matches first. Then at "xstop", "xray" does not match, so "x" is kept as plain text. Then "stop" matches.

Example 3

Command: checkoutcheckche

Shortcuts: check:4, checkout:9, che:2, out:7

Output: ["9", "4", "2"]

Why? At the beginning, both "check" and "checkout" could match, so we take the longer one: "checkout" -> "9". Then "check" -> "4", then "che" -> "2".

Straightforward Approach

The simple solution is to parse the string with a pointer. At each index, scan all shortcut patterns and find the longest one that matches command starting from the current position.

If found:

• Append the corresponding code
• Move the pointer forward by the pattern length

If not found:

• Append the current character
• Move the pointer by 1

This is easy to implement and probably acceptable if the input size is small.

Better Approach: Trie

If there are many shortcuts, a trie is cleaner and faster. Build a trie from all shortcut patterns. Each terminal node stores the command code for that pattern.

Then while parsing the command, start from the current index and walk down the trie as far as possible. Keep track of the last terminal node seen, because that represents the longest valid match so far.

If a terminal match exists, output its code and jump forward by the matched length. Otherwise, output the current character.

Complexity

• With the brute-force approach:
  • Time: O(n * m * L) where n is command length, m is number of shortcuts, and L is average shortcut length.
• With a trie:
  • Time: O(n * Lmax) where Lmax is the maximum shortcut length.
  • Space: O(total characters across all shortcut patterns)

Edge Cases

Some cases worth clarifying:

• No shortcuts at all
• No shortcut matches anywhere
• Multiple shortcuts share a prefix
• One shortcut is a full prefix of another shortcut
• Shortcut code may be any string
• Command contains punctuation or spaces
• Patterns are unique, but codes may or may not be unique

Prepping for Anthropic's Interview?

We’ve been tracking Anthropic's interview experiences at here and commonly asked coding questions at here.

Company: Uber
Role: Software Engineer II
Level: Mid-Level
Location: Sunnyvale, CA
Question Type: Coding + System Design
Result: Did not pass
Difficulty: 8/10

Phone Screen: Rotate Image

The phone screen asked Rotate Image, a LeetCode medium problem. Given an n x n matrix representing an image, the task was to rotate it 90 degrees clockwise in place. The key requirement was to modify the original matrix directly instead of allocating another matrix. A standard approach is to transpose the matrix first, then reverse each row.

Onsite Coding Round I

• The first onsite coding round had two hard problems. The first was Sliding Window Maximum. Given an array and a window size k, the task was to return the maximum value in every sliding window. The optimal solution uses a monotonic deque to keep candidate indices and runs in O(n) time.
• The second was Median of Two Sorted Arrays. Given two sorted arrays, the goal was to return the median in O(log(m+n)) time. This requires binary search over the partition point instead of merging the arrays.

Onsite Coding Round II

Rate limiter design / implementation question and Word Break.

• For the rate limiter, the candidate had to discuss possible algorithms such as Token Bucket or Leaky Bucket, choose one, explain the trade-offs, and describe the implementation logic. The important points were request timestamps, refill logic, capacity, and how the limiter behaves under burst traffic.
• The second question was Word Break. Given a string s and a dictionary wordDict, the task was to determine whether s can be segmented into dictionary words. The standard solution is dynamic programming over string prefixes.

System Design: Uber Matching

The system design round asked the candidate to design Uber’s rider-driver matching system. The discussion focused on low-latency geographic search, matching nearby riders and drivers efficiently, and scaling the architecture. Key topics included location indexing, driver availability updates, real-time matching, microservice boundaries, database choices, and consistency guarantees.

Behavioral Round

The behavioral round went deep into past project experience. The interviewer asked about project details, ownership, and how I made decisions. Other questions included conflict resolution, why the candidate wanted to join Uber, and how the candidate work under high pressure while still delivering results.

Takeaway

This was one of the most demanding mid-level loops the candidate have experienced. It required strong LeetCode fundamentals, practical design skills, system design knowledge, and detailed behavioral examples.

Prepping for Uber's Interview?

We’ve been tracking Uber's interview experiences at here

Company: OpenAI
Role: Forward Deployed Engineer
Level: Senior-Level
Location: Singapore
YOE: 6
Education: Master’s
Status: Accepted
Date: June 21, 2026

Compensation Breakdown

• Base salary: S$300K
• Equity grant: S$1M over 4 years
• Vesting schedule: 25 / 25 / 25 / 25
• First-year equity: S$250K
• First-year total compensation: S$550K

What Stands Out

The biggest thing that stands out is how strong this package is for Singapore. S$300K base alone is already very high for a senior engineering role in the region. Adding S$1M in equity makes the offer feel much closer to top-tier US AI company compensation than a typical local market package.

Forward Deployed Engineer Angle

The Forward Deployed Engineer title is interesting. This is not a pure backend SWE or ML engineer role. FDE roles usually sit closer to customers and real-world deployments, which means the work can involve product engineering, integrations, customer-facing problem solving, rapid prototyping, and translating messy business requirements into working AI systems.

At OpenAI, that could be a very high-impact role, but probably also a demanding one. The compensation reflects that mix of engineering ability, product judgment, and customer-facing execution.

Why This Offer Is Interesting

This feels like another signal that top AI companies are willing to pay globally competitive packages for strong engineering talent outside the US.

For Singapore specifically, S$550K first-year TC is a standout number. The question is whether this is becoming normal for OpenAI-style AI deployment roles, or whether this is an unusually strong offer for a high-priority hire.

It also raises an interesting comparison against senior SWE / solutions engineering / sales engineering roles at companies like Anthropic, Databricks, Palantir, Google, Meta, and other AI infrastructure companies.

Discussion

Curious how people would evaluate this.

• For a senior Forward Deployed Engineer in Singapore with 6 YOE, does S$550K first-year TC feel market-setting?
• Would you take an FDE role at OpenAI over a more traditional senior SWE role with similar compensation?
• And how much would you discount or value the customer-facing nature of the role compared with a pure engineering role?

Prepping for OpenAI Interview?

We’ve been tracking OpenAI's interview experiences at here.

Company: Databricks
Role: Software Engineer
Level: Senior-Level
Location: San Francisco, CA
Round: Phone Screen
Question Type: System Design
Result: Did not pass
Difficulty: 5/10
Duration: 60 minutes

System Design Prompt: Book Seller Platform

The prompt was to design a book marketplace platform where customers submit purchase requests for a specific book with a maximum price, and the system automatically finds the best deal from registered sellers. Sellers can register with different APIs, so the system needs an integration layer that normalizes seller-specific request and response formats. This could be handled through adapters, seller metadata, API credentials, timeout settings, and per-seller rate limits.

Core Flow

A customer submits a buy request, the system fans out price and availability queries to multiple sellers, filters offers above the customer’s maximum price, chooses the lowest valid offer, and then completes the purchase through the selected seller.

Synchronous vs Asynchronous Processing

The prompt asked to support both synchronous and asynchronous processing. For low-latency requests, the system can query a subset of sellers synchronously within a tight deadline. For slower or high-volume workflows, it can enqueue the request, gather seller responses asynchronously, and notify the customer when a purchase result is ready.

Scale Requirement

The system needs to scale to around 10,000 queries per second. This makes fan-out control important, because querying every seller for every request could multiply traffic dramatically. Caching, seller ranking, request hedging, timeouts, and backpressure become important design topics.

Reliability and Tail Latency

Since third-party seller APIs can be slow or unreliable, the design should include deadlines, retries with limits, circuit breakers, partial results, and fallback behavior. It is also important to avoid letting slow sellers block the entire purchase flow.

Payment and Purchase Safety

The purchase flow is a multi-step workflow, so idempotency matters. The system should avoid double-charging customers or placing duplicate seller orders. A payment hold, order reservation, idempotency key, and reconciliation process would help make the checkout safer.

Caching and Inventory Freshness

Seller prices and inventory may change quickly, so caching is useful but risky. The system can cache search results for short TTLs, but should revalidate price and availability before final purchase

Final Thoughts

This is not just an e-commerce design question; it is really about external API fan-out, heterogeneous integrations, tail latency, idempotent checkout, and resilient orchestration.

Prepping for Databrick's Interview?

We’ve been tracking Databrick's interview experiences at here and commonly asked coding questions at here.

Company: OpenAI
Role: Software Engineer
Level: Staff-Level
Location: San Francisco, CA
Round: Phone Screen
Question Type: Coding + System Design
Result: Did not pass
Difficulty: 5/10

Overall Format

The process had two technical phone rounds:

• Coding: Plant Infection
• System Design: Sora video generation orchestration

The coding round was not necessarily hard at the base level, but it had many follow-ups. The system design round was less about video generation itself and more about scheduling expensive, limited machines reliably.

Coding Round: Plant Infection

The first round was Plant Infection. This problem needs to be practiced thoroughly because the follow-ups can take a lot of time, (can practice at here) it is easy to run out of time before finishing the extensions.

System Design: Sora Generation Orchestration

The system design round asked the candidate to design a scalable system that lets users submit prompts to generate videos, check the statuses of all their video generations, and receive a push notification when a video finishes.

• Required APIs: The system needed to support POST /video {prompt, user_id} -> ack, GET /videos {user_id} -> [{video_id, status, video_address}], and a callback to an existing push notification service when video generation completes.
• Machine Constraint: The system has a limited number of expensive specialized machines that can generate videos. Each machine can generate only one video at a time, and the number of machines available to the system fluctuates throughout the day.
• Machine Control: The prompt allowed adding custom code on the generation machines, such as running an HTTP server or sending heartbeats. This means the design can include worker registration, health checks, leasing, progress reporting, and worker-to-scheduler communication.
• Out of Scope: The prompt explicitly said not to worry about storing or serving generated videos. Each generated video can be assumed to have a unique address that the system can reference.
• Core Design Direction: A good design is to treat this as a job orchestration system. The API service accepts video generation requests, stores job metadata, enqueues jobs, and a scheduler assigns jobs to available generation machines. Workers report status, write the final video address, and trigger notification when the job completes.
• Important Failure Cases: The design should cover worker heartbeat failures, machines disappearing while a video is generating, job retries, idempotent job state transitions, queue backpressure when machines are scarce, and how to avoid losing jobs when the scheduler or worker crashes.

Prepping for OpenAI's Interview?

We’ve been tracking OpenAI's interview experiences at here

I work in supply chain and used to work as an engineer at a site in Bay Area and got promoted to a sr engineer to move to SoCal to work at a different site for the same employer. I was making 140k (+8%) bonus in the Bay Area and was offered 147k (+15%) bonus for the promotion and relocation to SoCal. This was in November 2025, and I decided to accept the offer at the time even though it was just a 5% base pay increase, the increased bonus target and the lower cost of living in SoCal made it worth it.

Fast forward to now (June 2026), I am being contacted by my former site’s leadership for a Sr. operations manager role asking me to move back. I’m pretty confident that the offer would be mine if I went after it seriously and I want to ask for advice on the minimum offer I should ask for.

Sr Operation Manager and Sr Industrial Engineer sit in the same pay band at my company. For the move back to the Bay Area, I want to ask for a pay increase to 170k (+15% bonus). I have done math to calculate that my take home pay would have to increase by at least $800 a month for me to maintain my current lifestyle and savings rate. This number comes out to 165k. I am not thinking too much about what they would offer, but regardless I can’t accept the offer without at least 165k at a minimum. Is asking for 170k the right approach - this is a ~12% increase from current?

Company: Anthropic
Role: Software Engineer
Level: Sr. Staff-Level
Location: San Francisco Bay Area
Round: Onsite
Question Type: Multiple Types
Result: Did not pass
Difficulty: 5/10

Overall Process

The loop looked like this:

• Recruiter call
• Hiring manager chat
• Coding round
• System design 1
• System design 2
• Technical project discussion
• Culture round

The unusual part was that there was no OA or technical phone screen before the onsite. After the recruiter and HM conversations, the candidate moved directly into the full loop.

Hiring Manager Round

This round was fairly relaxed and mostly covered my background, past projects, and normal project-related behavioral questions. My impression was that the main goal was to check whether my experience matched the Infra org and whether it made sense to move me into the onsite loop.

Coding Round: Bootloader-Style Problem

The coding question was recently asked question: Repair Bootloader Program. I had a few simple bugs early on, but I debugged them and finished it right around the 50-minute mark. I felt this round probably went fine. I didn't realize this site has collected a similar question before.

System Design 1: Model Downloader

The first system design round was Model Downloader. I used a chunk-based pipeline design, and we discussed how chunk size affects the difference between a pipeline approach and a tree-style approach. I initially used a coordinator to assign chunks and handle recovery, then the interviewer followed up by asking how recovery would work without a coordinator. I felt this round likely passed.

System Design 2: 1:1 Chat System

The second system design round was a 1:1 chat system, and this one felt more average. I started with a queue-based design, but I got the sense that the interviewer may have expected a Pub/Sub channel-style approach instead, because they kept pushing on scaling questions. The discussion did not feel as smooth, and I was not fully sure what direction they wanted.

Technical Project Discussion

This was probably my strongest round. The interviewer was very senior, and I walked through a project I had worked on for around two years, including technical details and design decisions. One interesting follow-up was about ROI: if the project cost around 50 engineer-years, and each engineer cost roughly $400K per year, would the project return justify something like a $20M investment?

Culture Round

This round felt rough, and I did not prepare as well as I should have. The interviewer was not an engineer, so some of my technical examples may not have landed clearly. I got a few tricky questions, such as what kind of work I dislike most, and then a follow-up asking me to persuade the interviewer to do that same work if they also disliked it. I was also asked whether I had done anything morally incorrect, and I did not have a good answer ready.

Takeaway

The overall loop was unusual compared with many other interview experiences I had seen. There was no OA or screen; after the recruiter and hiring manager conversations, the onsite had one coding round, two system design rounds, one technical project discussion, and one culture round

Prepping for Anthropic's Interview?

We’ve been tracking Anthropic's interview experiences at here.

Company: OpenAI
Role: Software Engineer
Level: Senior-Level
Location: San Francisco Bay Area
Round: Full Journey
Question Type: Multiple Types
Result: Did not pass
Difficulty: 9/10

Overall Process

The process included:

• Phone screen system design
• Phone screen coding
• Onsite system design
• Onsite coding
• Technical deep dive
• Hiring manager round
• Extra director follow-up

Phone Screen: Payment System Design

The system design phone screen was Payment System. The discussion focused on payment flow, reliability, consistency, retries, duplicate-payment prevention, reconciliation, and how to handle failures across external payment providers.

Phone Screen Coding: Machine Topology

The coding phone screen was Machine Topology. I cannot recall the exact prompt details.

Onsite System Design: Design Sora

The onsite system design round asked me to design Sora. This round went unusually smoothly and even ended early because the interviewer seemed to run out of follow-up questions. After going through the main design and follow-ups, we still had extra time and ended up chatting for a while.

Onsite Coding: GPU Credit

GPU Credit: The onsite coding round was GPU Credit (can check this for reference). I am not sure whether this was the round that hurt me. I finished the implementation, including debugging, around 20 minutes early, but I may not have communicated my thought process clearly enough. One strange thing was that the interviewer kept pointing out bugs right before I found them myself, even though there was still plenty of time left.

Technical Deep Dive

The technical deep dive was fairly standard. I chose a project with strong cross-functional collaboration and clear impact, then walked through the project background, my role, technical decisions, trade-offs, and results.

Hiring Manager Round

The HM round was also standard. It mainly covered STAR-style behavioral questions around past work, decision-making, collaboration, conflict, and how I operate in ambiguous or high-pressure situations.

Extra Director Follow-Up

• The day after the onsite, the recruiter said interviewer feedback had not all come in yet. On the third day, they said they wanted to add one more director round to see whether there was a team match. At that point, I already felt something might be off, but since the process had gone this far, I agreed to do it.
• Director Follow-Up: The director conversation felt pretty good from my side. We talked through fit and potential match, and I thought the discussion went reasonably well.

Final Outcome

The next day, the recruiter said they had synced with the team and decided there was not enough positive signal to move the packet to hiring committee. The process ended there, which felt especially frustrating because I still do not know which round or signal caused the final decision.r round after onsite but still not move the packet to hiring committee?

Prepping for OpenAI's Interview?

We’ve been tracking OpenAI's interview experiences at here

Company: Airbnb
Role: Software Engineer
Level: Senior-Level
Location: San Francisco, CA
Round: Full Journey
Result: Did not pass
Difficulty: 8/10

Overall Process

The full loop included:

• Recruiter screen
• Phone screen
• VO coding round
• Code review
• System design
• Past experience
• Hiring manager call
• Extra system design round
• Rejection call

The main theme was that Airbnb seemed happy with most rounds, but system design was the deciding factor.

Recruiter Screen

The recruiter screen was a standard recruiting call. Nothing unusual stood out here. It sounded like a normal intro conversation about background, role fit, and process.

Phone Screen: KV Store

The phone screen was a KV store question. The implementation was bug-free, and the candidate discussed time complexity clearly. Because time was limited, they did not fully implement the optimized version, but they explained the optimization verbally and wrote some pseudocode.

The interviewer was nice, and this round was passed. One interesting detail: the candidate had to write their own test cases, which also came up again in the onsite coding round.

VO Coding Round: Airbnb-Style Chain Booking

The coding question was wrapped in an Airbnb-style listing booking scenario. The input was a list of properties like: [xi, yi, ri]

Where:

• xi, yi represent the listing coordinate
• ri is the chain-effect radius
• If one listing is booked, all listings inside its radius are automatically booked too
• Newly booked listings can trigger their own radius and continue the chain

The question was: If you can choose only one listing to book initially, what is the maximum number of listings that can eventually be booked?

Later, the candidate realized the problem was similar to LeetCode 2101, but during the interview they had not seen it before. They implemented a DFS solution on the spot, and it passed the test cases. This is one of those problems where the story is product-themed, but the core is graph traversal.

Code Review Round

The code review round was done in Java. The structure sounded similar to other Airbnb code review experiences, even though many public writeups use Python examples. The interviewer said there were four PRs total, but finishing all of them was not required.

The evaluation seemed to focus more on the quality and quantity of comments rather than simply reaching the end. The candidate completed comments for the first three PRs. They did not finish everything, but the interviewer said: “I think you did a great job.”

So this round sounded positive.

System Design: Booking System

The original system design question was a booking system, which is a pretty common Airbnb-style design prompt. The first half went okay because the candidate had prepared this topic a bit. But the weaker part was pagination, especially around relational database indexing.

This became important later because the recruiter said the system design round did not produce enough signal, so Airbnb wanted to add one more SD round.

Past Experience Round

The past experience round went well. The candidate prepared an architecture diagram beforehand, which helped the interviewer understand the project quickly. The interviewer asked detailed follow-up questions and stayed engaged throughout the discussion.

Because the candidate’s background was close to the team’s domain, this round felt strong. This seems like a good reminder that for senior interviews, preparing a clear architecture diagram for past work can make a big difference.

Hiring Manager Call

After the VO rounds, the recruiter said they wanted to schedule an HM call. The recruiter also mentioned that most rounds were solid, but system design needed an extra round because the original SD feedback was not conclusive.

The HM call went very well. The team’s domain was close to the candidate’s background, and the work sounded interesting. About two hours later, the recruiter emailed that the HM feedback was good. At this point, it sounded like the process was close.

Extra System Design: Internal Ticket System

The extra system design question was to design an internal ticket system. Tickets could come from:

• Email
• API
• Contact form

Agents should be able to view and claim tickets based on different rules, such as:

• Language
• Location
• Assignment rules
• Availability

Managers also needed metrics over a past time window, including:

• Average first response time
• Average close time

This question had a lot of surface area. The candidate had not seen it before and spent too much time clarifying requirements. By the time they started the actual design, there were less than 20 minutes left. They only finished the high-level diagram before time ran out.

Final Result

The recruiter later called with the rejection. The feedback was that many parts were strong, the HM call went well, and the decision was close. But the extra system design round was the reason they decided not to move forward.

That is probably the most painful type of rejection: not a total mismatch, not a bad loop overall, but one weak signal that outweighed the rest.

Discussion

• Curious how others would handle the internal ticket system design question.
• For a 45 to 60 minute SD round, would you start with ticket ingestion, assignment rules, agent workflow, or analytics metrics?
• And for Airbnb senior loops, how common is it for an extra system design round to decide the final outcome?

Prepping for Airbnb Interview?

We’ve been tracking Airbnb's interview experiences at here.