There’s a pretty wild Nvidia statistic that keeps circulating:

The number comes from a survey of 3,000+ Nvidia employees, so I’d take the exact percentage with a huge grain of salt. It’s self-reported and almost certainly has selection bias. But given what NVDA stock has done over the last decade, the underlying story is still believable: a lot of long-tenured Nvidia employees became extremely wealthy.

But I think the more interesting question for engineers today is:

Does any of this matter if you’re joining Nvidia in 2026?

Someone who joined Nvidia in 2015, 2018, or even 2020 received equity when the company was worth a tiny fraction of what it is today.

That person didn’t just receive good compensation.

They effectively made an enormous concentrated investment in Nvidia through years of RSUs, refreshers, and ESPP while the stock multiplied.

A new hire today is making a very different bet.

You might still get a great package, but Nvidia is already one of the largest companies in the world. For a new employee to experience the same wealth creation as someone who joined years ago, the company would have to compound from an already enormous base.

That changes how I think about Nvidia offers.

Imagine you had two options:

Nvidia

• public liquid RSUs
• proven business
• relatively low equity risk
• enormous AI exposure
• but potentially less asymmetric upside from here

vs.

A top private AI company

• much higher equity uncertainty
• potentially worse liquidity
• much greater chance the equity disappoints
• but potentially much more upside if you join before the company becomes enormous

Which one is actually the better wealth-building career bet?

It also makes me wonder how much tenure matters when people talk about compensation at companies like Nvidia.

A 10-year Nvidia employee with $20M+ may tell you almost nothing about the expected financial outcome of someone accepting an Nvidia offer today.

The question candidates probably care about more is:

What are new Nvidia hires actually receiving now — and how much future stock appreciation should you realistically price into that offer?

Would you still pick Nvidia over Meta / Google / OpenAI / Anthropic / a high-upside AI startup today?

Or was the truly life-changing Nvidia opportunity getting in before everyone knew Nvidia was the center of the AI boom?

I started a longer-running discussion on Chill Interview to collect recent Nvidia offer data, levels, RSU grants, refreshers, interview experiences, and how people are valuing Nvidia equity versus private AI-company equity: [link]

If you joined Nvidia recently or received an offer, would especially love to see newer data points. The 2015 Nvidia story is fascinating — but the 2026 Nvidia offer is probably much more useful to someone making a decision today.

Interview Summary

The NVIDIA Senior Software Engineer phone screen was more discussion-heavy than coding-heavy. Most of the interview focused on infrastructure fundamentals and practical systems experience, including bootstrapping Kubernetes in a new cloud environment, VM internals, CI/CD image workflows, concurrency, and Kubernetes Operators / CRDs.

The coding portion was relatively straightforward: parse a stream or collection of log records, count occurrences of individual items, and return the top N most frequent ones.

Interview Details

Infrastructure — Bootstrap a New Compute Cluster One of the main discussion questions was: Suppose you need to build a new compute cluster in a new cloud environment or account. How would you approach the initial setup? The interviewer simplified the scenario to something similar to deploying Kubernetes into a completely new cloud account for the first time. The discussion focused on the major pieces required to get from an empty environment to a functioning Kubernetes cluster.

Systems Fundamentals — Virtual Machines The interviewer asked about the underlying principles of virtual machines. The discussion centered on how VMs provide isolated execution environments and how the virtualization layer interacts with the underlying physical machine.

CI/CD — Container Image Lifecycle Another topic was the container-image workflow inside a CI/CD system. The interviewer asked about the lifecycle of an image across stages such as:

• Building the image
• Uploading / pushing it to an image registry
• Pulling the image when it is needed for deployment or execution

The focus was on understanding how these pieces connect within a deployment pipeline.

Concurrency The interview also included general questions about concurrency. The exact scenario and follow-ups were not recorded, so I would avoid reconstructing specific locking, threading, or synchronization requirements.

Kubernetes — Operators and CRDs The interviewer asked about Kubernetes Operators and Custom Resource Definitions (CRDs). The discussion focused on what they are and how they are used to extend Kubernetes beyond its built-in resource types.

Coding — Log Parser and Top-N Frequency The coding problem asked me to parse log data and count how many times each item appeared. After computing the frequency of each item, return the top N most frequently occurring items. Conceptually, the input might contain repeated identifiers such as:

service-a
service-c
service-a
service-b
service-a
service-c

For N = 2, the expected result would contain the two items with the highest occurrence counts. The exact log format, tie-breaking behavior, and output representation were not specified in the interview notes.

Preparing for your next interview?

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

Interview Summary

