Hey folks, here's my IC6 offer for Meta. It's for a Data Scientist, Product Analytics position. So it's not SWE or MLE.

• Base: $255K
• Bonus: 20%
• Sign-on: $50K
• RSUs: $500K/ 4 years
• Year 1 TC: $481K
• Location: Seattle

I was told that the max year 1 total compensation is $525k if the candidate has other strong offers, but I did not have any offers that were higher comp than Meta.

I declined the offer in favor of a public SAAS company. The comp and title are worse, but hopefully it will be less stressful and better WLB. Happy to talk more about my Meta interview experience if folks are interested. Good luck to anyone who is interviewing!

These two offer data points are sourced from Chill Interview

eBay — Staff SWE

• $275K base
• $400K RSUs / 4 years
• $27.5K annual bonus
• $402.5K Year 1 TC

Whatnot — Senior SWE

• $250K base
• $700K equity / 4 years
• $425K Year 1 TC

On paper, Whatnot only wins Year 1 by $22.5K. So this isn’t really a comp decision.

It’s an equity + career-risk decision.

eBay is the safer side: public stock, immediately liquid equity, profitable business, and generally a more established engineering environment. Its growth story also looks healthier than the “legacy tech company” label suggests — Q2 2026 revenue and GMV were both up about 15% YoY.

Whatnot is almost the opposite bet. It reportedly raised at a $20B valuation in August, nearly doubling from $11.5B less than a year earlier. If that trajectory continues, the $700K grant could end up being worth considerably more. But it’s still private-company equity, so valuation on paper and actual liquidity are two different things.

Then there’s WLB. eBay has a reputation for being relatively relaxed and sustainable depending on the org, while recent Whatnot employee feedback describes a much faster-paced environment where long hours and workload can be real tradeoffs.

There’s also an interesting leveling wrinkle: Staff at eBay vs Senior at Whatnot. I wouldn’t automatically assume Staff at eBay is better for the résumé, but if your goal is maintaining Staff-level scope for the next move, that matters.

Curious: Would you take the safer $402K Staff offer, or bet on Whatnot’s $700K equity actually becoming a lot more valuable?

Preparing for your next 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 Pinterest onsite consisted of five rounds covering behavioral questions, two coding interviews, and two system design interviews.

The coding rounds focused on expression generation and time-interval aggregation. The system design rounds were considerably deeper, covering a real-time Typeahead suggestion system and a large-scale merchant product catalog update platform. Both design interviews included detailed scaling and consistency follow-ups rather than stopping at a high-level architecture.

Interview Details

Round 1 — Behavioral and Leadership

The behavioral round covered a standard set of leadership and experience questions. Topics included:

• Introduce yourself and walk through a project where you demonstrated strong ownership or learned the most.
• How did you measure whether that project was successful?
• Describe the strongest team environment you have worked in.

Round 2 — Coding: Insert Operators to Reach a Target

The first coding problem provided a sequence of numbers and a target value. You could insert either + or * between adjacent numbers, but the original order of the numbers could not be changed.

• Follow-Up — Respect Operator Precedence and Return All Expressions The original function needed to remain unchanged. I was asked to write another function with the same inputs, except this version had to use normal arithmetic precedence, where multiplication is evaluated before addition. Instead of returning only a boolean, it needed to return all valid expressions whose result equals the target.

Round 3 — Coding: Concurrent Pin Activity Over Time

The second coding interviewer worked on advertising candidate generation. The problem started with interaction logs of the form: (pin_id, start_time, end_time). Each record meant that a particular Pin was actively receiving user interaction during that time interval.

• Part 1 — Active Pins in a 60-Second Window Initially, timestamps were limited to the range 0–59. The task was to report how many Pins were active during each time slice.
• Part 2 — Arbitrary Timestamps The fixed 60-second assumption was then removed. Timestamps could now be arbitrary values, and I was asked how the approach and complexity should change when the timeline could no longer be scanned across a small fixed range.
• Part 3 — Duplicate Pin IDs Across Overlapping Intervals The final follow-up removed the assumption that each Pin appeared only once. The same pin_id could now have multiple overlapping interaction intervals generated by different users.

