Genuine question: With AI coding tools getting better, why are coding interviews still so focused on solving problems under pressure without much real-world context?

I get that companies still need to test fundamentals. But in actual work, engineers now use AI tools, docs, search, linters, tests, code review, and existing codebases. The job is increasingly about understanding messy requirements, debugging, evaluating tradeoffs, and shipping reliable systems.

So what should coding interviews actually test in 2026?

• Classic LeetCode under time pressure?
• Practical coding with tests?
• Debugging broken code?
• Code review?
• System design follow-ups?
• AI-assisted coding, but with harder evaluation?
• Something else?

I’m not saying coding interviews should disappear. I’m just wondering whether the format is starting to feel outdated compared with how software engineering actually works now.

Curious what people are seeing in recent interviews.I also started a longer-running thread here to collect what people are actually seeing in recent coding interviews by company, role, and level.

Company: Hudson River Trading
Role: Software Engineer
Level: Senior-Level
Location: New York, NY
Round type: Online Assessment
Question type: Coding
Difficulty: Medium
Duration: Around 70 minutes
Platform: CodeSignal

Overall OA Format

The assessment had four Python questions. The main challenge was not that any one question was extremely hard. The challenge was switching quickly between different problem styles while staying precise about small rules in each prompt.

Question 1: Local Valley in an Array

The first problem gave a one-dimensional array and asked for an index where the current value is strictly smaller than both neighboring values.

In other words, it was looking for a local valley instead of a local peak. The key was handling neighbor comparison cleanly and paying attention to boundary assumptions from the prompt.

Question 2: Debugger State Simulation

The second problem modeled a tiny debugger. The input included:

• Total number of code lines
• A sorted list of breakpoints
• A sequence of commands

A next command moved execution down by one line. A continue command jumped to the next breakpoint.

This was mostly a state-machine simulation problem. The candidate needed to maintain the current line, process commands in order, and use the sorted breakpoint list efficiently.

Question 3: Identifier Formatting Inside Backticks

The third problem was a string transformation task involving code-like text. Some tokens were wrapped in backticks. Only identifiers inside those backticks needed special handling.

Rules included:

• Normal snake_case function or variable names should be converted to camelCase
• All-uppercase constants should stay unchanged
• Text outside backticks should remain untouched

The tricky part was not camelCase conversion itself. The real challenge was parsing only the backtick-delimited regions correctly and leaving the rest of the sentence unchanged.

Question 4: Rectangle Fit Queries

The last problem had a stream of operations. Some operations added a rectangle with dimensions a x b. Other operations asked whether all previously added rectangles could fit into a box of size a x b.

The clean way to think about it was maintaining enough aggregate information about inserted rectangles so each query did not need to scan every rectangle again.

The exact implementation depended on the fit rules in the prompt, but the core idea was efficient dimension tracking across updates and queries.

Prepping for HRT's Interviews?

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

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: Meta
Role: Software Engineer
Level: Mid-Level
Location: Seattle, WA
Round type: Virtual Onsite
Question type: Coding + System Design + AI Coding
Difficulty: Medium
Duration: Around 3 hours
Result: Passed

Overall Loop

The loop covered:

• AI-enabled coding
• Regular coding
• System design
• Practical implementation trade-offs

The most interesting part was that one coding round explicitly allowed or involved AI, while the system design question required a clear definition of what “trending” actually means.

AI-Enabled Coding Round

The AI-enabled coding question asked for the maximum subset of words where selected words do not overlap with each other, while the chosen set captures the most characters.

This is essentially a search / optimization problem. The solution needs to choose compatible words and maximize total coverage or character count. The hard part is not just generating code, but clarifying the constraint around “overlap” and explaining the search strategy clearly.

Coding Question 1: Minimum Round Trip Cost

One coding question gave two arrays:

• Departure prices
• Arrival prices

The task was to find the minimum round trip cost.

The key was to combine one departure and one arrival price under the required ordering or trip constraint, then compute the minimum valid total. This sounded like a practical array / prefix-min style problem where the exact constraint matters a lot.

