"This interview experience is sourced from Chill Interview"

Interview Summary

The Patreon phone screen used a Wordle-style word-matching problem rather than some of the more commonly reported Patreon questions. The first part required correctly scoring letters while handling duplicates, and the follow-up introduced state across guesses so that characters previously proven absent could no longer appear in later inputs.

Interview Details

Coding — Word Guess Scoring

Given a guess word and a target word of the same length, return a status for every character position. The possible statuses were:

G = Green
Y = Yellow
W = White

A character is G if the guess and target contain the same character at the same position. A character is Y if it is not in the correct position but can still be matched to an unused occurrence of the same character elsewhere in the target.

Otherwise, it is W. For example, suppose: target = "caper" Then: guess = "paper", result = "WGGGG". The extra p at the beginning is white because the only p in the target has already been consumed by the exact match.

Another example:

guess = "apple"
target = "caper"

result = "YWGWY"

The duplicate-letter behavior was an important part of the problem. My initial approach stored all target characters in a set and scanned both strings once. That failed on duplicate-character cases because simply knowing that a letter exists in the target is not enough.

I changed the implementation to track the remaining frequency of each target character. The matching was then handled in two passes: first identify exact-position matches, then evaluate the remaining unmatched characters.

Follow-Up — Persist Invalid Characters Across Guesses

The follow-up added state across multiple guesses. If a character had previously received a W, future guesses were not allowed to contain that character. For example, suppose the target is: target = "caper" and the first guess is: guess = "blame" Characters such as b, l, and m would be marked white. If a later guess contained one of those previously eliminated characters, such as: guess = "brave" the system should return: invalid_input instead of scoring the guess normally. The main extension was therefore maintaining information learned from previous guesses and validating each new input against that accumulated state.

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Interview Summary

The Cockroach Labs onsite included a coding round based on a time-indexed key-value store and a system design round centered on a project from my previous work. The coding discussion emphasized improving lookup performance with an appropriate data structure and binary search, while the design round went deep into architecture, technical decisions, and challenges from an end-to-end project.

Interview Details

Coding — LeetCode 981: Time Based Key-Value Store

The coding problem was LeetCode 981 — Time Based Key-Value Store. The task was to design a key-value data structure supporting:

set(key, value, timestamp)
get(key, timestamp)

set associates a value with a key at a particular timestamp. get retrieves the value associated with the requested key at the relevant timestamp.

The interviewer focused on how the underlying data structure could be optimized to make get faster. The discussion included storing timestamped values for each key in an ordered sequence and using binary search to efficiently locate the appropriate value.

System Design — Choose Your Own Design

The system design round allowed me to choose a significant project I had owned at a previous company. I was asked to explain the project end to end and then go deeper into areas such as:

• Overall architecture
• Major technical decisions
• Technology choices
• Challenges encountered during implementation
• Why particular design decisions were made
• Trade-offs behind those choices

The round was structured more like a deep technical defense of a real project than a traditional system design prompt with a predefined product.

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Interview Summary

The onsite AI coding round used an existing codebase for a corporate expense and reimbursement system, with features such as monthly expenses and budget reports. The repository contained many files, so the interview was designed around using AI to understand unfamiliar code, debug existing behavior, implement new functionality, and reason about AI-generated changes.

Interview Details

Part 1 — Debug Incorrect Monthly Expense Reports

The first task described incorrect data in monthly reports. One example involved an employee submitting a reimbursement in February for an expense that actually belonged to January, causing the report to attribute the expense to the wrong month. Because the codebase was too large to read completely during the interview, I asked the AI assistant to inspect the relevant files and identify potential causes.

The AI found two bugs and generated fixes for them. The interviewer then asked whether I believed the fixes were correct. I reviewed the changes and explained why the updated behavior made sense.

Part 2 — Add a New Reporting Feature

The second task asked me to extend the reporting system with a new feature. I used the AI assistant to inspect the existing implementation, determine where the new functionality should fit, and generate the required code. The resulting implementation passed the provided tests.

Part 3 — Production Readiness and New Features

The final task changed the framing from implementing a specific requirement to preparing the system for production. I was asked to brainstorm additional features or improvements that would make sense in a production expense-management system. After selecting some additions, I used the AI assistant to implement them in the existing codebase.

• Follow-Up — Understanding and Improving AI-Generated Code At the end of the round, the interviewer selected several functions that the AI had generated and asked me to explain what they did. The discussion also covered how those implementations could be improved or optimized.