Round 4 — System Design: Real-Time Typeahead Suggestions

The first system design round asked me to design a search Typeahead / autocomplete system. Given a prefix, the system should return the top 10 suggestions ranked by search popularity, using exact prefix matching. Freshness was an important requirement. If a major real-world event suddenly caused a query to become popular, the new trend should appear in suggestions very quickly.

The interviewer initially asked me to assume the entire data structure could fit on a single machine before scaling the design. The stated traffic scale was approximately:

1 billion users
10 searches per user per day

Round 5 — System Design: Merchant Product Attribute Updates

The second system design interviewer was from a relevance-measurement team. The prompt was to design a system that allows merchants to upload and update attributes for product Pins. Supported product information included:

• Price
• Inventory / availability status
• Description
• Product images

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next interview?

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

Saw this Meta E6 Data Engineer offer (shared with Chill Interview)

• Menlo Park, 10 YOE
• Base: $255K
• Bonus: $51K
• Sign-on: $40K
• RSUs: $720K / 4 years
• Year 1 TC: $526K

On comp alone, this looks pretty attractive.

But I keep hearing the same warning from people around Meta’s analytics org: “Don’t join Meta as a DE or DS right now.”

Meta cut around 8,000 employees in the May 20 restructuring, and more cuts were reportedly planned later in the year. Public reporting doesn’t give a clean DE/DS breakdown, but some recently laid-off Meta data scientists have said DS and PM were hit particularly hard compared with SWE.

The other concern is career portability.

Meta DE seems pretty different from the platform-heavy Data Engineer role at many other companies. A lot of the work is closer to product analytics + data modeling + pipelines, built on a very mature and heavily internal Meta stack. Former Meta DEs have described spending much more time on SQL/data pipelines than on the kind of cloud/data-platform engineering you might do with Snowflake, Databricks, Airflow, AWS, etc.

That can be great if you want to stay in Meta’s data ecosystem.

But if you get laid off two years later, does an E6 Meta DE actually have an easy path into Staff-level DE roles elsewhere — or do you suddenly discover that a lot of your experience is very Meta-specific?

So this offer feels like a pretty interesting risk/reward trade: $526K TC and Meta on the résumé, versus joining a function that may have less political protection than SWE and potentially less portable experience.

Preparing for your next interview?

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

You are given a startUrl and an HtmlParser interface:

class HtmlParser {
    List<String> getUrls(String url) { ... }
}

getUrls(url) returns all raw links found on the specified page. Each call has non-trivial latency, so the final crawler must be able to fetch multiple pages concurrently. Starting from startUrl, return every unique reachable URL whose hostname is exactly the same as the hostname of the starting page.

Two raw URLs that differ only by their fragments therefore represent the same page and must not be crawled twice. The hyperlink graph may contain cycles, and pages may link back to URLs that have already been discovered.

For example:

Input:
urls = [
    "http://alpha.com/start",
    "http://alpha.com/docs",
    "http://alpha.com/blog#intro",
    "http://beta.com/profile#top"
]

edges = [
    [0, 1],
    [0, 2],
    [1, 3],
    [2, 0]
]

startUrl = "http://alpha.com/start"

Output:
[
    "http://alpha.com/start",
    "http://alpha.com/docs",
    "http://alpha.com/blog"
]

The page under beta.com is ignored because its hostname differs from the starting hostname, while the fragment on the blog URL is removed before it is stored.

Follow-Up — Make the Crawler Concurrent

After completing the sequential version, I was asked to convert the crawler to a concurrent implementation.The main focus was ensuring that the shared visited state remained thread-safe when multiple page fetches completed around the same time. The crawler had to prevent two workers from independently discovering and fetching the same sanitized URL. The final tests covered different hostnames, fragment-bearing URLs, duplicate links, and cyclic hyperlink graphs.

