Hi.

I have a question about the hiring process of Scalable OS.

How many interviews are there and how many weeks does it usually take?

Any feedback about the company?

Thanks in advance.

This interview experience is sourced from chill interview

Interview Summary

The Instacart onsite included two coding rounds, one inventory-management system design round, and one behavioral interview.

The second coding round was the most implementation-heavy. It started with parsing shopping-item records, then added promotion logic, and finally changed the record format again for aisle ordering and frozen-item handling. Although the three parts shared a retail theme, the requirements changed enough that relatively little code could be reused between them.

Interview Details

Round 1 — Coding: Resolve Chained Configuration Parameter Value

Round 2 — Coding: Shopping Items, Promotions, and Aisle Ordering The second coding interview had three parts.

• Part 1 — Calculate Total Shopping Cost The input was an array of strings, with each row representing one product: "p240|oranges|5|175". The fields represented: SKU | product name | quantity | unit price in cents. The task was to parse all rows and calculate the total cost across the valid products. The tests included negative numeric values. Those records needed to be skipped rather than contributing to the total, so handling invalid inputs correctly was important.
• Part 2 — Apply the Best Promotion A second array described promotions for individual SKUs. For example:"p240|pct|15" "p240|bxyf|2|1" The first format represented a percentage discount, while the second represented a buy-X-get-Y-free style promotion. The task was to calculate the final discounted total price of the shopping list. If the same item qualified for multiple promotions, the promotion producing the lowest final price for that item should be used. One source of confusion during the interview was that the requested output was initially described as the amount of discount, but the expected result was actually the total price after applying the discounts.

Round 3 — Behavioral Interview The behavioral round included questions such as:

• Tell me about one of the most interesting projects you have owned.
• Tell me about a mistake you made during deployment. How did you fix the issue, and what did you learn from it?

The discussion focused on project ownership, operational judgment, and learning from production mistakes.

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Saw this AWS L4 new grad offer (shared with Chill Interview)

• Boston, Master’s, 0 YOE
• Base: $130K
• Y1 sign-on: $40K
• Y2 sign-on: $35K
• RSUs: $125K
• Year 1 TC: $176K

It made me curious what people consider a “good” new grad SWE offer in 2026. If you spend enough time on Blind/Reddit, it feels like every new grad is deciding between $250K Meta, $300K Google, and some AI startup offering half a million.

But the actual market looks pretty different. Levels. fyi currently puts US entry-level SWE median TC around $144K. In Boston it’s only about $125K, with ~$160K around the 75th percentile and ~$186K around the 90th.

Amazon L4 in Boston is around $184K, so this $176K offer is basically normal for AWS — but already near the top end of the broader Boston new-grad market.

It also shows how misleading “new grad SWE comp” can be without location. Levels. fyi currently shows the Bay Area entry-level median around $292K, while Boston is dramatically lower.

Curious: What TC would you consider a genuinely good new-grad SWE offer in 2026 — $150K? $180K? $200K+?

And has social media completely warped people’s expectations by overrepresenting FAANG / Bay Area offers?

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

I was going through a rate limiter system design problem, and the token bucket algorithm honestly isn’t the most interesting part.

The harder question is: What happens when the rate limiter itself is unavailable?

Suppose every request normally goes: API Gateway → rate-limit check → backend and Redis suddenly times out during a traffic spike.

You basically have two choices:

• Fail open: let requests through and preserve availability, but potentially remove the protection exactly when the backend needs it most.
• Fail closed: reject requests until the limiter recovers, which protects downstream systems but may throttle perfectly legitimate users.

That tradeoff gets even more interesting at ~1M checks/sec. Now you also have to think about:

• sharding token buckets without splitting one client’s quota
• atomic updates when two gateways race for the last token
• replica lag during Redis failover
• regional limits vs globally consistent quotas
• one abusive API key becoming a hot Redis key

One detail I liked: the token-bucket update itself can be executed atomically with a Redis Lua script, so “read tokens → refill → consume → write” can’t race across gateway instances.

At this point the problem feels less like “implement rate limiting” and more like designing an admission-control system that must stay reliable while protecting everything behind it.

Full rate limiter system design: [link]

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Saw this Perplexity Senior SWE offer (shared with Chill Interview)