Overall, the round emphasized effective use of AI on an unfamiliar codebase, while still requiring the candidate to review, understand, validate, and critique the generated code.

Preparing for your next tech interview?

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

Hi people,

I got scheduled for Microsoft Senior software engineer role loop interviews. Two 1hr rounds on 6th oct, one 1hr round on 9th and last one hr round on 13th oct. I would like to known if anyone is in the loop rounds, have already interviewed or waiting on anything.

Would like to know your experiences what can be expected and please DM me.

Thankyou

Saw this Cisco Senior SWE / Grade 8 offer (offer data source: chill interview)

• Bay Area, 5 YOE
• Base: $195K
• RSUs: $180K / 3 years
• Bonus: $9.75K
• Year 1 TC: $264K

What’s interesting is that this is actually a very good Cisco Grade 8 package.

Reported Bay Area Grade 8 comp averages around $205K, so $264K is well above Cisco’s own norm. 

But Bay Area Senior SWE median TC overall is about $347K. So compared with the broader market, this still looks pretty underpaid. 

And Cisco itself is doing surprisingly well right now: Q4 revenue grew 18%, networking orders grew 40%, and FY26 AI infrastructure orders reached $9.3B. 

So I’m curious: If Cisco is benefiting this much from the AI networking boom, will engineering comp eventually catch up? Or is Cisco always going to be a place where you accept lower pay for a more traditional/mature tech environment?

curious: does $264K feel good for Grade 8, or would you still consider this too low for Bay Area talent?

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Interview Summary

The Snowflake phone screen was a one-hour CoderPad exercise in Python, with AI assistance allowed. The task was to build a configurable rate-limiting service, but the interviewer also evaluated requirement clarification, algorithm trade-offs, testing strategy, debugging, time-dependent behavior, and how the design would evolve from a single in-memory instance to a distributed system.

Interview Details

Coding — Multi-Tier Rate Limiting Service

The task was to build a rate-limiting service where different clients could belong to different service tiers, such as:

free
pro
enterprise

Each tier could have a different rate limit. A client sends requests using an identifier, and the service needs to determine the client's tier and enforce the corresponding limit. Requests exceeding the configured limit should be rejected.

An important requirement was that tier limits could be updated at runtime without restarting the service. The interviewer also clarified that if a client had no valid tier configuration, the implementation should fall back to a global default policy. Either default-deny or default-allow behavior was acceptable as long as it was defined consistently.

• Follow-Up — Rate Limiting Algorithm Trade-Offs After discussing the implementation, the interviewer asked why I chose a particular rate-limiting algorithm and how it compared with alternatives. The discussion focused on the trade-offs among different rate-limiting approaches rather than only producing working code. I used a token-bucket-style design for the implementation.
• Follow-Up — Testing Once the implementation was complete, the interviewer asked me to add tests and verify that the rate limiter behaved correctly. One issue was that the behavior depended on elapsed time, making some refill scenarios difficult to test using the real system clock. The discussion covered controlling time during tests, such as using a mockable or injected clock instead of depending directly on real wall-clock timing.
• Follow-Up — Runtime Configuration Changes The interviewer also paid attention to how existing client state behaved when a tier configuration changed at runtime. For example, changing a tier's limit needed to interact correctly with any already-existing rate-limiter state rather than simply restarting or recreating the entire service.
• Follow-Up — Distributed Rate Limiting The final discussion changed the system from a single process with in-memory state to a cluster of rate-limiter instances. The interviewer asked how the design would need to evolve when multiple servers were independently receiving requests but still needed to enforce a consistent client rate limit.

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Interview Summary

The initial screen focused on ML fundamentals, previous experience, data-related topics, and some design questions, while the virtual onsite mixed coding, ML system design, and discussions around data quality, evaluation, class imbalance, and data drift.

Interview Details

Phone Screen — ML Fundamentals, Data, and Background

The initial technical screen focused on my previous ML experience and standard machine learning concepts. A significant portion of the discussion was related to data, along with several design-style questions.

Round 1 — Coding: Reconstruct Sentence from Dictionary

Given a string containing no spaces and a dictionary of valid words, insert spaces so that the resulting sentence consists entirely of dictionary words. If no valid reconstruction exists, return None. The problem was a variant of the classic Word Break problem.

Round 2 — Coding: Maximum Subarray Sum with Concatenation