Coding Question 2: Merge Sorted Intervals

Another coding question gave two arrays of sorted, increasing, non-overlapping intervals.

The task was to merge them.

Since each input list was already sorted and internally non-overlapping, the natural approach was to use two pointers to merge both lists, then apply standard interval coalescing when ranges overlap or touch.

This was straightforward if the implementation stayed clean.

System Design: Trending Hashtags

The system design round asked for a backend system to detect and serve trending hashtags from Facebook posts. The system needed to surface trends while the real-world event was still happening, with around one-minute latency, while considering posts from the last 24 hours.

The important part was defining trend ranking properly. A good system should balance:

• Timeliness
• Popularity
• Novelty
• Historical baseline
• Regional or community relevance

The system should not simply return the most common hashtags. A hashtag that is always popular should not be considered “trending” unless it shows a meaningful spike compared with its normal baseline.

Prepping for Meta's Interviews?

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

Company: Google
Role: Software Engineer
Level: L4 / Mid-Level
Location: Mountain View, CA
Round type: Full Journey
Question type: Multiple types
Duration: Around 4 hours
Interviewer tone: Neutral
Result: Passed

Overall Loop

There were five rounds total:

• Calendar scheduling
• Behavioral
• Car rental simulation
• Topological sort
• Additional AI / ML knowledge round

The technical questions were mostly recognizable patterns, but the candidate still needed to model each scenario clearly.

Round 1: Calendar Scheduling

The first round was similar to the classic meeting room / calendar availability problem, but framed around Google Calendar scheduling.

Given multiple people’s schedules, the task was to find time slots where everyone was free and there were no conflicts.

The core was interval processing:

• Merge or compare busy windows
• Track overlapping intervals
• Find common free slots
• Handle boundary cases carefully

This round seemed straightforward if the candidate was comfortable with interval problems.

Round 2: Behavioral

The second round was a standard behavioral interview. The questions focused on work experience, communication, project examples, and collaboration style. Nothing sounded especially unusual here.

Round 3: Car Rental Simulation

The third round was also somewhat similar to a meeting room-style problem, but the scenario was changed to car rentals.

The candidate had to simulate a car rental process and track usage. One follow-up was around identifying which car was used the most.

The main challenge was modeling events cleanly:

• Rental start
• Rental end
• Car availability
• Usage counts
• Current state of each car

This sounded like an implementation-heavy simulation problem where clean state management mattered more than tricky algorithms.

Round 4: Topological Sort

The fourth round was clearly a topological sort problem.

The pattern was recognizable quickly. The main work was to model dependencies correctly, process nodes in a valid order, and handle edge cases such as cycles or missing dependencies if needed.

This was probably the most standard algorithm round in the loop.

Additional Round: AI / ML Knowledge

The additional round focused on AI and ML fundamentals, especially LLM-related concepts.

Topics included:

• Post-training
• Fine-tuning
• Prompt engineering
• Basic Transformer knowledge

This round was more conceptual than coding-heavy. The questions seemed manageable if the candidate was already familiar with common LLM concepts.

Final Thoughts

This Google L4 loop sounded easier than expected, but still broad.

The coding rounds were not obscure: intervals, simulation, and topological sort were the main themes. The extra AI / ML round made the process longer, but it did not sound overly deep or research-heavy.

The main takeaway is that Google L4 candidates may now see AI/ML knowledge checks even for SWE loops, especially if the role or team is adjacent to AI.

Prepping for Google's Interviews?

We’ve been tracking Google's interview experiences at here and Google's commonly asked coding questions 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: Meta (Meta Superintelligence Lab)
Role: Machine Learning Engineer
Level: Senior-Level
Location: Menlo Park, CA
Round type: Onsite
Question type: Multiple types
Difficulty: Hard
Result: Did not pass

Overall Loop

The onsite covered several different areas:

• Research design
• ML fundamentals
• Coding
• Behavioral

The hardest part was not just knowing ML concepts. It was being able to connect model design, evaluation, recent research ideas, and practical deployment trade-offs under time pressure.