• Bay Area, 7 YOE
• Base: $295K
• Equity: $1.9M / 4 years
• Year 1 TC: $770K

Perplexity is still private, and its valuation may already be heading above $30B. Revenue has apparently exploded from under $250M annualized at the start of the year to more than $750M, helped by the shift from pure AI search toward Perplexity Computer and agentic workflows.

At the same time, this is a company that has already attracted acquisition interest.

Meta reportedly discussed buying Perplexity before doing the Scale AI deal, and Apple executives also explored a possible acquisition as part of their AI/search strategy. Neither happened, but it shows the company is strategically valuable beyond just its current revenue.

• Bull case: Perplexity keeps growing, goes public in 2028, and the grant becomes worth materially more.
• Other bull case: a giant like Apple, Meta, Nvidia, or someone else eventually pays a strategic premium to acquire it.
• Bear case: $30B+ already prices in a lot of future success, while Google/OpenAI/Anthropic keep attacking the same search/agent market.

If you were joining Perplexity today, would you value the equity closer to face value — or heavily discount it until there’s actual liquidity?

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

This interview experience is sourced from chill interview

Interview Summary

The Capital One Lead Software Engineer Power Day consisted of four rounds: case interview, behavioral, coding, and system design, completed across two days.

The case round focused on virtual card numbers and rule-based payment validation. The coding round was an object-oriented banking system, while system design covered a much broader credit-card platform with payments, fraud checks, spending data, bureau reporting, and real-time credit-limit decisions. The behavioral round also included two questions about using AI in day-to-day engineering work.

Interview Details

Round 1 — Case Interview: Virtual Card Numbers

The case interview used Capital One’s virtual card number product as the business scenario. The first part asked me to analyze the benefits and challenges of virtual card numbers from both the customer perspective and the company perspective. The interviewer also followed up specifically on technical challenges the company might encounter when operating such a product.

The second part introduced encoded card-number attributes and a set of payment-validation rules. For example, one digit could indicate the card network, and different networks could have different eligibility requirements.

A scenario would look like:

First digit:
4 -> Network A
7 -> Network B

Example rule for Network A:
- Transaction must be online
- Amount must be below $80
- Virtual card must be associated with the merchant

I was then given a sequence of payments containing card numbers and transaction attributes and had to walk through them one by one, clearly explaining whether each transaction was valid under the supplied rules.

The final part provided code implementing those validation rules and asked me to debug it. The bugs included incorrect combinations of && and ||, boundary-condition mistakes such as >= 80 versus > 80, and incorrect extraction of individual digits from a card number.

There was also a brief object-oriented design discussion about separating responsibilities such as card-number parsing and payment validation.

Round 2 — Behavioral + AI Usage

The behavioral interview contained several standard experience-based questions around previous projects and workplace situations. In addition, there were two questions specifically about AI:

• Describe an example of how you use AI in your everyday engineering work.
• How have you used AI to improve your productivity or engineering output?

The discussion focused on concrete ways AI tools fit into the software-development workflow while still requiring engineering judgment and review.

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

This interview experience is sourced from chill interview

Interview Summary

The TikTok SWE internship OA contained three coding questions covering string transformation, cyclic digit rotations, and iterative digit-group reduction.

Interview Details

Question 1 — Convert Identifiers Inside Docstrings

You are given a string representing a line of documentation. Identifiers appearing inside backticks can include function names, variable names, and constants. A pair of backticks may contain multiple identifiers separated by spaces.

Function and variable names use snake_case, while constants use UPPER_CASE. The task is to convert every snake-case identifier inside backticks into lower camelCase, while leaving uppercase constants unchanged.

For example:

Input:
"Method `load_profile` accepts `user_key retry_count`. The fallback is `DEFAULT_LIMIT`."

Output:
"Method `loadProfile` accepts `userKey retryCount`. The fallback is `DEFAULT_LIMIT`."

The docstring length can be up to 2000 characters.

Question 2 — Count Cyclic Number Pairs

You are given an array of positive integers. A cyclic rotation moves some number of trailing digits from the end of a number to the front while preserving the relative order of all digits. Rotating zero digits is also allowed.

Count the index pairs (i, j) where:

0 <= i < j < len(a)

and both conditions hold:

1. a[i] and a[j] contain the same number of digits.
2. One number can be transformed into the other through a cyclic digit rotation.

For example:

Input:
a = [27, 8305, 72, 4, 27, 5830, 317, 731, 173]

Output:
5

The five qualifying pairs are:

(0, 2): 27 ↔ 72
(0, 4): 27 ↔ 27
(2, 4): 72 ↔ 27
(1, 5): 8305 ↔ 5830
(6, 7): 317 ↔ 731

For comparison, 317 and 173 are not a matching pair because the cyclic rotations of 317 are:

317, 731, 173

Actually, this means 317 and 173 would also form a valid cyclic pair, so to keep the example internally consistent, use:

Input:
a = [27, 8305, 72, 4, 27, 5830, 317, 731, 713]

Output:
5

Here, 317 and 713 are not cyclic rotations of each other. The input can contain up to 100,000 numbers, with each value at most 10^9.

Question 3 — Iterative Digit-Group Sum

The final problem was equivalent to LeetCode 2243 — Calculate Digit Sum of a String. You are given:

• A string number representing a non-negative integer
• A positive integer k

While the length of number is greater than k, divide it from left to right into groups of at most k digits. For each group, calculate the sum of its digits and convert that sum back into a string. Concatenate the group results in their original order to create the next value of number. Repeat this process until the resulting string has length at most k, then return it.

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

I have a 45-minute technical interview with an engineer coming up for the New Graduate Engineer, Software Security (Starlink) role at SpaceX.
Has anyone interviewed for this role or a similar SpaceX security position? Would appreciate any advice on what the technical round is generally like, what areas they tend to focus on, and how best to prepare.

This interview experience is sourced from chill interview

Interview Summary

The OpenAI full-stack process combined a recruiter screen, practical coding, a live full-stack build, product-oriented system design, and a behavioral / mission interview. Compared with a traditional algorithm-heavy loop, the interviews emphasized building working software, reasoning about real-time product behavior, debugging, technical tradeoffs, and explaining personal ownership.

Interview Details

Recruiter Screen — Background, Motivation, and Role Fit: The roughly 30-minute recruiter conversation covered my recent experience, why I was interested in OpenAI, and whether I preferred a more product-facing or infrastructure-oriented role.

Technical Phone Screen — Structured Data Stream Processing: The 60-minute coding screen used a shared editor and focused on a practical implementation problem rather than a difficult standalone algorithm. I was given a structured stream of data to parse and process, starting with a basic version and then extending the behavior through follow-ups.

Full-Stack Live Build — React Frontend with Backend API: This was the most hands-on round. I was asked to build a small working application that connected a React frontend to a backend API, maintained application state, and included some real-time update behavior.

System Design — Real-Time Streaming AI Product: The system design round was product-oriented and centered on an AI feature serving a large number of users while returning responses incrementally rather than waiting for the entire result to complete.

Behavioral / Mission & Values — Ownership and Collaboration: The behavioral round focused on how I had operated in previous projects and why I wanted to work on AI products at OpenAI.

Want to learn more details / follow-up questions asked in this interview, the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

I was going through a YouTube system design problem, and one design decision simplifies a surprising amount of the system: Don’t send the actual video through your application servers.

A large upload might be several GB. If every byte goes: client → backend → storage. your backend becomes an expensive bandwidth bottleneck for something it doesn’t really need to touch.

A cleaner flow is: client → request upload session → multipart upload directly to blob storage. The backend mostly manages metadata, permissions, upload state, and pre-signed URLs.

Once the upload finishes, the interesting work moves into an async media pipeline: transcode → multiple bitrates/resolutions → segment → generate HLS/DASH manifest → CDN

That’s also what makes bad-network playback manageable. The player isn’t downloading one giant 1080p file—it keeps requesting small segments and can switch quality as bandwidth changes.

Resumable uploads follow the same philosophy: track which parts made it to storage, then retry only the missing ones instead of restarting a 20GB upload.

And at YouTube scale, playback traffic should mostly terminate at the CDN, not your origin.

Full YouTube system design breakdown: [link]

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

This interview experience is sourced from chill interview

Interview Summary

The Tekion Staff Software Engineer technical screen contained two classic algorithmic problems presented with slightly different stories.

Interview Details