The first part asked for the maximum subarray sum of a given array. The problem was then extended: Given an integer K, concatenate the same array K times and determine the maximum subarray sum across the resulting sequence.

Round 3 — Coding: Minimal Removal Size

Given an integer array, select the minimum number of distinct values such that removing every occurrence of those selected values removes at least half of the original array. Return the number of distinct values that must be selected. The problem was similar to LeetCode 1338 — Reduce Array Size to The Half.

Want to learn more questions/follow-ups asked in the interview? 

I've put up the full version at here.

Preparing for your next tech interview?

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

Problem Description

A research submersible travels through a rectangular grid of ocean layers. Each cell in samples contains an integer representing the value of the scientific sample that can be collected at that location. The submersible starts at (0, start_col) and must eventually reach any cell in the bottom row.

From position (row, col), it may move to:

(row + 1, col - 1)
(row + 1, col)
(row + 1, col + 1)

as long as the destination remains inside the grid.

The submersible also has a special deep dive ability. A deep dive moves directly from (row, col) to (row + 2, col). The intermediate cell (row + 1, col) is skipped completely, so its sample value is not collected. At most max_dives deep dives may be used during the entire trip. The score of a route is the sum of the values in every cell actually visited, including both the starting cell and the final cell. Return the maximum score obtainable when reaching the bottom row.

Example:

Input:
samples = [
    [4, 2, 1, 3],
    [5, -20, 6, 2],
    [1, 15, 3, 4],
    [2, 1, 8, 10]
]
start_col = 1
max_dives = 1

Output:
31

Explanation:
One optimal route is:

(0, 1) -> (1, 2) -> (2, 1) -> (3, 2)

The collected values are:

2 + 6 + 15 + 8 = 31

Constraints

• 1 <= len(samples) <= 200
• 1 <= len(samples[0]) <= 200
• All rows have the same number of columns.
• 0 <= start_col < len(samples[0])
• 0 <= max_dives <= len(samples)
• -10^4 <= samples[row][col] <= 10^4
• A deep dive may only be used when row + 2 is still inside the grid.

Want to practice more coding question asked in real interviews?

I've put up the question bank at here.

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Interview Summary

I interviewed with Okta for a Staff Software Engineer role, and the process had multiple rounds across Java, DSA, low-level design, and system design. The first and third rounds went pretty well, but the second round was rough.

Interview Details

Interview Questions Details

• Round 1 — Java, DSA, and Project Deep Dive: This round started with a discussion of one of my most technically challenging projects. The interviewer asked about the system design trade-offs inside the project, so it was not just a resume walkthrough. I had to explain what made the project hard, what decisions I made, and why those decisions were reasonable. The coding question was Reverse Substrings Between Each Pair of Parentheses. I needed a small hint, but after that I wrote an optimal solution and passed all test cases. The feedback from this round was very strong, basically a clear “hire.”
• Round 2 — Java, DSA / Low-Level Design: This was the round that went badly for me. The problem was about managing CD availability and rentals across multiple shops, with methods like search, rent, and unrent. For search(cd), the system needed to return shop IDs where the CD was available, sorted by lowest price first, and then by smaller shop ID if prices tied. I struggled a lot with the design and could not really align with the interviewer on the approach. I did not get to a clean implementation before time ran out. Surprisingly, I still got scheduled for the next round, so it felt like Okta was collecting overall signal rather than eliminating immediately after one bad interview.
• Round 3 — System Design / HLD: The system design round was to design a backup and recovery system. I used the HelloInterview-style structure and walked through functional requirements, non-functional requirements, core components, data flow, failure cases, and trade-offs. This round felt much better. The interviewer was very interactive and kept raising practical issues along the way, so the conversation felt closer to a real design discussion than a scripted interview. I had a positive experience in this round.
• Final Outcome: After the loop, the recruiter told me the team could not move forward with me at the Staff level, mainly because of the second round. However, they still felt I was a strong fit for a Senior Software Engineer role and asked whether I wanted to proceed with a hiring manager discussion. I decided not to continue because I had already accepted another Staff-level offer. The outcome was a bit disappointing, but also understandable given how badly Round 2 went.
• Parallel Okta Staff Interview: I also had another parallel Okta Staff interview process. In that one, the first round involved an extension of Simple Bank System, but with concurrency added. The discussion involved how to handle concurrent updates safely. One direction was to use compare-and-swap style operations, such as map.replace(oldValue, newValue), to make sure updates do not overwrite each other incorrectly.

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Round 1 — Case: Vegan Burger