Research Design Round 1: Coding LLM

The first research design round focused on designing a coding LLM. The discussion covered:

• Problem framing
• Data collection
• Model training
• Evaluation
• Iteration strategy
• Measuring whether the model actually improves developer workflows

This round felt less like a standard ML system design question and more like a research/product design discussion. The key was to define what “better at coding” actually means and how to measure improvement beyond benchmark scores.

Research Design Round 2: Chatbot

The second research design round asked the candidate to design a chatbot. This was another open-ended discussion, covering:

• Model behavior
• Instruction following
• Safety
• Evaluation
• User feedback
• Helpfulness vs reliability
• Deployment constraints

The tricky part was balancing usefulness and safety while still giving a concrete evaluation and iteration plan.

ML Fundamentals Round

One round focused on ML basics. Topics included:

• Optimizers
• Scaling laws
• K-means clustering
• Gaussian Mixture Models

Coding Round: Attention

The coding round asked the candidate to implement standard attention. The candidate need to write the attention logic, analyze time and space complexity, and then answer follow-ups about newer attention variants.

The follow-ups included:

• FlashAttention
• Why FlashAttention is faster
• What “flash” refers to in practice
• Linear attention
• How linear attention differs from standard quadratic attention

This round tested both implementation and whether the candidate understood recent attention improvements at a conceptual level.

Behavioral Round

The behavioral round was standard. It covered project experience, collaboration, motivation, ownership, and how the candidate worked through technical challenges with others.

Prepping for Meta's Interviews?

We’ve been tracking Meta's interview experiences at here and Meta's commonly asked coding questions 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.

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: 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

Company: Zoox
Role: Machine Learning Engineer
Level: Senior-Level
Location: San Francisco Bay Area
Round type: Full journey / virtual onsite
Difficulty: Medium
Duration: Around 6 hours

Overall Loop

The virtual onsite covered:

• Coding
• Hiring manager technical chat
• Math / probability / estimation
• Behavioral
• ML fundamentals and NumPy
• ML system design for autonomous driving

The main challenge was breadth. This was not just a LeetCode loop or just an ML theory loop.

Round 1: Coding

The coding round had three problems.

• The first was the classic LeetCode Best Time to Buy and Sell Stock question, with a follow-up about solving it using multi-threading. The discussed approach was to split the input into chunks. For each chunk, compute the best profit inside that chunk, while also tracking the chunk’s minimum and maximum values. Then use those min/max values to compute cross-chunk profits and compare them with the best intra-chunk result.
• The second problem asked to find four numbers from an array satisfying:y = mx + n. One possible approach is to use two nested loops to compute possible m * x values and store them in a hash map. Then use another two nested loops to compute y - n and check whether it appears in the map.
• The third problem was about assigning players to teams while minimizing duplicate nicknames within the same team. Since players can have duplicate nicknames, the idea was to group or sort players by nickname and distribute players with the same nickname across different teams as evenly as possible.

Round 2: Hiring Manager Technical Chat

This round was mostly conversational. The hiring manager asked about project experience and background. It did not feel like a deep technical grilling round, more like checking fit and understanding past work.

Round 3: Math

The math round included several estimation and probability-style questions. Examples included:

• Estimating how many hours of HD video fit on a 1 TB hard drive
• Choosing randomly between a 6-sided die and 8-sided die, then reasoning through conditional probability after rolling a 3
• Calculating the expected value of rolling the same die again
• Estimating the average number of Friday the 13ths in a year
• Reasoning about area coverage using circles of radius r
• Calculating how much a ball’s volume increases when radius increases by 50%

This round seemed to test practical quantitative reasoning more than memorized formulas.

Round 4: Behavioral

The behavioral round was standard. The questions were around past experience, work situations, and how the candidate handled different challenges. Nothing sounded especially unusual here.

Round 5: ML Skills

This round had two parts. The first part covered ML fundamentals and knowledge-check questions.

The second part focused more on implementation, especially NumPy. One problem involved computing the distance from a trajectory to a point, so being comfortable with vectorized array operations would be useful.

