System Design in English: A Backend Engineer Case Study

The Interview Problem

The CV shows the work. The interview asks you to explain it in English, live, without stopping to translate. He was a backend engineer in Brazil. When he had to explain a system design out loud, his answers lost structure and he paused to translate.

Interview Strategy

Practice matched the round he actually had to speak: system design. After each mock, he got notes on the same answer — where he paused, which words were vague, and where the structure broke.

• He practised clarifying requirements before naming services or components.
• He used a fixed spoken order: scope, components, bottlenecks, then trade-offs.
• He practised explaining trade-offs out loud, not only drawing boxes on a board.
• He worked on saying metrics and numbers in English (latency, load, cost).
• He narrated architecture without stopping to translate each sentence.

Useful references along the way: What to expect in English interviews, Pronouncing numbers and metrics.

Why System Design Is Difficult in English

System design is a 30–45 minute spoken explanation. You must sequence components, defend trade-offs, handle follow-ups, and keep 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 coherent in a second language.

Preparing for a similar path? Read How a Backend Engineer From Europe Prepped for English Interviews.

A Key Change

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

After the Coaching

He gained clearer, more confident English for interviews. He could explain the work more clearly when questions got hard. That readiness was the goal — not a promised job offer.

What to Practise

• Clarify the scope before you name services.
• Use one spoken sequence every time: requirements, scale, architecture, bottlenecks, then trade-offs.
• Practise saying metrics (latency, queries per second, storage) in full sentences.
• Name one trade-off out loud even if you already feel sure about the design.
• Record a fifteen-minute design walkthrough and listen only for jumps and unfinished sentences.

Where He Started

He prepared for English-language interviews as a backend engineer. Homework between classes practised the same phrases out loud. Written English was stronger than speaking against the clock.