Preparing for a Chat System Design Interview in English
He knew TLS and queues. Keeping a full chat-system design coherent in English - clarify, estimate, trade-offs - was the real drill.
What this case shows
System-design classes covered TLS handshakes and a full chat system in English: clarification questions, SLAs, queues, and scalability discussion - no offer claimed.
At a glance
| Role | Software engineer |
|---|---|
| Focus | System design (TLS, chat) |
| Skills drilled | Clarify → requirements → estimate → architecture |
| Vocab | Idempotency, failover, websockets, spoof |
| Outcome | Coherent timed design walkthroughs in English |
Timeline
TLS + chat system
Focus
Clarification questions
Outcome
Trade-off language
“I can draw the architecture. I need the English to propose, clarify, and defend trade-offs without oversimplifying.”
Profile
A software engineer preparing for system-design interviews in English. Classes walked through TLS (Transport Layer Security) and the TLS handshake, then a full chat-system design: clarification questions, functional and non-functional requirements, back-of-envelope estimates, high-level architecture, component breakdown, and scalability and security trade-offs.
Pain Points
- Oversimplifying security boundaries
- Pronunciation: partially, confirm, queue, read (past)
- Publicly vs publicity
- Assumptions stated without “Can I assume…?”
- Requirements too vague (<200ms, uptime) without proposing then clarifying
- Jumping components before sender vs receiver is clear
Goals
- Run a full chat-system design aloud in English
- TLS vocabulary: spoof, tangible, third-party authenticators
- Clarification habits: Can I assume…? How does that sound?
- Propose then clarify; name latency and uptime targets (service-level agreements)
- Discuss polling, websockets, idempotency, and failover
Lesson Notes
These are the classes we actually ran, not a generic curriculum. Each one started from a real interview question.
Class 1
Security fundamentals
TLS + TLS handshake
- Partially (SH sound); confirm; read (past = red)
- They should publicly (not publicity)
- Oversimplify; boundaries; tangible / non-tangible; third-party certificate authenticators; inherently; spoof; exposes / hides
- Authenticated / validated by; hide the IP address; do not oversimplify trust boundaries
Class 2
System design mock
Design a chat system
- Clarification: Can I assume…? How does that sound?
- Messages queued until the receiver is back online - sender vs receiver
- Requirements: more specific - e.g. <200ms latency, high uptime
- Propose a design choice, then clarify; discuss win-win trade-offs and what you are willing to sacrifice
- Back-of-envelope; high-level architecture; queue pronunciation; invoke
- Component breakdown; scalability, security, data modelling, bottlenecks
Class 3
Follow-up topics
Deep-dive homework
- Polling, websockets, idempotency, failover
- Revisit requirements on the shared Excalidraw board
- Warm-up: four-part Tell me about yourself structure for opening answers
Feedback
Coach notes from those sessions, kept as they were given in class.
Propose, then clarify
State a concrete SLA or design choice, then ask if anything is missing. Vague requirements waste the round.
Name sender vs receiver
Offline delivery only makes sense when roles are explicit in English.
Don’t oversimplify security
Boundaries, spoofing, and third-party validation need precise words - not a hand-wave.
Queue and invoke under time
Pronunciation and definitions matter when you narrate the diagram live.
Common Mistakes
Corrections from live answers, the same patterns that showed up in class.
| Heard in class | Use instead |
|---|---|
| “They should publicity” | “They should publicly” Adverb form. |
| “Confirm (wrong stress)” | “Confirm” Watch vowel quality under speed. |
| “Jumping to architecture” | “Can I assume…? / How does that sound?” Lock scope before boxes. |
| “Oversimplified trust boundary” | “Name what is authenticated / validated by whom” TLS and chat both need this. |
Before and After
Before coaching
- Assumptions left unspoken
- Security vocabulary too thin
- Requirements too soft
- Jumped to components before locking scope
After coaching
- Can I assume…? / How does that sound?
- TLS terms used in full sentences
- Concrete latency and uptime targets
- Queue and offline delivery narrated clearly
The Result
Stronger spoken structure for TLS and chat-system design rounds in English. Clarification questions and trade-off language became usable under time. Readiness - not a promised offer - was the goal.
What to practise for system design in English
- Open with clarification questions before naming services.
- Propose a concrete latency and uptime, then ask what’s missing.
- Narrate sender vs receiver for any messaging design.
- Drill security verbs: authenticate, validate, spoof, expose, hide.
- Rehearse one deep dive (websockets or failover) as a follow-up.
Why System Design Is Difficult in English
System design is a long spoken explanation. You must clarify, estimate, sequence components, and defend trade-offs while vocabulary stays accurate. Translating each sentence uses the time the interviewer needed for depth.
Preparing for a similar path? Read Amazon Interview Prep in English: A Software Engineer Case Study.
Learning paths
Practise in the course
Start with your introPractise 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
Other engineers practising interview English
Mockly knows what it takes to get hired. The preparation covers behavioral, algorithm, and system design interviews thoroughly - with real expertise in the STAR method, LeetCode, and Alex Xu’s system design frameworks. And when it comes to English and communication skills, the native-speaking mentors make all the difference.
I’ve had the pleasure of practicing English with Mockly and I truly appreciate the progress I’ve made. I highly recommend their services to professionals in tech and beyond. I particularly enjoy the teaching style and the philosophy behind it: “If you enjoy the process, you’ll get it.” The personalized learning plans make every session practical and useful. Their hands-on knowledge and genuine interest in the world of technology will genuinely boost your English skills.
FAQ
Questions
More questions? Email us at contact@mocklyenglish.com.
Similar case studies
Amazon Interview Prep in English: A Software Engineer Case Study
A Software Engineer from Europe prepped Amazon's interview english rounds in English: what stalled, what they practised, what changed.
How a Software Engineer From Europe Prepped for English Interviews
Written English was fine. Spoken answers stalled. See how one software engineer from Europe practised clear work stories out loud.
More case studies
Related resources
Case studies are illustrative, based on patterns from real coaching sessions.