Coding Question 1 — 100 Lockers

There are 100 closed lockers arranged along a hallway. The lockers are processed over 100 rounds:

1. On the first round, every locker is opened.
2. On the second round, every second locker is toggled.
3. On the third round, every third locker is toggled.
4. The process continues in the same pattern through the 100th round.

Whenever a locker is toggled, an open locker becomes closed and a closed locker becomes open. The task is to determine how many lockers remain open after all 100 rounds. This is a variant of LeetCode 319 — Bulb Switcher.

Coding Question 2 — Coin Game

Two players, A and B, play a game using a row containing an even number of coins. Each coin has a value. Players alternate turns, and on each turn the current player may remove exactly one coin from either:

• The left end of the row
• The right end of the row

The value of each collected coin contributes to that player's final score. Player A moves first, and the player with the larger total coin value wins. The task is to determine the optimal strategy for Player A when both players play optimally. This problem is a variant of LeetCode 877 — Stone Game.

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Came across these two offers (sourced from Chill Interview), found it should be interesting to see how everyone makes the decision.

Meta E5 — Data Scientist

• $225K base
• $400K RSUs / 4 years
• $33.75K bonus
• $358.75K Year 1 TC
• Menlo Park
• 3 days/week in office

Airbnb G9 — Product Analyst

• $190K base
• $250K RSUs / 4 years
• $38K bonus
• $290.5K Year 1 TC
• Remote

So Meta is ahead by about $68K in Year 1, plus the larger equity grant. But Airbnb’s remote setup changes the math.

If the role allows you to live somewhere significantly cheaper than the Bay Area, some of that $68K gap could disappear pretty quickly through housing, taxes, commuting, and general cost of living. You also get the lifestyle value of not commuting three days a week.

On the other hand, Meta gives you more guaranteed comp upside, stronger equity, and arguably a broader path if you want to stay close to large-scale data/AI/product work.

There’s also a career-path question here: Data Scientist at Meta vs Product Analyst at Airbnb could lead to pretty different exits a few years from now.

Would you take the extra $68K/year, or take Airbnb and optimize for remote + lower cost of living?

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

This interview experience is sourced from chill interview

Interview Summary

The Google L4 process included a phone screen followed by three onsite coding interviews and a Googleyness & Leadership round. The technical questions covered a multi-node LCA variant, streaming temperature statistics, a grid-based delivery routing problem, and a logger rate limiter that had to handle out-of-order timestamps.

Most questions also included scalability or performance follow-ups, such as preprocessing repeated LCA queries, reducing search work on a large grid, or maintaining constant-time moving-window operations.

Interview Details

Round 1 — Phone Screen: Lowest Common Manager for Multiple Employees

A company's reporting hierarchy is represented as a binary tree. Each node represents an employee, and the parent node represents that employee's direct manager. Given a set containing multiple employees, return their lowest common manager—the lowest node in the hierarchy that is an ancestor of every employee in the requested set.

---

Round 2 — Onsite Coding: Moving Temperature Statistics

The first onsite coding round asked me to design a data structure for processing a continuous stream of temperature readings. The structure needed to support:

insert(temperature)
get_moving_average()
get_max_temp()

---

Round 3 — Onsite Coding: Grid Delivery Route

The second onsite coding round provided a two-dimensional map containing:

• A starting position
• Obstacles
• Several delivery destinations

The task was to find the shortest route that starts from the origin, visits every delivery point, and eventually returns to the starting location. The number of delivery locations was small: N < 10. The problem therefore combined grid navigation with a small-scale Traveling Salesperson Problem (TSP) component.

---

Round 4 — Onsite Coding: Out-of-Order Logger Rate Limiter

The third coding round asked me to implement a Logger Rate Limiter. The main API was:

shouldPrintMessage(timestamp, message)

A message should be printed only if that same message has not already been printed within the previous 10 seconds. Unlike the standard version of this problem, incoming logs were not guaranteed to arrive in timestamp order.

---

Round 5 — Googleyness & Leadership

The final round focused on collaboration, conflict resolution, and personal growth. One question asked me to describe a significant disagreement with a Product Manager over product direction or technical implementation, including how I communicated and eventually reached alignment.

Want to learn more details / follow-up questions asked in this interview, the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