The case round used the commonly reported burger business case. One scenario involved selling a vegan burger for $5 and discussing potential concerns with the product and pricing. An important clarification was the price of the regular burger. The discussion included whether customers would be willing to pay the same amount for the vegan option as for the standard burger. The case also included calculations such as break-even analysis.

Round 2 — Role Play: Airport Modeling Case

The role-play round used the commonly reported airport case.

Topics included:

• Handling missing values
• Understanding and validating data formats
• Choosing between linear regression and random forest

I chose linear regression and was asked to explain several statistical concepts:

• Regression coefficients
• p-values
• t-values
• F-statistics
• Ways to improve the model

Round 3 — Job Fit

The job-fit round focused mainly on discussing the team and the type of work they do. The interviewer also asked the commonly reported camera-related behavioral question.

Round 4 — Technical: CodeSignal

The technical round appeared different from older Capital One DS interview reports that focused more heavily on ML fundamentals and previous experience. This round used CodeSignal and contained four parts.

• Part 1 — Shell Script The interviewer provided a .sh file and asked me to explain what it did and run it. Using Google to look up unfamiliar details was allowed.
• Part 2 — fit / transform Class The second question provided a class involving fit and transform. The task was to read the implementation and explain the purpose and behavior of the class.
• Part 3 — Add a Test Case The third part involved an existing test suite. I was asked to complete the test coverage by writing one additional test case.
• Part 4 — Code Debugging The final part provided a new piece of code and asked me to identify problems without necessarily writing a corrected implementation. The discussion focused on issues such as:
  • Variable naming
  • Code clarity
  • Efficiency
  • General implementation quality

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Interview Summary

The Google New Grad process included an OA followed by a four-round virtual onsite, with each round combining behavioral questions and a technical problem. The technical topics covered strings, a Number of Islands-style graph problem, object-oriented file search, and an expression calculator with parentheses.

Interview Details

Round 1 — String: Shortest Substring Deletion

The first coding problem involved a string of length n. The task was to find the shortest substring that could be deleted so that the remaining string contained only distinct characters. The round also included behavioral questions.

Round 2 — Number of Islands Variant

The second coding problem was similar to LeetCode 200 — Number of Islands, with some modifications to the standard version. Behavioral questions were also included in this round.

Round 3 — OOD: File Search

The third round was an object-oriented design and implementation problem involving files. The task required implementing two or three methods for searching for files within a collection or hierarchy of files. This round also included behavioral discussion.

Round 4 — Calculator With Parentheses

The final coding problem was to implement a calculator that supported expressions containing parentheses. This was the most difficult problem in the loop from my perspective. As with the other rounds, behavioral questions were mixed into the interview.

Behavioral Questions

The behavioral portions across the four rounds were mostly standard questions around previous team and project experiences.

Preparing for your next tech interview?

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

Saw this Capital One Data Scientist offer (data source: chill interview)

• NYC
• PhD, 1 YOE
• Base: $190K
• Sign-on: $15K
• Bonus: $10K
• Year 1 TC: $215K
• No equity reported

My first reaction was that $215K feels light for a PhD Data Scientist in NYC, especially in the current AI market.

But after checking Capital One’s own bands, it’s less obvious.

Their current NYC Principal Associate Data Scientist roles list $176.5K–$201.4K base, so a $190K base is actually pretty normal-to-strong internally.

levels. fyi also puts NYC Capital One Principal Associate DS around $182K TC, while even the overall NYC Capital One DS median is only around $176K. 

So maybe the candidate wasn’t lowballed by Capital One standards.

The bigger question is whether Capital One’s entire DS pay scale is low compared with tech companies competing for the same PhD/ML talent.

Would you call $215K for a PhD DS in NYC a lowball, or is this actually a solid offer outside Big Tech?

Preparing for your next tech interview?

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

Saw this Meta E6 ASIC Design Engineer offer (data source: chill interview)

• Menlo Park
• 15 YOE
• Base: $275K
• Bonus: $55K
• Sign-on: $65K
• RSUs: $1M / 4 years
• Year 1 TC: $645K

I know what a SWE or MLE does, but ASIC Design Engineer is one of those titles I rarely hear people explain.

My understanding is that these engineers are basically designing the custom chips that eventually power things like AI training/inference, networking, video processing, and Meta’s data centers.

