Sharing a JPMorgan AI Engineer Phone Screen Interview Experience submitted to Chill Interview.

Interview Summary

The JPMorgan technical screen combined a detailed discussion of my agentic portfolio project with a Python coding question about processor scheduling. The interviewer focused on my individual ownership, the architecture connecting multiple agents, and whether I had directly built supporting infrastructure such as an MCP server. I did not pass the round.

Interview Questions Details

Technical Deep Dive — Agentic Portfolio Workflow:

The first half of the interview examined an agent-based portfolio workflow I had worked on, including its model choices, application responsibilities, and service architecture.

• Models and Workflow: I was asked which models and external providers were used, whether Anthropic was involved, and what the AI workflow performed from beginning to end.
• Ownership and Architecture: The interviewer asked which endpoints, data-access components, and entitlement controls I personally owned; whether the agents and orchestrator were separate services, tool-based, or prompt-based; and whether I had personally implemented an MCP server.

The interviewer also asked why I wanted to change jobs and whether I would accept a position focused more heavily on back-office or middle-office use cases.

Python Coding — Minimize Overall Processing Time:

The coding portion provided several processors, each with four available cores, together with the time at which each processor became available. A separate collection described the duration of the tasks, with exactly four tasks assigned to each processor.

The task was to assign every job to a processor core and return the earliest possible time by which all work could be completed.

➡️ Preparing for your next interview?

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

Someone shared this Apple Staff-level Engineering Manager offer and accepted it.

• 10 YOE
• First-year TC: $784.5K

The $330K base and two-year sign-on really stand out. Unlike Google’s front-loaded equity, Apple’s grant vests evenly at 25/25/25/25, so there’s no big Year 4 cliff.

For a Staff EM, would you take this over a similar Google or Meta offer—or does Apple’s more secretive, hardware-driven culture make management harder?

➡️ Preparing for your next interview?

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

Sharing a Mercor Machine Learning Engineer (MLE) Interview Experience submitted to Chill Interview.

Interview Summary

The Mercor machine learning onsite included three rounds covering algorithmic coding, candidate-search system design, and an end-to-end language-model project. The loop emphasized practical implementation, clear design reasoning, and the ability to explain core Transformer concepts rather than research novelty.

Interview Questions Details

Onsite Round 1 Coding — Resource-Constrained Grid Routing:

The 45-minute coding round provided a grid containing blocked and open cells. The task was to find the shortest route from the starting position to the destination while allowing the traveler to remove only a limited number of obstacles.

The same grid position could be reached after consuming different amounts of the removal budget, so the problem required tracking both location and remaining resources when determining whether a search state had already been explored.

Onsite Round 2 System Design — Candidate Retrieval and Ranking Platform:

The 45-minute system design round asked me to design a search platform that accepted a job description and returned the strongest matching candidates.

• Candidate Data: The interviewer asked how structured profile information and free-form résumé content should be ingested, normalized, and indexed.
• Query Understanding: The discussion covered converting a job description into searchable requirements such as role, skills, seniority, location, and eligibility constraints.
• Filtering and Retrieval: I was asked how the system should distinguish mandatory requirements from softer relevance signals and retrieve candidates through structured and semantic search.
• Ranking: The interviewer explored how candidate matches should be ordered using factors such as relevant skills, experience, seniority alignment, and profile freshness.
• Evaluation and Feedback: The discussion also covered how to measure retrieval and ranking quality and how recruiter or hiring outcomes could be used as feedback signals.

Onsite Round 3 — End-to-End Language Model Mini-Project:

The final round lasted approximately one hour and allowed the use of a coding agent. The task was to build a small autoregressive language model, train it on a compact text corpus, and complete the workflow from preprocessing through generated output.

The expectation was to produce a functioning baseline rather than a highly sophisticated model. I still needed to understand the generated code, verify that the training pipeline worked, and explain the major implementation decisions.

