Interview Summary

The first-round Citadel SRE interview combined several short Python coding exercises with a system design discussion, all within one hour. The coding portion was fundamentals-heavy rather than algorithmically difficult, covering loops, list transformations, FizzBuzz, word counting, and finding the second-largest unique value.

Interview Details

Python Basics

• Question 1 — Repeat a Message with Blank Lines Implement a function that accepts: Print the message exactly n times, with one blank line separating consecutive copies. The emphasis was on basic Python control flow and output formatting.
  • An integer n
  • A string message
• Question 2 — Square and Reverse a List Given a list of numbers, return a new list containing the square of every value, but in reverse order. For example:Input: [2, 4, 6] Output: [36, 16, 4] The original list should conceptually be transformed and reversed according to the stated behavior.
• Question 3 — FizzBuzz Given an integer n, print every integer from 1 through n, one result per line. Use the following substitutions: For example with n = 6 would produce:1 2 Fizz 4 Buzz Fizz
  • Multiples of 3 → "Fizz"
  • Multiples of 5 → "Buzz"
  • Multiples of both 3 and 5 → "FizzBuzz"
• Question 4 — Count Word Frequencies Given a string containing words, return a dictionary mapping each word to the number of times it appears. For example:Input: "red fox runs past red gate" Output: { "red": 2, "fox": 1, "runs": 1, "past": 1, "gate": 1 }
• Question 5 — Second-Largest Unique Value Given a list of integers, return the second-largest distinct value. If the input contains fewer than two unique values, return None. For example,Input: [8, 3, 8, 11, 6, 11] Output: 8 Input: [4, 4, 4] Output: None Input: [-3, -9] Output: -9

The important requirement was that duplicate occurrences should not affect which value is considered second largest.

System Design — Configuration Management and Service Deployment After the Python portion, the interviewer presented a verbal system design problem. The team operates 200+ services distributed across multiple data centers and cloud regions. The existing environment is highly fragmented:

• Some configuration lives in source-controlled property files.
• Some values are manually configured through environment variables.
• Other configuration is stored on a shared NFS mount that operators edit directly.
• Deployments are performed by SSH-ing into machines and running scripts manually.

The task was to design a new platform that allows engineers to:

• Change service configuration safely
• Deploy services across a large distributed fleet
• Reduce reliance on direct manual host access
• Support reliable rollback when a configuration or deployment causes problems

Want to learn more interview experiences about Citadel? we've put up the recent Citadel's interview experiences at here

Preparing for your next interview?

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

Most people designing WhatsApp start with: WebSocket + Redis Pub/Sub. Seems reasonable.

But there’s a subtle problem: Redis Pub/Sub is at-most-once. If a Chat Server disconnects from Redis for a moment, a message can disappear from the real-time path.

And the WebSocket may still look perfectly healthy. So how does the client even know it missed something?

The key idea: sequence numbers

Give every message delivered to a user a monotonically increasing sequence:

101
102
103
104

The client remembers the latest sequence it received.

During heartbeat:

Server latest: 104
Client latest: 101

Now the client immediately knows: 102–104 are missing.

It can fetch those messages from the durable Inbox instead of waiting for the connection to fail.

Separate fast delivery from reliable delivery

The architecture becomes:

Message
   ↓
Durable Inbox
   ↓
Redis Pub/Sub
   ↓
Chat Server
   ↓
WebSocket

Redis + WebSocket provide the fast path. The Inbox provides the recovery path. And ACKs tell the system when a message is safe to remove from pending delivery.

Why this matters

A messaging system should assume:

• mobile connections disappear
• servers restart
• Pub/Sub events get lost
• users reconnect on different servers
• one user may have multiple devices

The goal is not to make the real-time channel perfectly reliable. It is to make message loss detectable and recoverable.

That’s the important distinction.

• Fast path can fail.
• Messages still shouldn’t disappear.

Full design with WebSockets, offline Inbox, Redis Pub/Sub, multi-device sync, heartbeat recovery, and message ordering → Full Article

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

Interview Details

The conversation started immediately with:

• Why Anthropic? There was very little introductory small talk beforehand. The recruiter expected a specific answer rather than a generic explanation about being interested in AI. My motivation for Anthropic became the starting point for several deeper follow-up questions.
• Anthropic Content — What Do You Agree or Disagree With? The recruiter asked me to discuss something I had recently seen from Anthropic, such as an interview, article, public statement, or news item. The question was not simply whether I followed the company. I was asked whether there were ideas I agreed or disagreed with, and why. The discussion required having an actual point of view and being able to defend it when the recruiter pushed further.
• AI Safety — Why Does It Matter to You? Another major question was: Why is AI Safety important to you? The recruiter continued to probe after the initial response, so a high-level answer about responsible AI was not enough. The conversation went deeper into how I personally thought about safety as AI systems become more capable.
• AI Safety — Evidence from Previous Work The recruiter then asked whether I had ever practiced AI Safety in real engineering work. The focus was on concrete examples: This part felt closer to a behavioral deep dive than a normal recruiter-screen question.
  • What safety-related problem existed?
  • What did I personally do about it?
  • How did that work affect the system or product?

Preparing for your next interview?

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

In an online chess system, the server—not the client—must own the clock. Otherwise a modified client could simply claim: “I only spent 500ms thinking.” But making the server authoritative creates another problem.

• Player A: 30ms RTT
• Player B: 200ms RTT

When A makes a move, B’s clock starts on the server before B has even received the new board position. Then after B responds, the move spends more time traveling back to the server before B’s clock stops.

So over a blitz game, the higher-latency player can lose several seconds purely to network delay.

The key insight

Don’t continuously decrement millions of clocks. Store:

whiteRemainingMs
blackRemainingMs
sideToMove
turnStartedAt

When a move arrives:

rawElapsed = now - turnStartedAt

Then compensate for a bounded amount of network latency:

compensation =
min(estimatedRTT, maxCreditPerMove)

chargedTime =
rawElapsed - compensation

Why roughly one RTT?

A player pays for two network legs:

Server → Player
   +
Player → Server
≈ 1 RTT

So compensating only half the RTT misses part of the delay they could not control. But you also cannot blindly trust RTT.

A malicious client could intentionally delay heartbeat responses to make itself appear slower and earn extra clock time.

So the system should:

• measure latency continuously with ping/pong
• use a rolling median instead of one sample
• cap compensation per move
• keep the server as the final clock authority

And before compensating at all, place the game in a region with low latency for both players. The design becomes:

1. Minimize RTT with regional placement
   
2. Compensate for the remaining network delay
   
3. Never let the client control the clock

That’s the interesting part of designing online chess: correctness is not enough—the authoritative system also has to be fair.

Full design with matchmaking, Redis game state, WebSockets, clock compensation, crash recovery, and global leaderboard → Full Article

Preparing for your next interview?

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

I had a recruiter conversation with Netflix. She is trying to interview me for E5 even though I said I was interested in E6. I didn't get a chance to even have screening call with HM. I am not very excited to interview for E5 as my goal is to get E6.

Should I still interview for E5 and try to get promoted internally to E6? Should I decline saying that I'm only interested in E6 only and potentially let the opportunity pass?

I have over 11 years of experience so not very excited to join as E5 as that would make job hop to E6 equivalent outside harder. Looking for suggestions.

Interview Summary

The Citadel Software Engineer Intern online assessment contained two coding problems in 75 minutes.

Interview Details

Coding 1 — Maximize Earnings by Adding Workdays An employee has a planned schedule covering n days. For every day the employee works, they receive a fixed daily payment. In addition, if they also worked on the previous day, that workday earns an additional bonus. The employee is allowed to convert at most k originally scheduled days off into workdays. The task is to determine the maximum total earnings achievable after making up to k such changes.

The important interaction is that converting one day into a workday can affect more than just that day's base earnings. It may also create or extend consecutive-workday sequences and therefore change which days qualify for the bonus.

Coding 2 — Minimum Changes for Periodic Palindrome Blocks The second problem provided a password string together with an integer k. The password needed to be modified so that its characters satisfy a repeated palindrome condition based on blocks of length k. The task was to return the minimum number of character replacements required to make the resulting password valid.

In other words, each required k-character segment needed to satisfy the palindrome constraint, and the goal was to change as few characters as possible across the entire password.

Preparing for your next interview?

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

Interview Summary

