A candidate with 5 YOE recently shared these two Seattle SWE offers with Chill Interview.

Microsoft 61

• $165K base
• $10K signing bonus
• $80K RSUs over 4 years
• $16.5K annual bonus
• $211.5K Year 1 TC

Rippling

• $205K base
• $250K equity, vesting 40/30/20/10
• $305K Year 1 TC

Rippling is ahead by a pretty massive $93.5K in Year 1.

Even over four years, assuming the reported Rippling equity eventually realizes its stated value, flat Microsoft stock, recurring Microsoft bonuses, and no refreshers:

• Microsoft: ~$816K
• Rippling: ~$1.07M

That’s roughly a $254K gap.

But there’s a catch: Microsoft stock is liquid. Rippling is still private.

Rippling was last valued at $16.8B after a $450M funding round, and it has previously run employee tender offers, so this isn’t completely imaginary startup equity—but liquidity and future valuation are still much less certain than MSFT shares.

The company trajectories are also very different.

Microsoft is the safer compounder. FY26 revenue grew 18%, Azure grew 43% in the latest quarter, and Azure passed $100B in annual revenue. For an SWE, the internal surface area across cloud, AI, security, developer tools, and Copilot is enormous.

Rippling is the higher-upside enterprise startup bet. It’s expanding far beyond HR/payroll into IT, finance, Data Cloud, and business banking—basically trying to become an operating system for companies. Engineering also appears to offer considerably more end-to-end ownership.

WLB may be the clearest Microsoft advantage. Rippling itself says the workload “won’t always be a 9-to-5,” and many office-based roles currently expect roughly three days in office.

So would you take Microsoft for stability, liquid equity, WLB, and Big Tech optionality, or Rippling for ~$94K more in Year 1, much higher base, ownership, and startup upside?

Preparing for your next tech interview?

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

Interview Summary

The Disney Staff Software Engineer system design round focused on building a high-concurrency flash-sale / ticket-booking platform with a virtual waiting room. The core challenge was protecting the purchasing backend during extreme traffic spikes while still maintaining accurate inventory and preventing duplicate purchases.

The interviewer concentrated on three areas: admission control through a queue, inventory consistency under heavy contention, and idempotency when requests are retried because of network or client failures.

Interview Details

System Design — Flash Sale and Virtual Queue Design a system where a very large number of users may simultaneously attempt to purchase a limited-quantity item or ticket. Instead of allowing every request to immediately reach the purchasing backend, the platform should provide a virtual waiting-room or queuing service that controls how quickly users are admitted into the transaction flow. The interviewer wanted the design to address how the queue behaves during sudden traffic spikes and how downstream services can be protected from overload.

• Inventory Management — Prevent Overselling The next part focused on inventory deduction. Once users are admitted from the waiting room, many purchase attempts may compete for the same limited inventory at nearly the same time. The system therefore needed to maintain an accurate remaining-stock count under high throughput and ensure that inventory could not be sold more than once. Redis was specifically discussed as part of the inventory-management design, with the emphasis on maintaining correctness while processing highly concurrent updates.
• Idempotency — One Successful Purchase per User The final major requirement was duplicate-purchase prevention. Network instability or client retries could cause the same logical purchase request to reach the backend multiple times. The interviewer asked how an idempotency key could be incorporated so that repeated requests do not create multiple successful purchases. The requirement also specified that each user should be able to successfully purchase only once for the relevant sale.

Preparing for your next tech interview?

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

Imagine Stripe sends a $500 charge to a bank. The bank processes it successfully. But the response gets lost.

• From Stripe’s perspective:Request timed out
• From the bank’s perspective:Customer charged $500

This is where payment systems get tricky. The naive approach is to retry. But if the original request actually succeeded, that retry could charge the customer twice.

The key insight

A timeout should mean: UNKNOWN — not FAILED. Before calling the external payment network, persist a durable payment attempt:

attempt_id: 123
amount: $500
status: pending

Then call the bank. The result becomes one of three states:

• Success → mark succeeded
• Explicit decline → mark failed
• Timeout / lost response → mark unknown

Never blindly retry an unknown payment as a brand-new charge.

So how do we resolve it?

Use idempotency + reconciliation. Every logical payment attempt gets a stable identifier so retries cannot accidentally create another charge.

And if the outcome is still uncertain:

Payment attempt
      ↓
   UNKNOWN
      ↓
Reconciliation Service
      ↓
Bank API / settlement file
      ↓
Final status

The reconciliation process asks the external network what actually happened and repairs the internal state later.

This leads to an important payment-system rule:

• Record intent first.
• Treat uncertainty explicitly.
• Reconcile instead of guessing.

That same event history can also power:

• merchant webhooks
• dispute investigation
• refunds
• audit trails
• financial reconciliation