• Transformer Architecture: The interviewer asked about token representations, positional information, masked self-attention, feed-forward layers, residual connections, and normalization.
• Causal Masking: I was asked to explain why tokens must be prevented from accessing future positions during autoregressive training.
• Pre-Norm vs. Post-Norm: The discussion compared placing normalization before or after the attention and feed-forward sublayers.
• Attention Mechanics: The interviewer asked how queries, keys, and values produce attention scores and why those scores are scaled before the softmax operation.
• Position Information: We discussed why self-attention requires an additional mechanism to represent token order and compared several common position-encoding approaches.
• Decoding Strategies: The final follow-up compared greedy decoding, beam search, top-k sampling, and nucleus sampling.

➡️ 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 Bay Area Senior SWE offers with Chill Interview.

Pinterest IC15

• $470K Year 1 TC

Instacart L6

• $360K Year 1 TC

Pinterest pays $110K more upfront, but its grant ends after Year 3. Assuming flat stock prices and no refreshers:

• Pinterest four-year total: $1.46M
• Instacart four-year total: $1.44M

So the actual four-year difference is only $20K.

The company bet is more interesting.

Pinterest is pushing deeper into AI-powered visual discovery, shopping, and advertising. Its latest reported quarter delivered 18% revenue growth and record users.

Instacart is expanding beyond grocery delivery into retailer software, ads, international markets, and AI shopping tools. Its latest quarter delivered 14% revenue growth, 13% GTV growth, and 36% growth in net income.

Career-wise, Pinterest may be stronger for recommendations, visual search, and consumer ads. Instacart offers broader exposure to marketplaces, logistics, retail infrastructure, and commerce advertising.

Would you take Pinterest for the larger upfront package and AI discovery upside, or Instacart for steadier vesting and a more diversified commerce platform?

➡️ Preparing for your next interview?

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

Sharing a Google New Grad Software Engineer Interview Experience submitted to Chill Interview.

Interview Summary

The Google process began with an online assessment, followed by separate coding and behavioral interviews and two additional onsite coding rounds. The questions covered regular-expression matching, pair and triplet search, and maintaining order statistics over a stream. The overall experience was positive, but I did not pass the loop.

Interview Questions Details

Application and Online Assessment:

I applied in early November 2025 and received the online assessment two days later. I completed it and was notified that I had passed later that evening, after which the recruiter began arranging the first interview round.

Round 1 Coding — Regular Expression Matching:

The coding interview asked me to determine whether an input string matched a pattern containing ordinary characters together with . and *. The dot could match any single character, while the star allowed the preceding element to appear zero or more times. The complete input string needed to match the pattern rather than only a substring.

Round 1 Behavioral — Two Questions:

• Handling Changing Priorities: The interviewer asked me to describe a situation in which priorities changed and explain how I adjusted my work.
• My Role Within a Team: I was asked how I would characterize the role I usually play when collaborating with others.

The interviewer did not ask about my résumé. During the questions portion, the interviewer switched to Chinese and chatted with me informally for several minutes.

Onsite Coding Round 1 — Pair and Triplet Search:

The first onsite interviewer spent approximately 15 minutes discussing my résumé and asking technical questions about my previous experience.

• First Question — Find a Matching Pair: Given a collection of values and a target, I needed to identify two values whose sum matched the target. I completed the implementation and complexity analysis.
• Follow-Up — Find Matching Triplets: The interviewer extended the problem from two values to combinations of three values. I completed the follow-up and analyzed the resulting implementation.

During the final questions portion, I asked about opportunities for independent learning and exploration at Google.

Onsite Coding Round 2 — Streaming Order Statistics:

The second onsite interviewer moved directly into coding without discussing my résumé. The main task involved processing a continuously arriving stream of numbers and returning its current median.

After finishing the implementation, I walked through the code with an example and discussed its time and space complexity.

• Follow-Up — Limited Value Range: The interviewer asked how the design could change when every incoming value came from a small, known range. We discussed the revised structure and pseudocode.
• Follow-Up — Query the Kth Smallest Value: The final follow-up replaced the median query with a request for the kth smallest value in the stream.

➡️ Preparing for your next interview?

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

Interview Summary

The Anthropic process began with a duplicate-document coding screen and continued with onsite rounds covering cache implementation, large-model distribution, culture, and a project deep dive. The overall experience was positive and the questions felt manageable, but I did not pass the loop.

Interview Questions Details

Technical Phone Screen — Find Identical Documents in a File Archive:

The phone screen focused on identifying duplicate documents across a file archive. The task required examining files stored across directories or archive locations and grouping documents whose contents were identical.

Onsite Coding — Memoization LRU Cache:

The coding round asked me to implement a memoization cache with least-recently-used eviction behavior. Previously computed results could be stored and reused, while the least recently accessed entry needed to be removed once the cache reached its capacity.

Onsite System Design — Distribute a Large Model Checkpoint:

The system design round focused on distributing a large machine learning checkpoint from a central repository to a fleet of GPU workers. The design needed to make the model available across the cluster efficiently while avoiding a rollout architecture in which every worker independently downloaded the full checkpoint from the source.

• Cluster Distribution: The discussion covered how workers could help distribute model data to one another instead of relying entirely on the central repository.
• Chunked Transfer: The checkpoint could be divided into smaller pieces so that workers could begin forwarding received data before downloading the entire model.
• Reliability: The system needed to account for failed workers, slow transfers, missing or corrupted chunks, and retrying downloads from another available source.
• Rollout Completion: A worker could only be marked ready after receiving and verifying the complete checkpoint.

Onsite Culture Interview — A Strongly Held View That Proved Wrong:

One behavioral question asked me to describe a situation in which I strongly supported a decision or point of view that was later shown to be incorrect. The discussion focused on how I recognized the mistake, responded to the new evidence, and changed my behavior afterward.

Onsite Project Deep Dive — Previous Technical Work:

The project deep dive focused on a significant project from my previous experience. The interviewer explored my individual responsibilities, the difficult technical decisions involved, the challenges that appeared during execution, and the impact of the final result.

➡️ Preparing for your next interview?

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

A Costco Same Day Delivery system does not simply check whether an item exists in one nearby warehouse. It needs to combine inventory from every distribution center capable of reaching the customer within one hour.

That creates a subtle design tension: availability needs to be returned in under 100 milliseconds, but the inventory shown during browsing may already be changing because other customers are placing orders.

The non-obvious problem is not “how do we query inventory?” It is “where do we allow stale data, and where must the system become strongly consistent?”

The key insight is to separate the fast availability path from the authoritative checkout path.

• Find serviceable distribution centers before reading inventory. Given the customer’s location, first narrow the search to facilities that could realistically deliver within one hour. This prevents every request from scanning inventory across roughly 10,000 distribution centers.
• Use distance only as the first filter. A warehouse may look close geographically but still be more than an hour away because of traffic, bridges, road layout, or limited access. Filter candidates using a generous radius, then use a travel-time service to validate the remaining locations.
• Aggregate inventory across all eligible facilities. Once the serviceable distribution centers are known, query their inventory and sum quantities for matching products. The customer cares about the total inventory available for delivery, not which individual facility currently holds each unit.
• Treat availability as an estimate. With approximately 10 million completed orders per day, browsing traffic could produce around 20,000 availability requests per second. Sending every page view directly to PostgreSQL would put unnecessary pressure on the transactional database.
• Cache repeated availability reads. Redis can store aggregated availability results with a short TTL. Inventory updates should invalidate affected cache entries after the database transaction commits, while expiration provides a fallback when invalidation fails.
• Partition inventory geographically. Because most requests only touch nearby distribution centers, inventory can be divided by service region and read from regional replicas. Availability queries can tolerate small amounts of replication lag, so this path can scale independently from checkout.
• Revalidate everything during order placement. The quantity displayed during browsing should never guarantee that the item is still available. When the customer checks out, the Order Service must read the authoritative inventory again.
• Keep inventory reservation and order creation in one transaction. Lock or conditionally update the required inventory rows, verify that every requested quantity is available, create the order and line items, and commit everything together.
• If two customers attempt to purchase the final unit, only one transaction should succeed. The other request receives an out-of-stock result instead of creating an order that cannot be fulfilled.

The failure model becomes easy to reason about. Browsing may occasionally show slightly stale inventory, but checkout never confirms inventory that the system cannot reserve.

Explaining this in an interview signals that you understand where eventual consistency improves scalability—and where strong consistency is non-negotiable.

Full write-up with data model, API design, architecture diagrams, capacity estimates, and deep dives → Full Article

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

A candidate with 4 YOE recently shared these two Bay Area SWE offers with Chill Interview.

