Entrevista técnica en inglés: preguntas reales y frases listas

## Apertura

Te comparten la pantalla, el entrevistador dice *'walk me through your approach'* y la primera frase en inglés se te atraganta. Esto es lo que me hubiera gustado tener antes de mi primera entrevista técnica en inglés: las preguntas reales que caen en cada fase, las frases exactas para cada momento — incluidas las de ganar tiempo mientras piensas — y las trampas de pronunciación que te delatan.

## Las cuatro fases de una entrevista técnica en inglés (y qué evalúan en cada una)

Una entrevista técnica en inglés no es un proceso único — son cuatro bestias distintas compartiendo el mismo calendario. Cada fase evalúa cosas diferentes y tu inglés se comporta distinto en cada una. Entender dónde estás te ahorra hablar como si fuera un examen oral cuando en realidad te están mirando si sabes particionar una tabla.

| Fase | Duración típica | Quién entrevista | Qué evalúan | Nivel de inglés exigido | |---|---|---|---|---| | Screening | 20-30 min | Recruiter / Talent | Fit cultural, motivación, expectativas, comunicación | Alto: es casi todo inglés conversacional | | Deep dive técnico | 45-60 min | Tech lead / Engineer senior | Experiencia real, profundidad técnica, criterio | Medio: puedes apoyarte en el vocabulario técnico | | Live coding | 45-90 min | 1-2 engineers | Resolver problema + pensar en voz alta | Medio-bajo pero constante: hablas todo el rato | | Behavioral / cultural fit | 30-45 min | Manager / EM | Cómo trabajas con gente, cómo gestionas conflicto | Alto: aquí se mide soltura, no técnica |

La proporción inglés/técnica se invierte según la fase. El screening es un 80% inglés-20% técnica; el live coding, casi al revés. Y ojo con un error frecuente: pensar que el inglés solo se evalúa en el small talk. Se evalúa todo el tiempo. El tech lead que te está preguntando por Kafka también está anotando si dices *'the messages are getting lost'* o *'we're experiencing message loss under high load'*. La diferencia importa.

Un apunte que no verás en la mayoría de guías: el entrevistador en un proceso internacional asume que tu inglés no es nativo. No busca acento perfecto. Busca que te puedas comunicar sin que la reunión se atasque. Esa es la vara real.

## Screening: presentarte sin soltar el CV entero

La primera pregunta casi siempre es *'so, tell me a little about yourself'*. Y aquí es donde la mitad de los candidatos hispanohablantes se hunde — no por el inglés, sino porque empieza recitando el CV entero en orden cronológico. Sesenta a noventa segundos. Ni más, ni menos. Si te pasas, el recruiter ya ha desconectado; si no llegas, no has dicho nada útil.

La estructura que funciona son tres bloques limpios: rol actual → trabajo reciente relevante → por qué estás aquí. Algo así:

> *"I'm currently a backend engineer working on payment infrastructure, mostly Java and Spring Boot with Kafka for async processing. Over the past two years I've led the rollout of our new settlement pipeline, which cut reconciliation time from four hours to under ten minutes. I'm looking for a role where I can keep working on distributed systems at scale, ideally in a fully remote international team."*

Tres frases. Con eso sobra para que el recruiter pase a la siguiente pregunta con contexto. Fíjate en los pivotes: *'I'm currently...'*, *'Over the past two years...'*, *'I'm looking for...'*. Tres tiempos verbales, tres bloques, cero relleno.

Errores típicos del hispanohablante que te marcan como junior aunque no lo seas:

- Empezar con *'My name is...'*. Nadie empieza así en una entrevista de verdad. El recruiter ya sabe tu nombre, está en su calendario. Arranca directo con el rol.

- Traducir *'llevo 5 años trabajando como X'* literalmente — *'I carry 5 years working as X'*. No. Es *'I've been working as X for five years'* o más natural, *'I've spent the last five years as a backend engineer'*.

- Contestar a *'why are you looking for a new role?'* hablando mal de tu empresa actual. En el mundo anglo eso es una bandera roja gigante. Frasing seguro: *'I've learned a lot in my current role, but I'm ready for a bigger challenge, especially around X'*. Siempre hacia delante, nunca contra el pasado.