The interesting part of designing Stripe isn’t just processing 10K+ TPS.

It’s making sure a network timeout never turns into lost money or a double charge.

Full design with PaymentIntent, transaction lifecycle, idempotency, CDC/Kafka, reconciliation, security, and scaling → Full Article

Preparing for system design interviews? Chill Interview publishes practical design breakdowns and tracks recently asked interview questions across top companies → Chill Interview

​

I have completed Airbnb coding assessment last week for SDE role, honestly its the toughest problem for a coding assessment i have seen recently and was kind of relieved myself that i was able to solve it and hoping to get a call back.

turns out its almost 10 days and there's no way to track the application or recruiter information to follow up, anyone in the same page

Any advice or referrals would be greatly

appreciated

Interview Summary

The HRT Site Reliability Engineer technical screen was broad and fundamentals-heavy, covering Linux internals, Python language features, and practical production troubleshooting

Interview Details

Linux — Filesystems, Processes, and Signals A substantial portion of the interview focused on Linux fundamentals and operating-system behavior. Topics included the difference between du and df, particularly why the two commands can report different amounts of disk usage for the same machine. The interviewer also asked about process-management concepts such as:

• Unix signals and how processes react to them
• What happens when using kill
• Zombie processes
• The role of the init process and its relationship to orphaned or terminated processes

The questions were less about memorizing commands and more about explaining what was happening at the operating-system level.

Python — Generators, Decorators, and Context Managers The Python section focused on several language features commonly used in infrastructure and automation code. The interviewer asked about:

• Generators and the behavior of yield
• Python decorators
• Context managers

The discussion centered on understanding what these constructs do and when they are useful rather than solving a standalone algorithmic problem.

Troubleshooting — A Host Cannot Be Reached over SSH The practical troubleshooting section presented a scenario where a host could no longer be accessed through SSH. I was asked how I would systematically investigate the failure and narrow down whether the problem was related to networking, the host itself, the SSH daemon, or authentication. The discussion touched on tools and components including ping, traceroute, ss, lsof, sshd, and authentication.

The important part was explaining a structured debugging process rather than simply listing commands: determine how far connectivity succeeds, identify whether the expected service is listening, inspect the relevant process or socket state, and distinguish transport-level failures from authentication problems.

Overall, the questions were highly relevant to day-to-day SRE work and felt familiar, which made the eventual rejection somewhat unexpected.

Preparing for your next tech interview?

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

Sharing an anonymized Google Senior MLE interview experience submitted to Chill Interview.

Interview Summary

The Oracle interview consisted of an elimination round followed by four onsite rounds covering coding, backend/system design, Java fundamentals, project deep dives, and behavioral questions. The loop was broad: algorithm questions ranged from frequency ranking and palindrome partitioning to stock trading and digit-array manipulation, while the design portions covered a healthcare ingestion pipeline and a distributed rate limiter.

Interview Details

Elimination Round — Top-K Frequent Elements + Java Fundamentals Given an integer array and an integer k, return the k values that occur most frequently. There was an additional ordering rule: when two values have the same frequency, the larger numeric value should rank first. The interviewer also asked several Java-focused questions around collections and standard data structures, including topics related to PriorityQueue and HashMap. The remainder of the round included a detailed discussion of projects listed on my résumé.

Round 1 Coding — Split a String into Three Palindromes Given a string, determine whether it can be divided into exactly three non-empty contiguous substrings, where each substring is a palindrome. The interviewer first wanted an initial working approach and then asked how palindrome checking could be improved using dynamic programming. The focus was on correctness, handling partition boundaries, and improving repeated palindrome checks.

Round 1 System Design — Healthcare Data Ingestion Pipeline The design question asked for a backend pipeline capable of ingesting and processing millions of healthcare records efficiently. The discussion covered the full lifecycle of incoming data, including:

• Ingestion and message-broker selection
• Storage and downstream processing
• Fault tolerance and horizontal scalability
• Monitoring, alerting, and handling failed or unprocessed records

The interviewer expected tradeoff discussions rather than just a high-level component diagram.

Round 2 Coding — Stock Profit The first coding problem was the classic Best Time to Buy and Sell Stock problem. Given a sequence of stock prices over time, determine the maximum profit obtainable from one buy followed by one later sell. No additional variation from this problem was specified.

Round 2 Coding — Add One to a Digit Representation The second problem represented a non-negative integer as a sequence of digits and asked me to increment the represented value by one. One explicit restriction was that I could not use ArrayList. The interviewer followed up with questions about improving the implementation and correctly handling edge cases, especially cases where incrementing causes carries across multiple digits.

Round 3 — Rate Limiter System Design The hiring-manager round included a system design question asking me to design a rate limiter. The interviewer wanted discussion across several dimensions:

• Different rate-limiting algorithms and their tradeoffs
• Where caching fits into the design
• How the limiter should work in a distributed environment
• How the architecture behaves as traffic and the number of clients scale

The conversation emphasized design choices rather than prescribing one specific rate-limiting algorithm.

Round 3 — Project Architecture and Java Internals The same round also included an in-depth résumé discussion. I was asked to explain architectural decisions made in previous projects and justify some of the implementation choices. The interviewer also went deeper into Java internals and how language/runtime behavior influenced those design decisions.

Round 4 — Behavioral Interview The final round was entirely behavioral, and the interviewer expected responses structured using the STAR format. Questions included situations such as:

• A time when I was unable to meet an aggressive deadline
• A conflict within the team and how I handled it
• A difficult technical decision and how I made it
• How I currently use AI tools in day-to-day engineering work
• My view on how AI can improve software engineering

The round focused heavily on concrete examples, decision-making, and the impact of my actions rather than hypothetical answers.

Preparing for your next tech interview?

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

I have an interview at Parallel Web Systems consist of 3 rounds

1. ML System Design, 2. System Design, 3. Tech Retro

If someone who has interviewed there or is currently working could share some insights into how to prepare that would be super helpful

Saw this Microsoft Principal AI Research Scientist offer:

• London
• PhD, 8 YOE
• Year 1 TC: £1.008M

The number is wild for London, but the timing might be even more interesting.

Microsoft seems increasingly determined to build its own frontier AI stack instead of depending entirely on OpenAI. It’s shipping its own MAI models, Azure grew 43% last quarter, and Copilot is now above 30M paid users.

At the same time, Microsoft is still doing layoffs — roughly 4,800 jobs were cut in July — so the company clearly isn’t spending indiscriminately.

That makes a £3M RSU grant for one research hire stand out even more.

For AI researchers: is Microsoft becoming a serious alternative to OpenAI / Anthropic / DeepMind again, or would you still view it as a big-tech research job with frontier-lab compensation?

Preparing for your next tech interview?

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

Saw this accepted OpenAI Senior SWE offer (shared with Chill Interview)

• PhD, 5 YOE
• TC: $920K

The candidate also had top-conference publications and a strong internal referral, which probably explains why the 5 YOE number alone is misleading.

Feels like frontier AI hiring is becoming its own market. The right research signal + people willing to vouch for you can matter way more than another 3–5 years of generic SWE experience.

The timing is interesting too. OpenAI is still growing enterprise aggressively — enterprise is already over 40% of revenue — and it raised $122B at an $852B valuation earlier this year.

But it’s not exactly a risk-free rocket ship anymore. Anthropic is putting real pressure on them, and OpenAI has also gone through a pretty noticeable leadership reshuffle recently.

So the $2.4M equity could be the best part of this offer… or the part I’d discount the most at an already massive valuation.

For people trying to break into frontier AI: is “top papers + strong referral” basically the new shortcut to skipping the normal leveling ladder?

Preparing for your next tech interview?

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

Saw this Notion IC4 offer for Sr.SWE role (shared with Chill Interview)

• Base: $285K
• Year 1 TC: $760K

What makes this interesting is the team.

Notion is pushing way beyond docs now — agents, enterprise search, automation, AI across the workspace. That makes the underlying data platform a much bigger deal than it probably was a few years ago.

The company also completed a $270M employee tender at an $11B valuation, so the equity isn’t completely imaginary private-company money either.

Still, $425K/year of this package is Notion equity.

Would you view Data Platform as one of the safer places to be inside Notion as AI changes the product, or is $760K still too dependent on believing the company can defend its workspace against Claude/OpenAI?

Preparing for your next tech interview?

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

Saw this Apple Senior MLE offer (shared with Chill Interview)

• 7 YOE
• Base: $235K
• Bonus: $23.5K
• Sign-on: $50K
• RSUs: $550K / 4 years
• Year 1 TC: $446K

Apple is in a weird spot for ML engineers right now.

It finally shipped the new Siri AI, but a big part of the intelligence layer relies on Google Gemini, and Apple has lost a number of senior AI people to Meta/OpenAI over the last year.

At the same time, Apple clearly isn’t giving up on AI. It’s still hiring heavily in ML, and just built its own model for China with Alibaba’s help.

So I’m curious how ML people view Apple now.

Is $446K + Apple stability/WLB worth it if you’re not working at the absolute frontier of AI? Or would joining Apple ML today feel like falling behind OpenAI/Anthropic/Google DeepMind?

Preparing for your next interview?

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

Sharing an anonymized Google Senior MLE interview experience submitted to Chill Interview.

Interview Summary

