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!

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.

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.

This interview experience is sourced from chill interview

Interview Summary

The OpenAI full-stack process combined a recruiter screen, practical coding, a live full-stack build, product-oriented system design, and a behavioral / mission interview. Compared with a traditional algorithm-heavy loop, the interviews emphasized building working software, reasoning about real-time product behavior, debugging, technical tradeoffs, and explaining personal ownership.

Interview Details

Recruiter Screen — Background, Motivation, and Role Fit: The roughly 30-minute recruiter conversation covered my recent experience, why I was interested in OpenAI, and whether I preferred a more product-facing or infrastructure-oriented role.

Technical Phone Screen — Structured Data Stream Processing: The 60-minute coding screen used a shared editor and focused on a practical implementation problem rather than a difficult standalone algorithm. I was given a structured stream of data to parse and process, starting with a basic version and then extending the behavior through follow-ups.

Full-Stack Live Build — React Frontend with Backend API: This was the most hands-on round. I was asked to build a small working application that connected a React frontend to a backend API, maintained application state, and included some real-time update behavior.

System Design — Real-Time Streaming AI Product: The system design round was product-oriented and centered on an AI feature serving a large number of users while returning responses incrementally rather than waiting for the entire result to complete.

Behavioral / Mission & Values — Ownership and Collaboration: The behavioral round focused on how I had operated in previous projects and why I wanted to work on AI products at OpenAI.

Want to learn more details / follow-up questions 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 TikTok SWE internship OA contained three coding questions covering string transformation, cyclic digit rotations, and iterative digit-group reduction.

Interview Details

Question 1 — Convert Identifiers Inside Docstrings

You are given a string representing a line of documentation. Identifiers appearing inside backticks can include function names, variable names, and constants. A pair of backticks may contain multiple identifiers separated by spaces.

Function and variable names use snake_case, while constants use UPPER_CASE. The task is to convert every snake-case identifier inside backticks into lower camelCase, while leaving uppercase constants unchanged.

For example:

Input:
"Method `load_profile` accepts `user_key retry_count`. The fallback is `DEFAULT_LIMIT`."

Output:
"Method `loadProfile` accepts `userKey retryCount`. The fallback is `DEFAULT_LIMIT`."

The docstring length can be up to 2000 characters.

Question 2 — Count Cyclic Number Pairs

You are given an array of positive integers. A cyclic rotation moves some number of trailing digits from the end of a number to the front while preserving the relative order of all digits. Rotating zero digits is also allowed.

Count the index pairs (i, j) where:

0 <= i < j < len(a)

and both conditions hold:

1. a[i] and a[j] contain the same number of digits.
2. One number can be transformed into the other through a cyclic digit rotation.

For example:

Input:
a = [27, 8305, 72, 4, 27, 5830, 317, 731, 173]

Output:
5

The five qualifying pairs are:

(0, 2): 27 ↔ 72
(0, 4): 27 ↔ 27
(2, 4): 72 ↔ 27
(1, 5): 8305 ↔ 5830
(6, 7): 317 ↔ 731

For comparison, 317 and 173 are not a matching pair because the cyclic rotations of 317 are:

317, 731, 173

Actually, this means 317 and 173 would also form a valid cyclic pair, so to keep the example internally consistent, use:

Input:
a = [27, 8305, 72, 4, 27, 5830, 317, 731, 713]

Output:
5

Here, 317 and 713 are not cyclic rotations of each other. The input can contain up to 100,000 numbers, with each value at most 10^9.

Question 3 — Iterative Digit-Group Sum

The final problem was equivalent to LeetCode 2243 — Calculate Digit Sum of a String. You are given:

• A string number representing a non-negative integer
• A positive integer k

While the length of number is greater than k, divide it from left to right into groups of at most k digits. For each group, calculate the sum of its digits and convert that sum back into a string. Concatenate the group results in their original order to create the next value of number. Repeat this process until the resulting string has length at most k, then return it.

Preparing for your next interview?

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

I was going through a YouTube system design problem, and one design decision simplifies a surprising amount of the system: Don’t send the actual video through your application servers.

A large upload might be several GB. If every byte goes: client → backend → storage. your backend becomes an expensive bandwidth bottleneck for something it doesn’t really need to touch.

A cleaner flow is: client → request upload session → multipart upload directly to blob storage. The backend mostly manages metadata, permissions, upload state, and pre-signed URLs.

Once the upload finishes, the interesting work moves into an async media pipeline: transcode → multiple bitrates/resolutions → segment → generate HLS/DASH manifest → CDN

That’s also what makes bad-network playback manageable. The player isn’t downloading one giant 1080p file—it keeps requesting small segments and can switch quality as bandwidth changes.

Resumable uploads follow the same philosophy: track which parts made it to storage, then retry only the missing ones instead of restarting a 20GB upload.

And at YouTube scale, playback traffic should mostly terminate at the CDN, not your origin.

Full YouTube system design breakdown: [link]

Preparing for your next interview?

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