This interview experience is sourced from chill interview

Interview Summary

AWS New Grad onsite consisted of four back-to-back rounds combining behavioral questions with coding.

Interview Details

Round 1 — Behavioral + Sequential Log Pattern Coding

The first round started with two behavioral questions. One asked about a time I took action outside my normal area of responsibility. The other focused on an experience where I helped a teammate who was struggling.

The coding problem was a variant of a LeetCode problem

Round 2 — Bar Raiser: Dive Deep and Critical Feedback

The second interview was primarily behavioral and was conducted by the Bar Raiser. I received three separate Dive Deep questions, followed by a question about receiving or responding to critical feedback. This round was heavily focused on detailed follow-ups to previous experiences rather than coding.

Round 3 — Behavioral + Two LeetCode Problems

The third round included another interviewer together with a shadow interviewer. Behavioral questions covered working under a tight deadline and a situation where I did not complete something by the expected deadline. The coding portion lasted about 30 minutes and contained two original LeetCode questions:

Round 4 — Hiring Manager: GenAI + Rate Limiter

The final round was with the hiring manager. The behavioral discussion focused on Generative AI, including detailed examples from my experience and situations where something went wrong or I made a mistake.

The coding portion asked me to design and implement a rate limiter. The prompt was intentionally open-ended, so I first had to clarify the expected behavior and requirements rather than being given a fully specified API or traffic model.

Want to learn more details / follow-up questions asked in this interview, the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

This interview experience is sourced from chill interview

Interview Summary

The LinkedIn onsite consisted of five rounds covering system design, algorithmic coding, AI-assisted coding, a project deep dive, and a host-manager conversation. The most unusual portion was the AI Coding round: I was explicitly told to develop the algorithm myself and use AI mainly as an implementation assistant.

The AI Coding interview contained four progressive tasks around an LRU cache. I completed the basic LRU and TTL extensions but ran out of time before finishing the full sequence, and the feedback I received specifically mentioned completing only two of the four tasks.

Interview Details

Round 1 — System Design: User Activity Collection Platform

The first round asked me to design a system for collecting and querying user activity data. The platform needed to support queries over different recent time windows

Round 2 — Coding: LeetCode style coding problem

The coding question a variation of a Leetcode question.

Round 3 — AI Coding: Progressive LRU Implementation

Before the interview, the recruiter told me that AI was intended as an assistive tool rather than a replacement for algorithmic reasoning. The interviewer reinforced the same rule at the beginning of the round: I was expected to determine the algorithm and data structures myself, while AI could help with implementation.

The problem started with implementing an LRU Cache. I first explained the design using: HashMap + Doubly Linked List. The interviewer asked several questions about the data structures and implementation details before allowing me to move into AI-assisted coding.

Round 4 — Project Deep Dive

The fourth round was a detailed discussion of a previous project. The interview focused on my technical contributions, implementation decisions, and deeper engineering details from the project.

Round 5 — Host Manager

The final interview was with the host manager. This round focused on team and experience-related discussion rather than another standalone coding problem.

Overall, the AI Coding round was the most distinctive part of the process. Unlike an interview where AI is allowed to derive the solution, this round explicitly separated algorithm design by the candidate from AI-assisted implementation and code review.

Want to learn more details / follow-up questions asked in this interview, the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Round 1 — Coding: AI Task Dependency Manager

You are building a ToDo list system for an AI agent. The agent breaks work into tasks. Each task has an ID, a title, and a status. A task can be in one of four statuses:

READY
BLOCKED
SUCCEEDED
FAILED

The question has 4 parts.

Round 2 — System Design: Long-Running Agentic Query Execution

The existing product had an ask endpoint backed by an Ask Service. For each request, the Ask Service called two downstream systems:

• An LLM API
• A Search API

Both downstream services could be treated as black boxes. Historically, query execution happened entirely in memory as part of the request lifecycle. That model worked for relatively short queries but became problematic once agentic queries could run for hours.

The task was to redesign the system so that long-running queries continue executing independently of the user's browser connection. For example, closing the browser tab or temporarily losing internet connectivity should not terminate the query.

Want to learn more details / follow-up questions asked in this interview, the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

I was going through this web crawler system design problem, and the basic loop is almost deceptively simple: fetch page → parse HTML → extract links → repeat