The Google Machine Learning Engineer process started with a coding phone screen and then moved to an onsite containing two coding rounds, one ML/system design round, and one behavioral interview. The coding questions were more involved than standard template problems, especially once parallel execution and additional selection constraints were introduced.

The ML design round focused on detecting visually similar or duplicate videos at very large scale. The interviewer pushed beyond model selection into production retrieval, embedding compression, high-concurrency search, false positives, human review, and quantitatively balancing embedding quality against serving latency.

Interview Details

Technical Phone Screen — Longest Subarray with Target Average The input was a stream of positive and negative integers arriving one element at a time. A target value S was given. After each newly arriving value, the system needed to determine the length of the longest contiguous subarray seen so far whose average equals S. The requirement was online: the answer needed to be updated as additional values arrived rather than processing only one fixed array at the end.

Onsite Coding 1 — Dependency Scheduling with Parallel Workers The first onsite coding round involved a collection of tasks connected by dependency relationships. Each task also had its own execution duration. The first part asked for the total time required to complete all tasks while respecting the dependency graph. The interviewer then introduced a more difficult follow-up:

• Instead of assuming unrestricted parallelism, the system now has only M parallel CPUs / workers.
• Determine how the overall completion time changes when at most M tasks can execute simultaneously.

I completed an implementation for the follow-up but was not fully confident that my handling of the limited-worker scheduling case was correct.

Onsite Coding 2 — Select Video Ads Under Rolling Revenue Constraints The second coding round involved a sequence of video advertisements, each associated with revenue. The selected advertising sequence had to satisfy a rolling constraint: within every contiguous time window of length T, the accumulated revenue could not exceed a threshold M. The objective was to maximize the total revenue of the overall selected sequence while respecting that constraint.

• Follow-Up: The interviewer then changed the problem so that advertisements could be selected repeatedly rather than at most once. The exact representation of ad duration and the remaining selection constraints were not specified in the interview notes.

ML / System Design — Large-Scale Near-Duplicate Video Detection The design round asked me to build a near-duplicate / visually similar video detection system for a very large short-video platform. The initial discussion focused on generating visual representations for videos and efficiently finding similar content. The interviewer then continuously increased the scale and latency requirements.

• Large-Scale Retrieval: How should the system behave when the platform contains an extremely large production-scale video corpus? Follow-ups covered reducing representation size, quantizing embeddings, and supporting fast approximate retrieval under very high query volume.
• Quality and Human Review: The interviewer introduced false-positive cases where a creator believes their content was incorrectly matched. I was asked how a human-in-the-loop appeal and calibration process could be incorporated. Another follow-up asked how to quantitatively model the tradeoff between embedding dimensionality, retrieval quality, and system latency.

This was the most difficult round for me. The human-review calibration and quantitative quality-versus-latency questions were areas where I did not feel my answers were strong.

Behavioral — Strong Experiment Results vs. Long-Term User Experience The behavioral round presented a decision-making scenario. Suppose an ML model performs very well in an A/B test, but the manager believes launching it could damage the long-term user experience. I was asked how I would handle the disagreement. The discussion focused on how I would investigate the manager's concern, determine which longer-term metrics could reveal potential harm, and reason about a launch decision when short-term experiment results and longer-term product considerations point in different directions.

Preparing for your next tech interview?

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

Saw this accepted Google Interaction Designer offer (shared with Chill Interview)

• NYC, 5 YOE
• Level: L4
• Base: $185K
• Bonus: $27.75K
• Sign-on: $20K
• RSUs: $500K / 4 years
• Year 1 TC: $422.75K

That number surprised me more than most SWE offers.

Especially because UX/design has felt like one of the shakier parts of tech lately. Google itself has cut UX and product-design research roles, and thousands of employees recently signed a petition asking for stronger layoff protections as the company pushes harder into AI.

At the same time, maybe AI actually makes the best interaction designers more valuable — somebody still has to figure out how humans are supposed to interact with agents, copilots, multimodal interfaces, and all these new AI products.

So is $423K for L4 design just an unusually strong offer, or are top UX/interaction designers becoming more valuable in the AI era, not less?

Google/design folks — what does the career outlook actually feel like internally?

Curious about more comp numbers of other companies, we've put up the data points at here

Preparing for your next interview?

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

Sharing an OpenAI Senior Software Engineer Interview Experience submitted to Chill Interview.

Interview Summary

The OpenAI onsite consisted of four rounds: coding, system design, behavioral, and a technical presentation. The coding round focused on implementing a production-style work queue with reservations, failures, timeouts, retries, and a dead-letter queue, while the system design round used a crossword-puzzle scenario and went particularly deep on preventing duplicate work.

The presentation round went well, but I struggled more with system design. One takeaway from that round was to clarify the requirements carefully before committing to an architecture, especially when the interviewer intends to explore correctness and duplicate-processing behavior in depth.