Round 6: ML System Design

The ML system design round was closely tied to autonomous driving. The prompt was about using imitation learning to design an ego vehicle’s right-turn behavior.

This was not generic system design. The discussion was more applied and focused on how to think through the ML pipeline, training data, modeling setup, evaluation, and deployment considerations for an autonomous driving behavior.

Prepping for Zoox's Interview?

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

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.

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.

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: Netflix
Role: Software Engineer
Level: Senior-Level
Location: San Francisco Bay Area
Round: Onsite
Question Type: Multiple Types
Difficulty: 8/10

Leveling Discussion

At the beginning, the candidate asked whether they could interview for Staff level. HR pushed back firmly. Their explanation was that an external L6 candidate would be considered L5 at Netflix, and if the candidate later had opportunities to do L6-level work, they should not worry too much about the initial level.

First Round: Versioned KV Store

The first technical round was a versioned key-value store. The interviewer was very nice and seemed experienced in ads-related systems. Since the candidate also had ads experience, the interviewer suggested framing the KV store as an ads data store.

The round was interactive: they discussed and coded at the same time. The candidate talked through common ads data store patterns, trade-offs, and implementation details while building the solution. The candidate felt they coded a bit slowly because of the ongoing discussion, but the round still went well. Two days later, they were moved forward to the virtual onsite.

VO Coding: Topological Sort Variant

The coding round was the closest to a classic interview problem, but it was not plain topological sort. It had a topological-sort structure with an additional DP-like constraint around prerequisites and when each prerequisite could be completed.

The candidate had not seen this exact variant before. They understood the tricky edge case after the interviewer gave a hint, but did not fully fix the bug before time ran out.

System Design: Ad Pacing

The system design round was about ad pacing, not frequency capping. The candidate understood the high-level idea and answered using standard pacing-system logic:

• Budget allocation
• Delivery rate control
• Traffic forecasting
• Real-time adjustment
• Underdelivery handling
• Overdelivery prevention

They felt some areas could have gone deeper, especially the exact rate-limiting or pacing mechanism. But the interviewer did not push too hard and mostly let the candidate drive the discussion.

This round seems very domain-specific. If you only prepare generic system design, you might miss important ads concepts like pacing curves, supply forecasting, campaign budget smoothing, and delivery constraints.

Domain Modeling: Publisher Config Rules

The domain modeling round focused on publisher-side configuration rule management. This was not about demand-side ads logic. It was about managing publisher-specific configuration rules on the supply side.

The candidate’s background was mostly demand-side, so this threw them off at first. They spent a while clarifying the problem.

One area where the answer may not have matched the interviewer’s expectation was inventory modeling. That is a subtle but important ads-domain concept, and it sounds like the interviewer expected a more natural model for publisher inventory and rule application.

Behavioral Rounds

There were also two behavioral rounds. The questions were fairly general, and the candidate tried to connect their experience to the team and role. Nothing sounded too surprising here.

By this point, though, the candidate already felt that the technical and domain rounds had some gaps.

Final Thoughts

This loop felt very different from the Netflix interview experiences the candidate had seen before. For ads-related Netflix roles, it probably is not enough to prepare only general coding and system design.

Prepping for Netflix's Interview?

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

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.

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: Snowflake
Role: Software Engineer
Level: Senior-Level
Location: San Francisco Bay Area
Round: Phone Screen
Question Type: Multiple Types
Result: Did not pass
Difficulty: 8/10

Overall Process

This Snowflake process had multiple phone coding rounds, and every round required writing full classes and test cases. The candidate solved the questions overall, but a few small bugs were only fixed near the end instead of being bug-free on the first try. After an extra coding round, the candidate still ended up getting rejected.

Round 1 — Filter System OOD

The first question was an object-oriented design problem about a dynamic blacklist filter system. The required methods were processFilter(int value), processInput(int value), and emit(int value). processFilter dynamically adds or removes values from the blacklist, while processInput processes an input stream. If a value appears in the input and is not currently filtered, the system should call emit(value)

