Technical interview English
How to Ace a Technical Interview in English: Scripts for Every Stage
July 15, 2026
Exact phrases for introducing yourself, thinking out loud while coding, asking for clarification, handling questions you do not know, and negotiating salary. Written for Spanish-speaking developers.
Key Takeaways
- The biggest mistake is going silent. Narrate your thinking at every step, even when you are stuck.
- Asking for clarification is expected and professional. Do it before you start coding.
- When you do not know something, say so and then reason your way through it. That is what interviewers want to see.
- Salary negotiation starts before you name a number. Try to get their range first.
- You do not need perfect English. You need clear communication. Short sentences work.
The language of a technical interview is its own dialect
Most developers know the algorithm problems. They can solve Two Sum and reverse a linked list. What trips them up is the language layer on top of the code.
How do you say you do not know something without sounding incompetent? How do you think out loud in English without losing the thread? How do you push back on a salary offer without being awkward?
This article is not a vocabulary list. It is a practical script for every stage of a technical interview in English, written specifically for developers who speak Spanish as their first language.
If you want to practice the vocabulary that comes up in coding challenges, see the coding interviews guide. For the behavioral part of the process, the behavioral interview questions article covers the most common questions with example answers.
Phrases for introducing yourself
“Hi, I'm [name]. I'm a backend developer with five years of experience working mainly with Python and PostgreSQL.”
Keep it under 30 seconds. Role + years + main tech. That is all.
“I've been working at [company] for the past [X] years, mostly on [area]. Before that, I was at [company] building [product].”
Walk forward in time from your most relevant previous job to your current one.
“What brought me to apply here is your work on [specific thing] — I've been focused on that area and it seemed like a good fit.”
One sentence on why this company. Shows you did your research.
Phrases for asking clarification
“Sorry, could you repeat the question? I want to make sure I understood it correctly.”
Safe, polite, and completely normal to say in any interview.
“When you say [X], do you mean [Y] or [Z]?”
Use this to confirm scope before you start coding. Interviewers expect it.
“Just to make sure I understand the problem: we are given [input] and we need to return [output], right?”
Restating the problem confirms you understand it and shows structured thinking.
“Can I assume the input will always be valid, or do I need to handle edge cases like null or empty arrays?”
Asking about edge cases before coding is a green flag for interviewers.
“What scale are we designing for? Thousands of users or millions?”
Critical for system design interviews. Scale changes every decision.
Phrases for thinking out loud
“Let me think through this for a moment.”
Say this instead of going silent. Silence feels awkward; narrating feels professional.
“My first instinct is to use a hash map, but let me think about whether there is a simpler approach first.”
Shows you are not jumping to the first solution you think of.
“I am going to start with a brute-force solution to get something working, and then we can optimize from there.”
This is the right approach for most coding challenges. Say it out loud.
“So the time complexity here would be O(n log n) because of the sort. I think we can do better.”
Always name the complexity of your solution before the interviewer asks.
“I am going to approach this by first splitting the problem into two parts. The first part is X and the second part is Y.”
Breaking problems down visibly is a strong signal of seniority.
“Let me trace through this example to make sure my logic is correct.”
Walking through a test case before running code shows discipline.
Phrases for when you do not know
“I have not worked with that directly, but I would approach it by [general method].”
This is the single most important phrase in this article. Use it whenever you hit a technology you have not used.
“That is not something I have deep experience with, but from what I know, the typical approach would be [X]. Is that the direction you had in mind?”
Acknowledges the gap honestly, then shows you can reason about unfamiliar problems.
“I am not sure about the exact syntax off the top of my head, but the algorithm would be [X].”
For language-specific syntax gaps. The algorithm matters more than the exact method name.
“I would need to look that up to give you an exact answer, but my understanding is [X]. Would that approach make sense here?”
Honest and proactive. Interviewers value intellectual honesty.
Phrases for salary negotiation
“Before I give you a number, could you tell me what the budgeted range for this role is?”
The first person to name a number is at a disadvantage. Try to get theirs first.
“Based on my research and my experience level, I am looking at a range of [X] to [Y].”
Give a range, not a single number. The bottom of the range should be the minimum you would accept.
“I am open to discussing the full compensation package, including equity, benefits, and bonus.”
Salary is only one part of compensation. Use this if the base seems low.
“That range is a bit below what I was expecting. Is there flexibility there, or is that fixed?”
Direct and professional. Most companies have some flexibility. Ask.
“I have another offer in the range of [X]. Is that something you can match or come close to?”
Use this only if it is true. If you have another offer, it is a strong negotiating position.
What it looks like in practice
Here is a short coding challenge exchange that puts several of these phrases together. The candidate asks for clarification, thinks out loud, names the complexity, and then codes. Notice that the English is simple and direct.
Okay, let's start. Can you reverse a string in Python?
Sure. Just to make sure I understand the problem: I need to take a string as input and return it reversed, right?
Exactly.
And can I assume the input is always a valid string, or do I need to handle cases like None?
Assume it's always a valid string for now.
Okay. My first instinct is to use Python's slice syntax with a step of -1, since that is the idiomatic way in Python. Let me trace through a quick example first to make sure the logic is right. If the input is 'hello', the reversed version would be 'olleh'. The slice s[::-1] would give me that. Time complexity is O(n) because we have to copy the whole string, and space complexity is also O(n) for the new string.
Great. Can you code that up?
Sure.
def reverse_string(s: str) -> str:
return s[::-1]Common mistakes (and how to avoid them)
Going silent when stuck
Say 'Let me think through this for a moment' and keep narrating. Silence reads as being lost, not thoughtful.
Starting to code before clarifying
Ask at least one clarifying question before you write a single line. It signals seniority, not uncertainty.
Saying 'I don't know' and stopping there
Always follow with 'but I would approach it by...' and reason through it. An honest attempt is better than giving up.
Naming a salary number first
Ask for their budgeted range first. If they push, give a range where the bottom is your real minimum.
Using very complex English
Short, clear sentences work better than long, complex ones. Clarity is the goal, not impressive vocabulary.
Vocabulary reference
The key terms from this article in a quick-reference table.
| Term | Spanish | Example |
|---|---|---|
| to think out loud | pensar en voz alta | I am going to think out loud while I work through this. |
| to trace through | recorrer paso a paso | Let me trace through this example to verify my logic. |
| brute force | fuerza bruta (solución naive) | The brute-force solution is O(n squared). We can do better. |
| edge case | caso límite, caso extremo | What should we return if the array is empty? That is an edge case. |
| time complexity | complejidad temporal | The time complexity of this solution is O(n log n). |
| trade-off | compromiso, equilibrio entre dos opciones | There is a trade-off between speed and memory usage here. |
| to walk you through | guiarte/explicarte paso a paso | Let me walk you through my reasoning. |
| off the top of my head | de memoria, sin consultarlo | I do not remember the exact syntax off the top of my head. |
| compensation package | paquete de compensación total | I am open to discussing the full compensation package. |
| budgeted range | rango presupuestado | Could you tell me what the budgeted range for this role is? |
Related articles
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for free
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.