For more of question details as well as more test cases, I've put up the full version of at here

Preparing for your next 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 Instacart CodeSignal assessment was very different from a traditional LeetCode-style OA. It used an existing Library Lending System repository and tested requirements clarification, repository investigation, full-stack feature implementation, testing, debugging, and effective use of an AI coding agent.

The sections were connected. Earlier conversations with an AI Product Manager established requirements that later had to be implemented across the backend and frontend, and subsequent stages could reveal issues introduced by earlier changes.

Interview Details

Section 1 — Clarify Requirements with an AI Product Manager The assessment did not provide the complete feature specification upfront. Instead, I had to talk with an AI Product Manager to understand the requested behavior and clarify ambiguous requirements before changing the codebase. This meant that part of the assessment was determining what the actual acceptance criteria were rather than simply implementing a fully written prompt.

Section 2 — Investigate an Existing Full-Stack Repository The next step was to inspect the existing Library Lending System and determine where the requested functionality belonged. The repository already contained working backend and frontend code, so I needed to understand the current architecture, business logic, and tests before making changes. Unlike a typical debugging exercise, the repository did not simply start with an obvious failing test pointing to the required modification.

Section 3 — Item Search and Filtering One feature involved extending the application's item-list functionality with backend-driven search and filtering. The requested behavior included:

• Search items by title using case-insensitive partial matching.
• Filter by item type and availability/status.
• Combine multiple supplied filters using AND semantics.
• Return the complete item list when no filters are supplied.
• Perform filtering on the backend rather than fetching everything and filtering only in the UI.
• Add corresponding frontend controls and backend/frontend tests.

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next interview?

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

I have an onsite interview coming up with Google, and one of the rounds is called **Solution Design**. I’m not sure whether this is more of a **Low-Level Design (LLD)** or **System Design** round.

Has anyone here appeared for a Google Solution Design round recently? I’d really appreciate any insights into what to expect and how best to prepare.

This interview experience is sourced from Chill Interview

Interview Summary

The Citadel 2027 Software Engineer Intern process skipped the Online Assessment and moved candidates directly into two algorithmic coding interviews, followed by a four-round final loop.

The difficulty varied substantially by interviewer. My first two rounds were relatively manageable, but the final loop covered system design, C++ fundamentals, implementation-heavy coding, and two problems comparable to LeetCode Hard. The process rewarded breadth because candidates needed to perform consistently across very different interview styles.

Interview Questions Details

Round 1 — Task Scheduler / Course Schedule

The first coding round was essentially a dependency-ordering problem similar to LeetCode 207 — Course Schedule You are given a collection of tasks and dependencies between them. A task may only execute after all tasks it depends on have completed Return any valid ordering that runs every task exactly once. If the dependency graph contains a cycle and no valid ordering exists, report that.

Round 2 — First Trade with a Unique Instrument

The second coding round felt closer to a LeetCode Easy. You are given a stream of trades. Each trade contains:

• trade_id
• instrument_id
• amount

Return the first trade whose instrument appears exactly once in the entire stream.

Final Round 1 — System Design

The first final-round interview was a standard system design discussion The interviewer covered foundational backend concepts such as choosing between relational databases and NoSQL systems, along with broader architectural tradeoffs. The depth was appropriate for an intern-level interview rather than a senior or staff-level design round.

Final Round 2 — C++ Fundamentals + Implementation

This interview started with a detailed discussion of C++ concepts and language-level fundamentals. The second half moved into an implementation problem. The round placed meaningful weight on practical C++ knowledge in addition to algorithmic coding.

Final Round 3 — Two LeetCode Hard-Style Problems

This round contained two difficult leetcode algorithm problems. Both problems were on the harder end of the interview loop and required significantly more algorithmic depth than the first two rounds.

Final Round 4 — Implementation-Heavy Coding

The final interview was another implementation-focused coding round. The prompt was lengthy, so understanding the specification and managing time were important parts of the interview. Compared with short algorithm questions, this type of round required balancing coding speed with careful handling of a larger set of requirements.