• Filter System Follow-Up: The follow-up added an updateFlag and changed the APIs to processFilter(boolean updateFlag, int value), processInput(int value), and emit(boolean updateFlag, int value). The flag controls adding or removing a filter. If a filter update causes a previously seen value to become hidden or visible again, the system should emit a status change, such as emit(false, value) when blocked and emit(true, value) when visible again.
• Filter Example: One example involved filter updates like +1, +2, -1, +3, and input values like 1 and 3. The expected output behavior depends on whether a value has already appeared in the input stream and whether the current filter status changes from visible to hidden or hidden to visible.

Round 2 — OOD Tax Calculation

The second question was the known Snowflake tax calculation problem, similar to LeetCode 2303. The task is to compute taxes based on brackets, but the interviewer expected an OOD-style solution with full classes and test cases rather than only a quick function.

Post-Round Feedback: The candidate solved the first two rounds, but had some small bugs that were only fixed in the last few minutes. A few days later, he was asked to do an additional coding round, probably because the signal was not strong enough.

Extra Round Question 1 — Reverse Only Alphanumeric Chunks

The first extra-round question was a variant of reverse words. The requirement was to reverse only continuous chunks made of English letters and digits, while keeping all other characters in the same positions. For example, "Hello! jason!!!" becomes "olleH! nosaj!!!". This one was straightforward and I solved it quickly.

Extra Round Question 2 — Number Transformation Path

The second extra-round question was a math-style transformation problem. Three operations were provided: add(num) -> num + 2, sub(num) -> num - 2, and split(num) -> floor(num / 2). Given positive integers a and b, implement a function that returns any valid path from a to b; the path does not need to be optimal.

• Number Transformation Discussion: The candidate proposed several approaches, including BFS and repeatedly splitting down toward 1 or 0 and then using add operations. The interviewer seemed to want the simplest possible implementation, so I wrote a while-loop solution. There was a small bug, and I fixed it after the interviewer gave a hint.

Final Thoughts

This process felt hard to prepare for because the questions were not all standard LeetCode patterns. Snowflake seems to care about clean class design, test cases, and bug-free execution, so even if the algorithm is not difficult, small implementation issues can hurt the signal.

Prepping for Snowflake's Interview?

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

Company: Snowflake
Role: Backend Engineer
Level: Junior-Level
Location: San Francisco Bay Area
Round: Full Journey
Question Type: Multiple Types
Difficulty: 9/10

Overall Format

The process had two main technical rounds:

• Phone interview: Forest node deletion
• Onsite: Distributed N-ary tree counting

The onsite felt especially hard because it was not a typical algorithm pattern. It required thinking in terms of independent processes, async messages, local state, and distributed coordination.

Phone Interview: Forest Node Deletion

The phone question gave a forest represented by a parent-index array. Each element in the array stores the index of that node’s parent. For root nodes, the parent index equals the node’s own index.

For example, if node i is a root, then:parent[i] = i.The input is always valid, and there are no null or None values. The task was to delete a specified node and return a new parent-index array that still follows the same representation.

Onsite: Distributed N-ary Tree Counting

The onsite question was much more unusual. The interviewer gave an N-ary tree in a distributed system:

• Each node runs as an independent process
• Each node is on a different host
• Each node has a unique ID
• Each node only knows the IDs of its children
• There is no shared memory
• Communication only happens through async message passing

The available communication model was something like:sendAsync(targetId, message)and receiving a message triggers:receive(senderId, message).The goal was to count the total number of nodes in the tree and print the final result at the root.

• Distributed Counting Approach: The root starts the count request. Each node forwards the request to all of its children. Leaf nodes immediately reply with count 1. Internal nodes wait until all children respond. Then they sum the child counts, add 1 for themselves, and send the result back to their parent. The root does the same aggregation, except instead of sending the result upward, it prints the final total.

Discussion

For a junior backend role, does this feel unusually hard, or is this normal for Snowflake?

Prepping for Snowflake's Interview?

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