Module 7: The Hiring Process in 2026
5. The Technical Interview in English
Description
On the recruiter call you proved you exist, that you fit, and that you know what you're talking about. This is the stage where they ask you to show it: solving a problem, designing a system, or defending code you've already written, and doing it thinking out loud in English while someone watches. This is where most Spanish speakers get tense, and not always over lack of technical skill. They get tense because they believe the interview measures whether they reach the correct answer, when in reality it measures something quite different: how you think when you don't know the answer yet.
That's the turn that changes everything. An interviewer who already works at the company isn't going to ask you to memorize; they're going to ask you to work with them for forty-five minutes the way they'd work on any given Tuesday in front of a bug. They're interested in seeing whether you ask good questions, whether you organize your approach before writing, whether you catch your own mistakes, whether you can say "I'm not sure, let me check." All of that is communication, and communication is exactly what this guide has been training you for. The "thinking out loud" you practiced in module 5 wasn't a warm-up exercise: it was this lesson's core skill.
Connection to the module: in the previous lesson you held up the fit conversation with the recruiter. Now you enter the room where the technical part gets decided. In the next lesson you'll learn to tell your behavioral stories with the STAR structure; here we stay strictly in the technical zone: coding, design, and defending a take-home. This lesson gives you the structure for narrating a solution, the vocabulary for talking about complexity and trade-offs, and a concrete plan for when you get stuck, which is the most feared moment and the easiest one to turn in your favor.
Before you start: what this interview really evaluates
A developer with a good technical level can fail a technical interview by staying quiet. And an average developer can pass it because they made the process legible. This isn't unfair or random: it's that the technical interview, in 2026 practice, evaluates the process more than the result. The interviewer is trying to answer a very concrete question about you: "What would it be like to work with you?"
Think of it as a pair programming session disguised as an exam. In real pair programming, your partner doesn't read your mind; you narrate what you're doing so they can follow you, correct you, and contribute. The interview is the same. If you solve the problem in silence and write the perfect solution without saying a word, the interviewer is left with no data and has to assume the worst. If you keep saying what you think — even if you make a mistake halfway through — you give them exactly what they came looking for.
This has a huge and very reassuring consequence for anyone carrying linguistic impostor syndrome: you don't need to speak pretty English, you need to speak legible English. You're not evaluated on accent or perfect grammar. You're evaluated on whether the interviewer can follow your reasoning. Clear technical English, with short sentences and precise vocabulary, always beats "fluent" but vague English. And short sentences with precise vocabulary are something you learn, not a gift. This lesson is that vocabulary.
What to expect logistically. Most 2026 technical interviews in English are remote, 45 to 60 minutes, in a shared editor (CoderPad, HackerRank, CodeSignal) or in your own editor while screen-sharing. There's almost always one person watching and talking with you; sometimes two. What matters: they're on your side more than you think. Their job is hiring, not failing you; an interview where the candidate shines makes their life easier.
The structure that turns chaos into a narrative
When you're given a problem, the panic reaction is to jump straight into writing code. Don't. There's a six-step sequence that works for almost any coding interview, and its real value is twofold: it organizes your head and gives the interviewer a clean narrative to follow. Those same six steps are your script in English.
| Step | What you do | Why it matters |
|---|---|---|
| 1. Reframe | Repeat the problem in your own words | You confirm you understood and buy seconds to think |
| 2. Clarify assumptions | Ask about edges, sizes, types | You show you think before typing |
| 3. Propose an approach | State your plan out loud before coding | You give the interviewer a chance to correct you in time |
| 4. Mention trade-offs | Compare at least two paths | You show engineering judgment, not just mechanics |
| 5. Implement | Write while narrating what you're doing | You keep the interviewer with you, not guessing |
| 6. Test | Run examples, edge cases included | You catch your own mistakes before they do |
Let's go step by step, with the English you need at each one.
Step 1 — Reframe the problem
Don't start solving something you might have misunderstood. Give the problem back in your own words. This buys you three or four seconds of air and confirms to the interviewer that you're talking about the same thing.
Model phrases in English:
"Let me make sure I understand. We need to find the two numbers that add up to the target, and return their indices — is that right?" (Déjame confirmar que entendí. Necesitamos encontrar los dos números que sumen el objetivo y devolver sus índices, ¿correcto?)
"So the input is a list of integers, and the output is a single boolean. Let me restate it back to you." (Entonces la entrada es una lista de enteros y la salida es un solo booleano. Déjame repetírtelo.)
The useful pattern here is "Let me make sure I understand…" and "So, if I got it right, …". These are opening formulas that sound professional and buy you time without making it look like you're unsure.
Step 2 — Clarify assumptions
Nobody's going to give you a fully specified problem, because part of what they're measuring is whether you ask. The right questions are a signal of seniority. Ask about input size, types, empty cases, duplicates, whether to optimize for memory or speed.
Model phrases in English:
"A couple of clarifying questions before I start. Can the input be empty? And can there be duplicate values?" (Un par de preguntas antes de empezar. ¿Puede la entrada estar vacía? ¿Puede haber valores duplicados?)
"Should I optimize for time or for memory here?" (¿Optimizo por tiempo o por memoria aquí?)
"Are the inputs always valid, or do I need to handle malformed data?" (¿Las entradas son siempre válidas, o tengo que manejar datos mal formados?)
Key vocabulary for this phase: edge case, constraint, assumption, input / output, empty / null, duplicates, sorted / unsorted.
Step 3 — Propose an approach before coding
This is the step most candidates skip, and the one that impresses the most when you do it. Before writing a single line, say your plan. If it's bad, the interviewer corrects you right there and saves you twenty wasted minutes. If it's good, you've already won almost the whole interview.
Model phrases in English:
"My first idea is a brute-force approach with two nested loops. It works, but it's O(n²). Let me think if there's something better." (Mi primera idea es un enfoque de fuerza bruta con dos bucles anidados. Funciona, pero es O(n²). Déjame pensar si hay algo mejor.)
"I think a hash map lets me do this in a single pass. Let me walk you through the idea before I code it." (Creo que un hash map me permite hacerlo en una sola pasada. Déjame explicarte la idea antes de codificarla.)
The gold connector is "Let me walk you through…". It's the phrase a senior engineer uses daily to explain something to a colleague, and it sounds exactly as natural in an interview.
Step 4 — Mention trade-offs
A trade-off is a compromise: you gain something in exchange for losing something else. In engineering there's almost never a perfect solution, there's a solution suited to a context. Naming the trade-off out loud is the difference between "I know how to code" and "I know how to decide."
Model phrases in English:
"The hash map approach is faster — O(n) — but it uses extra memory. The two-pointer version is O(n log n) if we sort first, but it's constant space. Given the constraints, I'd go with the hash map." (El enfoque con hash map es más rápido —O(n)— pero usa memoria extra. La versión de dos punteros es O(n log n) si ordenamos primero, pero usa espacio constante. Dadas las restricciones, me iría con el hash map.)
"There's a trade-off here between readability and performance. For this size of input I'd prioritize readability." (Hay un compromiso entre legibilidad y rendimiento. Para este tamaño de entrada priorizaría la legibilidad.)
Notice the formula: "There's a trade-off between X and Y. Given [context], I'd go with Z." Memorize that mold. It works in coding, in design, and in the real life of the job.
Step 5 — Implement while narrating
Now, code. But not in silence. Narrate what you're doing at a medium level: neither every semicolon, nor a three-minute silence. State the intent of each block.
Model phrases in English:
"I'll create a hash map to store the values I've already seen." (Voy a crear un hash map para guardar los valores que ya vi.)
"Now I iterate through the array, and for each element I check if its complement is already in the map." (Ahora recorro el arreglo, y para cada elemento verifico si su complemento ya está en el map.)
"I'm using a descriptive variable name here so the logic stays readable." (Uso un nombre de variable descriptivo aquí para que la lógica se mantenga legible.)
If you make a mistake while writing — and you will, everyone does — say it naturally: "Wait, that's not right. Let me fix that." Correcting yourself out loud isn't weakness; it's exactly the sign that you know how to review your own work.
Step 6 — Test
Don't wait for the interviewer to ask "does it work?" Get ahead of it. Trace through a normal example by hand and, above all, run the edge cases you identified in step 2.
Model phrases in English:
"Let me trace through an example. If the input is [2, 7, 11] and the target is 9…" (Déjame recorrer un ejemplo. Si la entrada es [2, 7, 11] y el objetivo es 9…)
"Now let me check the edge cases: an empty list, and a list with a single element." (Ahora reviso los casos borde: una lista vacía y una lista con un solo elemento.)
"I think there's an off-by-one error here. Let me double-check the loop bounds." (Creo que hay un error de uno-por-uno aquí. Déjame revisar los límites del bucle.)
Vocabulary for complexity, performance, and trade-offs
You can't narrate a technical solution without the technical words. This is the minimal toolbox. Don't memorize it all at once; read it out loud, and when you practice, force yourself to use three terms per session.
| Spanish | English | How it's said out loud |
|---|---|---|
| Complejidad temporal | Time complexity | "This runs in linear time, O(n)." |
| Complejidad espacial | Space complexity | "It uses constant space, O(1)." |
| Fuerza bruta | Brute force | "Let me start with a brute-force solution." |
| Una sola pasada | Single pass / one pass | "We can solve it in a single pass." |
| Anidado | Nested | "Two nested loops give us O(n²)." |
| Caso borde | Edge case | "Let me handle the edge cases." |
| Cuello de botella | Bottleneck | "The sort is the bottleneck here." |
| Compensación | Trade-off | "There's a trade-off between time and space." |
| Escalar | To scale | "This won't scale to millions of records." |
| Optimizar | To optimize | "We could optimize this later if needed." |
How complexities are read out loud in English, because this gets said, not written:
O(1)→ "oh of one" or "constant time"O(n)→ "oh of n" or "linear time"O(n log n)→ "oh of n log n"O(n²)→ "oh of n squared"O(2^n)→ "oh of two to the n" (exponential)
A pronunciation detail that puts people at ease: the "O" is read as the letter ("oh"), not as "zero." A lot of Spanish speakers hesitate right there. Not anymore.
What to do when you get stuck (the moment you think sinks you and that actually saves you)
You're going to get stuck. At some point in some interview, your mind is going to go blank in front of someone evaluating you in your second language. This isn't a remote possibility; it's normal, and it happens to native speakers too. The difference between someone who passes and someone who doesn't isn't whether they get stuck, but what they do when it happens.
The reaction that sinks you is silence. The interviewer sees a frozen screen, a panicked face, and not a word. They have no data, so they assume you don't know. The reaction that saves you is verbalizing the block: turning your stall into useful information for both of you.
Model phrases in English for when you get stuck:
"I'm going to think out loud for a moment. I know I need to reduce this to O(n), but I'm not seeing the trick yet." (Voy a pensar en voz alta un momento. Sé que necesito reducir esto a O(n), pero todavía no veo el truco.)
"Let me step back and reconsider my approach." (Déjame dar un paso atrás y reconsiderar mi enfoque.)
"I'm stuck on this part. My instinct says a hash map, but I'm not sure how to handle the duplicates. Can I get a small hint?" (Estoy atascado en esta parte. Mi instinto dice hash map, pero no estoy seguro de cómo manejar los duplicados. ¿Me puedes dar una pista pequeña?)
About asking for a hint: asking for a hint well doesn't cost you points, it earns you points. The key is in how you ask. Don't say "I don't know, help me." Say where you are, what you've already ruled out, and what specifically you're missing. That shows you're reasoning, not giving up. Compare:
| Asking badly (looks like giving up) | Asking well (looks like collaboration) |
|---|---|
| "I don't know how to do this." | "I've narrowed it down to a hash map, but I'm stuck on the duplicates. Could you point me in a direction?" |
| (90 seconds of silence) | "Let me think out loud so you can see where I'm at." |
| "Can you just tell me the answer?" | "Am I on the right track with the two-pointer idea?" |
What to expect: a good interviewer wants you to solve the problem, so they'll almost always give you the hint, and often that gets the whole interview back on track. A hint asked for with judgment and put to good use can end in a hiring "yes." Asking for help intelligently is a work skill, not a confession of ignorance.
And a phrase to buy time without going blank, which you can use while you think:
"That's a good question, let me think about it for a second." (Buena pregunta, déjame pensarlo un segundo.)
Saying that in English, calmly, already sets you apart. Silence scares; a bridge phrase doesn't.
The system design interview
Not every technical interview is about algorithms. From a certain level on — and in a lot of backend, platform, or architecture roles even earlier — they're going to ask you to design a system: "design a URL shortener," "design a notifications feed." There's no single correct answer here; there are defensible decisions. It's, literally, the "design document in plain language" the Architecture ecosystem asked for, but spoken.
The structure for narrating it in English:
- Clarify requirements and scale. "Before I design, how many users are we talking about? Reads-heavy or writes-heavy?" (Antes de diseñar, ¿de cuántos usuarios hablamos? ¿Predominan las lecturas o las escrituras?)
- Define the API or the contracts. "Let me sketch the main endpoints first." (Déjame bosquejar los endpoints principales primero.)
- Draw the components. "At a high level, we have a load balancer, an application layer, and a data store." (A alto nivel tenemos un balanceador de carga, una capa de aplicación y un almacén de datos.)
- Justify each decision with its trade-off. "I'd use a relational database here for consistency, but if we need horizontal scale we could move to a NoSQL store — the trade-off is weaker consistency guarantees." (Usaría una base relacional aquí por consistencia, pero si necesitamos escala horizontal podríamos pasar a NoSQL; el compromiso es garantías de consistencia más débiles.)
- Anticipate bottlenecks. "The bottleneck will likely be the database reads, so I'd add a caching layer." (El cuello de botella probablemente serán las lecturas de la base, así que agregaría una capa de caché.)
Design vocabulary you should recognize and use: load balancer, cache, database (relational / NoSQL), horizontal vs vertical scaling, latency, throughput, consistency, availability, sharding, replication, queue, rate limiting. You don't need to use them all; you need to use the right ones with confidence. The phrase that holds up the whole design interview is the same one from coding step 4: "The trade-off here is…". A design with no trade-offs sounds like you memorized an answer; a design with trade-offs sounds like you've actually built things.
Defending a take-home or reviewing your own code
More and more processes replace the live algorithm with a take-home: they give you a problem to solve at home, with your editor and your own time, and then a call to defend it. This format is a blessing for anyone who gets nervous solving live, because the code is already written, and written calmly. But it has its own skill: talking about decisions you already made.
Here the star question is "Why did you…?" — why you chose this library, why you structured the folders this way, why you didn't write tests for a certain part. It's not an attack; it's genuine curiosity about your judgment. The trap is getting defensive. The way out is treating every decision as what it was: a choice among options, with a reason.
Model phrases in English for defending your code:
"I chose this library because it's well-maintained and the team likely already knows it. I did consider writing it from scratch, but that felt like over-engineering for the scope." (Elegí esta librería porque está bien mantenida y probablemente el equipo ya la conoce. Consideré escribirlo desde cero, pero me pareció sobreingeniería para el alcance.)
"I focused my tests on the core business logic and left the trivial getters untested. Given the time box, that's where the risk was." (Enfoqué las pruebas en la lógica de negocio central y dejé sin probar los getters triviales. Dado el tiempo, ahí estaba el riesgo.)
"That's a fair point. If I had more time, I'd refactor this into a separate service. For now I kept it simple on purpose." (Es un punto justo. Con más tiempo, lo refactorizaría a un servicio aparte. Por ahora lo mantuve simple a propósito.)
That last sentence hides a powerful tool: acknowledging a limitation without apologizing for it. "That's a fair point" followed by "I kept it simple on purpose" turns a possible criticism into a conscious decision. You're showing you knew about the trade-off and chose. That's exactly what separates a senior from a junior, and it's said with two learnable sentences.
Another useful formula for when the interviewer points at something you'd genuinely improve: "You're right, that's a limitation. My reasoning was [X], but I can see how [Y] would be better." You concede, you explain your logic, and you don't fall apart. Flawless.
What you should evaluate about the interviewer
The interview goes both ways, even though nerves make it feel like an interrogation. While they're evaluating you, you're also getting data on what it's like to work there, and paying attention gives you two advantages: you decide better whether to accept, and you project the confidence of someone who isn't begging for a job. Observe:
- Does the problem resemble real work, or is it a contest puzzle? An applied problem suggests a pragmatic team. An abstract puzzle might signal a culture of technical "hazing."
- How do they react when you get stuck? If they give you space and a hint, that's someone you can work with. If they let you sink in silence, you already know something about the team.
- Can they answer your technical questions clearly? When you ask why they chose their stack, do they give you reasons or slogans?
- Do they treat you as a colleague or as a suspect? The room's tone is usually the tone of everyday work.
A question you can ask at the end, and one that reveals a lot:
"What does a typical week look like for the person in this role?" (¿Cómo se ve una semana típica para la persona en este puesto?)
The answer tells you whether the role is what they announced or something different. And asking it, in English, naturally, closes the interview with the impression you want to leave: that of someone who's also choosing.
Your practice plan for this lesson
Technical English under pressure isn't learned by reading; it's learned by talking to yourself, badly, many times, until it stops hurting. Before your next real interview, train like this:
- Take three easy problems from any practice platform and solve them out loud and in English, recording yourself. It doesn't matter if your code is slow; what matters is that you narrate the full six steps.
- Listen to yourself. You're going to hate your accent for the first two minutes and then stop noticing it. What you're after isn't sounding native: it's that your reasoning is followable. Is your plan understandable? Did you say the trade-off? Did you verbalize when you got stuck?
- Practice getting stuck on purpose. Choose a problem above your level and, when you stall, say the hint-asking phrase out loud. Train the muscle of not going quiet.
- Memorize five bridge formulas: "Let me make sure I understand…", "Let me walk you through…", "There's a trade-off between X and Y…", "Let me step back…", "That's a fair point, I did that on purpose because…". With those five you can navigate almost any interview.
I'll close with what you need to hear if the linguistic impostor voice is talking to you right now. You already know how to code; that's not in question in this lesson. The only new thing is narrating in English what you already do in your head, and that's a small, finite set of phrases that get practiced in a week. The interviewer isn't looking for someone who speaks perfect English. They're looking for someone they'd enjoy solving a problem with. That person can be you, speaking slowly, with short sentences, with a heavy accent, and with this lesson's formulas. You don't need more English than you already have. You need to use what you have with method. You just learned that method.
Exercises
Exercise 1 — Reframe out loud. You're given this problem in the interview: "Given an array of integers and a target sum, return the indices of the two numbers that add up to the target. You can assume there's exactly one solution." Write, in English, the reframing sentence you'd say before touching the keyboard.
See solution
"Let me make sure I understand. We have an array of integers and a target value, and I need to return the indices of the two elements that sum to the target. There's guaranteed to be exactly one solution — is that right?"
Why this works: it repeats the problem in your own words (not a literal copy), includes the key detail you were given (exactly one solution guaranteed), and closes with a short question inviting the interviewer to confirm or correct before you waste time solving the wrong problem.
Exercise 2 — Name the trade-off. You have two solutions for the same problem: one with a hash map that runs in O(n) but uses extra memory, and another with two pointers that runs in O(n log n) because it sorts first, but uses constant space. Using the mold "There's a trade-off between X and Y. Given [context], I'd go with Z," write the full sentence.
See solution
"There's a trade-off between the hash map approach, which is faster at O(n) but uses extra memory, and the two-pointer approach, which is O(n log n) but uses constant space. Given that we don't have strict memory constraints here, I'd go with the hash map."
Why this works: it names both options with their complexity and cost, and closes with a decision — exactly the sequence an interviewer wants to hear to confirm you understand there's no single "correct" answer, but a choice made with judgment.
Exercise 3 — Turn silence into a well-asked hint. You got stuck solving a binary tree problem. Your first mental impulse is "I don't know how to continue." Rewrite that thought as a hint request that sounds like collaboration, not surrender.
See solution
"I've narrowed it down to a recursive approach, and I think I need to track the depth as I go, but I'm not sure how to combine the results from both subtrees. Could you point me in a direction?"
Why this works: it says where you are (recursion, depth tracking), what specifically you're missing (combining results from subtrees), and ends by asking for direction, not the answer. That shows you're still reasoning — the signal that separates "asking for help well" from "giving up."
Exercise 4 — Defend a take-home decision without getting defensive. The interviewer asks you: "Why didn't you add input validation on this endpoint?" You did think about it, but decided to prioritize something else given the exercise's limited time. Answer using the acknowledge-without-apologizing formula.
See solution
"That's a fair point — I did think about it. Given the time box, I prioritized the core matching logic since that's where the actual complexity lives. In a real PR I'd add validation before merging, but for this exercise I made a conscious trade-off."
Why this works: it acknowledges the interviewer's observation without apologizing, explains the reason (priority plus time limit), and clarifies it was a conscious decision, not an oversight — the difference between sounding junior and sounding senior lies exactly in that distinction.
Summary and next step
Before moving on to the next lesson, you should be able to:
- Narrate any coding problem in English following the six steps: reframe, clarify assumptions, propose an approach, mention the trade-off, implement while narrating, and test.
- Confidently use the mold "There's a trade-off between X and Y. Given [context], I'd go with Z" to justify a technical decision.
- Ask for a hint when you're stuck in a way that sounds like collaboration ("I've narrowed it down to..., but I'm stuck on...") instead of staying silent or giving up.
- Structure a system design answer with requirements, API, components, trade-offs, and bottlenecks.
- Defend a take-home decision by acknowledging a limitation without apologizing for it.
If any of these five points still feels hard, go back to recording yourself narrating an easy problem before moving on: the vocabulary sticks with repetition, not with reading.
The next lesson leaves the strictly technical behind. You already know how to narrate how you think in front of a code problem or a system design; now it's your turn to narrate how you think in front of a real work situation: a conflict, a mistake, a decision made under pressure. That's the behavioral interview, and in the next lesson you'll learn the STAR structure for telling those stories in English without sounding either rehearsed or scattered.
Resources
- System Design Primer — a reference repository with the vocabulary and patterns (load balancer, caching, sharding, replication) you need for the system design interview.
- Big-O Cheat Sheet — a table of time and space complexity for common data structures and algorithms, useful for verifying your O(n) or O(n log n) claims before saying them out loud.
- interviewing.io — a platform for practicing live technical interviews, in English, with engineers from companies like Meta, Google, and Amazon; ideal for training "thinking out loud" with a real conversation partner.
- How We Hire — Interviewing, Google Careers — Google's official description of what their technical interviews evaluate and how to prepare.
- Interviewing at Amazon — Amazon's official guide to their interview process, including the technical part.