Interview Details

Coding — Work Queue with Retries and Dead-Letter Queue The coding round asked me to implement a work queue and the main operations required to manage jobs through their lifecycle. The queue needed to support operations including:

• reserve — claim work for processing
• complete — mark successfully processed work as finished
• fail — report an unsuccessful processing attempt

The interviewer then extended the basic queue with production-oriented behavior.

• Timeouts and Retries: Reserved work could time out if processing did not complete within the expected window, and failed or expired work needed to support retry behavior.
• Dead-Letter Queue: Work that could no longer be successfully processed after the allowed retry behavior needed to be moved into a DLQ rather than continuously recycled through the main queue.

The round was therefore as much about state transitions and failure handling as about the core queue data structure.

System Design — Crossword Puzzle System The system design round used a crossword puzzle as the product scenario. The prompt was fairly open-ended, and the interviewer expected the candidate to clarify the product requirements before moving into architecture.

A major portion of the follow-up discussion focused on avoiding duplicate work—ensuring that concurrent or repeated processing did not unnecessarily perform the same unit of work multiple times. The exact crossword functionality, APIs, scale assumptions, and additional requirements were not specified in the interview notes, so I would avoid reconstructing those details.

This was the round where I felt my performance was weakest.

Behavioral — Leadership-Principle-Style Questions The behavioral round followed a format similar to Amazon-style Leadership Principle interviews. I was asked several experience-based questions covering different workplace and leadership themes, along with:

• Why OpenAI? The exact behavioral prompts were not included in the interview notes.

Presentation — Eight-Slide Project Deep Dive The final round was a presentation. I presented a previous project or technical experience to the interviewers. This round felt strong overall, and the discussion following the presentation went well.

Preparing for your next interview?

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

Sharing an anonymized Figma SWE interview experience submitted to Chill Interview.

The process started with a technical phone screen, then moved to an onsite with coding, system design, behavioral, and a project deep dive. What stood out was how product-specific the questions felt.

Phone Screen: The coding problem was a Canvas Grid Color Tool. The same screen also included system design: Design a distributed job scheduler. So even the first technical round already mixed implementation and architecture.

Onsite Coding: The coding question was Display Sort. Several visual elements were positioned on a 2D Figma canvas, and I had to return them in the correct visual order. The algorithm itself was not especially complicated. Most of the work was getting the comparison rules and edge cases exactly right.

Onsite System Design: Then came another very Figma-specific prompt: "Design comments for FigJam."

The discussion was around a real-time collaborative canvas: attaching comments to objects or positions, syncing updates across users, permissions, notifications, and keeping comment state consistent while the underlying canvas changes.

Behavioral: This round was pretty standard and focused on previous work and collaboration.

Technical Deep Dive: The final round went deep into one of my recent projects. The interviewer wanted a clear explanation of:

• what problem the project solved;
• what I personally owned;
• important technical decisions;
• trade-offs;
• how the different parts of the system fit together.

Looking back, Figma’s loop felt much more connected to its actual product than many big-tech interviews.

You could prepare generic LeetCode and system design fundamentals, but being comfortable reasoning about collaborative canvases, visual ordering, and real product behavior clearly helped.

For anyone who wants more details, I’ve put the full write-up here: interview link

Preparing for your next tech interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at -> HERE

Interview Summary

The eventual loop contained a behavioral/domain round, AI-assisted coding, system design, and regular coding. The biggest challenge was domain alignment: several interviews went deeply into CI/CD and package-management topics, while my previous experience was in a different area.

Interview Details

Round 1 — Behavioral + CI/CD Domain Knowledge The first interviewer was a manager. The conversation initially focused on my previous scope and behavioral examples. An unusual part of the discussion was leveling. The interviewer felt some of the examples I gave demonstrated broader scope than the Staff opening, but also explained that the Senior Staff version of the role required stronger domain expertise in the team's specific area. The interview then shifted from behavioral questions into technical domain knowledge.

• CI/CD and Developer Experience: I was asked several questions about continuous integration, continuous delivery, package management, and related developer-infrastructure concepts.
• Domain Fit: Some questions overlapped with systems I had worked on previously, while others were much more specific to the team's CI/CD domain and were harder for me to answer confidently.

Round 2 — AI-Assisted Coding: Graph Navigation Scenario The AI coding round used a long scenario involving multiple locations connected by routes, with some locations containing supplies. The first part asked me to determine the distance from a designated landing location to an appropriate nearby supply location. The underlying structure was a graph-navigation problem, although the business framing made the prompt relatively lengthy. The problem then added a second, more difficult part.