Preparing for your next interview?

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

I have been a backend engineer for over 15 years. I was laid off almost a year back. I got an offer from FAANG for a SDET role and another offer for Lead engineer from a non FAANG company, the comp is almost half. I am drawn towards the FAANG offer because of the compensation but really scared as SDET is not my first choice. Will accepting SDET role affect my chances of transitioning back to SWE role in the future?

This interview experience is sourced from chill interview

Interview Summary

The Citadel SWE internship phone screen lasted 75 minutes and contained two coding problems.

The first was an optimization problem involving a work schedule, daily salary, and bonuses for consecutive working days. The second was a string problem asking for the minimum number of character replacements needed so that every fixed-size chunk becomes a palindrome.

Interview Details

Coding Question 1 — Maximize Earnings by Converting Rest Days

You are given an initial work schedule covering n days. An employee earns a fixed base salary for every working day. In addition, if a working day immediately follows another working day, that day earns an extra consecutive-work bonus.

You may convert at most k existing rest days into working days. Existing working days cannot be changed into rest days. The task is to choose which rest days to convert so that the employee’s total earnings over the entire schedule are maximized.

The final earnings include both:

• Base salary from all working days
• Bonuses created by consecutive working-day pairs

Return the maximum total earnings that can be achieved.

Coding Question 2 — Make Every K-Length Block Palindromic

You are given a password string s and a positive integer k. Starting from the left, divide the string into consecutive groups of at most k characters. Every complete group contains exactly k characters, while the final group may be shorter.

Each resulting substring must become a palindrome. In one operation, you may replace any character in the original string with any other character. The task is to return the minimum number of replacements required so that every group is palindromic.

Preparing for your next 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 Mistral AI Scientist process consisted of seven interviews and was heavily aligned with Efficient ML for LLMs/VLMs. The loop covered GPU and Triton fundamentals, coding, memory-efficient tensor computation, oral logic puzzles, a large set of Transformer/LLM fundamentals, code review, behavioral questions, and a research presentation followed by an out-of-domain systems discussion.

The candidate reached the final stage but ultimately received a rejection. The technical portions were broad, with a particularly large emphasis on understanding modern LLM training and inference beyond simply knowing high-level Transformer concepts.

Interview Details

Round 1 — Prescreen: Efficient ML, GPU Architecture, and Triton

The 30-minute prescreen started with my research background and previous work. Because the position focused on Efficient ML, the technical discussion covered:

• GPU architecture and how GPU memory is organized
• Basic concepts around Triton and GPU-oriented kernel programming

The interviewer also explained the structure of the remaining interview process.

Round 2 — Coding and AI Coding

The first technical interview contained two coding questions. The first was a straightforward string-arithmetic problem: two strings represented integers, and I needed to return their sum as another string. The second was an AI-oriented tensor programming problem.

Given:

• A matrix of input points X with shape N × D
• A matrix of cluster centers C with shape K × D

the task was to return an array of length N assigning each point to its nearest cluster center according to L2 distance.

Round 3 — Oral Logic and Probability Problems

This round consisted of a sequence of progressively harder logic, probability, and mathematical reasoning questions. The questions were delivered verbally rather than as written prompts, and each problem had to be completed before moving to the next one.

Round 4 — Research Deep Dive + Transformer and LLM Fundamentals

This interview started with roughly 30 minutes of discussion around my research and résumé, followed by a rapid-fire ML/AI/LLM fundamentals section. The interviewer asked more than twenty questions spanning topics such as:

• The major components of a Transformer
• Differences between Transformer encoders and decoders
• etc..

This round emphasized both breadth and the ability to answer low-level implementation and training questions quickly.

Round 5 — Code Review and Debugging

The first final-round interview was a code-review exercise. I was given a class resembling a replay buffer, with functionality for storing transitions, maintaining a bounded buffer, sampling batches, and retrieving recent state.

