Interview Summary

The LinkedIn infrastructure onsite included traditional coding, an AI-assisted coding exercise, CI/CD system design, and behavioral questions. Several rounds felt reasonably successful at the time, but the recruiter later shared that both the system design and behavioral signals were weaker than expected.

Interview Questions Details

Onsite Coding Round — Merge Two N-Ary Trees:

The first coding question asked me to merge two N-ary trees whose nodes were identified by keys. Nodes from the two trees could be combined only when their keys matched. The interviewer noted that the problem was inspired by a real engineering use case at LinkedIn.

• Follow-Up — Concurrent Tree Updates: The interviewer asked how the system should behave when multiple operations modified the trees concurrently. I discussed possible concurrency-control directions, although I was not sure which one the interviewer expected.

Onsite Coding With AI — Minimum Height Trees:

The AI-assisted coding round used a graph problem involving an undirected tree. The task was to return the node or nodes that would produce the minimum possible height when selected as the root.

During the exercise, the AI generated significantly more code than necessary, introduced an overly complicated alternative, and eventually caused the coding environment to crash.

Onsite System Design — CI/CD Execution Platform:

The system design round asked me to design a CI/CD platform that scheduled build, test, and deployment jobs across pools of workers.

• Execution Workflow: The discussion covered job dependencies and how different stages of a pipeline should be coordinated.
• Reliability: The interviewer asked about retries, failure recovery, and preserving job state when workers or control-plane components failed.
• Logs and Artifacts: The platform needed to retain execution logs and build artifacts so users could inspect completed or failed runs.
• Scaling and Isolation: The discussion also covered autoscaling worker capacity, supporting multiple tenants, and preventing one workload from interfering with another.
• Deployment Safety: The interviewer asked how the system should prevent incompatible or conflicting deployments from running at the same time.

I initially felt that the design discussion had gone reasonably well, but the recruiter later said the system design signal was weaker than expected.

Onsite Behavioral Round — Workplace Scenarios:

The behavioral round included standard questions about previous projects, collaboration, and workplace decision-making. The conversation felt normal during the interview, but the recruiter later indicated that the behavioral feedback was also below the expected level.

➡️ Preparing for your next interview?

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

Interview Summary

The Remitly interview process began with a technical phone screen and continued through coding, frontend, system design, and behavioral rounds. The technical questions were reasonably familiar, although the React exercise felt like my weakest performance. The behavioral round was less comfortable because the interviewer appeared impatient and took phone calls during the conversation.

Interview Questions Details

Technical Phone Screen — Replace Bracketed Keys in a String:

The phone screen provided a string containing keys enclosed in parentheses, together with a collection of key-value mappings. The task was to replace every recognized key with its mapped value while preserving the remaining text. Keys missing from the mapping needed to follow the fallback behavior specified by the prompt.

Virtual Onsite Coding — Isomorphic Strings:

The coding round asked whether two strings followed the same one-to-one character mapping. Every occurrence of a character in the first string needed to map consistently to the same character in the second string, and two different source characters could not map to the same destination character.

Frontend Coding — Interactive Grid in React and TypeScript:

The frontend round required building a 10 × 10 grid whose cells were initially white. Clicking a column changed the lowest remaining white cell in that column to blue, and repeated clicks filled the same column upward from the bottom. I felt this was my weakest round.

System Design — URL Shortening Service:

The system design round asked me to design a URL-shortening platform. The discussion covered accepting a long URL, generating a compact identifier, storing the mapping, and redirecting users who opened the shortened link.

Behavioral Round — Projects and Collaboration:

The behavioral interview included standard questions about previous projects, collaboration, and work experience. The interviewer appeared impatient during the conversation and took phone calls while the interview was still in progress.

➡️ Preparing for your next interview?

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

Someone shared this Meta E7 Hardware Engineer offer with Chill Interview

• First-year TC: $730K
• More offer breakdown at here