- Responder a *'walk me through your resume'* leyéndolo entero. Es una trampa. Quieren los tres o cuatro momentos que realmente importan. *'I'll hit the highlights — happy to dig into any of them'* es la manera elegante de acotarlo tú mismo.

## Describir tu proyecto más complejo: la pregunta que decide la entrevista

*'Tell me about the most challenging project you've worked on.'* Esta pregunta cae en prácticamente todas las entrevistas técnicas internacionales y decide más entrevistas de las que la gente cree. No porque tu proyecto sea alucinante o mediocre — decide porque **el formato de tu respuesta** le dice al entrevistador si sabes razonar como senior o no.

La estructura que aguanta cualquier entrevista es CPDI: **Context → Problem → Decision → Impact**. Una frase para cada bloque si hace falta, dos como mucho. Ejemplo con carne real:

> **Context**: *"We run a payment service handling about 3 million transactions a day, mostly card payments through a Spring Boot microservice on Kubernetes."*

>

> **Problem**: *"During peak hours — Friday nights, Black Friday — our p99 latency was hitting 2.3 seconds, and we were getting timeouts from the merchant side. SLA was 500 milliseconds."*

>

> **Decision**: *"I profiled the JVM and found we were thrashing on garbage collection because of an oversized in-memory cache. I moved the cache to Redis, tuned the G1GC flags, and batched the downstream calls."*

>

> **Impact**: *"We dropped p99 to 180 milliseconds and cut pod memory usage by 40%. No more timeouts during peak, and we could actually scale horizontally without doubling the RAM."*

Cuatro frases. El entrevistador ya tiene todo: escala, dolor, decisión técnica, resultado medible. A partir de ahí, *él* decide dónde quiere profundizar.

El vocabulario técnico que necesitas dominar — y pronunciar — para que esa respuesta suene creíble:

- **throughput** — /ˈθruːpʊt/. Ojo con la *th*, es la inglesa de *think*, no una *t* española seca.

- **bottleneck** — cuello de botella. Literal.

- **rollout** — despliegue progresivo. *'We did a gradual rollout over three days.'*

- **rollback** — volver atrás un deploy. *'We had to roll back within an hour.'*

- **downtime** — tiempo caído. *'Zero downtime deploy.'*

- **latency** — /ˈleɪt.ən.si/. No *latencia* con acento español.

- **SLA** — se dice letra a letra, *'ess-ell-ay'*.

- **backfill** — rellenar datos históricos después de un cambio de esquema.

Esto no es vocabulario solo de entrevista — es el inglés de tu día a día. Tres sitios donde lo vas a usar igual:

**En la daily standup**:

> *"Yesterday I finished the Redis migration for the cache layer. p99 latency dropped from 2.3 to 180 milliseconds. Today I'm working on the gradual rollout plan — we want a 5% traffic ramp-up for the first day. No blockers."*

**En un Slack DM a un senior cuando algo se rompe en producción**:

> *"Hey — quick heads-up. We're seeing a spike in p99 on the payments service since the 14:30 deploy. The new caching layer looks like the bottleneck. Rolling back now and will update in #incidents."*

**En un comentario de PR review**:

> *"Looks good overall. One thing — this rollout will affect downstream consumers. Can we put it behind a feature flag so we can roll back without a full redeploy if something breaks?"*

Si dominas estas tres situaciones, las palabras salen solas en la entrevista. Si solo las has memorizado para la entrevista, se nota.

Ahora la comparación que mejor enseña por qué el formato importa. Pregunta: *'Tell me about a challenging project.'*

Respuesta débil: *'We had a problem with the payment service, it was slow, and I fixed it. The team was happy.'*

Respuesta fuerte: *'Our payment service was hitting 2.3s p99 latency during Friday peaks, well over our 500ms SLA. I profiled the JVM, found GC thrashing from an oversized in-memory cache, moved it to Redis, and tuned G1GC. p99 went down to 180ms.'*

Mismo proyecto. Mismo inglés gramaticalmente. Una pasa la entrevista y la otra no. La diferencia son los números concretos y el verbo correcto en cada paso: *profiled*, *found*, *moved*, *tuned*. O das números, o no digas nada — *'it was slow'* y *'it got faster'* no existen en una entrevista senior.