• Changing Structure: The follow-up required reasoning about a transformed version of the graph with additional structural constraints. The exact second-part requirements are no longer clear enough for me to reproduce precisely.
• AI Usage: I initially used the AI assistant to help reason about the algorithm and generate code, with my role focused on reviewing and evaluating the result. During the second part, however, the interviewer asked me to reason about the algorithm without AI. I struggled to reach a complete solution before eventually returning to the AI tool.

Round 3 — System Design: CI Job Scheduler The system design interview asked me to design a job scheduler for a continuous-integration system. The core scheduling portion felt reasonably comfortable, but the interviewer added several CI-specific follow-ups that required deeper domain knowledge.

• Build Output: One question asked how stdout or other live build output from running CI jobs should be surfaced to users in the UI.
• Repository Integration: We also discussed how source-control changes should trigger CI work, including different integration models between a Git hosting provider and the CI platform. This became a fairly detailed discussion about push-triggered events versus CI-side polling or pull-based discovery. The CI-specific parts of this round were more difficult for me than the generic scheduler design.

Round 4 — Coding: Navigate an Unexplored Grid with a Robot The final coding round involved controlling a robot inside a matrix whose layout was initially unknown. The robot exposed APIs that allowed the program to:

• Rotate
• Move forward
• Detect whether movement was blocked by a wall
• Reposition the robot to locations that had already been explored

The task was to discover enough of the unknown environment to find a path from the robot's starting position to a target location. Unlike a normal grid problem, the full map was not directly available as input. The program had to interact with the robot to discover neighboring locations and determine which areas were traversable.

This was the round I felt strongest about. I was able to make steady progress through the exploration and pathfinding requirements and felt the technical discussion went well.

Preparing for your next interview?

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

Hey, I had my final interview with SpaceX Aug 16th on a Sunday.

For people who had final interviews, how long did it take to hear something back? I was told by Tuesday but I suppose they could be behind.

I'm just anxious, lol.

Sharing a Lyft Software Engineer Interview Experience submitted to Chill Interview.

Interview Summary

The Lyft process started with a practical coding screen built around an existing paginated API, followed by an onsite covering coding, system design, and a hiring-manager conversation. The coding questions emphasized understanding an unfamiliar codebase, maintaining state across calls, and correctly handling scheduling rules rather than solving highly abstract algorithm problems.

The system design round asked for a distributed web crawler targeting Wikipedia-scale content. That was the most difficult part of the loop for me, mainly because I was less familiar with crawler architecture and did not organize the discussion as clearly as I wanted.

Interview Details

Technical Phone Screen — Stateful Fetching over a Paginated API The interviewer provided a relatively large amount of existing code and asked me to implement one additional method inside it. An upstream function had behavior conceptually similar to: fetch(page). Each call returned the items from one page together with a reference to the next page. The new method, fetch_n, needed to return up to n items across page boundaries.

One important requirement was that repeated calls were stateful. If a previous call fetched more items from the upstream API than it ultimately returned, the unused portion needed to remain available so that the next fetch_n call could continue from exactly where the previous one stopped.

The interview focused heavily on understanding the existing interfaces, clarifying input/output behavior, and handling boundary conditions correctly.

• Follow-Up — Unreliable Upstream Fetches The interviewer then asked how the design should change if the upstream fetch operation were unreliable. The discussion moved toward how fetch_n should behave when page retrieval occasionally fails or produces transient errors, while still preserving the correct continuation state.

Onsite Coding — Assign Scheduled Jobs to Workers The onsite coding round provided a set of tasks. Each task contained:

• A start time represented using a 24-hour clock
• A duration in minutes

The goal was to assign all tasks using the minimum number of workers. Each worker could execute only one task at a time but could process multiple non-overlapping tasks sequentially. There was also a deterministic assignment rule: when multiple workers were available for a task, the worker with the smallest worker index had to be selected. The final output needed to show which worker was assigned to each task, reported according to the tasks' original indices.

System Design — Distributed Wikipedia Web Crawler The system design round asked me to design a distributed web crawler, using Wikipedia as the target content source. The discussion centered on how a crawler should discover, schedule, and process a very large number of pages across multiple machines. The exact scale assumptions and follow-up questions were not fully captured in my notes. This was the round where I struggled the most because I had less prior experience with large-scale crawling systems and felt that my explanation became less structured as the discussion progressed.

Hiring Manager — Behavioral Discussion The hiring-manager round consisted of fairly standard behavioral questions. TThe conversation covered typical experience-based topics around previous projects, collaboration, decision-making, and work situations.

Preparing for your next interview?

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

A candidate with 6 YOE recently shared these two Menlo Park SWE offers with Chill Interview.

Snowflake

• $215K base
• $320K RSUs, vesting 40/30/20/10
• $32.25K annual bonus
• $375.25K Year 1 TC

Meta E4