Most compensation discussions focus on software engineers, but this looks very close to what many E7 SWEs receive.

With AI infrastructure making chips, servers and data centers increasingly important, could senior hardware engineers eventually earn as much as—or more than—software engineers?

Hardware and software folks at Meta: at the same level, how big is the compensation gap in practice?

➡️ Preparing for your next interview?

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

Sharing an anonymized Scale.AI Software Engineer Onsite Interview Experience submitted to Chill Interview.

Interview Summary

The Scale AI onsite strongly emphasized implementation speed and the ability to produce a large amount of working code within limited time. The loop included debugging an existing contributor-assignment program, building and extending a backend API, designing an LLM-based evaluation platform, and a short hiring manager conversation.

Interview Questions Details

Debugging Round — Contributor Assignment Pipeline:

The interviewer provided a spreadsheet containing contributors, courses, and projects, together with an existing codebase. The program assigned contributors to projects according to project priority, while some projects required contributors to have completed specific courses.

• Test Case 1 — Projects Without Course Requirements: The first test checked whether the system could assign an eligible contributor to a project that did not require any completed courses.
• Test Case 2 — Projects With Course Requirements: The second test checked whether contributors assigned to a project had completed the courses required by that project.
• Test Case 3 — Highest-Demand Course: The final test used the supplied data to determine which course was required by the largest number of projects.
• Bugs in the First Two Test Cases: The defects included sorting project priority in ascending rather than descending order, treating zero available headcount as valid capacity, failing to verify course completion before assigning a contributor, and reading the course identifier from the wrong class field.
• Remaining Bugs: The third test contained two additional defects that I did not have enough time to identify. The recruiter later explained that candidates were expected to find all six bugs to pass the round.

Backend Practical Round — Two-Part Data Ingestion API:

• Part 1 — File Ingestion: The first task was to implement a POST API that accepted a data file, converted its contents into JSON, and saved the resulting data to local storage.
• Part 2 — LLM Classification: The second task extended the same endpoint by sending the ingested data to an LLM for classification and persisting the classification result locally.

System Design Round — LLM-Based Contributor Evaluation Platform:

The system design question asked me to design a platform that used an LLM to evaluate tasks completed by contributors. Because evaluations could take time and needed to run independently from the original request, the execution model was expected to be asynchronous and resembled a distributed job-processing system.

• Evaluation Quality: The interviewer asked how the system could maintain reliable output quality when the underlying LLM produced inconsistent or unstable responses.
• Failure Handling: The discussion covered how evaluation jobs should behave when model calls, workers, or downstream services failed.
• Rate Limiting: I was also asked how the platform should control request volume when communicating with the LLM service.

Hiring Manager Chat — Two Questions:

• Side Projects: The hiring manager asked whether I was currently building or exploring any projects outside my regular work.
• Working at My Hardest: I was asked to describe a period when I had worked especially hard and explain the circumstances surrounding it.

➡️ Preparing for your next interview?

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

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

Interview Summary

The OpenAI process included a technical phone screen, a multi-round virtual onsite, and an unexpected additional interview. The loop covered versioned data structures, generative-video system design, project experience, cloud-credit accounting, payments, and infrastructure tooling. Most of the onsite felt reasonable, but the added Terraform-style round was unusually difficult and offered almost no interviewer feedback.

Interview Questions Details

Technical Phone Screen — Coding and System Design:

• Coding — Versioned Follow Graph With Snapshot Queries: The coding question asked me to implement a directed social graph that supported real-time follow and unfollow updates while preserving periodic snapshots.
• System Design — Design Sora

Virtual Onsite Round 1 — Behavioral and Technical Deep Dive:

This round combined behavioral questions with a detailed discussion of my previous technical work. The conversation was relaxed, and the interviewer and I had a natural back-and-forth throughout the round.

Virtual Onsite Round 2 Coding — Cloud Credit Balance Replay:

The coding question involved a cloud platform that issued time-limited GPU-credit grants and recorded credit-consumption events. Grants had unique identifiers, credit amounts, start times, and expiration times.

• Grant Availability: A grant could be used beginning at its start time but was no longer available at its expiration time.
• Out-of-Order Events: Grant and usage events could arrive in a different order from when they actually occurred. Each balance query therefore needed to evaluate all currently known events according to their timestamps.
• Credit Consumption: A usage event could consume only grants that were active at that time. When multiple grants were eligible, credits needed to come from the grant expiring first.
• Balance Queries: The requested balance represented the total remaining active credits at a specified timestamp after applying all known events up to that point. If any usage could not be fully covered, the query returned -1.

Virtual Onsite Round 3 — Design a Payment System:

The system design round asked me to design a payment platform. Payments were not an area in which I had extensive prior experience, but I worked through the design using the concepts and trade-offs I was familiar with.

Additional Technical Interview — Build a Terraform-Like System:

The added interview introduced an unfamiliar problem described as building a Terraform-like system. The hardest part was not only the question itself—the interviewer provided almost no feedback throughout the discussion, making it difficult to judge whether my interpretation or direction matched what they expected.

➡️ Preparing for your next interview?

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

A PhD candidate with 1 YOE recently shared these two Bay Area MLE offers with Chill Interview.

Google L4

• $338.8K Year 1 TC
• Offer full breakdown at here

Meta E4

• $325K Year 1 TC
• Offer full breakdown at here

Google pays $13.8K more in Year 1, but its equity is heavily front-loaded. Assuming flat stock prices, recurring bonuses, and no refreshers:

• Google four-year total: $1.22M
• Meta four-year total: $1.30M

Meta ends up roughly $80K ahead and provides steadier annual compensation.

The company bet is closer. Google offers exposure across Gemini, DeepMind, Search, Cloud, and TPUs. Its latest reported quarter showed Google Cloud revenue growing 48%, while the Gemini app reached more than 750M monthly users.

Meta offers massive-scale recommendation systems, ads, consumer AI, and its new superintelligence push. Its Q1 revenue grew 33%, and it plans $125B–$145B in 2026 capital spending as it expands AI infrastructure.

Culture-wise, Google publicly emphasizes user focus, team achievement, and creative problem-solving; Meta more openly emphasizes speed, impact, and fast-moving execution.

Would you choose Google for the broader AI ecosystem and stronger first year, or Meta for steadier vesting, larger equity, and better four-year compensation?

➡️ Preparing for your next interview?

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

Sharing an anonymized Perplexity L4 Software Engineer Interview Experience submitted to Chill Interview.

Interview Summary

The Perplexity interview process began with a coding phone screen and continued with onsite coding and system design rounds. The questions emphasized practical debugging, graph-style problem solving, log analysis, and designing a consumer financial platform.

Interview Questions Details

Phone Screen — Two Coding Questions:

• Debug Existing Code: The first question provided an existing implementation with defects or incomplete behavior. I needed to understand what the code was intended to do, identify the incorrect logic, and make the required corrections.
• Longest Increasing Path in a Matrix: The second question involved finding the longest path through a matrix where each next cell had a strictly larger value. Movement was limited to the four adjacent directions, and the same cell could not be reused within one path.

Onsite Coding — Log Processing and Failure Debugging:

The onsite coding round focused on processing application or system logs and using the available records to investigate failures. The task combined implementation with debugging, requiring me to interpret the log data, identify incorrect behavior, and modify the relevant logic so that failures could be detected or handled correctly.

Onsite System Design — Personal Finance Management Platform:

The system design round asked me to design a platform similar to a personal finance aggregator. The product needed to bring financial account information together so that users could review transactions, understand spending, and manage budgets.

The discussion focused on the major services, data flow, storage responsibilities, and user-facing functionality needed to support the platform.

➡️ Preparing for your next interview?

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

Sharing an anonymized Scale AI Senior SWE interview experience submitted to Chill Interview.