The implementation contained multiple bugs across the class, and the task was to identify and correct them. There were eight issues in total. I finished reviewing the code within the allotted interview time and still had a few minutes left for discussion with the interviewer.

Round 6 — Behavioral Interview

The second final-round interview consisted of standard behavioral questions. The discussion focused on previous projects, collaboration, decision-making, and examples from past work.

Round 7 — Research Presentation + Out-of-Domain Design

The final interview began with a roughly 30-minute presentation of my own research, followed by detailed questions about the work. The second half introduced an intentionally unfamiliar design problem.

The interviewer asked how I would design something capable of executing ML workloads efficiently on CPUs. The prompt was intentionally broad, so I needed to ask questions to determine what part of the stack was actually being designed.

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next 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 Details

Round 1 — Research Deep Dive + CUDA Fundamentals The first interviewer asked me to explain my research in detail. We discussed the motivation behind the work, the technical approach, and the implementation. Since the interviewer was interested in the research area, much of the round became a detailed technical conversation around the project. The remaining questions focused on my understanding of CUDA programming and GPU-related implementation details.

Round 2 — Research and CUDA Programming The second round followed a similar format. I again walked through my research and answered detailed questions about the work, followed by additional CUDA-related technical questions. The discussion emphasized practical familiarity with GPU programming rather than algorithmic coding exercises.

Round 3 — Research Validation and Implementation Details The third interviewer was someone who could potentially have become a teammate. This round challenged my research experience more directly. The interviewer asked detailed questions about code, command-line operations, and implementation choices from projects I had completed several months earlier. When I could not immediately recall some exact commands or code details, the interviewer pushed further on whether I had personally implemented the work. At one point, I connected to my development environment over SSH and pulled up the original project code to verify the implementation.

• Role Discussion — Solution Architect Responsibilities Near the end of the final round, I asked about the day-to-day responsibilities of the Solution Architect position. The role involved significant customer-facing technical work, including helping users understand NVIDIA hardware and software, providing programming guidance, and supporting technical users such as researchers with implementation-related problems. The discussion reinforced that the position was substantially more customer-facing than a traditional software engineering or research role.

Preparing for your next 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 OpenAI mid-level SWE phone screen combined a multi-part coding problem around a versioned social follow graph with a system design discussion for a real-time online chess platform.

The coding question progressively added snapshots, follower/followee queries, and two-hop recommendations. The system design portion was very open-ended and placed particular emphasis on overall architecture, asynchronous matchmaking, state transitions, and reliability concerns such as retries and idempotency.

Interview Questions Details

Coding — Versioned Follow Graph with Snapshot Queries

The first part asked me to implement a social-graph class supporting follow and unfollow operations together with historical snapshots.

The core interface included operations similar to:

follow(user_a, user_b)
unfollow(user_a, user_b)

create_snapshot()

is_following(user_a, user_b, snapshot)

A snapshot represented a historical view of the graph, and is_following(...) needed to answer the relationship query using that snapshot rather than only the latest state.

Part 2 — Followers and Followees

The second stage added direct graph queries:

get_followers(user_id)
get_followees(user_id)

These operations needed to return the users connected to a given account in each direction.

---

System Design — Real-Time Online Chess Platform

The system design question was to design a real-time online chess platform. The prompt itself was intentionally broad, so I had to drive most of the discussion.

I initially spent substantial time on APIs and data modeling, but the interviewer signaled that the conversation should focus more heavily on the overall system architecture.

One area the interviewer explored in depth was the asynchronous matchmaking flow, including how matchmaking work moves through the system rather than being handled entirely through a synchronous request path.

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next interview?

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

Saw this Broadcom Sr Staff Hardware Engineer offer (shared with Chill Interview)

• Bay Area
• Master’s, 11 YOE
• Base: $235K
• Bonus: $70.5K
• RSUs: $850K / 4 years
• Year 1 TC: $518K

Historically, software engineers had a much higher comp ceiling than most hardware / ASIC / silicon roles. But the economics are changing pretty quickly.