## Live coding: pensar en voz alta sin bloquearte

El live coding es donde más devs hispanohablantes se bloquean, y rara vez es por el algoritmo. Es porque tu cerebro está resolviendo el problema en español mientras tu boca tiene que producir inglés. Doble tarea, doble coste cognitivo. La solución no es hablar mejor inglés en tiempo real — es tener un banco de frases automáticas que salgan sin pensar, para que el hilo técnico no se rompa.

**Para abrir**, nunca arranques tecleando en silencio. Arranca narrando. Dos o tres frases:

- *"Let me walk you through my approach before I start coding."*

- *"I'll start with a brute-force solution and then optimize once we have something working."*

- *"Before I write anything, let me make sure I understand the problem correctly."*

**Para ganar tiempo mientras piensas** — y vas a necesitarlas más de lo que crees:

- *"Let me think about this for a second."*

- *"Give me a moment to work through the edge cases."*

- *"That's an interesting one, let me reason about it out loud."*

- *"Okay, so what I'm thinking is..."*

La regla práctica: si llevas más de diez segundos callado, narra. El silencio en un live coding en inglés se interpreta como *'se ha perdido'*. Aunque estés pensando a toda máquina, díselo: *'I'm weighing two approaches here — a hashmap lookup or a two-pointer pass. Let me think which one fits better.'* Eso te compra medio minuto de oro.

**Para pedir clarificación** sin sonar inseguro:

- *"Can I clarify the input format?"*

- *"Should I handle the case where the input is empty?"*

- *"Are we optimizing for readability or performance here?"*

- *"Just to confirm — do we need thread safety, or is this single-threaded?"*

Pedir clarificación es señal de seniority, no de debilidad. Nadie de verdad ataca un problema sin entender los bordes. Lo que sí es mala señal es empezar a codear y preguntar después cuando ya estás embarrado.

**Para reconocer un bug en tu propio código**, el error clásico es quedarte callado y empezar a retocar líneas sin decir nada. No. Lo narras:

- *"Wait — I see an issue on line 12, let me fix that."*

- *"Actually, this doesn't handle the null case. Give me a second."*

- *"I think I've got an off-by-one here. Let me trace through it with an example."*

Admitir un bug a tiempo es más impresionante que que no lo tuviera. Lo que hunde candidatos no es el bug — es el dev que lo descubre el entrevistador antes que él.

**Ejemplo real: narrar un two-sum mientras lo codeas**

Imagina que te piden el clásico *two-sum*: dado un array y un target, devuelve los índices de los dos números que suman target. Esto es lo que sale por tu boca mientras tu mano teclea:

*"Okay, the brute-force approach is two nested loops, O(n²). That works but I think we can do better with a hashmap — let me try that."*