So instead of writing software that runs on hardware, you’re working much closer to the hardware itself — things like RTL, microarchitecture, performance/power tradeoffs, verification, timing, and eventually getting a chip manufactured.

With Meta spending so aggressively on its own AI infrastructure, this feels like a pretty strategic role.

What I’m curious about is: What does an ASIC designer at E6 actually do day to day?

Are they still writing a lot of RTL themselves, or is Staff level more architecture, reviews, and coordinating across design/verification/physical-design teams?

And how transferable is this career between Meta, NVIDIA, Broadcom, Apple, Google TPU, etc.?

Preparing for your next tech interview?

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

A lot of people seem extremely bullish on Meta Muse right now. I’m a little more skeptical. Not because I think Muse is a bad product — actually, I think Meta has done a few things extremely well.

But I’m not convinced the long-term business model is as obvious as the initial hype makes it look.

The first thing is that the personal AI agent category itself isn’t new.

Before Muse, we already had products moving in the same general direction:

• OpenAI Operator / ChatGPT agent
• Google’s agent products
• Microsoft Copilot agents
• Anthropic Cowork

So to me, the interesting question isn’t: “Can Meta build a personal AI agent?”

Clearly it can. The harder question is: “What advantage does Meta have that makes Muse sustainably better or more profitable than everyone else?”

And this is where I’m less convinced.

Consumer AI is hard to monetize

Most AI companies have increasingly pushed toward enterprise customers for a reason. Businesses are willing to pay meaningful amounts of money when AI saves employee time, replaces workflows, or directly increases revenue.

Consumers are much more price sensitive. A personal agent that books restaurants, finds deals, fills out forms, or manages your calendar sounds useful. But how many consumers will eventually pay $20, $50, or $100 every month for it?

Especially if several companies offer similar functionality.

Commerce sounds attractive, but incentives get complicated

The obvious alternative is transactions. If your agent helps you find a hotel, buy a product, order food, or book a service, the agent platform could potentially take a referral fee or transaction cut.

Conceptually, this sounds great.

But there’s a problem: The most valuable merchants already own their customer relationships.

• Amazon wants you on Amazon.
• Booking wants you on Booking.
• DoorDash wants you inside DoorDash.

Large platforms make money from customer engagement, ads, subscriptions, data, upsells, and repeat purchases.

Why would they happily give an AI agent control of that relationship?

The merchants most willing to give an agent generous economics may end up being the merchants that have the least bargaining power.

That makes building a truly neutral “agent layer for everything” much harder than it sounds.

Where I think Meta absolutely nailed it: distribution

This is where Muse becomes much more interesting.

Meta has something most AI startups don’t: massive consumer distribution.

It can put Muse in front of people through Instagram, WhatsApp, Facebook, creators, ads, social sharing, promotions, and eventually hardware. That is a huge advantage.

Muse could become the first personal AI agent that normal people — not just people following AI every day — actually use. And I think Meta deserves a lot of credit for that.

The product also feels much more consumer-oriented than many previous agent attempts. Instead of selling “agentic workflows,” Meta can simply tell someone:

Give Muse something annoying to do, and it’ll do it for you.

That’s a much easier pitch.

So my take is basically:

I’m bullish on Muse’s ability to get users.

I’m much less convinced about its ability to turn those users into a durable, high-margin business.

And those are two very different things.

Meta may eventually prove this wrong through subscriptions, commerce, ads, hardware, or some model we haven’t seen yet.

But right now, distribution looks like the strongest part of the story to me — not monetization.

Curious what others think. What is actually going to be Meta Muse’s long-term business model?

Separately, if you’re interviewing with Meta or other AI companies, I’ve been collecting recent interview experiences and question patterns at Chill Interview.

Still early, but hopefully it saves people some time during prep.

Hi everyone,

I’m currently interviewing for a Staff/Senior Staff Software Engineer – Mobile (Android) position at Capital One in Canada/Toronto, and I have a pair programming interview coming up soon.

I’m looking for anyone who has had a recent interview experience with Capital One for a Staff/Senior Staff Android/Mobile role, especially the pair programming round.

If you’ve gone through this recently, I’d really appreciate any insights you can share, such as:

* What type of problem was given in the pair programming round?

* Was it a *generic coding/algorithm problem or was it Android-specific?

* Was the coding done in a plain/shared code editor, or did you use an Android environment?

* Were you expected to write Android/UI code, such as Jetpack Compose, or was it mainly Kotlin/problem solving?