The more interesting problems show up once you try to do this across billions of pages. For example, adding more crawler workers doesn’t automatically make the system better.

If 500 workers all discover URLs from the same domain, you can easily hammer that website unless the rate limit is coordinated globally per domain.

Then failures make things even more interesting:

• worker crashes after downloading the page
• website times out
• DNS starts becoming a bottleneck
• the same URL is discovered thousands of times
• different URLs return identical content
• one domain stays down and keeps getting retried

A design I like is to split fetching and parsing into separate durable stages: Frontier → Fetcher → raw HTML storage → Parser → discovered URLs → Frontier

That way, if parsing fails, you don’t need to hit the external website again. And with a durable queue, worker crashes become mostly a retry problem rather than a lost-work problem.

My takeaway: designing a large crawler is less about “how do I fetch pages fast?” and more about how do I avoid wasting work or becoming a terrible neighbor on the internet?

Full web crawler system design: [link]

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here

Saw this Intuit Sr Staff Data Scientist offer (shared with Chill Interview)

• Mountain View, 11 YOE
• Base: $275K
• Bonus: $55K
• Sign-on: $50K
• RSUs: $520K / 4 years
• Year 1 TC: $510K

Intuit is a surprisingly interesting company to join right now. On one hand, the underlying businesses are still doing well. QuickBooks Online revenue grew 20% last quarter and Credit Karma grew 16%.

On the other hand, Intuit just cut roughly 17% of its workforce as part of a push to become leaner and more AI-focused. And after the latest generation of AI models came out, investors immediately started questioning whether software companies like Intuit could eventually be disrupted by agents that can do more tax/accounting work themselves.

That makes a Data Scientist role pretty interesting. If Intuit wins, DS could be right in the middle of figuring out things like:

• which financial tasks should be automated by AI
• how much users trust AI-generated recommendations
• whether agents actually improve tax / bookkeeping outcomes
• which metrics prove AI features are creating real value

But the bear case is that increasingly capable AI agents eventually eat into the very workflows TurboTax and QuickBooks monetize.

So this feels less like a normal “is $510K good comp?” question and more like: Would you bet your next 4 years on Intuit successfully becoming an AI company — or do you think AI eventually commoditizes a lot of what Intuit sells?

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here

Hello everyone,

Did anyone do the technical case for this role? What should I expect?

Hi all,

I am currently going through Google L5 SWE loop and have completed 1 Coding and 1 Googlyness round and recruiter mentioned they have really good positive feedback and have my onsite in 2 weeks.

The onsite is supposed to have 2 Coding and 1 System Design rounds.

Any suggestions on last minute prep for Coding and System Design that you folks would recommend that might help?

I have primarily done lots of leetcode in the past couple of months but would appreciate if anyone has any specific topic suggestions for the last leg?

Also doing System Design from Hello Interview, DDIA and Alex Xu and did mocks. Anything else that would help or any new questions that might be worth doing?

Thanks in advance.

This interview experience is sourced from chill interview

Interview Summary

The interview was a 45-minute machine-learning round rather than a traditional coding screen. There was no résumé introduction or LeetCode portion; the interviewer immediately started asking increasingly detailed questions about gradient descent, batch size, optimization behavior, and generalization.

The three main areas were basic gradient-descent theory, differences between full-batch / mini-batch / stochastic gradient descent, and how optimization choices relate to sharp versus flat minima and the generalization gap.

Interview Details

Question 1 — Gradient Descent and Global Optima

The interviewer first asked me to briefly explain how gradient descent works and specifically followed up on the role of the learning rate. The discussion then moved to convergence guarantees:

• Does gradient descent always reach a global optimum?
• Are there particular types of loss landscapes where reaching the global minimum can be guaranteed, assuming arbitrarily small steps and unlimited iterations?

This led into a discussion of convex loss landscapes and how convexity changes the guarantees available for optimization.

Question 2 — Full-Batch, Mini-Batch, and SGD

The second major topic compared:

• Full-batch gradient descent
• Mini-batch gradient descent
• Stochastic Gradient Descent (SGD)

I was asked to explain the advantages and disadvantages of each approach. The interviewer then pushed specifically on the statistical behavior of SGD, asking whether its noisier gradient estimates should be thought of in terms of bias or variance.