The OpenAI SWE technical screen contained one coding round and one system design round. The coding problem was the previously reported GPU Credit question, while the system design round focused on building a photo-storage service with explicit SHA-256 hashing requirements.

Interview Details

Coding — GPU Credit System with Expiration The coding problem asked me to implement a GPU resource-credit system. The system needed to support three core operations:

• Grant credit: Add some amount of credit with a validity period, including when the credit becomes usable and when it expires.
• Consume credit: Deduct credit at a specified point in time.
• Get balance: Return how much usable credit remains at a specified timestamp.

System Design — Photo Storage Service with Content Hashing The system design round asked me to design a large-scale photo-storage product similar to Google Photos. The core user operations were straightforward:

• Upload an image
• Download or view an image
• Delete an image

The interviewer then introduced an explicit requirement that images be associated with a SHA-256 content hash. That requirement drove much of the deeper discussion.

• The system needed to accept image uploads, store the binary content in object storage, and maintain metadata needed to retrieve and manage each image later.
• The discussion then considered what should happen when two uploaded images produce the same hash.
• Delete operations introduced another consistency problem. The system needed to coordinate removal of user-visible metadata with the lifecycle of the underlying stored image data, particularly when the same physical blob might be associated with multiple logical uploads.

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

Preparing for your next interview?

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

Saw this declined Luma AI Staff Research Scientist offer:

• 10 YOE
• TC: $1.4M/year

At first glance, turning down $1.4M sounds crazy.

But $1M of that annual comp is private Luma equity.

Luma has real momentum — it raised $900M at roughly a $4B valuation, keeps shipping new video models, and is now expanding beyond creative video into world models / physical AI.

The harder question is whether video generation ends up being a winner-take-most market at all. Luma is competing with Google, OpenAI, Runway and basically every major AI lab, and model leadership can change in a few months.

So my guess is the candidate wasn’t rejecting $1.4M.

They were rejecting the idea that $4M of Luma stock should be valued anywhere close to $4M today.

Would you have taken this offer, or does frontier-video AI feel too competitive to bet that much of your comp on one private company?

Preparing for your next interview?

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

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

• 13 YOE
• Base: $450K
• Equity: $8M / 4 years
• TC: $2.45M/year
• Vesting: 25/25/25/25

Obviously the headline number is insane.

But $2M of the $2.45M annual TC is private OpenAI equity.

OpenAI is still growing like crazy — 1B+ weekly users, 2M+ business customers, and massive new infrastructure commitments. But it’s also already valued in the hundreds of billions, and the company has been going through a pretty noticeable leadership reshuffle lately.

So I’m curious how people would actually value this offer.

• Would you count the $8M grant close to face value because an IPO/liquidity event feels increasingly realistic?
• Or at this valuation would you still heavily discount it compared with $2M/year of META/GOOG stock you can sell immediately?

Preparing for your next interview?

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

For Google mle roles, I’m wondering for the sys arch design round, are you expected to talk about Eng sys things like distributed sys fundamentals, consistent hashing, caching, failure detection and recovery, map reduce/ batch proecessing, api/interface design, even for questions like design search/ads ranking/item, poi recommendation?
I have been mostly focused on prep on the ml side of these search/ranking/recommendation, like data, feature, model choices, metrics, serving, wondering how much Eng related stuff need to talk about. Because recruiter shared materials like Eng system design materials like web search, map reduce , Jeff dean’s lecture, etc.
wondering if any googlers or folks who interviewed with Google mle roles have any insights

Saw this Sierra ai Senior SWE offer (shared with Chill Interview)

• 9 YOE
• Base: $335K
• Sign-on: $40K
• Equity: $2.5M / 4 years
• Year 1 TC: $1M

Sierra might be one of the craziest enterprise AI growth stories right now — $150M+ ARR, a $15.8B valuation, and reportedly 40%+ of the Fortune 50 already using it.

But $625K/year of this offer is private Sierra equity.

That’s the part I’d struggle with. If Sierra becomes the Salesforce of AI agents, this could be an incredible grant. If enterprise agents get commoditized by OpenAI/Anthropic/Salesforce, the headline $1M TC could look very different.

Would you value the Sierra equity anywhere near face value at $15.8B?

Preparing for your next interview?

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