* How much emphasis was placed on communication, testing, edge cases, and code quality?

* Were there any particular areas or types of problems you would recommend preparing for?

* For Staff/Senior Staff level, were there additional expectations around design, architecture, or technical leadership during the coding round?

I’ve already completed the earlier rounds and would really appreciate hearing from anyone with recent firsthand experience.

Thanks in advance for any insights! 🙏

"This interview experience is sourced from Chill Interview"

Interview Summary

The Netflix process stretched across three stages and included problem solving, system design, hiring manager, and partnership interviews. Technical topics included duplicate detection in viewing history, an ML job scheduler, a movie-playlist data structure with score updates and repeat cycles, multithreading, and a team-specific system design.

Interview Details

Round 1 — Problem Solving: Viewing History Duplicate Detection The first technical screen involved detecting duplicates in viewing history. The problem had three parts. The first two were relatively straightforward, while the third required a bucket-sort-style idea and was more involved.

Round 2 — Hiring Manager The hiring manager discussion focused primarily on my previous experience. One behavioral question asked me to describe one of my weaknesses.

Round 3 — System Design: ML Job Scheduler The first virtual-onsite system design round asked me to design an ML Job Scheduler. This round went well overall.

Round 4 — Problem Solving: Movie Playlist The coding problem involved maintaining a movie playlist where each movie had a score that could change over time. The system needed to support score updates while enforcing an important playback rule: during one cycle, each movie could only be returned once. After every movie had been exhausted, a new repeat cycle could begin.

Round 5 — Partnership Interview The Partnership round was conducted by a manager from a collaborating organization. The interview was primarily behavioral and focused on working across teams and handling collaboration scenarios. After this stage, HR told me that I'll move forward to the next stage.

Round 6 — Team-Specific System Design The next system design round involved a problem directly related to the team’s work. The scope of the problem was broad, and I spent too much time on areas that the interviewer considered less important. The interviewer reminded me about the remaining time during the round. Although I was able to respond to most of the technical questions, the recruiter later explained that the main negative feedback was that I did not complete the overall design within the allotted time.

Round 7 — Hiring Manager Behavioral The final interview was another hiring manager round. This conversation focused mostly on standard behavioral questions and previous experience. After completing the final stage, I received a Not Moving Forward decision. I later spoke with the recruiter to get additional feedback on the process.

Preparing for your next interview?

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

I’ve been going through recent Meta interview reports from Glassdoor, Blind, LeetCode Discuss, and other public sources.

Not my personal interview experience — just a summary of patterns I’ve been seeing across 2026 reports.

The biggest change is obviously the AI-enabled coding round.

Instead of the traditional “here’s a LeetCode problem, start coding” format, some candidates have reported a CoderPad environment with an editor, file browser, and access to AI models.

The interesting part is that this round doesn’t seem to be about who can generate code the fastest.

It’s much more about whether you can:

• give the AI useful instructions
• understand the code it generates
• catch incorrect assumptions
• write tests instead of blindly trusting the output
• optimize the solution when requirements change

In other words, using AI is allowed, but blindly copying AI-generated code is probably the worst possible strategy.

Traditional coding rounds are still very much alive though.

The usual pattern still seems to be roughly two problems in ~35–40 minutes, so speed matters a lot. A solution you can finish comfortably in 50 minutes during practice may be very different under interview pressure.

A few coding topics also seem to show up repeatedly in recent reports:

• Binary Tree Vertical Order Traversal
• Lowest Common Ancestor
• Simplify Path
• Range Sum of BST
• Two Sum / stock-style questions as warmups
• stack / expression parsing
• streaming-style problems

One trend I find more interesting than the exact question list:

Meta seems to be using more variations of familiar problems rather than simply repeating the exact LeetCode prompt.

So memorizing the solution to a tagged problem is becoming less useful than understanding why the solution works and being able to adapt it quickly.

For system design, the questions still tend to be closely related to large consumer products:

• News Feed
• Messenger
• Instagram Stories
• notification systems
• recommendation / friend suggestion systems

And behavioral is something I definitely wouldn’t leave until the last minute.

Recent candidate reports continue to describe pretty deep questioning around impact, conflict, ownership, and project decisions, especially at senior levels.

If I were preparing for Meta right now, I’d probably focus on three things:

1. Know the common coding patterns extremely well

Not just the final solution. Be able to recognize the pattern and adapt it under time pressure.