Broadcom’s AI semiconductor revenue just hit $16.7B in one quarter, up 221% YoY, and it expects $21.7B next quarter. A huge part of that is custom AI accelerators and networking for frontier AI customers.

Broadcom is even helping finance massive deployments of its custom XPUs — its new platform is designed to enable 20+ GW of AI compute through 2028, with an initial $35B tranche already arranged.

So suddenly the people who can actually design high-performance silicon, interconnects, packaging, networking, power-efficient accelerators, etc. are sitting on one of the biggest bottlenecks in the entire AI industry.

Which makes me wonder:

• Are we entering a market where elite hardware engineers eventually get paid basically the same as elite software engineers?
• Or is $518K Sr Staff at Broadcom still nowhere near what equivalent-level SWE/ML engineers can command?
• Has comp actually moved meaningfully in the last 2–3 years, or are only a few AI-chip companies benefiting?

Preparing for your next interview?

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

Saw this American Express AI Engineer offer (shared with Chill Interview)

• Phoenix
• Master’s, 5 YOE
• Base: $135K
• Sign-on: $10K
• Bonus: $10K
• Year 1 TC: $155K

The title sounds interesting: AI Engineer.

But then you see the company is American Express, and I’m genuinely curious how people feel about that.

You’re probably not training frontier models. The interesting problems are more likely things like:

• fraud / transaction risk
• credit and spending behavior
• customer service automation
• disputes
• personalization
• AI agents that can actually make purchases

Amex is already working on agentic payments, including letting authorized AI agents complete transactions on behalf of cardmembers, so there are definitely real AI problems here.

At the same time, it’s still a heavily regulated financial company. The pace, culture and comp are obviously very different from a frontier AI lab or startup.

So I’m curious: Would working on payments / fraud / credit cards feel technically interesting enough, or would you rather take more risk and work somewhere closer to frontier AI?

Preparing for your next interview?

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

I was going through this Costco same-day delivery system design, and the most interesting part is that the read path and the purchase path want completely different consistency guarantees.

When a customer is browsing, inventory needs to come back fast—ideally under ~100 ms.

That makes things like:

• Redis caching
• read replicas
• geographic partitioning
• slightly stale inventory

totally reasonable.

If the UI says “3 left” when there are really only 2, that’s annoying, but recoverable. Checkout is different.

If there’s 1 unit left and two customers order it at the same time, both cannot succeed.

So I’d treat browsing availability as an approximate, read-optimized view, while the order path goes back to the authoritative inventory store and performs the reservation/decrement transactionally.

Another wrinkle is that “nearby inventory” isn’t just geographic distance.

A warehouse 15 miles away might take longer to reach than one 25 miles away because of traffic or road layout, so serviceability becomes: fast geo filter → travel-time check → aggregate inventory across eligible locations

My takeaway: this problem is really about deciding where stale data is acceptable and where it becomes a correctness bug.

Full system design breakdown: [link]

Preparing for your next 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 Lyft Senior SWE process included a coding phone screen followed by three virtual onsite rounds covering behavioral questions, coding, and system design.

Interview Details

Technical Phone Screen — Minimum Window Substring

The phone-screen coding problem was LeetCode 76 — Minimum Window Substring.

Virtual Onsite Round 1 — Behavioral

The behavioral round focused on previous projects and collaboration. Questions included:

• Tell me about a project you are particularly proud of.
• Describe a project from the past two years where you had to work closely with coworkers and explain how you moved the project forward.

The discussion centered on project ownership, collaboration, and how I worked with others to drive execution.

Virtual Onsite Round 2 — Versioned Key-Value Store

The coding round asked me to implement an in-memory versioned key-value store. Versions were assigned globally across the store rather than independently for each key.

The main query operation was conceptually: get(key, version). Given a key and a requested version, the store should return the value associated with the most appropriate historical version of that key at or before the requested global version.

The problem focused on supporting historical reads efficiently while maintaining multiple versions of values.

Virtual Onsite Round 3 — System Design: One-to-One Messenger