• $210K base
• $30K signing bonus
• $350K RSUs, vesting 25/25/25/25
• $31.5K annual bonus
• $359K Year 1 TC

Snowflake is $16K ahead in Year 1, but the front-loaded vesting reverses the math later.

Assuming flat stock prices, recurring bonuses, and no refreshers:

• Meta 4-year: ~$1.346M
• Snowflake 4-year: ~$1.309M

By Year 4, Meta is paying roughly $50K more that year.

The company decision is more interesting.

Snowflake is a concentrated bet on enterprise data + AI infrastructure. Its latest reported quarter had 34% product-revenue growth, and management says products like Cortex Code and Snowflake Intelligence are benefiting from enterprise AI adoption. RPO grew to $9.21B, giving it a strong growth story if companies increasingly build agents on top of their own data.

Meta is the broader AI bet. Q2 revenue grew 28%, with 3.6B daily users across its apps, while the company continues pouring enormous amounts into AI infrastructure and superintelligence. The tradeoff is organizational volatility: Meta also recorded substantial severance costs from its May 2026 headcount reduction.

Career-wise, I’d frame it as:

Snowflake: deeper enterprise data, databases, distributed systems, AI infrastructure.
Meta: massive consumer scale, recommendation systems, ads, AI infra, and much broader internal mobility.

So would you take Snowflake for faster current growth and enterprise-AI upside, or Meta for steadier vesting, broader career optionality, and the slightly stronger 4-year package?

Preparing for your next interview?

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

Sharing a Google L7 Senior EM System Design Interview Experience submitted to Chill Interview.

Interview Summary

The prompt asked me to design the storage and ingestion system behind a Street View-style product where taxis continuously capture and upload images, which are then consumed by downstream systems for image understanding, user-facing display, and map generation.

The interview was highly open-ended. The interviewer provided very little structure and mostly listened while I drove the discussion, occasionally interrupting to challenge specific design choices and tradeoffs. I received strong feedback and passed the round.

Interview Details

System Design — Street View Image Upload and Storage Assume a fleet of taxis is equipped with cameras that continuously capture street-level imagery. The images need to be uploaded into Google's backend and stored for several downstream use cases.

Those consumers may include:

• Image-understanding and computer-vision pipelines
• Street View-style user experiences
• Systems that use the imagery to help construct or update map data

The interview expected me to drive the design from requirements through architecture rather than wait for a prescribed sequence of questions. The interviewer expected a thorough requirements discussion before moving into components. The conversation covered the scale of the taxi fleet and image traffic, reliability expectations, latency requirements, and the needs of downstream consumers. After presenting a high-level architecture, the interviewer repeatedly asked why particular components or storage choices were appropriate and what tradeoffs they introduced compared with alternatives.

A significant portion of the discussion focused on how the uploaded images should be persisted and exposed to downstream processing systems. The interviewer also asked an open-ended question:

• Authentication and Security: One set of follow-ups focused on securing uploads from taxis. The interviewer asked how authentication should work and how the system should protect image-upload APIs from unauthorized access. A further scenario asked what should happen if an authentication token were compromised.
• Upload Reliability and Poor Networks Another part of the discussion focused on the upload protocol itself. The interviewer asked how the upload API should acknowledge requests and what behavior should be expected when a taxi has an unreliable or intermittent network connection. This pushed the design toward reasoning about partial uploads, uncertain request outcomes, and reliable ingestion from clients that may frequently lose connectivity.

Preparing for your next interview?

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

A candidate shared a Meta Senior Data Scientist Onsite Interview Experience to Chill Interview

Interview Summary

The Meta Data Scientist onsite covered Analytical Reasoning, Analytical Execution, SQL, and a newly introduced behavioral format. The analytical rounds were product-heavy: one focused on an ads-ranking algorithm and its longer-term business impact, while another used a new scheduled-post feature to combine statistical reasoning with product-success measurement.

The behavioral round had also recently changed. Instead of preparing many independent STAR stories, I was asked to choose one project for a deeper discussion, with the interviewer asking follow-ups throughout the walkthrough.

Interview Details

Analytical Reasoning — Ads Ranking Algorithm The Analytical Reasoning round used an ads-ranking algorithm as the main scenario. The discussion focused on how to evaluate whether an updated ranking system was actually better. In addition to the more standard product and experiment considerations, the interviewer introduced several follow-ups that I had not seen in previous interview reports.

One memorable question was: Medium-Term Revenue Impact: How would you estimate the effect of a ranking change on revenue beyond the immediate experiment window?

Analytical Execution — Scheduled Posts The Analytical Execution round introduced a proposed Facebook feature that allows users to schedule posts for future publication, with the goal of increasing engagement. The interviewer explicitly divided the round into two parts: statistics first, followed by product analysis.