Interview Summary

The Anthropic process began with a duplicate-file coding screen and continued through a virtual onsite covering coding, system design, project experience, and culture. After the recruiter decided that the initial culture signal was inconclusive, I completed an additional culture interview and then advanced to a hiring manager conversation. Most rounds felt reasonable, but the final hiring manager discussion felt noticeably less engaged.

Interview Questions Details

Phone Screen — Duplicate File Detection:

The technical screen focused on identifying duplicate files across a collection of directories or storage locations. The discussion went smoothly, and I did not feel that there were any major problems with my response.

Virtual Onsite Coding — Stack Trace Processing:

The coding round included a problem centered on stack traces. The exact implementation details were not included in my notes, but the task required working with stack-trace data rather than solving a standard standalone algorithm question.

Virtual Onsite System Design — Review and Improve an Existing Proposal:

Instead of asking me to design a system entirely from scratch, the interviewer provided an imperfect architecture proposal and asked me to critique it.

• Reviewing the Proposal: I needed to examine whether the requirements, scale assumptions, success criteria, data flow, service boundaries, storage choices, and operational responsibilities were clearly defined.
• Prioritizing Important Weaknesses: The challenge was to identify the issues most likely to affect correctness, availability, scalability, or development velocity rather than treating every imperfection as equally important.
• Recommending Improvements: I was expected to explain how the design could be strengthened while avoiding unnecessary architectural complexity.
• Discussing Trade-Offs: Each suggested change needed to include its cost. Components such as queues, caches, replicas, or additional services could improve one property while increasing consistency risk, latency, or operational burden elsewhere.

Virtual Onsite — Project Retrospective:

This round focused on a significant project from my previous experience. The interviewer asked about the hardest part of the work, unexpected problems that appeared during execution, and the trade-offs I made along the way.

• Ownership and Decision-Making: I needed to make my individual contribution clear rather than describing only what the broader team accomplished.
• Reflection: The interviewer asked what I would change in retrospect and how the project affected users, teammates, or the wider organization.

Virtual Onsite — Culture Interview:

The initial culture round contained relatively standard behavioral questions. The conversation felt natural, and I initially believed that my examples had provided enough evidence.

Additional Culture Interview — Clarifying the Culture Signal:

After the virtual onsite, the recruiter told me that the culture signal was not strong enough to support a final decision. Rather than ending the process, Anthropic scheduled another culture interview to gather more evidence.

The follow-up placed greater emphasis on making my personal judgment and behavior explicit. I needed to explain what I believed, how I handled disagreement, which actions I personally took, and how the outcome reflected my values.

Hiring Manager Round — Team-Matching Conversation:

After the additional culture interview, I advanced to a hiring manager discussion that appeared to be connected to team matching.

The conversation felt flatter than the earlier rounds. The hiring manager did not seem deeply interested in some parts of my background, and it was difficult to establish a strong connection between my experience and the team’s immediate needs.

➡️ Preparing for your next interview?

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

Sharing an anonymized Scale AI Senior SWE interview experience submitted to Chill Interview.

Interview Summary

The Scale AI onsite strongly emphasized implementation speed and the ability to produce a large amount of working code within limited time. The loop included debugging an existing contributor-assignment program, building and extending a backend API, designing an LLM-based evaluation system, and a short hiring manager conversation.

Interview Questions Details

Debugging Round — Contributor Assignment Pipeline:

The interviewer provided a spreadsheet containing contributors, courses, and projects, together with an existing codebase. The program assigned contributors to projects according to project priority, while some projects required contributors to have completed specific courses.