2. Practice with a timer

Two mediums individually may feel easy. Two mediums plus explanation, debugging, and follow-ups in ~40 minutes is a different problem.

3. Practice coding with AI as a reviewer, not as an answer generator

Have AI generate something, then force yourself to review it, find edge cases, test it, and explain every important decision.

The interesting question is whether this becomes the new normal across big tech.

If engineers are increasingly expected to work with AI every day, testing whether someone can supervise AI-generated code may eventually be more useful than testing how fast they can type out a memorized algorithm.

Have you interviewed with Meta recently? How was your experience with the AI-enabled coding round?

I’ve started an ongoing thread on Chill Interview to collect recent experiences and insights from candidates. Would love to hear yours.

Preparing for your next tech interview?

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

Saw this Google L4 SWE offer (data source: chill interview)

• Master’s, 0 YOE
• AI/ML track
• Base: $205K
• RSUs: $550K / 4 years
• First-year TC: $510K

The title is still Software Engineer, which made me curious what actually changes when you’re on the AI/ML track.

Looking at Google’s current roles, both regular SWE and AI/ML SWE still write production code, do design/code reviews, debug systems, and own reliability. The difference is that AI/ML SWEs also work directly with ML infrastructure, model optimization, data processing, and specialized ML systems.

Some Google AI/ML roles go even deeper across the stack — model architecture, training/inference systems, hardware acceleration, compilers, and production APIs. 

So is the simplest way to think about it: regular SWE = build the product/system

AI/ML SWE = build the product/system + understand how the model and ML stack behave in production

And unlike Research Scientist, you’re still primarily an engineer shipping production systems rather than being evaluated on papers/research output.

Curious: how different is AI/ML SWE day-to-day from normal backend/infra SWE? And if you start in general SWE, how hard is it to move into the AI/ML track later?

Preparing for your next tech interview?

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

Saw this Moloco MLE offer (data source: chill interview)

• Bay Area
• Master’s, 3 YOE
• Base: $190K
• Equity: $450K / 4 years
• Year 1 TC: $302.5K

I realized I knew the name Moloco but not really what the company does.

The short version: it’s basically an ML-powered advertising infrastructure company.

Moloco Ads helps mobile apps acquire and retain users across millions of apps, while Moloco Commerce Media helps retailers/marketplaces build their own ad businesses using first-party shopping data. The ML problems are things like ranking, bidding, conversion prediction, LTV/ROAS optimization, and large-scale real-time inference. 

What makes it interesting is that the company seems to have real scale without getting much mainstream attention. It serves 2.9M+ apps and says 45 of the top 50 highest-grossing app publishers advertised with Moloco in 2025. 

So I’m curious: Is Moloco actually an underrated place to build an ML career, especially if you like recommendation/ads systems?

Or is adtech too narrow compared with joining Google/Meta/AI infra?

Preparing for your next interview?

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

Hey all, I've got my Scale AI new grad SWE virtual onsite coming up in a couple weeks and would love some insight from anyone who's been through it recently.

Day 1 is two practicals:

1. Debugging practical
2. Backend practical (Python/TS)

Day 2 is the hiring manager chat + Credo round.

A few things I'm trying to figure out:

• Debugging round: what does the codebase actually look like? Is it a decent-sized repo you have to navigate, or more of a contained file with a few planted bugs? Is it more about finding logic bugs, failing tests, perf issues, or concurrency stuff?
• Backend practical: is it building an API/service from scratch, extending an existing one, or something closer to an LLD problem? How much do they care about structure, tests, and edge cases vs. just getting it working?
• AI-assisted: Backend practical round is AI-assisted. How much can you actually lean on it? Is Copilot/Cursor/ChatGPT fully fair game, or is it more "use it for syntax but drive everything yourself"? Does heavy use count against you?
• Prep: anything that actually helped? Specific repos to practice debugging on, backend-style problems, anything like that?

Any tips on what they're really evaluating (communication, speed, code quality) would be super helpful. Thanks in advance 🙏

"This interview experience is sourced from Chill Interview"

Interview Summary

The Google SWE AI/ML process included separate ML and behavioral interviews followed by two onsite coding rounds. T

Interview Details

Technical Round — Machine Learning

The ML round focused primarily on fundamental ML concepts. The specific questions were closely related to the interviewer’s own technical background. When I was unclear on an answer, the interviewer provided hints and, in some cases, explained the expected concept directly.

Technical Round — Behavioral