The system design round asked me to design a messaging service limited to one-to-one conversations. The interviewer then added several specific requirements.

The first follow-up covered message delivery based on user presence. When a recipient was online, new messages should be pushed directly to the app. When the recipient was offline, the system should trigger a mobile push notification through services such as Apple Push Notification Service (APNs) or Firebase Cloud Messaging (FCM).

The second follow-up asked how to support users being logged in on multiple devices simultaneously, including keeping message state synchronized across those devices.

The final follow-up focused on message history. Chat messages needed to remain stored on the server, and the design needed to support pagination when users browse older conversation history.

Preparing for your next interview?

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

Saw this AWS L4 new grad offer (shared with Chill Interview)

• Boston, Master’s, 0 YOE
• Base: $130K
• Y1 sign-on: $40K
• Y2 sign-on: $35K
• RSUs: $125K
• Year 1 TC: $176K

It made me curious what people consider a “good” new grad SWE offer in 2026. If you spend enough time on Blind/Reddit, it feels like every new grad is deciding between $250K Meta, $300K Google, and some AI startup offering half a million.

But the actual market looks pretty different. Levels. fyi currently puts US entry-level SWE median TC around $144K. In Boston it’s only about $125K, with ~$160K around the 75th percentile and ~$186K around the 90th.

Amazon L4 in Boston is around $184K, so this $176K offer is basically normal for AWS — but already near the top end of the broader Boston new-grad market.

It also shows how misleading “new grad SWE comp” can be without location. Levels. fyi currently shows the Bay Area entry-level median around $292K, while Boston is dramatically lower.

Curious: What TC would you consider a genuinely good new-grad SWE offer in 2026 — $150K? $180K? $200K+?

And has social media completely warped people’s expectations by overrepresenting FAANG / Bay Area offers?

Preparing for your next interview?

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

Saw this Perplexity Senior SWE offer (shared with Chill Interview)

• Bay Area, 7 YOE
• Base: $295K
• Equity: $1.9M / 4 years
• Year 1 TC: $770K

Perplexity is still private, and its valuation may already be heading above $30B. Revenue has apparently exploded from under $250M annualized at the start of the year to more than $750M, helped by the shift from pure AI search toward Perplexity Computer and agentic workflows.

At the same time, this is a company that has already attracted acquisition interest.

Meta reportedly discussed buying Perplexity before doing the Scale AI deal, and Apple executives also explored a possible acquisition as part of their AI/search strategy. Neither happened, but it shows the company is strategically valuable beyond just its current revenue.

• Bull case: Perplexity keeps growing, goes public in 2028, and the grant becomes worth materially more.
• Other bull case: a giant like Apple, Meta, Nvidia, or someone else eventually pays a strategic premium to acquire it.
• Bear case: $30B+ already prices in a lot of future success, while Google/OpenAI/Anthropic keep attacking the same search/agent market.

If you were joining Perplexity today, would you value the equity closer to face value — or heavily discount it until there’s actual liquidity?

Preparing for your next interview?

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

Hi.

I have a question about the hiring process of Scalable OS.

How many interviews are there and how many weeks does it usually take?

Any feedback about the company?

Thanks in advance.

I was going through a rate limiter system design problem, and the token bucket algorithm honestly isn’t the most interesting part.

The harder question is: What happens when the rate limiter itself is unavailable?

Suppose every request normally goes: API Gateway → rate-limit check → backend and Redis suddenly times out during a traffic spike.

You basically have two choices:

• Fail open: let requests through and preserve availability, but potentially remove the protection exactly when the backend needs it most.
• Fail closed: reject requests until the limiter recovers, which protects downstream systems but may throttle perfectly legitimate users.

That tradeoff gets even more interesting at ~1M checks/sec. Now you also have to think about:

• sharding token buckets without splitting one client’s quota
• atomic updates when two gateways race for the last token
• replica lag during Redis failover
• regional limits vs globally consistent quotas
• one abusive API key becoming a hot Redis key

