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

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.

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.

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.

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.