How X interviews — Question to Offer

1. The shape of an X loop

X is the smallest engineering org in this course. Post-Musk, the company runs lean — somewhere near a tenth of its old headcount. That changes the interview shape more than people expect. There is no committee, no calibration body, no bar raiser. The hiring manager decides, and they decide fast.

A standard loop is three to four rounds, often run inside a single week. One round is system design, one is coding, one is hands-on debugging or "build something small in 45 minutes," and one is a manager / culture conversation that decides whether you'd survive the pace. L4 candidates skip one of the technical rounds. L6 candidates pick up a second design round.

The system design round at X is almost always "design something we already have." Timeline, trending, DMs, t.co, Spaces. They want to see you draw their own system, defend the choices they actually made, and name the tradeoffs they actually hit. Knowing X's history (the original Ruby monolith, the move to Scala, the unbundling into Manhattan + Earlybird + FlockDB) is a real advantage.

2. What X grades you on

Three signals, ranked by how much they weigh:

Shipping speed. Can you make a decision and move? X interviewers will push you to commit to a primitive within two minutes of the question. Hedging reads as bad here. Hedging at Google reads as careful; at X it reads as slow.
Engineering taste. Specifically, the taste to pick the simpler answer when both work. "I'd just use Redis" wins over a five-page distributed system if Redis would actually work. The reverse is also true — if the simpler answer doesn't scale, you'd better know the breaking point in numbers.
Honesty about what you don't know. Engineers who fake distributed systems vocabulary lose points fast here. The interviewer is usually a working engineer on the team that ships the thing you're designing. They will catch you.

The Googleyness equivalent at X is sometimes called "hardcore." It's a culture filter, not a skill filter. The question they're answering is: can this person ship a feature end to end, on call, on a Saturday, without complaining about it.

3. What's different here

Faster cycles. Recruiter screen Monday, onsite Friday, offer or rejection by the following Tuesday. Some loops finish in five business days. Plan for it.
Smaller teams own bigger surfaces. The team that owns timelines also owns trending and probably the ranking pipeline. Your interviewer has shipped code in three or four of these areas. Design answers that respect cross-system dependencies score well.
The questions are unusually concrete. "Design Twitter" at most companies is a metaphor. At X, "design the home timeline" means design our home timeline. The interviewer will compare your answer to the real one.
No staff-level committee polish. L6 at X is more like senior-plus at Meta. You're not expected to operate at "drive the org" altitude. You're expected to operate at "own this system end to end, fix it at 3am, mentor two engineers."
Performance over process. Process answers ("I'd file an RFC, get a design review, set up an oncall rotation") read as drag here. Lead with the system, not the process.

4. The level bar

How the bar shifts:

L4 (mid-level) — design at the competent IC level. One subsystem deeply. You scope, name a primitive correctly, and survive one push on the deep dive.
L5 (senior) — design at the team-owner level. You bring up the celebrity case unprompted on the timeline question. You name a non-obvious failure mode. You survive three pushes on at least one deep dive.
L6 (staff) — design at the cross-system level. You connect the question to two adjacent X systems (timeline depends on the follower graph depends on the spam pipeline). You name the inversion case for every major choice and propose a migration plan when you'd flip the design.

In this chapter the units target L5 unless the question naturally pushes higher — DMs and celebrity-aware fan-out are L6 by default.

5. The X-flavored mistakes

Watch for:

Over-engineering the trivial path. Proposing Kafka + Flink for trending detection when a Redis sorted set with a 5-minute rolling window covers most of it. The interviewer wants the simple answer first, then the upgrades.
Ignoring the directional follow graph. X's follower edges go one way. A celebrity has many followers, not many friends. Designs that assume Meta-style symmetric friendship are wrong from the first slide.
Forgetting the celebrity tail. "Push for everyone" is the wrong answer here in a way it isn't quite at Meta. A user with 100M followers exists on X. Their post cannot be fanned out 100M times.
Skipping spam. X has a serious spam and bot problem and the team interviewing you knows it. A trending or timeline design that doesn't mention abuse signals reads as junior.
Solo-driving through the round. X interviewers check in. They will steer. Going head-down for ten minutes without checking in reads worse here than at Google because the interviewer is the decider, not the committee.

6. The seven scenarios in this chapter

Each unit dissects one question. The chapter covers:

13.1 The timeline — fan-out write vs read. The canonical X question. Push, pull, hybrid.
13.2 Trending topics. Rolling-window velocity, per-region, anti-spam.
13.3 DMs with E2E encryption. The Premium feature. Mixed-mode E2E and non-E2E.
13.4 Celebrity-aware fan-out. The L6 version of 13.1. The threshold, the merge, the read path.
13.5 URL shortener — t.co. The classic shortener question with X's specific reasons.
13.6 X Spaces — live audio rooms. Hosts, speakers, listeners, real-time audio.
13.7 Take-home: celebrity-aware fan-out service. TypeScript code. Build, test, ship.

7. The next page

The first scenario: the home timeline. The single most-asked X question and the one your interviewer will compare to the real thing.