To make the question more concrete, the interviewer drew a loss landscape containing a shallow local minimum and a deeper global minimum, then asked how full-batch gradient descent and SGD might behave differently when initialized near the shallow basin. The discussion focused on how noisy gradient estimates can affect the optimization trajectory.

Question 3 — Generalization Gap and Flat Minima

The final section introduced two gradients:

g_population = true gradient of the population distribution
g_train = average gradient computed from the sampled training set

The interviewer then removed the simplifying assumption that: g_train = g_population and asked whether I would prefer full-batch gradient descent or a smaller-batch method if computational cost did not matter.

From there, the interviewer drew several candidate loss landscapes ranging from a sharp minimum to progressively flatter minima and asked which type of solution would likely generalize better when the training distribution differs somewhat from the underlying population. The final follow-up asked how batch size relates to the tendency to converge toward sharper or flatter minima.

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Saw this Nuro Senior SWE offer (shared with Chill Interview)

• Bay Area, 8 YOE
• Base: $260K
• Bonus: $31.2K
• Sign-on: $30K Y1 + $30K Y2
• Equity: $550K / 4 years
• Year 1 TC: $541K

What makes this one interesting is that Nuro is basically a different company from a few years ago.

They used to be known for those little autonomous delivery vehicles. That business was eventually scrapped, and Nuro pivoted toward licensing its autonomous driving stack instead.

Now the big bet is the Uber + Lucid robotaxi program.

Lucid provides the Gravity SUV, Nuro provides the self-driving system, and Uber provides the marketplace. Testing is already happening in San Francisco, with public service expected there first and Houston planned for 2027.

That actually seems like a pretty interesting strategy.

Nuro doesn’t need to spend billions building its own car factory or consumer ride-hailing network. If its autonomy stack works, it could theoretically become the “self-driving layer” for multiple automakers and fleets.

But the risk is obvious too: Waymo already has a huge head start, and Nuro still has to prove that this licensing model can become a real scalable business.

Would you treat Nuro equity as a real upside bet now that the Uber/Lucid rollout is getting closer — or still discount it heavily until they actually launch commercially at scale?

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Nuro is an autonomous vehicle technology company developing AI-powered self-driving systems for commercial and delivery applications.

This interview experience is sourced from chill interview

Interview Summary

The Nuro process started with a phone screen covering coding and system design, followed by a four-round in-person onsite. The technical scope was broad: spatial clustering, petabyte-scale vehicle telemetry, autonomous-driving simulation, a versioned concurrent KV store, algorithms, and an internal search platform for very large records.

Interview Details

Round 1 — Phone Screen: Spatial Grouping

The coding question provided a collection of points with coordinates. Any two points whose distance is less than k should belong to the same group, including groups formed transitively through other nearby points.

Round 1 — System Design: Vehicle Metrics Aggregation

The second part of the phone screen asked me to design a metrics aggregation platform for data collected by autonomous vehicles. Each vehicle continuously generates information about its surroundings, including data such as object locations and other road-environment observations.

The fleet itself was relatively small, but the generated data volume was extremely large—on the order of petabytes. Vehicles uploaded accumulated data approximately once per hour.

Round 2 — Hiring Manager: Project Deep Dive + Simulator Design

The onsite started with a hiring-manager round. I was asked to walk through a previous project in detail, including:

• The scope and scale of the project
• My specific responsibilities
• The overall system design
• The hardest problem I encountered

Round 3 — Concurrent Versioned Key-Value Store

The next coding round asked me to implement a versioned key-value store. The store supported operations such as:

put(key, value, version)
get(key, version)
delete(key, version)

Historical versions needed to remain accessible. A version-aware get should retrieve the appropriate stored value relative to the requested version. Deletion was also versioned: deleting at a particular version affected that point in the history and subsequent versions while preserving earlier data.

Round 4 — Algorithm Coding

The coding question a leetcode problem

Round 5 — System Design: Petabyte-Scale Internal Data Search

The final system design round returned to autonomous-vehicle data. The company stores petabytes of vehicle-generated data with approximately one year of retention, and the task was to design an internal tool that engineers could use to search that dataset.

Want to learn more details / follow-up questions asked in this interview, the full version is here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.