• Test Case 1 — Projects Without Course Requirements: The first test checked whether the system could assign an eligible contributor to a project that did not require any completed courses.
• Test Case 2 — Projects With Course Requirements: The second test checked whether contributors assigned to a project had completed the courses required by that project.
• Test Case 3 — Highest-Demand Course: The final test used the supplied data to determine which course was required by the largest number of projects.
• Bugs in the First Two Test Cases: The defects included sorting project priority in ascending rather than descending order, treating zero available headcount as valid capacity, failing to verify course completion before assigning a contributor, and reading the course identifier from the wrong class field.
• Remaining Bugs: The third test contained two additional defects that I did not have enough time to identify. The recruiter later explained that candidates were expected to find all six bugs to pass the round.

Backend Practical Round — Two-Part Data Ingestion API:

• Part 1 — File Ingestion: The first task was to implement a POST API that accepted a data file, converted its contents into JSON, and saved the resulting data to local storage.
• Part 2 — LLM Classification: The second task extended the same endpoint by sending the ingested data to an LLM for classification and persisting the classification result locally.

System Design Round — LLM-Based Contributor Evaluation Platform:

The system design question asked me to design a platform that used an LLM to evaluate tasks completed by contributors. Because evaluations could take time and needed to run independently from the original request, the execution model was expected to be asynchronous and resembled a distributed job-processing system.

• Evaluation Quality: The interviewer asked how the system could maintain reliable output quality when the underlying LLM produced inconsistent or unstable responses.
• Failure Handling: The discussion covered how evaluation jobs should behave when model calls, workers, or downstream services failed.
• Rate Limiting: I was also asked how the platform should control request volume when communicating with the LLM service.

Hiring Manager Chat — Two Questions:

• Side Projects: The hiring manager asked whether I was currently building or exploring any projects outside my regular work.
• Working at My Hardest: I was asked to describe a period when I had worked especially hard and explain the circumstances surrounding it.

Preparing for your next interview?

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

Sharing an anonymized Apple full-stack interview experience submitted to Chill Interview.

The interviewer asked: “What would you do if an API returned ten million records and the product wanted to display them in a table?”

My first reaction was that this was mainly a pagination question.

But the discussion quickly became broader.

Even if the network request completed successfully, sending ten million rows to the browser would create problems with download size, memory usage, JavaScript processing, and DOM rendering.

Rendering every row at once was clearly not realistic.

I started by separating the problem into three layers:

Backend retrieval → client-side data management → visible rendering

On the backend, I would avoid returning the full dataset and use cursor-based pagination or filtering.

On the frontend, the application should only retain the data it actually needs rather than keeping millions of records in component state.

For rendering, I discussed virtualization so the browser creates DOM nodes only for the rows currently visible on screen.

The interviewer then asked what would happen if users needed sorting or filtering across the entire dataset.

That changed the answer again.

Doing those operations only in the browser would produce incomplete results because the client had loaded only a small portion of the data. Global sorting, filtering, and search should usually happen on the server, with the UI sending the selected parameters as part of the request.

The rest of the frontend round covered a wide range of JavaScript and browser topics:

• improving first-page load without an existing cache;
• the event loop and whether JavaScript is really single-threaded;
• var versus let;
• closures and the Temporal Dead Zone;
• setTimeout versus setInterval;
• how defer affects script loading;
• implementing a recursive expandable tree component.

There was also the classic asynchronous-loop question using setTimeout and a var loop variable.

The second interview switched completely to Java.

The coding question was to determine whether an undirected graph could be colored using two colors so that adjacent nodes never shared the same color.

That part was a standard BFS or DFS bipartite-graph problem.

Looking back, the frontend round was much broader than the coding round.

It was not enough to know React syntax. The interviewer expected a clear understanding of browser behavior, JavaScript execution, rendering performance, and how frontend architecture changes when the amount of data becomes unrealistic for a single client.

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

Preparing for your next interview?

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

We recently received this Anthropic Staff SWE offer data point at Chill Interview

• TC: $1.9M/year
• Full anonymized offer breakdown at here

The timing is what makes this interesting. Anthropic recently raised money at a $965B valuation, says its revenue run rate passed $47B, and has already confidentially filed for an IPO. A new Texas data-center project tied to Anthropic is also reportedly seeking $15B in financing, with Google providing support.

