Scale honestly
Most system design advice online is written for companies with a hundred million users. Almost no company hiring in this region has that problem, and answering as if they do reads as someone reciting rather than thinking.
If you are asked to design something, ask what the actual load is. "How many users, and how spiky?" is a strong first question. Designing for a hundred thousand users when the answer is five thousand is not caution, it is expense.
The structure that works
You have roughly forty minutes and nobody expects a finished architecture. What they expect is a sequence they can follow.
- Clarify — what does the system do, for whom, at what volume
- Define the interface — the handful of operations that matter
- Sketch the data — what is stored and what is read most
- Draw the path — one request end to end
- Break it — what fails first under load, and what you do
Design a system that notifies candidates when a job matching their profile is posted. Start wherever you like.
Naming the trade-off
Every design decision costs something. The single strongest signal in this round is saying what you are giving up, unprompted.
«Закеширую на пять минут — кто-то увидит устаревший счётчик, тут это нормально; для статуса заявки так не сделаю» ценится выше любой диаграммы.
- Consistency versus latency, on a specific field rather than in general
- Sync versus queued, and what the user sees while they wait
- One database versus several, and who owns the joins afterwards
- The thing you are deliberately not building yet
What breaks first
Interviewers will push on failure, and it is usually the last ten minutes. Have an instinct for the weakest point in your own design and volunteer it.
Your queue backs up and stops draining. What happens to the rest of the system, and what does the user see?
Answers that mention retries, idempotency and back-pressure land well. Answers that add a second queue to solve a queue problem do not.
What interviewers here are really assessing
- Do you ask before you build
- Can you hold a whole system in your head and still talk about one part
- Do you know the difference between a real constraint and a habit
- Would you be able to explain this design to the team that has to run it
What to focus on at your level
Junior · 0–2 years
Rarely asked. If it comes up, it is a conversation about a system you have worked on, not a design from scratch.
Mid · 2–5 years
One service designed end to end, with data modelling and a clear account of where it would strain.
Senior · 5+ years
Trade-offs by default, cost awareness, and a view on organisational boundaries as much as technical ones.
Open engineering roles right now
Read from the live roles on Nebryx when this page loaded — not a list written into the page. If it is empty, nothing matching is open today.
Frequently asked questions
Do I need to memorise architecture patterns?
Knowing the names helps you communicate faster. Reciting a pattern that does not fit the problem is worse than describing the right thing in plain words.
Should I draw?
Yes, and keep it ugly. Boxes and arrows that you talk over beat a neat diagram drawn in silence. If the interview is remote, ask whether they want to share a whiteboard before you start.
What if I have never designed a system from scratch?
Say so, then design one anyway using the structure above. Interviewers are assessing reasoning, and pretending to experience you do not have collapses on the first follow-up question.