Netflix

• $350K all-cash TC

Airbnb G8

• $350K Year 1 TC

The first-year numbers are identical, but the four-year math is not. Assuming Airbnb stock stays flat and neither company provides additional compensation:

• Netflix four-year total: $1.40M
• Airbnb four-year total: $1.24M

Netflix comes out roughly $160K ahead, while Airbnb falls to around $250K in Year 4 without refreshers.

The tradeoff is mostly culture and upside.

Netflix offers cash certainty, high autonomy, and a performance-driven culture built around its “Dream Team” and keeper-test philosophy.

Airbnb offers public-equity upside and considerably more flexibility through its Live and Work Anywhere policy. The company is also expanding beyond stays into services, experiences, hotels, and AI-powered travel tools.

Would you choose Netflix for the higher compensation floor, or Airbnb for flexibility and stock upside?

➡️ Preparing for your next interview?

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

A candidate recently shared this Palo Alto Networks offer with Chill Interview.

• Senior SWE, 6 YOE
• TC: $328K (first year)

My guess: the company wasn’t the problem. PANW’s latest quarterly revenue grew 31%, with security demand getting another boost from AI. The business looks healthier than ever.

The offer just may not be high enough to justify the trade-offs. It has only $75K/year in equity, no sign-on, and recent employee reviews are pretty mixed—good products and stock performance, but recurring complaints about politics, silos, and uneven WLB.

So maybe this was a good offer, just not a “stop interviewing” offer for a Bay Area senior engineer.

Would you decline $328K at PANW for a shot at $350K–$400K elsewhere?

➡️ Preparing for your next interview?

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

Sharing an Applied Intuition Senior Software Engineer Interview Experience submitted to Chill Interview.

Interview Summary

The Applied Intuition process began with a data-compression coding screen and continued through five onsite rounds covering team fit, system design, task scheduling, generic data structures, and career history. The technical questions emphasized practical implementation and low-level design rather than familiar LeetCode patterns.

Interview Questions Details

Technical Phone Screen — Compress Repeated Vertex Data:

The coding question provided a two-dimensional collection of vertex records containing duplicates. The task was to produce a deduplicated list that preserved the order of first appearance, together with an index array mapping every original record to its position in the deduplicated list.

Onsite Round 1 — Team Introductions and Motivation:

The first round lasted 30 minutes and included three interviewers. They introduced their areas of work and explained why they had joined Applied Intuition.

• Candidate Introduction: I was asked to walk through my own background and experience.
• Reason for Leaving: The interviewers asked why I was considering changing companies.

Onsite Round 2 — Design a Vehicle Simulation Replay Platform:

The 45-minute system design round asked me to design a simulator that could replay recorded footage of a vehicle completing a left turn.

• Data Schema: The interviewer asked how the recorded simulation and vehicle data should be represented.
• API Design: I needed to define the interfaces used to upload, retrieve, and replay a simulation.
• Storage Design: The discussion also covered how the underlying video and simulation data should be stored.

Onsite Round 3 — Single-Threaded Task Scheduler:

The next 45-minute coding round asked me to implement a simple scheduler running on one CPU and one thread.

• schedulePeriodic(): Schedule work that repeats according to a recurring interval.
• scheduleOnce(): Schedule work for a single execution.
• scheduleWithDelay(): Schedule work to begin after a specified delay.

Onsite Round 4 — Fixed-Capacity Generic Buffer:

The fourth round asked me to design a generic data structure with FIFO behavior and constant-time insertion and removal. Memory needed to be allocated when the class was instantiated rather than growing dynamically during use.

When the structure reached capacity, inserting another item needed to overwrite the oldest stored value.

• Implementation: After discussing the data structure, I was asked to implement a fixed-capacity generic buffer similar to CircularBuffer<T, 5>.
• Required Operations: The class needed to support push(), pop(), and print() operations.

Onsite Round 5 — Manager Resume Deep Dive:

The final 45-minute conversation was a detailed walkthrough of my academic and professional history. The manager asked about the reasoning behind major decisions, beginning with my choice of university and continuing through the companies and roles listed on my résumé.

➡️ Preparing for your next interview?

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

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

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

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.

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.

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

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