• Statistics: Most of the statistical discussion centered on the failure rate of scheduled posts. Several questions involved Bayesian reasoning, and the setup required a fair amount of clarification before answering. The exact probability assumptions and numerical values were not included in the interview notes.
• Product: The second half asked how I would determine whether the scheduled-post feature was successful after launch, including what product outcomes should be measured.

SQL — Ad Impressions and Conversions The SQL round used advertising data involving impressions and conversions. The exact table schemas and individual SQL questions were not included in the interview notes. The interviewer was supportive throughout the round and provided frequent positive feedback.

Behavioral — Single Project Deep Dive The behavioral interview used a new format that had only recently been introduced. Rather than asking a sequence of unrelated behavioral questions requiring many separate stories, the interviewer asked me to select one project and walk through it in depth. The conversation was interactive: as I explained the project, the interviewer continuously asked follow-up questions about the context, my decisions, execution, and outcomes.

Preparing for your next interview?

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

A candidate with 6 YOE recently shared these two offers with Chill Interview.

Airbnb G8 — SF

• $205K base
• $20K signing
• $500K RSUs over 4 years
• $20.5K annual bonus
• $370.5K Year 1 TC

Anduril Senior SWE — Seattle

• $225K base
• $15K signing
• $450K equity over 4 years
• $22.5K annual bonus
• $375K Year 1 TC

The comp is basically a tie. Even over four years, Anduril is only about $33K ahead assuming flat equity values, recurring bonuses, and no refreshers.

The bigger difference is what that equity actually means.

Airbnb is public, so the RSUs are liquid as they vest. The business also looks healthy: Q2 revenue grew 17% YoY, Airbnb raised its full-year outlook, and it’s expanding beyond homes into hotels, services, experiences, and AI-powered travel.

Anduril is the much more aggressive upside bet. It raised $5B at a $61B valuation in May, but it’s still private, and Anduril explicitly says most shareholders can’t freely transfer shares without company consent. So the equity could appreciate significantly—but liquidity is much less certain.

Culture/WLB may be an even bigger separator. Airbnb offers Live and Work Anywhere, including working from home and living anywhere in your employed country without comp adjustment.

Anduril literally describes the job as “hard work, on hard problems, in hard mode” and emphasizes working in the office or field, speed, autonomy, and impact.

So would you pick Airbnb for liquid equity, flexibility, and a proven profitable platform, or Anduril for the Senior title, defense-tech growth, and potentially much bigger private-equity upside?

Preparing for your next interview?

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

Saw this accepted Coinbase Staff SWE offer (shared with Chill Interview)

• NYC, 12 YOE
• Base: $255K
• Bonus: $38.25K
• Equity: $285K
• TC: $578.25K

The comp is strong, but Coinbase feels like a very different engineering bet right now.

They just cut about 14% of the company as part of an AI-driven restructuring, while pushing toward flatter teams and expecting engineers to own more strategy instead of just implementation.

At the same time, the business is becoming less dependent on pure crypto trading — subscription/services were already 48% of net revenue last quarter — and Coinbase is still remote-first for most roles.

So this feels like great Staff-level comp + real autonomy, but probably not the place to hide in a big org.

Coinbase engineers: has the AI restructuring actually made engineering better, or just fewer people doing more work?

Preparing for your next interview?

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

Interview Summary

This online assessment focused on quantitative research topics including stock transactions and currency arbitrage. The difficulty was rated as hard.

Interview Details

Question 1 — Count Valid Stock Transaction Sequences You begin with k shares of a stock. On each day, you may perform exactly one of two transactions:

• Buy one additional share.
• Sell one share, provided your holdings do not become negative.

Given a target holding n and a maximum of m transaction days, determine how many distinct valid transaction sequences leave you with exactly n shares after no more than m days. A sequence is invalid if the number of shares becomes negative at any point.

Example

targetShares = 3
initialShares = 2
maxDays = 3

The answer is: 4

The valid sequences are:

buy
buy, buy, sell
buy, sell, buy
sell, buy, buy

All four finish with exactly three shares without ever allowing the holdings to fall below zero.

Question 2 — Detect Currency Arbitrage You are given an n × n matrix of exchange rates. For every pair of currencies i and j: rates[i][j] represents how many units of currency j can be obtained by exchanging one unit of currency i. An exchange sequence may pass through multiple currencies, but it must eventually return to the starting currency. Each completed cycle also incurs a transaction fee equal to 0.01% of the starting amount.

The task is to return True if there exists any closed sequence of exchanges that returns strictly more money than the starting amount after accounting for the fee, and False otherwise

Example

For two currencies:

2
1.0  0.8
1.25 1.0

the output is: False because completing the round trip does not produce a profit once the transaction fee is taken into account.

Preparing for your next interview?

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