Interview experience
Twitter (X) Interview Questions and Answers (2026)
Overview
Section titled “Overview”X’s interview loop is leaner and less standardized post-2022 than old Twitter’s, with heavy emphasis on practical coding and a high-intensity culture check.
X (Twitter) interview process at a glance
Section titled “X (Twitter) interview process at a glance”| Round | Duration | What it tests |
|---|---|---|
| Recruiter screen | 30-45 min | Background, tech stack, and direct fit with X’s high-intensity pace |
| Technical assessment | 60-90 min | Automated coding challenge or longer real-world scenario |
| Technical phone screen | 45-60 min | Live coding with an engineer, often deliberately ambiguous prompts |
| Virtual/onsite - Coding (1-2 rounds) | 45-60 min each | DSA with a practical bent: caches, schedulers, concurrency |
| Virtual/onsite - System design (mid/senior+) | 45-60 min | Feed/timeline, search, or rate-limiting at platform scale |
| Behavioural / hiring manager | 30-45 min | Ownership, speed of execution, fit with a demanding culture |
Recruiter screen and technical assessment
Section titled “Recruiter screen and technical assessment”The recruiter screen (30-45 min) covers background, tech stack, and - candidates report - a fairly direct conversation about whether you’re comfortable with X’s long-hours, high-output culture. Most candidates then get a 60-90 minute automated coding assessment, sometimes stretched into a longer, more open-ended scenario rather than a plain multiple-choice-plus-two-problems test.
Common questions
- Implement an LRU cache
- Build a hit counter / rate limiter
- Task scheduler with a cooldown period
- Array/string problems at medium difficulty
Full round-by-round breakdowns are on the X interview experience page.
Technical phone screen
Section titled “Technical phone screen”A single 45-60 minute live coding round with an engineer. Multiple sources note that interviewers introduce ambiguity into the prompt on purpose - they’re watching how you clarify requirements and communicate your reasoning as much as whether you land the exact right answer.
Common questions
- Sliding-window / two-pointer array problems
- Thread-safe data structure design (concurrency, race conditions)
- Graph traversal (BFS/DFS) variants
- API-design-style prompts drawn from problems the team actually faces
Virtual/onsite: coding rounds
Section titled “Virtual/onsite: coding rounds”One or two further coding rounds in the loop, similar format to the phone screen. Reports consistently describe X moving away from trick-based brain teasers toward problems that mirror real backend/platform work.
Common questions
- Design a data structure supporting insert/delete/getRandom in O(1)
- Detect a cycle in a directed graph
- Concurrent queue or thread-safe counter implementation
- Longest substring / subarray pattern problems
Virtual/onsite: system design (mid-level and up)
Section titled “Virtual/onsite: system design (mid-level and up)”Reported as the most consequential round for mid-level and senior candidates: reasoning about latency, reliability, and scale at very high request volumes, using X’s own product surface as the prompt.
Common questions
- Design the home timeline / feed (fanout-on-write vs fanout-on-read)
- Design real-time tweet search across billions of posts
- Design a notification delivery pipeline (push, in-app, email)
- Design a rate limiter for a public API
Behavioural / hiring manager round
Section titled “Behavioural / hiring manager round”A shorter round (30-45 min) that closes the loop: ownership, how you operate with limited resources, and direct questions about pace and expectations. This is where the post-acquisition culture shift is most explicit in candidate reports - be ready to speak candidly to working at high intensity rather than treating it as a throwaway question.
Common questions
- Tell me about a time you shipped something with incomplete information
- Describe a decision you made under a tight deadline with limited headcount
- How do you handle direct or blunt feedback on your work?
- Why X, specifically now?
Sample answer frameworks for these are on the X HR interview questions page.
The post-acquisition intensity bar
Section titled “The post-acquisition intensity bar”This is the one genuinely distinctive thing about interviewing at X today: the company is dramatically smaller than pre-2022 Twitter (headcount fell an estimated ~80% during the 2022-2023 layoffs, before recovering to roughly 2,800 by end of 2024), and Musk’s initial “extremely hardcore” mandate - long hours at high intensity - has been echoed in multiple 2024-2025 reports about continued long-hours norms and stock/equity tied to performance. The March 2025 all-stock merger with xAI (valuing the combined entity above $100B) folded X’s engineering org further into an AI-first roadmap. Practically, this means interviewers are evaluating pace and resilience as directly as technical skill, and candidates who can’t speak concretely to thriving in a lean, fast-moving team tend to get filtered here rather than in the coding rounds.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Design a data structure supporting insert, delete, and getRandom in O(1).
Combine a dynamic array holding the values with a hash map from value to its index in that array. insert appends to the array and records the index. delete looks up the index, swaps the last element into that slot, updates the moved element’s index in the map, pops the array, and erases the key - that swap-with-last is what makes deletion O(1) instead of O(n). getRandom picks a uniform index into the array. Every operation is O(1) average and space is O(n); the follow-up allowing duplicates replaces the map’s value with a set of indices, which keeps the same asymptotics with more bookkeeping.
Q: Implement a hit counter that reports the number of hits in the last five minutes.
For modest traffic, keep a queue of timestamps, push on each hit, and pop from the front while the head is older than 300 seconds, then return the queue size - amortised O(1) per hit but O(n) memory in the window. For high throughput, use a circular buffer of 300 buckets, each holding a second’s timestamp and count: on a hit, index by time modulo 300 and either increment the bucket or, if its stored timestamp is stale, reset it to the current second with count one. Counting sums the buckets whose timestamps fall inside the window, which is O(300) with O(300) fixed memory regardless of traffic. Mention thread safety - the buckets need atomic increments or per-shard counters - since concurrency follow-ups are standard here.
Q: Given a list of tasks and a cooldown n, find the least number of intervals needed to execute them.
The answer is driven by the most frequent task. Let maxCount be the highest task frequency and k the number of tasks tied at that frequency. Arranging the most frequent task first creates maxCount minus 1 gaps of length n plus 1, giving (maxCount - 1) times (n + 1) plus k as a lower bound. If there are enough distinct other tasks, they fill the idle slots and the answer is simply the total number of tasks, so take the maximum of the formula and the task-list length. Counting frequencies is O(n) time and O(1) space over a fixed alphabet. If you must output the actual schedule rather than the count, use a max-heap of remaining counts plus a cooldown queue instead.
Q: How do you detect a cycle in a directed graph?
Run DFS with three colours: white for unvisited, grey for on the current recursion stack, and black for fully explored. An edge to a grey node is a back edge and proves a cycle - the union-find approach used for undirected graphs does not work here, and a plain visited set gives false positives on a diamond-shaped DAG. Time is O(V + E) with O(V) space. The iterative alternative is Kahn’s algorithm: repeatedly remove nodes of in-degree zero, and if fewer than V nodes come out, the remainder forms a cycle - which conveniently gives you a topological order as a by-product when there is none.
Q: How would you implement a thread-safe counter, and what are the trade-offs?
The simplest correct version guards the increment with a mutex, but under contention every thread serialises on one lock. An atomic integer using a compare-and-swap or fetch-and-add is faster because it avoids kernel-level blocking, yet at very high core counts all cores still contend for the same cache line, so throughput collapses from false sharing and cache-line ping-pong. The scalable answer is a striped or per-thread counter - Java’s LongAdder or a padded per-core array - where each thread increments its own cell and a read sums the cells, trading exact real-time reads for write throughput. Note that a volatile variable alone is not enough: it guarantees visibility, not atomicity of read-modify-write.
Q: Design the home timeline for a service with hundreds of millions of users.
The core choice is fanout-on-write versus fanout-on-read. Fanout-on-write pushes each post into every follower’s precomputed timeline list in a cache such as Redis, making reads a single fast range query - correct for the vast majority of accounts. It breaks for celebrity accounts with tens of millions of followers, where one post causes a write storm, so those accounts are handled with fanout-on-read: their posts are merged into the timeline at query time. The production design is hybrid, with a follower-count threshold selecting the path per author. Timelines are capped at a few hundred entries, ranking runs as a separate scoring pass over the merged candidates, and the whole thing is eventually consistent - a post appearing a few seconds late is acceptable.
Q: How would you build real-time search across billions of posts?
Use an inverted index mapping each term to a posting list of document ids, sharded by document so every shard searches its own slice in parallel and a scatter-gather aggregator merges the top-k results. Real-time freshness needs a two-tier design: a small in-memory index over the last few hours that accepts writes immediately, plus larger immutable segments built in the background and periodically merged, which is essentially how Twitter’s Earlybird worked. Index only what you must, compress posting lists with delta encoding, and store documents in reverse-chronological id order so early termination can stop once enough recent hits are found. Rank with a cheap first-pass score, then re-rank the top candidates with an expensive model, and keep a separate cache for the head of the query distribution.
Q: Design a rate limiter for a public API.
Token bucket is the standard: per API key store a token count and a last-refill timestamp, refill lazily at a fixed rate up to a burst capacity, and reject with 429 plus a Retry-After header when no token is available. It allows a controlled burst while bounding sustained rate, and it costs two fields per key. Distributed enforcement needs the check-and-decrement to be atomic, so run it as a Redis Lua script or use per-node quotas equal to the global limit divided by node count, accepting some slack in exchange for removing a network hop. Decide the failure mode deliberately - failing open keeps the API up when the limiter store is down but exposes you to abuse. Layer limits by key, by IP, and by endpoint cost so one expensive route cannot be hammered within a generous global limit.
Frequently asked questions about X (Twitter) interviews
Section titled “Frequently asked questions about X (Twitter) interviews”What is the X (Twitter) interview process in 2025-2026?
X’s loop is leaner than pre-2022 Twitter and reportedly runs: 1. Recruiter screen (30-45 min) - background, tech stack, and a direct check on fit with X’s long-hours, high-intensity culture. 2. Technical assessment (60-90 min) - an automated coding challenge, sometimes a longer take-home-style scenario. 3. Technical phone screen (45-60 min) - live coding with an engineer, often deliberately ambiguous prompts. 4. Virtual/onsite loop (2-4 rounds) - coding, system design (mid/senior+), and a behavioural round. Public reporting on exact round counts is thin and inconsistent post-acquisition, so treat this as a directional map, not a fixed script.
What questions are asked in X (Twitter) interviews?
Coding rounds lean on practical, job-relevant problems over trick puzzles: LRU cache, hit counter / rate limiter, task scheduler with cooldown, and concurrency-flavoured problems (thread-safe structures, race conditions). System design centers on X’s own domain: home timeline / fanout, real-time search (historically built on Earlybird), notification pipelines, and rate limiting at platform scale. Behavioural questions probe ownership, speed of execution, and comfort with a high-pressure, resource-constrained environment.
How many rounds are there in the X (Twitter) interview?
Most 2025-2026 reports describe 3-6 total touchpoints: a recruiter screen, a technical assessment, a technical phone screen, and a virtual/onsite loop of 2-4 rounds (coding, system design, behavioural). Exact counts vary by team and level, and public data since the 2022 acquisition and 2025 merger with xAI is sparser than for most FAANG peers - confirm your own loop with the recruiter rather than assuming a fixed number.
Does X (Twitter) still hire engineers in India?
Uncertain and much smaller than pre-2022. Twitter’s Bengaluru engineering presence was heavily cut during the 2022-2023 layoffs (headcount fell roughly 80% company-wide). Since the March 2025 xAI-X merger, most reported India engineering hiring (including a Bengaluru office) is under the combined xAI Holdings entity and skews toward AI/ML, infra, and backend roles rather than classic mass campus SDE drives - so don’t assume a traditional India campus-hiring pipeline exists for X specifically.
What is X’s engineering culture like after the Musk acquisition and xAI merger?
Widely and consistently reported as high-intensity: Musk’s late-2022 ‘extremely hardcore’ memo set an expectation of long hours at high output, and multiple 2024-2025 reports describe continued long-hours norms and performance-linked equity. In March 2025 X merged into xAI (all-stock deal, combined entity valued over $100B), pushing engineering priorities further toward AI-integrated product work. Interviewers reportedly screen directly for comfort with this pace during the recruiter screen and behavioural round.
How should I prepare for X (Twitter) interviews?
Drill practical coding patterns (LRU cache, rate limiters, scheduler/cooldown problems) rather than obscure puzzles, be ready to reason about concurrency and thread safety, and prepare one system design narrative around a large-scale feed/timeline or search system since that’s the most consistently reported design topic. For behavioural rounds, prepare concrete examples of moving fast with limited resources and owning outcomes end-to-end - and be candid that you’re aware of, and fine with, X’s demanding pace.