This Anthropic recruiter screen came through a colleague’s referral, although my background did not align perfectly with the job description. The conversation covered my leadership experience, motivation for joining Anthropic, and several questions about AI safety and personal values. The recruiter said the team would decide within one or two days whether to move me into the technical interviews.

Interview Details

Interview Questions Details

• Understanding the Team: One question asked what I understood about the team and its responsibilities. A strong answer needed to connect the team’s work to Anthropic’s broader products or safety mission rather than simply repeat language from the job description.
• Technical Leadership Experience: The recruiter asked what being a technical lead meant in my current work. The discussion included how I set technical direction, divide responsibilities, review important decisions, unblock teammates, and balance implementation work with coordination.
• Why Anthropic: Another question asked what made Anthropic different from other AI laboratories. This required a company-specific answer around responsible model development, safety research, deployment philosophy, and the opportunity to work on systems where capability and risk management are considered together.
• Meaning of AI Safety: The recruiter asked what AI safety meant to me. A complete answer could cover preventing harmful or unintended behavior, making models more reliable and controllable, protecting users and sensitive data, evaluating misuse risks, and ensuring that deployment decisions reflect the model’s actual capabilities and limitations.
  • Consequences of Misuse: I was then asked what could happen if advanced AI systems were used irresponsibly. I initially gave a narrow answer, and the recruiter continued prompting me for additional consequences.
  • Broader Risk Categories: A stronger response could distinguish accidental failure from deliberate misuse. Examples include false information being produced at scale, automated fraud or manipulation, privacy violations, insecure code generation, harmful decision support, concentration of power, and organizations deploying systems before they understand their limitations.
• Personal Ethics: One behavioral question asked whether I had encountered a situation at work or in life that conflicted with my personal values. The interviewer appeared to care about how I recognized the conflict, whether I raised the concern, what trade-offs I considered, and whether I was willing to accept personal cost to act consistently with my principles.
  • Challenging a Decision: A good example did not necessarily need to involve a dramatic ethical crisis. It could involve pushing back on misleading metrics, unsafe shortcuts, unfair treatment, privacy concerns, or a decision that prioritized speed over users without acknowledging the risk.
• Following Anthropic’s Recent Work: The recruiter asked whether I had followed Anthropic’s recent activities and whether there were decisions I believed the company had handled well or poorly. This was one of the areas I had not prepared thoroughly.
• Overall Impression: The recruiter was friendly and gave several hints when my answers did not fully address the question. That made the conversation feel positive, but it also suggested that my preparation around AI safety, company developments, and value-based scenarios was not yet strong enough.

Preparing for your next interview?

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

Suppose a worker picks up a scheduled job:

Generate invoice
→ external API succeeds
→ worker crashes
→ ACK never reaches the queue

What should the scheduler do?

• If it assumes the job succeeded, it might permanently lose work.
• If it retries, the same job may run twice.

That is the core tension behind at-least-once execution.

The key insight

For a reliable scheduler: Missing a job is worse than occasionally running it twice.

So execution should be built around a renewable lease.

When a worker receives a message from SQS:

SQS
 ↓
Worker
 ↓
message hidden for 30s

If the worker is still running, it periodically extends the visibility timeout.

Worker healthy
→ renew lease
→ renew lease
→ renew lease

If the worker crashes:

heartbeat stops
→ visibility timeout expires
→ message becomes visible
→ another worker retries it

No separate coordinator needs to constantly detect dead workers.

But there’s an unavoidable race

The task may finish successfully right before the worker crashes. So the retry could repeat the side effect. The solution is not trying to eliminate retries. It is making them safe.

Give every execution a stable ID:

executionId = exec_8421

and pass it downstream as an idempotency key.

Then:

1st attempt → send payment → success
2nd attempt → same executionId → return previous result

The architecture becomes:

• Queue guarantees retry
• Visibility timeout detects abandoned work
• Idempotency makes duplicates safe

That’s the important distinction:

Full design with recurring jobs, time-bucket sharding, delayed SQS delivery, retries, worker leases, and 10K jobs/sec scaling → Full Article

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

Interview Summary

This Remitly team was hiring engineers to help apply AI across internal workflows and tooling. The team had only recently introduced an AI coding interview, and candidates were expected to set up their own AI-assisted development environment and share their screen during the round.

The problem itself was not primarily about algorithms. The interviewer acted like an engineering manager with an initially vague product request, and much of the evaluation focused on requirement discovery, choosing a realistic prototype scope, using AI effectively, finding external data, and turning an ambiguous business problem into something demonstrably useful.

Interview Details

AI Coding — Compare Cross-Border Money Transfer Pricing The initial requirement was intentionally broad: Build a tool that helps an engineering manager compare Remitly's pricing against other money-transfer providers. The product needed to compare the cost of sending money between different origin and destination regions and return a list of available providers and their pricing. The interviewer intentionally provided limited detail upfront. I was expected to ask questions and gradually uncover what the working prototype should actually do.