```python
def two_sum(nums: list[int], target: int) -> list[int]:
    seen = {}
    for i, n in enumerate(nums):
        complement = target - n
        if complement in seen:
            return [seen[complement], i]
        seen[n] = i
    return []

"So I'm walking the array once. For each number, I check if its complement — target minus current — is already in the map. If it is, we've found the pair and I return both indices. Otherwise, I store the current number and keep going. That gets us O(n) time and O(n) space. Want me to walk through an example, or should we talk about edge cases first?"

Fíjate cómo cierro con una pregunta abierta. Eso le pasa la pelota al entrevistador y le da control sobre dónde quiere ir. Mucho mejor que terminar en silencio esperando aprobación.

Deep dive técnico: responder cuando no sabes la respuesta

El deep dive es donde el entrevistador abre el capó. Preguntas como 'what happens when you type a URL in the browser?', 'how would you optimize a slow SQL query?', 'explain how garbage collection works in your language' son clásicas precisamente porque no tienen una respuesta corta — quieren ver hasta dónde llegas y qué haces cuando se te acaba el hilo.

Aquí el inglés se pone más denso. Necesitas encadenar frases largas con conectores sin perder el ritmo: 'which means that...', 'the reason being...', 'as a consequence...', 'and that's why...'. Si cada frase la empiezas desde cero, suenas entrecortado. Si encadenas, suenas como alguien que razona.

Un ejemplo concreto. Pregunta: "Walk me through how you'd debug a SQL query that suddenly takes 8 seconds on a 50-million-row table." Esta es la pinta que tiene una respuesta encadenada bien:

"First thing I'd do is run EXPLAIN ANALYZE to see what the planner is actually doing — sequential scan, hash join, nested loop, whatever. Most of the time it's a missing index on the WHERE column, which means a seq scan over 50 million rows. If we're already indexed but it's still slow, the next thing I'd check is whether we're pulling more columns than we need — replacing SELECT * with the actual fields helps a lot when rows are wide. After that, I'd look at the access pattern and ask whether the table should be partitioned by date or by tenant_id. And as a last resort, if the query is read-heavy and the data doesn't need to be real-time, I'd consider a materialized view."

Cinco ideas encadenadas con conectores: "First thing... If we're already indexed... After that... And as a last resort...". Ese ritmo es lo que el entrevistador percibe como "este tío sabe de qué habla". El contenido técnico ayuda, pero la cohesión es la que vende seniority.

Pero la parte que nadie cubre en los blogs hispanohablantes es esta: cómo admitir que no sabes algo sin hundir la entrevista. Porque va a pasar. Alguien te va a preguntar por un detalle interno de Postgres, de la JVM, de Kubernetes, que no te suena. Y la respuesta que das en ese momento vale más que las diez anteriores juntas.

La respuesta mala: "I don't know." Seca. Muerta. Punto final.

La respuesta que funciona:

• "I haven't worked with X directly, but based on my understanding of Y, I'd expect..."

• "I'm not 100% sure about the exact mechanism, but here's how I'd approach figuring it out..."

• "Honestly, I don't know the internals there. If I had to debug this, I'd start by checking the docs and running a quick experiment with..."

Fíjate lo que está pasando en esas frases: admites el hueco, lo acotas, y luego demuestras el músculo que sí tienes — razonamiento, capacidad de búsqueda, método. El entrevistador no espera que sepas todo. Espera que cuando no sepas, no te desmorones.

Pienso que la honestidad técnica en inglés se valora más que el farol mal pronunciado. He visto entrevistas perderse por candidatos que se inventaron una respuesta, la dijeron con convicción y el entrevistador — que sí sabía — los destripó. Un 'I don't know, but here's how I'd find out' te salva la entrevista. Un 'well, basically it works like...' inventado te la hunde.

Behavioral questions: STAR en inglés sin sonar a libro de texto

Las preguntas de comportamiento son las que empiezan por 'tell me about a time when...'. Te van a preguntar por un conflicto con un compañero, por la vez que rompiste producción, por una decisión técnica que salió mal. Y si no las tienes preparadas, te metes en un monólogo largo estilo narración oral castellana y pierdes al entrevistador a los treinta segundos.

La estructura STAR (Situation → Task → Action → Result) es la herramienta para esto, pero aplicada con soltura, no recitándola. Ejemplo para 'tell me about a time you disagreed with a teammate':

"The situation was during a migration from our monolithic auth service to a new microservice. One of the senior engineers wanted to ship a big-bang cutover over a weekend. My task was basically to validate the rollout plan. I pushed back — I thought a gradual rollout behind a feature flag was safer, even if it meant three weeks instead of one weekend. What I did was put together a short doc comparing the two approaches with concrete rollback costs for each, and walked the team through it. As a result, we went with the gradual rollout, and it actually caught two auth edge cases in staging that would've caused an incident on cutover weekend. What I learned from that was that pushing back with data lands better than pushing back with opinions."

Las frases conectoras que te salvan el ritmo:

• "The situation was..."

• "My task was to..."

• "What I did was..."

• "As a result..."

• "What I learned from that was..."

• "In hindsight, I would have..."

Dos avisos importantes. El primero: no uses el mismo proyecto para responder a todas las preguntas de comportamiento. Si tu respuesta a conflicto, fallo y éxito es la misma migración, el entrevistador lo nota y piensa que no tienes más material. Ten tres proyectos preparados y repártelos.

El segundo: el modo narración larga que nos sale por defecto en castellano — "pues resulta que un día estábamos..." — no funciona en inglés. En inglés esperan estructura visible. No hace falta que digas "situation was" literal cada vez, pero el entrevistador tiene que poder dibujar los cuatro bloques mentalmente mientras te escucha. Si no, tu historia es ruido.

Tus preguntas al final: demostrar criterio en inglés

'Do you have any questions for us?' no es cortesía. Es la última fase de la entrevista y se evalúa igual que las otras. Una pregunta floja aquí puede tirar abajo una entrevista que iba bien, porque sugiere que no estás pensando como alguien senior.

Preguntas de alto impacto, con frasing exacto:

• "How does the team handle technical debt? Is there dedicated time for it, or does it get prioritized against features?"

• "What does the on-call rotation look like? How often does someone get paged?"

• "How do you measure the impact of engineering work here? OKRs, DORA metrics, something else?"

• "What's the biggest engineering challenge the team is facing right now?"

• "If I joined tomorrow, what would a successful first 90 days look like?"

Cada una de esas preguntas le dice al entrevistador algo sobre ti: que te importa la calidad del código, que sabes lo que es estar de guardia, que piensas en impacto, que entiendes cómo funciona un equipo de verdad.

Preguntas a evitar — demasiado genéricas o que ya están en la web de la empresa:

• "What's the company culture like?" — vacía.

• "Do you offer remote work?" — eso ya lo viste en LinkedIn.

• "What are the benefits?" — esa va al final, con el recruiter, no al tech lead.

Y un detalle de frasing que marca nivel: para abrir tus preguntas, di "I have a few questions if that's okay". Suena natural y adulto. "Can I ask questions?" suena a permiso infantil.

Cuándo NO aplica esta guía

Este post asume un perfil concreto. Si no es el tuyo, el consejo cambia:

• Si la entrevista es íntegramente en tu idioma nativo, tu cuello de botella es otro — técnica, algoritmos, comunicación en general. Las frases en inglés aquí no te ayudan.

• Si optas a un puesto junior puro donde el proceso es un test técnico escrito y una charla corta con RR.HH., no vas a tener deep dive ni live coding. Sobra buena parte del post.

• Si tu nivel de inglés general está por debajo de un B1 funcional, el problema no son las frases de entrevista — es el inglés base. Intentar memorizar plantillas sin entender la gramática que las sostiene te va a traicionar en cuanto el entrevistador salga del guion. Empieza por construir el nivel general, luego vuelves.

• Si tu entrevista es FAANG con algoritmos LeetCode hard puros, necesitas además preparación algorítmica específica. Las frases de este post te ayudan en la narración, pero sin el músculo de resolver DP en 40 minutos no hay frasing que te salve.

Preguntas frecuentes

¿Qué nivel de inglés mínimo necesito para una entrevista técnica?

B2 funcional para defenderte en procesos remotos internacionales. C1 si apuntas a puestos senior en equipos 100% angloparlantes donde vas a llevar decisiones técnicas en reuniones. Por debajo de B2 puedes aprobar un screening por suerte, pero el deep dive te va a comer. Y no hablo de títulos oficiales — hablo de soltura real hablando sin atrancarte más de dos o tres segundos por frase.

¿Puedo pedir que me repitan una pregunta sin que quede mal?

Sí, siempre que lo hagas con naturalidad. El frasing seguro es "Sorry, could you rephrase that?" o "I want to make sure I understood — are you asking about X or Y?". Lo que sí te marca es pedir que repitan tres veces la misma pregunta, o quedarte callado como si la pregunta no hubiera existido. Un "could you rephrase that?" lo usa hasta un nativo cuando el otro habla con acento fuerte.

¿Qué hago si me bloqueo en medio del live coding?

Narras el bloqueo, no lo escondes. "I'm stuck on how to handle X — let me think out loud for a second." El silencio largo es el enemigo; admitir que estás atascado mientras sigues razonando no lo es. Muchas entrevistas se aprueban precisamente en el momento del bloqueo, porque demuestras cómo te desatascas: pides una pista, pruebas un caso más pequeño, reescribes el enunciado con tus palabras. Eso es exactamente lo que el entrevistador quiere ver.

<ProductCTA variant="prominent">
¿Quieres practicar esto con un tutor IA? Empieza gratis en DevLingo.
</ProductCTA>