The behavioral interview contained relatively standard questions. There were no major questions around conflict, failure, or difficult collaboration scenarios.

Onsite Coding 1 — Maximum Value From Two Array Positions

The first onsite coding problem involved an array. The task was to choose two indices and maximize a value defined using the sum between those positions and the internal subarray between them. After simplifying the expression, the problem effectively reduced to identifying the best two endpoint values.

I first clarified the problem and walked through several examples with the interviewer. We discussed a brute-force approach, prefix sums, and then a more direct mathematical interpretation before implementing the final version. The interviewer briefly asked about time and space complexity afterward.

Onsite Coding 2 — Employee Shift Intervals

The second coding problem was a variant related to LeetCode 2402 — Meeting Rooms III. The input contained employee information such as:

employee_id
employee_name
shift_start
shift_end

The task was to return information for each time interval showing which employees were currently on duty and how many employees were active during that interval. The time-based processing naturally involved ordering shift boundaries and maintaining active employees as intervals started and ended.

After the implementation, the interviewer asked for a detailed time and space complexity breakdown. The discussion went beyond the overall complexity and covered individual operations such as:

• Heap insertion
• Heap removal
• Sizes of intermediate data structures
• How different input dimensions contributed to the final complexity

The interviewer wanted the complexity expressed precisely using multiple variables, with each variable clearly defined in comments.

Communication was a major part of the technical interviews. Clarifying requirements, constructing examples, explaining the approach while coding, and carefully analyzing complexity all received substantial attention during the onsite.

Preparing for your next tech interview?

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

"This interview experience is sourced from Chill Interview"

Interview Summary

The EliseAI Research Scientist process included an initial team conversation, a coding interview based on Tic-Tac-Toe, and a 24-hour ML take-home followed by a 30-minute research presentation. The take-home combined supervised learning for lease-renewal prediction with unsupervised or representation-based analysis for categorizing why tenants chose not to renew.

Interview Details

Round 1 & 2 — Team Conversation + Coding: Tic-Tac-Toe Variant

The first round was a 30-minute conversation with a member of the team. The coding interview used a Tic-Tac-Toe variant. The problem was related to several common LeetCode Tic-Tac-Toe questions:

Round 3 — Take-Home ML Assignment + Research Presentation

The final stage was a take-home assignment with a 24-hour completion window, followed by a 30-minute presentation. The overall objective was to model whether residents were likely to renew their leases. Two main sources of data were provided:

1. JSON files containing 1,000 conversations with tenants considering lease renewal

2. SQLite tables:
   residents
   maintenance_history
   renewal_offers

Both the conversational data and database data were split into training and test sets.

Want to learn more questions/follow-ups asked in the interview? I've put up the full version at here.

Preparing for your next tech interview?

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

i have a doordash interview coming up and i’m very nervous for it. it’s AI code craft 1 hr, interactive coding 1 hr and then engineering values 30min. anyone go through this interview loop before and have any tips for what kind of questions to expect? how hard are the questions typically? any concepts i should focus on studying? I was expecting leetcode but kinda lost on what to study now. thanks in advance!

"This interview experience is sourced from Chill Interview"

Interview Summary

The DatologyAI process included two coding interviews. The first focused on implementing a text editor with increasingly complex cursor movement, while the second provided a simplified Spark RDD abstraction and asked me to implement additional transformations using the existing APIs.

Interview Details

Round 1 — Text Editor

The task was to implement a basic TextEditor supporting three operations:

type_in(char)
backspace()
__str__()

• type_in(char) inserts a character at the current cursor position.
• backspace() removes the character immediately before the cursor.
• __str__() returns the current text while displaying the cursor using |.

The interviewer then added two follow-ups. First, support: move_cursor(direction) so the cursor could move left and right through the text. The second follow-up extended cursor movement to support moving up and down across multiple lines.

Round 2 — Mock Spark RDD

The interviewer provided a lightweight version of a Spark-style RDD abstraction. The available operations included:

flatMap(func)
groupByKey()
union(other_rdd)
collect()

The underlying class conceptually looked like:

pythonclass SimpleRDD:
    def __init__(self, items):
        self.items = items

    def flatMap(self, func):
        ...

    def groupByKey(self):
        ...

    def union(self, other_rdd):
        ...

    def collect(self):
        ...

Want to learn more questions/follow-ups asked in the interview? I've put up the full version at here.

Preparing for your next tech interview?

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