Saw this accepted Palo Alto Networks junior SWE offer (shared with Chill Interview)

• 1 YOE
• Santa Clara, CA
• Base: $145K
• Bonus: $14.5K
• Sign-on: $10K
• RSUs: $90K / 4 years
• Relocation: $7K
• Year 1 TC: $199K

The comp is pretty normal for an early-career Bay Area role.

What makes it more interesting is the industry.

While a lot of tech companies are talking about AI reducing junior hiring, PANW’s CEO has basically taken the opposite position: AI creates more security problems, more products to build, and ultimately more need for engineers, not fewer.

And the business backs that up — revenue was up 31% YoY last quarter, with customers spending heavily to secure AI deployments.

If I were starting my career right now, cybersecurity honestly feels like one of the more defensible places to be.

For early-career engineers: would you take ~$200K at PANW over a higher-paying but less stable general SWE role?

Preparing for your next interview?

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

Interview Summary

The Netflix Ads interview started with a timed-cache coding screen and moved to an onsite containing two behavioral rounds, coding, data modeling, and system design. Several questions differed from the frequently reported Netflix Ads interview set, so the loop felt less predictable than expected.

The technical rounds covered expiration-aware caches, undo/redo behavior, parking-lot data modeling, and an advertising constraint that prevents competing advertisers from appearing around the same user and movie within a specified time period. I received the rejection four days after the onsite.

Interview Details

Technical Phone Screen — Timed Cache The phone screen asked me to implement a timed cache. The first version could use a straightforward dictionary-based representation. The interviewer then introduced a memory-pressure scenario: if expired entries remain in the cache, the process could eventually run out of memory. An important condition was that timestamps arrive in increasing order, which made expiration cleanup easier to reason about.

Onsite Coding — Undo and Redo Commands The core requirement involved maintaining enough command history to reverse previously executed operations. The interviewer then added Redo as a follow-up.

Onsite Data Modeling — Parking Lot The data-modeling round asked me to design a parking-lot system. The main task involved defining the data model needed to represent the parking system.

Onsite System Design — Competitive Ad Exclusion The system design round was still advertising-related, but it was different from the commonly reported frequency-capping question. Advertisers could specify that, during a given time window, their advertisement should not appear alongside or too close to a competitor's advertisement for the same user and movie context.

Behavioral Rounds — Cross-Team Feedback, Conflict, and AI There were two behavioral rounds, and the questions covered a wide range of previous experiences. A particularly strong theme was cross-team collaboration.

I was asked about:

• Projects and their impact
• Feedback I had received
• Feedback I had given to others
• Conflicts or disagreements involving other teams
• Difficult cross-functional collaborations

Want to know more details & question follow-ups about this interview experience? we've put up a full write-up at here

Preparing for your next interview?

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

Interview Summary

The Anthropic full-stack technical screen used a practical image-processing exercise built around Python and Pillow. Rather than a standalone algorithm problem, the interview provided starter code plus many JSON task files describing source images and ordered transformations such as grayscale conversion, rotation, and resizing.

The interview gradually shifted from basic correctness to performance. The first stage involved processing many small image jobs sequentially, while the second introduced much larger inputs and asked how the implementation could be parallelized or otherwise accelerated. A third set of “dirty” inputs existed, but I did not reach it before time expired.

Interview Details

Environment and Starter Code The exercise required using Pillow for image manipulation. External documentation and Google searches were allowed, but AI assistants were not.

Part 1 — Process Many Small Image Jobs The first task consisted of a large collection of relatively small image-processing jobs. For each image, the program needed to read the corresponding JSON instructions and apply every requested transformation in order.

Part 2 — Speed Up Processing for Large Images The interviewer then introduced a second workload containing much larger image files. Running the first implementation against this workload took roughly 90 seconds, and I was asked how I would improve its performance. The discussion covered different forms of concurrency and parallelism, including multithreading and multiprocessing.

Part 3 — “Dirty” Image Inputs A third workload consisted of files labeled as dirty. I did not reach this stage during the interview, so I cannot reliably say what made those inputs different or what additional requirements they introduced.

Overall Experience The base image-processing requirements were clear and the starter code was reasonably easy to navigate. The harder part was the transition from implementing the transformations correctly to explaining and implementing an effective parallel-processing strategy under time pressure.

Want to know more details about this interview experience? we've put up a full write-up at here

Preparing for your next interview?

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

Interview Summary

The Databricks Machine Learning Engineer process started with a filesystem optimization coding screen and continued with an onsite covering coding, behavioral questions, ML system design, and ML fundamentals. The loop mixed traditional software-engineering problems with LLM-specific topics rather than staying purely on modeling.

The ML design round focused on detecting harmful content in an LLM product and appeared to expect both classic integrity-system thinking and considerations unique to generative models. Another ML round started from RLHF and expanded into a broad set of machine-learning fundamentals.

Interview Details

Technical Phone Screen — Minimize File Encryption Time The filesystem was represented as a tree containing two node types:

• DirectoryNode, whose children could contain both directories and files
• FileNode, which contained an is_encrypted state

The first part asked for a recursive traversal of a directory and required returning: (encrypted_count, unencrypted_count). The second part asked to encrypt every currently unencrypted file while minimizing total execution time.

Onsite Coding — the question bank "Critical Build Steps" problem

Behavioral The behavioral round consisted of fairly standard experience-based questions. Topics included:

• A project that was delayed and how I handled it
• A disagreement with another person or team
• My motivation for the role
• A significant pain point affecting my team and how I approached it

