On this page

Case studies

By Mockly English · Last updated:

How a Singapore Engineer Prepped YouTube-Style System Design in English

ByteByteGo diagrams were familiar. Clarifying scope, saying idempotency, and narrating autocomplete — in English — needed reps.

At a glance

RoleSoftware engineer
RegionSingapore
FocusSystem design technical English
MocksYouTube, notifications, web crawler, autocomplete
OutcomeStronger clarify → architecture narration

Timeline

Singapore

Focus

YouTube + autocomplete

Outcome

Propose → clarify

7-Day Free Trial

Land your dream tech job. In English.

Practice technical, behavioral & system design interviews with interactive lessons and native-speaking coaches

Start freeNo card needed

Join 500+ preparing for global roles

Courses · Coaching · Mock Interviews

I want to restate the requirements so we’re on the same page — then deep-dive the trie without losing the interviewer.

Software engineer · system design prep

Profile

A software engineer in Singapore coaching for system-design interviews in English. Sessions covered designing YouTube, a notification system, a web crawler, and a search autocomplete system — with clarification questions, requirements restatement, back-of-envelope estimates, and component deep-dives (including tries).

Pain Points

  • “Boils down to…” needs an object after it
  • Pronunciation: idempotency, geographically, traverse
  • Saying “hope” instead of “aim for” on latency targets
  • Evolving vs involving; not scalable vs not scaling
  • Wording for beta users, unique selling point (USP), and professional management
  • Record (noun) vs record (verb) stress

Goals

  • Full YouTube design walkthrough in English
  • Notification system and web crawler chapters
  • Search autocomplete with trie deep-dive
  • Propose → clarify; restate requirements
  • Business-dialogue vocabulary for SWE role play

Lesson Notes

These are the classes we actually ran, not a generic curriculum. Each one started from a real interview question.

Class 1

System design

Design YouTube

  • Clarification: boil [something] down; bare bones; in-scope / out-of-scope
  • Propose then clarify (especially video safety); malicious / harmful content
  • Upload vs download flows; pay-per-use; % of users who upload
  • Restate requirements to stay on the same page
  • Idempotency pronunciation; 1080p / 4K; geographically; associated with

Class 2

System design

Notifications + web crawler

  • Roughly / approximately / ballpark; SLA; 99.999 spoken clearly
  • Graceful toward third parties; production vs consumption rate
  • Based on my experience at X…; anything I’m missing?; aligned / on the same page
  • Traffic spike; scale in/out, up/down; max capacity; guarantees uniqueness

Class 3

Trie deep-dive

Search autocomplete

  • Instant messaging app; policy; browser; localised; debounce
  • Aim for latency / give an SLA; availability as uptime
  • Trie pronunciation; core concept / in a nutshell; deep-dive the trie
  • Traverse (not tranverse); out-of-the-box; rank / calculate weights
  • Record vs record noun/verb stress

Class 4

Vocabulary

Business dialogues warm-up

  • Beta users, unique selling point (USP), end user, leadership (not “the boss”)
  • Resistant to change; conversion rate; nurture; flywheel; from scratch
  • Pain points; in-house; early stages; word of mouth

Feedback

Coach notes from those sessions, kept as they were given in class.

Restate requirements

A one-sentence recap prevents building the wrong YouTube.

Aim for an SLA

“We hope latency is low” is weak. Aim for a number and name availability.

Propose safety scope

For upload products, propose what is in/out of scope for malicious content, then clarify.

Trie deep-dive needs signposts

In a nutshell → deep-dive → small optimisation. Keep the interviewer oriented.

Common Mistakes

Corrections from live answers, the same patterns that showed up in class.

Heard in classUse instead
Boils down to (no object)Boils down to [X]

Needs a noun phrase.

We hope that latency…We aim for latency of…

SLA language.

TranverseTraverse

TRUH-verse.

This is not scalingThis is not scalable

Adjective form.

The bossLeadership / management

More professional.

Before and After

Before coaching

  • Soft latency language (“we hope”)
  • Content-safety scope left unclear
  • Pronunciation blockers on key terms
  • Deep dives without signposts for the interviewer

After coaching

  • Requirements restated aloud
  • Concrete latency and uptime targets
  • Idempotency and traverse usable live
  • Trie deep-dive with a clear structure

The Result

Clearer English for YouTube- and autocomplete-style system design interviews. Clarification, SLAs, and deep-dive signposting improved. Readiness — not a promised offer — was the goal.

What to practise for design interviews in English

  • Restate requirements before you draw.
  • Replace hope with aim-for latency and uptime targets.
  • Drill idempotency, traverse, and geographically aloud.
  • Signpost deep dives: in a nutshell → detail → optimisation.
  • Propose safety and policy scope, then clarify.

Why System Design Interviews Stress English

You are graded on how you think out loud. Mispronounced core terms and soft SLAs make a strong design hard to trust. A fixed spoken order plus practised deep-dive phrases keeps the round coherent in a second language.

Preparing for a similar path? Read How a Singaporean Software Engineer Built Interview-Ready English.

Practise explaining system design in English

No card required. Start with a 7-day free trial — a lesson, a mock interview, or both.

Join 500+ preparing for global roles

Create your Mockly account →

Frequently Asked Questions

How do I explain a trie in a system design interview?

One sentence on the core idea, then deep-dive structure and a small optimisation. Check alignment before you go low-level.

What should I say instead of “we hope latency is good”?

“We aim for X ms p99” and give availability as uptime. Numbers beat hope.

How do I handle content-safety scope on YouTube-style prompts?

Propose what is in and out of scope, then ask if that matches the interviewer’s intent.

Is business vocabulary useful in system design?

Yes for stakeholder framing — pain points, scalable, from scratch — especially in hybrid loops.