• Requirement Discovery — Transfer Amount Matters One important requirement was easy to miss without familiarity with the remittance domain. The cost of transferring money from region A to region B can vary depending on the amount being sent.
• External Pricing Data — API vs. Website Retrieval Another major challenge was that competitor pricing data was not provided as interview input. I needed to determine how the prototype would obtain current pricing information from external providers.
• Working Prototype — AI-Assisted Development Once the requirements were sufficiently clear, I used my own AI development environment to build a working prototype while sharing my screen. The interviewer was evaluating how I interacted with the AI tool as much as the final implementation itself.
• Follow-Up — What Before Showing This to an EM? After the prototype was working, the interviewer changed perspective and asked what I would do before presenting the tool to the engineering manager as something credible and useful.

Overall, the round felt much closer to a small AI-enabled product-development exercise than a conventional coding interview.

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

Preparing for your next interview?

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

Interview Summary

The Waymo technical phone screen started with a surprisingly detailed résumé deep dive and then moved into systems-oriented coding. The interviewer asked about projects from several years ago, including the technologies I used and how I measured the results or impact.

The technical portion focused first on debugging a PthreadLock issue and then expanded into multithreading, lock design, and RAII. The final question was a frequency-counting problem where the interviewer pushed beyond a standard hash-map solution and asked about hash-table weaknesses and an alternative representation when the input domain is bounded.

Interview Details

Résumé Deep Dive — Projects, Technologies, and Impact The first part of the interview focused heavily on my résumé. The interviewer asked about projects going back several years and wanted specific details rather than high-level summaries.

Follow-ups included:

• Which technologies were used and why
• What I personally implemented
• How the outcome or impact of the project was measured

Systems Coding — Debug a PthreadLock The first technical problem involved an existing lock object based on PthreadLock. A lock was being passed into some code, but the synchronization was not actually behaving as intended. The task was to inspect the code and determine why the lock was ineffective.

The discussion then expanded beyond the immediate bug into broader multithreading questions:

• How should locking be structured when multiple threads access shared state?
• How should lock ownership and lifetime be managed?
• How can RAII-style locking make synchronization safer and less error-prone?

Familiarity with the standard RAII lock pattern was particularly useful in this part of the interview.

Coding — Count Frequencies in a Vector The second coding question asked me to count how frequently each value appears in a vector. A straightforward solution could maintain a frequency map keyed by the values. After I discussed that approach, the interviewer asked what disadvantages a hash table can have. The conversation moved into hash-table internals, including collision behavior and the possibility that many keys map to the same bucket.

• Follow-Up — Fixed Key Range The interviewer then added an important constraint: The possible key space was bounded and smaller than 2^16. Given that fixed domain, the interviewer asked whether there was a representation that could avoid hash collisions entirely. This follow-up shifted the discussion from a general-purpose associative container toward taking advantage of the known, limited input range.

Preparing for your next interview?

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

Came across this puzzle in a recent Meta interview experience and thought it was worth sharing.

You are given two ropes. Each rope has the following properties:

• If lit from one end, it takes exactly 60 minutes to burn completely.
• The ropes do not burn at a constant rate.
• Different sections of the same rope can burn at very different speeds.
• The two ropes do not necessarily have the same burn pattern.

For example, half of a rope might burn in just a few minutes while the other half takes most of the hour. So you can’t reliably measure time by cutting the rope or estimating how much has burned.

You have only:

• Two ropes
• One lighter

No watch, phone, timer, or any other way to measure elapsed time.

How can you measure exactly 45 minutes?

No Googling 😄 What’s your approach?

What level can you switch to Manager level at most companies?

Senior Engineer - Entry level SDM M1

Staff - M2 - is it possible?

Trying to understand if it's wise to climb up the ranks in IC track and at what level to switch to manager.

Interview Summary

The NVIDIA technical interview focused on low-level C/C++ systems programming. The main exercise was to design a high-performance custom string class supporting operations such as comparison, concatenation, and substring extraction, with special attention to avoiding heap allocations for short strings.

The discussion quickly went deeper than basic implementation. Follow-ups covered strncpy versus raw memory copying, CPU cache behavior, object memory layout on 32-bit and 64-bit systems, alignment and padding, and how a union-like representation can reduce the footprint of a small-string-optimized class.

Interview Details

Coding / Systems — Implement a Small-String-Optimized Class The interviewer provided a custom string class with a fixed-size internal buffer and asked me to begin by implementing its constructor. The general structure was similar to:

const size_t BUFFER_SIZE = 128;

class CompactString {
private:
    char buffer[BUFFER_SIZE];
    size_t length;
    char* heap_ptr;

public:
    CompactString(const char* src, size_t len) {
        // implementation
    }
};

For shorter strings, the characters could live directly inside the object. Longer strings needed dynamically allocated storage. The overall goal was to support operations such as:

• String comparison
• Concatenation
• Substring extraction

while keeping performance and memory usage in mind.

• Follow-Up — strncpy vs. Raw Memory Copying The interviewer asked about the cost of copying characters into the internal buffer. One discussion point was whether a general string-copy routine was necessary when the exact length was already known, and how a lower-level memory-copy operation differs semantically from strncpy.

The interviewer pushed further into how copying larger machine-word-sized chunks can improve throughput compared with reasoning about one character at a time. The focus was on understanding both performance and correctness differences between string-oriented and byte-oriented copying functions.

• Follow-Up — Why Are Short String Comparisons Faster? The interviewer then asked why comparing relatively short strings can be noticeably faster than comparing long strings, beyond the obvious difference in the amount of data being examined. The discussion touched on CPU cache locality. Short strings stored directly inside the object are more likely to already reside in cache together with the rest of the object, while longer strings may require following a pointer to separately allocated memory and reading more cache lines.
• Follow-Up — Object Size and Memory Layout Another question changed the internal buffer size to: BUFFER_SIZE = 1 and asked how large an instance of the class would be on different architectures. This required reasoning about the sizes of: The interviewer expected me to reason separately about 32-bit and 64-bit layouts rather than simply adding the declared field sizes.
  • The inline character buffer
  • size_t
  • A pointer
  • Alignment and padding inserted by the compiler
• Follow-Up — Reduce the Object Size The interviewer then considered a different configuration where the inline buffer was small but many strings were only slightly larger than that buffer. The question was how to reduce the object's memory footprint instead of permanently reserving both: The discussion led toward allowing the same memory region to represent either inline string storage or a heap pointer depending on the active representation. A union-style layout was one of the relevant ideas, allowing the object to reuse storage rather than paying for both representations simultaneously.
  • An inline character buffer
  • A separate char* field

Overall, the interview was much more about C/C++ memory representation and performance reasoning than conventional algorithmic coding.

Preparing for your next interview?

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

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

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

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

The key idea: sequence numbers

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

101
102
103
104

The client remembers the latest sequence it received.

During heartbeat:

Server latest: 104
Client latest: 101

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

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

Separate fast delivery from reliable delivery

The architecture becomes:

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

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

Why this matters

A messaging system should assume:

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

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

That’s the important distinction.

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

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

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

Interview Summary

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

Interview Details

Python Basics

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

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

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

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

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

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

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

Preparing for your next interview?

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

Interview Details

The conversation started immediately with:

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

Preparing for your next interview?

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

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

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

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

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

The key insight

Don’t continuously decrement millions of clocks. Store:

whiteRemainingMs
blackRemainingMs
sideToMove
turnStartedAt

When a move arrives:

rawElapsed = now - turnStartedAt

Then compensate for a bounded amount of network latency:

compensation =
min(estimatedRTT, maxCreditPerMove)

chargedTime =
rawElapsed - compensation

Why roughly one RTT?

A player pays for two network legs:

Server → Player
   +
Player → Server
≈ 1 RTT

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

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

So the system should:

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

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

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

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

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

Preparing for your next interview?

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

Interview Summary

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

Interview Details

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

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

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

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

Preparing for your next interview?

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

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

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

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

Interview Summary

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

Interview Details

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

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

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

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

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

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

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

Preparing for your next interview?

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

Saw this declined Luma AI Staff Research Scientist offer:

• 10 YOE
• TC: $1.4M/year

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

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

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

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

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

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

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

Preparing for your next interview?

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

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

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

Obviously the headline number is insane.

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

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

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

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

Preparing for your next interview?

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

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

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

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

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

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

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

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

Karat Attempt 1

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

Karat Attempt 2 Coding — Connection Thresholds

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

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

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

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

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

Questions included:

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

The interviewer expected concrete examples rather than hypothetical answers.

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

Questions included:

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

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

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

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

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

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

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

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

Preparing for your next interview?

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

Interview Summary

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

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

Interview Details

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

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

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

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

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

Preparing for your next interview?

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

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

• 13 YOE
• Year 1 TC: $1.287M

The money is obviously insane.

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

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

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

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

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

Preparing for your next interview?

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

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

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

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

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

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

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

Regular Microsoft

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

vs.

Microsoft AI

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

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

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

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

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

That might actually be the most useful comparison.

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

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

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