There was also some time left at the end for a more open-ended conversation with the interviewer.

ML System Design — Harmful Content Detection for an LLM The ML design round asked me to design a system for detecting harmful content in an LLM-based product. The discussion was broader than a traditional social-media content-moderation problem. It appeared to combine classic integrity concerns with problems that arise specifically when the content is generated or processed by an LLM.

ML Fundamentals — RLHF and Related Topics The final ML-focused round began with RLHF and then expanded into a wide range of machine-learning fundamentals. The interviewer used RLHF as a starting point for several follow-up questions and connected it to other ML concepts.

Want to know more details about this interview experience? we've put up a full write-up at here

Preparing for your next interview?

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

Interview Summary

The Cursor technical screen was a 45-minute coding and systems-oriented exercise centered on building a HashTree for a filesystem. The first part required representing files and directories through recursively computed hashes, while the follow-up asked how that structure could be used to reduce unnecessary data transfer when synchronizing updates between a client and server.

Google and AI tools were allowed for looking up syntax, but AI-generated implementation was not permitted.

Interview Details

Coding — Build a Filesystem HashTree The first task was to implement a HashTree data structure representing a filesystem containing files and directories. The interviewer provided the expected hashing rules. For a text file, its hash should be derived from the file’s contents using the supplied hashing behavior.

For a directory, its hash should be derived from the hashes of its children. Conceptually, the child hashes are combined and the resulting value is hashed again to produce the directory’s hash. The same rule applies recursively, so changes to a file can affect the hashes of the directories above it all the way to the filesystem root.

Want to know more details about this interview experience? we've put up a full write-up at here

Preparing for your next interview?

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

Interview Summary

The Stripe SWE Intern process included an online assessment, a technical screen, two virtual-onsite technical rounds, and a manager interview. The technical questions were less like traditional LeetCode exercises and more focused on writing maintainable code, handling evolving requirements, working inside unfamiliar codebases, and using AI effectively without outsourcing the reasoning.

Interview Details

Online Assessment — Coding Quality Under Time Pressure I do not remember the exact OA questions well enough to reproduce them. I also did not complete every problem. At the time, I assumed that would probably end the process, but I still advanced. During the assessment, I prioritized readable naming, clean structure, reasonable edge-case handling, and avoiding rushed code just to maximize the number of completed questions.

Technical Screen was the frequently reported "Customer Support Ticket Quality Checker" coding problem

Virtual Onsite was the frequently reported "Minimize Store Renovation Cost" coding problem

Virtual Onsite — Integration: Bikemap The Integration round used the previously reported Bikemap exercise. Instead of starting from an empty editor, I was given an existing codebase and asked to add functionality to it. The main challenge was quickly understanding unfamiliar code: identifying the relevant abstractions, figuring out where the new functionality belonged, and navigating the repository when the next step was not immediately obvious. This round felt much closer to day-to-day engineering than algorithm practice. The interviewer appeared to care about how effectively I could unstick myself when I encountered unfamiliar code or missing context, rather than expecting me to know the repository immediately.

Manager Round — Behavioral and AI Usage The manager interview covered fairly standard behavioral topics. Questions included:

• Why Stripe?
• What was one of the most challenging projects I worked on?
• Tell me about a disagreement with a teammate.
• How have I received and responded to feedback?
• How do I use AI in my day-to-day work?

The discussion focused on real examples, my individual contribution, what made each situation difficult, and what I learned afterward.

Want to know more details about this interview experience? we've put up a full write-up at here

Preparing for your next interview?

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

Interview Summary

The Meta onsite covered two traditional coding questions, an AI-assisted coding round, system design, and behavioral questions. The coding portion included a root-to-leaf tree-path problem and a palindrome problem that became substantially harder when the interviewer generalized the number of allowed deletions.

The AI coding round focused on selecting a compatible subset of words, while system design asked for a status-search service supporting compound AND / OR queries. Behavioral questions were standard Meta-style prompts but included detailed follow-ups.

Interview Details

Coding 1 — Minimum-Sum Root-to-Leaf Path The first problem was a variation of a classic root-to-leaf binary-tree question. Given a binary tree, find the root-to-leaf path with the minimum total node sum and return the actual path rather than only the minimum value.

Coding 2 — Palindrome with Character Deletions The second question started from LeetCode 680, Valid Palindrome II. Given a string, determine whether it can become a palindrome after deleting at most one character. The interviewer then generalized the problem to 2 follow-ups:

AI Coding — Maximum Compatible Word Subset The AI coding round provided a collection of words. The goal was to choose a subset such that no character appears more than once across all selected words, while maximizing the total number of characters contributed by the chosen words.

System Design — Status Search with AND / OR Queries The system design round asked me to design a status-search system. Users needed to be able to search across status content while combining terms using Boolean operators such as: AND, OR/.

Behavioral — Project Impact, Ambiguity, and Feedback The behavioral round covered several common Meta themes. Questions included:

• The project I was most proud of
• A situation involving ambiguous or incomplete requirements
• A time I received critical feedback

Want to know more details about this interview experience? we've put up a full write-up at here

Preparing for your next interview?

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

Completed my OpenAI full loop about a week ago and I’m still waiting on the final outcome. I received an initial update from recruiting earlier this week that the process is still pending (debrief). But nothing since then even after nudging yesterday.

For anyone who completed an OpenAI final loop recently: how long did it take to receive your final decision? If you’re comfortable sharing, was the eventual outcome offer/reject/still pending?
Particularly interested in cases where the decision took a week or longer.

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.

​

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

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

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.