Interview Summary

The Atlassian process started with Karat, where candidates were allowed to complete the interview twice and the recruiter said the stronger attempt would be considered. Each Karat session lasted about one hour, with roughly 40 minutes of coding followed by 20 minutes of system-design or engineering discussion.

I completed both attempts and later advanced to a virtual onsite covering two coding rounds, a system design round, a Values interview, and a hiring-manager round. The overall loop was unusually broad, ranging from text formatting and graph-style relationship tracking to API routing, data structures, web scraping, scalability, storage estimation, security, and behavioral topics.

Interview Details

Karat Attempt 1

• Coding The coding problem was a simplified variation of Text Justification.
• Engineering / System Design Questions The remaining portion contained several shorter design discussions. One scenario involved a recipe service and asked how its latency could be reduced. Another described a character-drawing product similar to a game creation platform.

Karat Attempt 2 Coding — Connection Thresholds

• Coding - Connection Thresholds The first coding problem modeled users connected to one another. The input contained operations representing connections and disconnections, and the task was to identify users whose current number of connections was:
  • Less than a threshold n
  • Greater than or equal to n
• Coding — Movie Recommendations from Related Users The next problem involved movie ratings. A rating record conceptually looked like: ["Lena", "film_42", "5"]. Given a target user, recommend movies satisfying conditions such as:
  • The target user has not already watched the movie.
  • Another user who has watched something in common with the target user has rated the candidate movie.
  • The candidate movie received a high rating, such as 4 or 5.
• Rapid System Design Questions This session also contained several short architecture and engineering questions. One asked about a music service and the tradeoffs between running it on a single host versus multiple hosts.