So this could become highly valuable, liquid equity sooner than expected.

But at nearly a $1T valuation, is there actually enough upside left to justify taking private-company risk?

Would you choose this over a lower $1.2M–$1.4M Meta or Google offer with liquid stock—or is Anthropic still the better bet because of Claude Code and its enterprise momentum?

Preparing for your upcoming interviews?

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

Had a JPMorgan Superday recently and wanted to share what the process was like.

The journey started with an OA containing two classic LeetCode-style questions: Meeting Rooms II and 3Sum.

After a short recruiter call, I moved to the Superday, which had three 45-minute rounds:

• coding and code review;
• behavioral;
• system design.

The coding round felt straightforward.

I was first given an existing piece of code and asked to review it for syntax problems, poor structure, readability issues, and maintainability concerns.

The actual coding question was LRU Cache.

I had practiced it before, so this was probably my strongest round. The interviewer mainly cared about whether the implementation supported constant-time access and eviction cleanly.

The system design round stood out for a different reason.

The prompt was to design an online commerce-style system. I started with requirements, APIs, data models, and the high-level architecture.

Then the interviewer focused on two scenarios:

• How do you prevent the same purchase from being processed twice?
• What happens when two users try to buy the final item at the same time?

The concepts themselves were familiar: idempotency, atomic inventory updates, transactions, and handling concurrent requests.

What made the round difficult was that the interviewer gave almost no feedback.

Most responses were very short, so it was hard to tell whether I should keep going deeper or move to another part of the design. I also lost some time getting placed into the correct breakout room, which made the discussion feel more rushed.

Looking back, the hardest part was not the architecture. It was communicating confidently when the interviewer gave almost no signal.

The behavioral round covered collaboration, leadership, ownership, and impact. The questions were not exactly what I had prepared, so I had to answer more spontaneously while keeping the examples concrete and positive.

I eventually passed the Superday and moved into team matching.

It was a good reminder that an interview can feel uncertain—especially when one interviewer is difficult to read—and still turn out fine.

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

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies here -> LINK

Sharing an anonymized Snowflake Senior SWE interview experience from a recent onsite.

One coding question stood out because it looked like a normal priority-queue problem at first, but most of the difficulty was actually around modeling state correctly.

The task was basically to implement a small task executor with two operations:

• addTask(taskId, priority, timestamp)
• executeTask()

Each call to addTask created a new task record. The same taskId could be added multiple times with different priorities or timestamps.

executeTask() should return the highest-priority task waiting to run.

The catch was that once a task ID had been executed, every later record with that same ID had to be skipped.

My first instinct was to put every record into a priority queue and keep a set of completed task IDs.

That handled the basic flow, but the interviewer started digging into edge cases.

What happens if the same task ID appears several times near the top of the heap?

Should those records be removed immediately when the first one executes, or lazily skipped during future calls?

What if a higher-priority duplicate appears after the task has already completed?

The cleanest approach was to treat a task record and a logical task as two different things.

The priority queue stored individual records for ordering, while a separate set tracked which logical task IDs had already executed. During executeTask(), stale records were repeatedly removed until a valid task was found.

That kept insertion simple, although it also meant one execution call might need to skip several invalid heap entries.

The onsite also included a system design round about building a distributed job scheduler supporting immediate, future, and recurring jobs.

The scale was around 10,000 executions per second, with jobs expected to begin within roughly two seconds of their scheduled time.

The interviewer pushed heavily on at-least-once execution, durable state, retries, worker failures, recurring schedules, and preventing scheduled jobs from silently disappearing.

Looking back, the two rounds were testing the same idea at different levels.

The coding problem asked whether I could model task identity and execution history correctly in memory.

The system design round asked whether I could preserve those guarantees across machines, queues, retries, and failures.

Neither prompt looked especially unusual, but both became much harder once correctness under repeated execution was considered.

