System Design in English: A Frontend Engineer Case Study

The Gap Between Knowing and Explaining

The CV shows the work. The interview asks you to explain it in English, live, without stopping to translate. She was a frontend / mobile engineer in Brazil. Day-to-day work used React. In the room, system design was what broke down.

What We Practised

Practice matched the round she actually had to speak: system design. Each mock interview included notes on the same answer — where she paused, which words were vague, and where the structure broke.

• Practised stating the requirements in English before naming any services or components.
• Used the same spoken order every time: scope, then main components, then bottlenecks, then trade-offs.
• Practised explaining design trade-offs out loud, not only drawing boxes on a board.
• Worked on saying metrics in full English sentences — for example latency, load, and cost.
• Described the architecture in English without stopping to translate each sentence in her head.

Useful references along the way: STAR interview framework, What to expect in English interviews.

Why System Design Is Difficult in English

System design is a thirty-to-forty-five-minute spoken explanation. You must order the components, defend trade-offs, handle follow-up questions, and keep the vocabulary accurate while the clock runs. Translating each sentence in your head uses the time the interviewer needed for depth. A fixed spoken order is what keeps the round clear in a second language.

Preparing for a similar path? Read How a Frontend Engineer From China Prepped for English Interviews.

The Turning Point

The shift showed up in a timed system-design mock interview. She knew the architecture but jumped between components. A fixed spoken sequence — requirements, then scale, then architecture, then bottlenecks — was repeated until follow-up questions stayed inside that order.

What Changed

Gained clearer, more confident English for interviews. She could explain system-design answers more clearly when questions got hard. That readiness was the goal — not a promised job offer.

What to Practise

• State the scope in English before you name any services.
• Use one spoken order every time: requirements, then scale, then architecture, then bottlenecks, then trade-offs.
• Practise saying metrics such as latency, queries per second, and storage in full sentences.
• Name at least one trade-off out loud, even when you are sure about the design.
• Record a fifteen-minute design walkthrough and listen only for jumps and unfinished sentences.

Starting Point

She prepared for English-language interviews as a frontend and mobile engineer. The stack was React. Written English was stronger than speaking under time pressure.