Most LATAM engineers who fail a US technical interview don't fail on the code. They fail in the silence. The interviewer asks a question, the candidate goes quiet for four minutes, translating in their head and solving at the same time, and then types a correct answer. The interviewer writes down "hard to follow, didn't communicate." That's a rejection.
Your English doesn't need to be perfect. It needs to keep the interviewer inside your head while you think.
Key Takeaways
- US interviewers grade how you think out loud, not only the final code.
- Use a small set of ready-made phrases for clarifying, planning, and getting unstuck. Memorize them.
- Ask clarifying questions first. It buys thinking time and shows seniority.
- Practice 15 minutes a day out loud, recorded. Reading English doesn't train this.
What the interviewer is actually scoring
A typical US technical round has four quiet scorecards: problem understanding, approach, code quality, and communication. Communication often decides close calls. Two candidates write similar code; the one who explained trade-offs gets the offer.
This is good news for you. Communication in an interview is a narrow skill. You don't need to talk about football or politics in English. You need to describe code, data, and decisions, and that vocabulary is small and repetitive.
The phrases that do most of the work
Learn these until they come out without thinking. They cover most of what you'll say.
| Moment | What to say |
|---|---|
| Before coding | "Let me make sure I understand the problem." / "Can I ask a few questions first?" |
| Clarifying | "What should happen if the input is empty?" / "Roughly how big can this list get?" |
| Planning | "My first idea is a brute-force approach, then I'll improve it." / "I'm thinking of using a hash map here because lookups are constant time." |
| Thinking | "Give me a moment to think this through." / "I'm going to write down the steps first." |
| Stuck | "I'm stuck on this part. Let me try a small example." / "Could you give me a hint on the edge case?" |
| Trade-offs | "This is faster but uses more memory." / "I'd pick this for readability unless performance matters here." |
| Testing | "Let me walk through this with an example." / "I think there's a bug on this line." |
| Finishing | "The complexity is O(n log n) because of the sort." / "If I had more time, I'd add tests for..." |
"Give me a moment to think" is the most useful sentence in this list. Thirty seconds of announced silence is fine. Four minutes of unexplained silence is not.
Ask before you code
Senior engineers in the US almost always ask questions before writing a line. Juniors jump in. Interviewers know this, and many leave the problem vague on purpose to see what you do.
Asking also solves your language problem. While the interviewer answers, you get time to think in whatever language you think in. Three good questions can give you two free minutes.
Good questions are about inputs, scale, and edge cases: "Are the IDs unique?" "Does this need to handle concurrent requests?" "Is it OK to use the standard library sort?"
When you don't understand the question
This happens to everyone, including native speakers on a bad connection. Never guess. Say:
- "Sorry, could you repeat the last part?"
- "Just to confirm, you want me to return the index, not the value?"
- "Could you type the example in the chat? I want to be sure I have the numbers right."
Paraphrasing the question back is a strong move. It proves you understood, and if you didn't, the interviewer fixes it before you waste 20 minutes.
Accent is rarely the issue. Speed is. Most nervous non-native speakers talk too fast. Slow down about 20%. It sounds more senior, too.
A 15-minute daily practice routine
Reading English docs all day built your vocabulary. It didn't build speaking. Fix that with a daily routine for three to four weeks before interviews:
1. Minutes 1-5: Pick one easy LeetCode or HackerRank problem. Solve it out loud, in English, recording your screen and voice.
2. Minutes 6-10: Watch the recording at 1.5x. Note every long silence and every sentence you got stuck on.
3. Minutes 11-15: Explain one system you built at work, out loud, in English, as if to a new teammate. "The service receives an order, validates it, then..."
Twice a week, replace the solo recording with a mock interview with a friend or on a peer-practice platform. A real listener changes how you talk.
A Concrete Version
A composite example: Lucas, a senior Java engineer in Sao Paulo, B2 English, strong code. His first two US interviews ended in rejections with the same note: "struggled to communicate approach."
His own practice recording showed the problem. It was a graph traversal question. He was silent for 3 minutes 40 seconds, then wrote a correct BFS.
He spent three weeks on the routine above. In the next interview, same kind of problem, the transcript looked like this: "Let me make sure I understand. We have a grid, and we need the shortest path from the top left to the bottom right? Can we move diagonally? OK. My first thought is BFS, because every step has the same cost. Give me a moment to write the steps." Then 40 seconds of quiet, then code, narrated.
Same code quality as before. This time the feedback said "clear communicator, strong approach." He got the offer.
The Honest Counterpoint
Phrases and practice fix nervous B2 English. They don't fix A2 English. If you can't follow a 10-minute conversation about your own project without subtitles, memorized phrases will break at the first follow-up question, and interviewers notice. Spend two or three months on real English first. Our guide to improving English for remote developer jobs has a plan.
And the opposite trap: some engineers over-narrate every keystroke. Talk about decisions, not typing. "Now I'm writing a for loop" adds nothing.
Frequently Asked Questions
Is it OK to have a strong accent?
Yes. US tech teams are full of engineers with accents. Clarity and pace matter much more. Slow down and finish your sentences.
Can I ask the interviewer to repeat or rephrase?
Yes, and you should. It's normal and it's better than guessing wrong. Do it once or twice without apologizing too much.
Should I think in Spanish or Portuguese during the interview?
Think in whatever language is fastest for you, but speak in English as you go. The phrases above are the bridge.
The Bottom Line
US technical interviews reward engineers who make their thinking visible. Learn the phrases, ask before you code, slow down, and practice out loud every day for a few weeks. Our own process includes a technical assessment and interviews in English, so this is exactly what we look for. If you're ready, find a role at /jobs, from Java backend to DevOps. For the full search plan, read how to get a remote job with a US company from LATAM, and if the process includes a recorded screen, see how to prepare for an AI video interview.
Roberto Espinoza is CEO of Ruzora, which places senior LATAM engineers with US startups. Browse open roles.