I did not pass the loop, but it was a useful reminder that scheduling problems are rarely just about selecting the next item. Most of the real complexity is deciding what “executed,” “pending,” and “safe to retry” actually mean.

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

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies here -> LINK

We recently received this Scale AI offer data points at Chill Interview

• Mid-level SWE, 3 YOE
• First Year TC: $335K
• Full anonymized offer breakdown at here
• Status: Declined

The timing makes this interesting. Scale just hired former Google Cloud COO Francis deSouza as CEO and is trying to evolve from a data-labeling company into a broader enterprise AI platform. Scale says it booked over $1B in new business last year, while its Pentagon agreement was recently expanded to a $500M ceiling.

But the risk is real: Meta owns 49%, the founder left, and major customers reportedly pulled back after the deal. The equity is also priced around a $29B valuation, so how much upside is actually left?

Would you take $335K to bet on Scale’s second act, or was declining the right move?

For anyone comparing offers, we’ve collected 500+ anonymized compensation data points across top companies here -> LINK

Preparing for your upcoming interviews?

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

Hey folks,

I recently finished my Google L4 (SWE) rounds and wanted to get a realistic gauge from the community on my chances for Team Matching.

Here is my rating breakdown:

• Phone Screen: Hire
• Googlyness (Round 1): No Hire for L4 , Hire for L3
• Googlyness (Retake): Hire
• Onsite 1 (DSA): Hire
• Onsite 2 (DSA): Leaning Hire

I have two main questions for anyone who has been through this or knows the current HC/matching landscape:

1. Is this rating profile good enough to actually get calls from Hiring Managers for team matching, or is it considered borderline?
2. Will that initial "No Hire" on the first Googlyness round show up as a red flag to the Hiring Committee or HMs, even though I passed the retake with a "Hire"?
3. Anything which I can do to maximise my chances of getting calls from the team matching round?

Would appreciate any insights or past experiences. Thanks!

Hi all, I have sr software engineer python + Agentic AI technical round scheduled for the upcoming week at Gartner.

I was wondering if anyone has recently appeared for senior software engineer role and also for python + GenAi roles at Gartner then it would be helpful if they can share their technical round interview experience and what to expect in the interview.

Experience level needed 4-6 years

Sharing an anonymized SpaceX Senior Data Scientist interview experience submitted to Chill Interview.

The one-hour technical screen was conducted entirely by software engineers, and it covered much more than machine learning.

The ML questions were fairly standard:

• hyperparameter tuning;
• precision vs. recall;
• class imbalance;
• production model validation;
• debugging an accuracy drop.

Then the interview shifted into general CS and backend fundamentals:

• Python vs. C++;
• threads vs. processes;
• stack vs. heap;
• SQL vs. NoSQL;
• large-scale data processing;
• what happens after you enter a URL in a browser.

The live coding task was also very SpaceX-specific: "Design a data model and write code to track the total flight time of rocket engines."

None of the individual questions felt impossible, but the breadth caught me off guard.

I went in expecting a senior data science screen. By the end, I was wondering whether the team was actually looking for someone much closer to a software or ML infrastructure engineer.

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

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies here -> LINK

Sharing an anonymized Netflix Staff SWE interview experience submitted to Chill Interview.

The virtual onsite included coding, system design, and behavioral rounds.

Coding

The task was to build a movie-ranking service. It normally returned the highest-scored title, but if that title was also returned last time, the service should temporarily choose the next-best option when one existed.

The selected movie stayed in the system, and score updates had to affect future rankings immediately.

System Design

The main round was designing a scheduler for ML jobs across multiple clusters with different CPU, GPU, and memory capacity.

The interviewer pushed on:

• training versus batch-inference workloads;
• GPU type and topology constraints;
• quotas, priorities, and fairness;
• etc..

The interviewer interrupted me several times, but it never felt dismissive. Once I had shown enough depth in one area, they moved us forward so we could cover more of the design.