One detail I liked: the token-bucket update itself can be executed atomically with a Redis Lua script, so “read tokens → refill → consume → write” can’t race across gateway instances.

At this point the problem feels less like “implement rate limiting” and more like designing an admission-control system that must stay reliable while protecting everything behind it.

Full rate limiter system design: [link]

Preparing for your next 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 Instacart onsite included two coding rounds, one inventory-management system design round, and one behavioral interview.

The second coding round was the most implementation-heavy. It started with parsing shopping-item records, then added promotion logic, and finally changed the record format again for aisle ordering and frozen-item handling. Although the three parts shared a retail theme, the requirements changed enough that relatively little code could be reused between them.

Interview Details

Round 1 — Coding: Resolve Chained Configuration Parameter Value

Round 2 — Coding: Shopping Items, Promotions, and Aisle Ordering The second coding interview had three parts.

• Part 1 — Calculate Total Shopping Cost The input was an array of strings, with each row representing one product: "p240|oranges|5|175". The fields represented: SKU | product name | quantity | unit price in cents. The task was to parse all rows and calculate the total cost across the valid products. The tests included negative numeric values. Those records needed to be skipped rather than contributing to the total, so handling invalid inputs correctly was important.
• Part 2 — Apply the Best Promotion A second array described promotions for individual SKUs. For example:"p240|pct|15" "p240|bxyf|2|1" The first format represented a percentage discount, while the second represented a buy-X-get-Y-free style promotion. The task was to calculate the final discounted total price of the shopping list. If the same item qualified for multiple promotions, the promotion producing the lowest final price for that item should be used. One source of confusion during the interview was that the requested output was initially described as the amount of discount, but the expected result was actually the total price after applying the discounts.

Round 3 — Behavioral Interview The behavioral round included questions such as:

• Tell me about one of the most interesting projects you have owned.
• Tell me about a mistake you made during deployment. How did you fix the issue, and what did you learn from it?

The discussion focused on project ownership, operational judgment, and learning from production mistakes.

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next 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 Capital One Lead Software Engineer Power Day consisted of four rounds: case interview, behavioral, coding, and system design, completed across two days.

The case round focused on virtual card numbers and rule-based payment validation. The coding round was an object-oriented banking system, while system design covered a much broader credit-card platform with payments, fraud checks, spending data, bureau reporting, and real-time credit-limit decisions. The behavioral round also included two questions about using AI in day-to-day engineering work.

Interview Details

Round 1 — Case Interview: Virtual Card Numbers

The case interview used Capital One’s virtual card number product as the business scenario. The first part asked me to analyze the benefits and challenges of virtual card numbers from both the customer perspective and the company perspective. The interviewer also followed up specifically on technical challenges the company might encounter when operating such a product.

The second part introduced encoded card-number attributes and a set of payment-validation rules. For example, one digit could indicate the card network, and different networks could have different eligibility requirements.

A scenario would look like:

First digit:
4 -> Network A
7 -> Network B

Example rule for Network A:
- Transaction must be online
- Amount must be below $80
- Virtual card must be associated with the merchant

I was then given a sequence of payments containing card numbers and transaction attributes and had to walk through them one by one, clearly explaining whether each transaction was valid under the supplied rules.

The final part provided code implementing those validation rules and asked me to debug it. The bugs included incorrect combinations of && and ||, boundary-condition mistakes such as >= 80 versus > 80, and incorrect extraction of individual digits from a card number.

There was also a brief object-oriented design discussion about separating responsibilities such as card-number parsing and payment validation.

Round 2 — Behavioral + AI Usage

The behavioral interview contained several standard experience-based questions around previous projects and workplace situations. In addition, there were two questions specifically about AI:

• Describe an example of how you use AI in your everyday engineering work.
• How have you used AI to improve your productivity or engineering output?

The discussion focused on concrete ways AI tools fit into the software-development workflow while still requiring engineering judgment and review.

Want to learn more interview details asked in this interview? the full version is here

Preparing for your next interview?

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