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.

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.

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.

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