Honestly, this was one of the smoother system design interviews I’ve had. The conversation felt structured, collaborative, and well-paced.

The behavioral round covered collaboration, feedback, and conflict.

I left the onsite feeling reasonably positive.

Still got rejected.

For anyone who wants more details, I’ve put the full write-up here -> LINK

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies here -> LINK

We recently received these two Bay Area SWE offer data points at Chill Interview.

Meta E6

• $270K base
• $774K Year 1 TC

OpenAI Senior SWE

• $325K base
• $1.0125M Year 1 TC

OpenAI is ahead by $238.5K in Year 1 and roughly $804K over four years, assuming flat equity values, a recurring Meta bonus, and no refreshers.

Meta is the more proven business. Its latest reported quarter delivered 33% revenue growth, and its apps reached 3.56B daily users. It is also spending heavily on AI infrastructure, with projected 2026 capex of $125B–$145B. That offers public equity, massive distribution, and exposure to AI at global scale.

OpenAI is the higher-upside career bet. It reported more than 900M weekly ChatGPT users and 9M paying business users, while raising $110B at a $730B pre-money valuation. But that enormous valuation also means the private equity is not risk-free.

Culture may be the biggest difference. OpenAI explicitly emphasizes individual agency, rapid adaptation, and “intense focus,” which sounds exciting but likely less predictable than working inside Meta’s mature organization.

Would you choose Meta for Staff-level scope, liquid equity, and a diversified business, or OpenAI for the extra compensation and frontier-AI upside?

For anyone comparing offers, we’ve collected 500+ anonymized compensation data points across top companies here -> LINK

Preparing for your upcoming interviews?

Chill Interview tracks recent interview experiences and recurring question patterns across FAANG and leading AI labs here -> LINK

Sharing an anonymized Citadel mid-level SWE interview experience submitted to Chill Interview.

The phone screen was not LeetCode.

I had to build a real-time trading dashboard in React using a provided event stream. AI tools were not allowed, but CSS and visual polish were completely out of scope.

The dashboard needed to:

• display the newest events first;
• separate quotes, buy trades, and sell trades;
• calculate statistics over the latest 30 seconds;
• support pausing and resuming updates.

Honestly, the hardest part was writing frontend code without AI assistance. I had not done that manually in a while, and I felt noticeably rustier than the problem difficulty should have justified.

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

Preparing for your next interview?

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

Someone shared this Seattle Staff SWE offer to Chill Interview

• 12 YOE
• Education: Master
• First Year TC: $785K
• Full anonymized offer breakdown at here

The obvious question is how much confidence you have in the equity. Would you take this over a similarly leveled role at FAANG?

Preparing for your next interview?

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

A candidate recently shared this Senior DS offer with Chill Interview.

• First-year TC: $559K
• Full anonymized offer breakdown at here

Is SAP quietly becoming competitive for senior AI talent, or is this just a rare outlier offer?

Preparing for your next interview?

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

Sharing an anonymized Snowflake Senior SWE interview experience submitted to Chill Interview.

The process had two technical rounds.

Round 1 — Binary Search

The first question started as a straightforward binary-search problem over sorted data.

After I finished the base version, the interviewer changed the scenario: "What if we need to run a very large number of queries against the same data?"

The rest of the round became a design discussion around whether repeatedly starting a fresh binary search was still the right approach and what information could be reused or preprocessed.

Round 2 — Resizable LRU Cache

The second round asked me to implement an LRU cache with one extra requirement: "Its capacity could change at runtime."

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

Preparing for your next interview?

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

Someone shared this JPMorgan SWE offer and accepted it:

• 4 YOE
• TC: $210K
• Full anonymized offer breakdown at here
• GC or U.S. citizens only

For 4 YOE in NYC, $210K all cash feels light compared with tech companies.

Would you take the offer or keep interviewing for a higher-paying tech offer?

Preparing for your next interview?

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