What a system design interview actually is
A system design interview asks you to architect something from a vague prompt: "design a URL shortener" or "how would you build a news feed for millions of users." The interviewer is not checking tool trivia, they are checking engineering thinking — how you decompose, prioritise, and explain decisions.
How it differs from a coding interview
A coding interview scores correctness and code quality. System design scores architectural choices: how data is stored, how reads scale, what happens when a node fails, where bottlenecks hide. There is rarely one right answer; there are justified and unjustified ones.
Who gets invited
System design usually appears at middle level and above: backend and full-stack engineers, platform and SRE roles, tech leads and architects. Junior loops tend to stop at algorithms and language questions. Aiming at a team with real load means starting preparation early — see career guides and salary benchmarks by role.
The answer structure interviewers expect
Strong answers follow the same sequence: clarify, estimate scale, sketch high-level architecture, drill into components, then cover bottlenecks and trade-offs. A candidate who starts drawing databases in the first minute usually signals trouble.
Step 1: clarifying questions
Narrow the problem before proposing anything. Ask about functional requirements, non-functional ones such as latency, availability and consistency, and resource constraints. A solid opening sounds like: how many users, what read-to-write ratio, is eventual consistency acceptable, any geo-distribution needs.
Step 2: scale estimation
Estimate requests per second, data volume per year, storage and cache footprint. Precision does not matter — what matters is showing that you size the architecture to an order of magnitude instead of guessing.
Step 3: high-level sketch
Draw clients, load balancer, service layer, storage, cache, queue and external dependencies. Narrate the data flow from request entry to response. Clarity beats detail at this stage.
Step 4: depth and trade-offs
Then go deep on two or three nodes the interviewer picks: data model, sharding, replication, caching strategy, idempotency, retries. For every decision, name the alternative and the cost — what you gained, what you gave up.
Common cases and what they test
The case library repeats across companies: URL shorteners, feeds, chat, rate limiters, payment gateways, file storage, search, notifications. The point is not memorising each answer but practising a universal framework.
Case: link shortener
This tests key generation, collision handling, the read/write ratio, read caching and click analytics. A strong answer covers what happens when the key space runs out and how to count clicks without slowing the hot path.
Case: content feed
Core topics are fan-out on write versus fan-out on read, caching the first pages, pagination, personalisation and graceful degradation. Interviewers watch whether you see where the system breaks under traffic spikes.
Case: rate limiter
A compact distributed systems case. Expect discussion of limiting algorithms, counter storage, atomicity, behaviour when a node drops, and how strict the limit must be. It reveals how well you reason about consistency.
Tools and topics you need to know
The topic list is finite and manageable. Learn what each tool is for and its weak spots — that is enough to reason confidently in an interview.
| Topic | Why it appears in answers | Follow-up questions |
|---|---|---|
| Load balancing | Spreading traffic across services | Health checks, sticky sessions, node failure |
| Caching | Cutting latency and storage load | Invalidation, warm-up, cache stampede |
| Queues and brokers | Async processing, service decoupling | Delivery guarantees, ordering, retries |
| Replication and sharding | Scaling writes and reads | Shard key choice, rebalancing |
| CAP and consistency | Justifying a data model | Which trade-off you chose and why |
Lock down your terminology before the interview — if a term feels shaky, check an IT glossary.
Handling unfamiliar technologies
You do not need deep knowledge of every product. Saying "I worked with a similar system, here is how it differs and how I would choose" scores higher than faking expertise. Interviewers test your reasoning, not a product catalogue.
Time management during the interview
A typical system design interview runs about an hour and time is unevenly spent. A candidate who burns forty minutes on requirements and never reaches architecture fails the section even with good questions.
A practical hour breakdown
- First minutes — clarifications and writing requirements down.
- Next few minutes — scale estimation and system boundaries.
- Middle — high-level sketch and data flow discussion.
- Final third — depth on chosen components and trade-offs.
- Wrap-up — bottlenecks and what you would improve with more time.
What to do while working
Interviewers often stay quiet and take notes — that is normal. Think out loud, check in periodically about whether to go deeper. Remote asynchronous formats demand more verbalisation than a whiteboard in an office, so practise narrating your reasoning.
Building a multi-week preparation plan
System design cannot be crammed the night before. A workable plan is several weeks of forty-to-sixty-minute sessions alternating theory, case breakdowns and verbal practice.
Weeks 1-2: foundations
Cover the table topics: load balancing, caching, queues, replication, sharding, consistency models. The goal is understanding purpose and weak spots, not internal implementation depth.
Week 3: case breakdowns
One case a day: twenty minutes writing an answer outline and twenty minutes saying it out loud. Record the reasoning path, not just the final design — that is what you reproduce in the room.
Week 4: mock interviews
Find a partner and run the full hour seriously, with a silent observer playing interviewer. Mocks reveal timing problems invisible in solo prep. If you are job hunting in parallel, keep a vacancy list open and map interview topics to requirements — see affiliate and media buying vacancies and remote jobs.
Mistakes that sink the section
Most failures come from answer organisation, not missing knowledge. Candidates go silent, dive into details, or refuse to acknowledge trade-offs.
The usual slip-ups
- Designing before clarifying requirements and scale.
- One solution with no alternatives or cost discussion.
- Diving into database internals during the high-level sketch.
- Ignoring component failure and load degradation.
- Working silently without narrating the reasoning.
Turning a hard question around
If a question is outside your experience, do not stall. State that the topic is new, then reason from the known: requirements, constraints, familiar patterns. Interviewers value honesty and thinking on your feet above encyclopaedic recall.
The roles and salaries behind these interviews
System design usually accompanies middle and senior grades, and the income gap between grades is substantial, though the exact range depends heavily on country, company and work format. In the Russian-speaking digital segment, estimates vary by vertical and level of responsibility.
How the grades differ
| Grade | What is assessed | Income level |
|---|---|---|
| Junior | Coding and language basics | Below market; system design rarely asked |
| Middle | Designing a mid-complexity service | Noticeably above junior, grows with experience |
| Senior / Lead | Trade-offs under load, resilience, cross-system impact | Substantial premium over middle; depends on product and location |
Indicative figures by role and vertical sit in a separate breakdown, which also lists vacancies with published ranges (some media buyer roles in dating publish a range around 700-1000 USD, though that is a different stack and role). Employers hunting engineers with architecture experience can post a vacancy or review employer pricing.
How the section affects the offer
System design is one of the heaviest stages for roles with architectural ownership. A confident design interview often sets the grade, and with it the offer band, so it deserves real preparation even if your algorithms are strong.
Frequently asked questions
How long does system design interview preparation take?
Roughly several weeks of forty-to-sixty-minute sessions. The first half covers foundations — caching, queues, replication, sharding, consistency. The second is case breakdowns and mock interviews with a partner. If you already design systems under load, you can compress the theory and go straight to case practice and narration drills.
Should I prepare in my native language if the interview is in English?
Many candidates on the Russian-speaking market prepare in Russian and interview in English. Know the terminology in both: consistency, sharding, load balancer come up in English at international companies, while you may reason more fluently in your first language. Practise switching — break down a case in Russian, then explain the final architecture in English.
What if I do not know the technology the interviewer asks about?
Say so plainly, then reason. Name a system you do know, explain the difference in data model or delivery guarantees, and describe how you would choose by requirements. Interviewers assess reasoning and comfort with ambiguity rather than product recall. Faking depth usually collapses within two or three follow-ups.
Do I need to draw diagrams on a whiteboard?
Remote interviews often use online whiteboards or shared docs; on-site ones use a marker board. The principle is identical: draw a minimal but sufficient block-and-arrow diagram, label data flows, and narrate what each component does. Diagram aesthetics are not graded — structural clarity and how well the sketch reflects your decisions are.
Is experience in affiliate marketing or media buying relevant?
It helps if you have touched infrastructure: tracking systems, high postback load, event processing, real-time analytics. Those map well onto classic cases. For pure engineering roles, expect standard architectural trade-off questions, so work through the core curriculum regardless of background.
How do I find companies running these interviews?
Read the requirements in active listings — they usually spell out the interview loop. WEB-HH currently lists roughly 1,897 active vacancies in the career cluster, about 47% of them remote, which is enough to gauge the market. The WEB-HH blog also covers hiring and interview preparation in practice.