Interview experience
Dream11 Interview Questions and Answers (2026)
Overview
Section titled “Overview”Dream11 runs a 4-5 round DSA-and-system-design-heavy loop typical of a high-traffic consumer product company, with extra weight on designing for the massive, predictable traffic spikes that hit right before live matches.
Dream11 interview process at a glance
Section titled “Dream11 interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online DSA Round(s) | 60-90 min | 2 LeetCode-style DSA problems per round |
| Technical Interview | 45-60 min | DSA (medium-hard), OS/OOPs/DBMS/SQL-NoSQL, projects/internship experience |
| Techno-Managerial / System Design | 45-60 min | Caching, load balancing, CDN, sharding, microservices |
| HR Round | 20-30 min | Fit, career aspirations, offer discussion |
Online DSA round(s)
Section titled “Online DSA round(s)”One or two timed online rounds, roughly an hour each, with 2 DSA problems per round at LeetCode medium-hard difficulty. This is the widest filter in the process.
Common questions
- Array/string/graph problems at medium-hard difficulty
- Time and space complexity trade-off discussion for your solution
- Edge-case handling under time pressure
Technical interview
Section titled “Technical interview”Mixes more DSA with core CS fundamentals - OS, OOPs, DBMS, and both SQL and NoSQL database questions - plus a real deep-dive into your projects or internship work, sometimes including schema design for a feature like a leaderboard or wallet.
Common questions
- Medium-to-hard DSA problems (trees, graphs, hashing)
- OOPs fundamentals and OS concepts (scheduling, concurrency)
- SQL vs NoSQL trade-offs; design a schema for a feature like contest leaderboards or wallet transactions
- Deep dive into your resume project or internship work
Techno-managerial / system design round
Section titled “Techno-managerial / system design round”Built around the concrete scaling problem Dream11 actually has - a huge, predictable spike in traffic right before a live match starts. Expect questions framed around real product surfaces (notifications, leaderboards, wallet) rather than abstract system-design templates.
Common questions
- Design a system to handle a sudden traffic spike right before a big match starts
- Caching strategy and CDN usage for a high-read, bursty-traffic product
- Sharding and the CAP theorem in the context of a wallet or leaderboard service
- Microservices architecture trade-offs for a live-sports product
- Design a real-time leaderboard or notification system
Round-by-round breakdowns are on the Dream11 interview experience page.
HR round
Section titled “HR round”A closing 20-30 minute round on fit, career aspirations, and offer discussion.
Common questions
- Tell me about yourself?
- Why Dream11?
- How would you design a system to handle a sudden traffic spike right before a big match starts?
- Tell me about a feature you’d build to keep users engaged during a live match.
Sample answer frameworks for each of these are on the Dream11 HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How would you design a real-time leaderboard for a contest with millions of users?
Use a Redis sorted set per contest, keyed by contest id with the user id as member and score as the sort key. ZADD updates a score in O(log n), ZREVRANGE fetches the top N in O(log n + N), and ZREVRANK returns a specific user’s rank in O(log n), so both the top-100 view and the my-rank view are cheap. Persist authoritative scores to a durable store asynchronously so Redis can be rebuilt after failure, and shard by contest id since contests are independent. For very large contests, avoid recomputing ranks on every point event by batching score updates on a short interval and serving approximate rank tiers rather than exact rank to users far down the board.
Q: What is the CAP theorem, and what does it mean for a wallet service?
CAP states that a distributed system facing a network partition must choose between consistency and availability - it cannot have both, and partition tolerance is not optional in a real network. A wallet holding real money must choose consistency: it is better to reject a debit during a partition than to let the same balance be spent twice on two sides of the split. So wallets are built on strongly consistent stores with single-master or consensus-backed writes, using transactions and idempotency keys so a retried request cannot double-debit. Read-heavy, non-financial surfaces like contest listings or a leaderboard view can take the opposite trade-off and stay available on eventually consistent replicas.
Q: How would you handle the traffic spike right before a live match starts?
Treat the spike as predictable and pre-provision rather than react. Warm autoscaling groups and caches ahead of the toss window, push static contest and match metadata to a CDN so the origin never sees those reads, and keep hot data such as contest state and team rosters in Redis with cache-aside loading. Put the write path - joining a contest, wallet debit - behind a queue like Kafka so bursts are absorbed and consumed at a sustainable rate instead of overwhelming the database, and make each request idempotent so client retries are safe. Add rate limiting, per-service circuit breakers and graceful degradation, so that if the leaderboard service is struggling, contest joining still works.
Q: What is database sharding, and how would you shard a contest database?
Sharding splits one logical dataset horizontally across many database instances so writes and storage scale beyond a single machine, unlike read replicas which only scale reads. The key decision is the shard key: it must spread load evenly and keep the queries you actually run inside a single shard. For contests, sharding by contest id works well because almost every query - the participant list, the leaderboard, the join operation - is scoped to one contest, and contests are naturally independent. Consistent hashing limits how much data moves when a shard is added, and cross-shard queries such as a user’s contest history need either a secondary index keyed by user id or a separate read model.
Q: When would you choose NoSQL over a relational database?
Choose a relational database when the data is highly structured, relationships matter, and you need multi-row ACID transactions - a wallet ledger is the clearest example, because balance correctness depends on atomic debit and credit. Choose NoSQL when the access pattern is a known key lookup at very high volume, the schema varies, or you need horizontal write scaling and flexible replication more than joins. In practice a fantasy-sports product uses both: PostgreSQL or MySQL for wallets, orders and user accounts, a document or wide-column store for match and player statistics feeds, and Redis for leaderboards and sessions. The answer interviewers want is per-workload reasoning, not a blanket preference.
Q: What is the difference between a load balancer and a CDN?
A load balancer distributes incoming requests across a pool of backend servers in one region, using health checks to route away from failed instances and algorithms such as round robin, least connections or consistent hashing for sticky routing. A CDN is a geographically distributed cache that serves static and cacheable content - images, JavaScript bundles, player photos, cached API responses - from an edge location near the user, so the request never reaches your origin at all. They solve different problems: the CDN cuts latency and origin load for cacheable reads, while the load balancer spreads dynamic requests and provides failover. A high-traffic consumer product uses both, with the CDN sitting in front of the load balancer.
Q: How do you find the k largest elements in a stream of scores?
Maintain a min-heap of size k. Push the first k elements, then for each new score compare it with the heap root: if the new score is larger, pop the root and push the new score, otherwise discard it. The heap always holds the current top k and its root is the kth largest. Each element costs O(log k), so processing n elements is O(n log k) time with only O(k) space - far better than sorting the whole stream at O(n log n), and it works when the stream does not fit in memory. Interviewers often follow up by asking for the top k over a sliding time window, which needs a different structure such as a deque of time-bucketed heaps.
Q: What is the difference between a process and a thread, and how do deadlocks happen?
A process has its own address space, while threads inside a process share heap and globals but keep separate stacks and registers - which makes threads cheap to create and communicate but exposes them to data races. A deadlock occurs when four Coffman conditions hold simultaneously: mutual exclusion, hold-and-wait, no preemption, and circular wait. Breaking any one prevents it; the usual production fix is to impose a global lock ordering so a circular wait cannot form, or to acquire locks with a timeout and back off. In a wallet service this matters concretely: two concurrent transfers between the same pair of accounts will deadlock unless both lock the accounts in a fixed order, such as ascending account id.
Frequently asked questions about Dream11 interviews
Section titled “Frequently asked questions about Dream11 interviews”What is Dream11’s interview process for freshers?
Dream11’s process typically has 4-5 rounds: 1-2 Online DSA Rounds (around an hour each, 2 problems per round), followed by onsite rounds - one or two Technical interviews on DSA and CS fundamentals (OS, OOPs, DBMS, SQL/NoSQL), a Techno-Managerial or System Design round, and a final HR round. The whole loop averages around 12 days end-to-end per candidate reports.
How many rounds does Dream11’s hiring process have?
Most candidates go through 4-5 rounds total: one or two online DSA rounds, a technical interview, a techno-managerial or system-design round, and an HR round. Experienced hires sometimes see an additional dedicated system design round split out separately.
What does the system design round at Dream11 focus on?
It focuses on concepts relevant to a high-traffic consumer product - caching, load balancers, the CAP theorem, sharding, and microservices architecture. Given Dream11’s user base spikes massively during live cricket/sports matches, interviewers are especially interested in how you’d design for sudden, large traffic surges - a recurring theme in candidate reports is designing notification, leaderboard, or wallet systems at scale.
What CS fundamentals come up in Dream11 technical interviews?
Beyond DSA, candidate reports mention OS, OOPs, DBMS, and both SQL and NoSQL database questions, plus database-schema design tied to a real feature (like contest leaderboards or wallet transactions). Interviewers also probe internship/project work and CDN/load-balancer basics.
How should I prepare for Dream11 interviews?
Practice medium-to-hard DSA on LeetCode-style platforms under time pressure, revise system design fundamentals (caching, load balancing, sharding, microservices, CDN), brush up OS/OOPs/DBMS and both SQL and NoSQL basics, be ready to walk through your internship/project work in detail, and think about how a fantasy-sports product would handle real-time scale, like millions of concurrent users joining contests right before a match starts.