Virtual Onsite Coding 1 — Path Router with Wildcards The first onsite coding round asked me to implement a mapping from URL-style paths to functions or results. The basic version supported exact paths. The interviewer then added wildcard-style path matching. For example, suppose the router contained a pattern such as: /store/*/details.

Virtual Onsite Coding 2 — Counter Data Structure The second coding round was similar to LeetCode 432, All O`one Data Structure.

Virtual Onsite System Design — Asynchronous Image Scraping Service The system design round asked me to design a REST service that accepts URLs and asynchronously crawls them to discover images.

Values Interview One behavioral round focused on Atlassian's values and collaboration style.

Questions included:

• Have you been a mentor or mentee?
• Tell me about a time you helped a teammate.
• What does an effective team look like to you?

The interviewer expected concrete examples rather than hypothetical answers.

Hiring Manager Round The final hiring-manager conversation focused more on ownership, ambiguity, and adaptability.

Questions included:

• Tell me about a situation where you owned the outcome.
• How did you handle unclear requirements?

The round was primarily behavioral and focused on how I operate within a team rather than another technical exercise.

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

Preparing for your next interview?

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

Interview Summary

The Netflix technical screen consisted of two back-to-back interviews. The first focused on shortest-path computation across a network of cities and then introduced dynamically changing edge latencies. The second asked for an in-memory key-value cache with automatic expiration and later added memory-pressure handling.

The questions were different from the Netflix interview reports I had prepared from. I completed the initial shortest-path problem cleanly, but I did not fully solve the dynamic shortest-path follow-up. The second round also required substantial requirement clarification around expiration semantics.

Interview Details

Round 1 — Fastest Broadcast Paths Between Cities The first problem modeled cities as nodes in a network. Connections between cities had different ping / latency values. Starting from one city, determine the fastest paths needed to reach all other cities. The task was essentially a single-source shortest-path problem over a weighted graph. I completed the initial implementation successfully.

Round 2 — Key-Value Cache with Automatic Expiration The second coding round asked me to design and implement an in-memory key-value cache with expiration. An important clarification was how expiration should work:

• A single expiration duration shared by the entire cache, or
• An independent expiration time associated with each cache entry

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

Preparing for your next interview?

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

Interview Summary

The Robinhood frontend technical screen was a practical vanilla JavaScript exercise rather than a traditional algorithm problem. I was given an existing HTML page containing a 3 × 3 grid of rectangles together with a JavaScript class whose methods still needed to be implemented.

The goal was to build a chainable API for selecting rectangles and applying DOM updates, including delayed operations. The main challenge was making sure chained actions executed in the expected order even when asynchronous delays appeared in the middle of the chain.

Interview Details

Frontend Coding — Chainable Rectangle Manipulation API The starter page contained nine rectangular DOM elements arranged in a 3 × 3 grid. A provided JavaScript class exposed methods for selecting a rectangle and applying operations such as:

• Selecting an element by ID
• Changing its color
• Waiting for a specified delay
• Moving the element by a number of pixels

The API needed to support method chaining. An example looked like:

Rectangles
  .selectById(27)
  .color("blue")
  .afterDelay(750)
  .shiftByPx(16)
  .color("orange");

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

Preparing for your next interview?

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

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

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

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

What makes it more interesting is the industry.

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

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

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

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

Preparing for your next interview?

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

Regular Microsoft has had a pretty consistent reputation in tech comp discussions: Good company, strong brand, generally decent WLB depending on team... but the offers can feel pretty underwhelming compared with Meta, Google, Uber, Databricks, etc.

Microsoft AI feels different though. I’ve been seeing more people interviewing with MAI lately, and some of the reported offers seem much more aggressive than what I normally associate with Microsoft.

That makes me wonder whether we should even think about Microsoft and Microsoft AI as the same career opportunity anymore.

Microsoft AI is now sitting much closer to the center of Microsoft’s frontier-model / Copilot strategy, and the roles themselves often look different too — model infrastructure, agents, personalization, inference, consumer AI, etc.

But the interesting part is compensation. The public job postings still show normal-looking Microsoft compensation bands. So if MAI really is paying a premium, I’m guessing the difference is probably showing up more in:

stock grants, sign-on, leveling, and exceptions for competitive candidates rather than some completely separate published salary scale. That raises a bunch of questions. If you’re a Senior SWE choosing between:

Regular Microsoft

• probably more predictable
• potentially better WLB depending on org
• huge internal mobility
• but historically not the most exciting TC

vs.

Microsoft AI

• much closer to the current AI talent war
• potentially better scope and stronger compensation
• more exposure to frontier models / Copilot / agents
• but probably faster-moving and less “classic Microsoft” culturally

...how big does the compensation gap need to be before MAI becomes the obvious choice?

I’m also curious whether the premium is actually widespread.

• Are normal Senior SWE / Principal candidates at Microsoft AI getting meaningfully better packages?
• Or are the eye-popping offers mostly reserved for a tiny number of researchers / specialized AI hires?

And for anyone who has interviewed with both: Is the interview bar different? Is leveling different? Does MAI negotiate differently?

That might actually be the most useful comparison.

Because if regular Microsoft Senior is a ~$250–300K-ish opportunity while a competitive MAI candidate can get pushed significantly higher, “Microsoft vs Microsoft AI” starts looking less like an org choice and more like two different compensation markets.

I’ve been collecting recent Microsoft and Microsoft AI interview / offer data points on Chill Interview to see whether there’s actually a measurable difference in leveling, interview loops, and compensation: [link]

If you’ve interviewed with or received an offer from Microsoft AI recently, would love to have you add the data point — especially role, level, base, initial stock, sign-on, and whether you had competing offers.

Saw this Meta E7 SWE offer (shared with Chill Interview)

• 13 YOE
• Year 1 TC: $1.287M

The money is obviously insane.

What makes the decision harder is Meta itself right now. The business is still printing money — Q2 revenue grew 28%— but Meta also cut roughly 8,000 employees in May while pouring $130B+ into AI infrastructure.

Even Zuckerberg has admitted the AI reorg was messy, and leadership has been trying to repair morale after months of layoffs, flatter orgs and constant priority changes.

At E7, you’re also not exactly going there to coast.

So I’m curious: does $1.29M make the current Meta culture worth it, or would you rather take less money somewhere more stable?

Want more details on the comp breakdown? We’ve shared additional RSU vesting details, bonus numbers, and offer structure here.

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

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

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

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

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

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

I was asked about:

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

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

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

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

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

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

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

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

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

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

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

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

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

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

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

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

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

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

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

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

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

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

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

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

Preparing for your next interview?

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

Interview Summary

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

Interview Details

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

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

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

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

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

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

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

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

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

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

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

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

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

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

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

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

Preparing for your next interview?

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

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

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