Inglés para entrevistas tech: más allá de 'Tell me about yourself'

Sabes la respuesta. La tienes clarísima en español. Pero el entrevistador termina de hablar, se hace el silencio, y te descubres traduciendo en tu cabeza mientras la pausa se alarga y todo suena peor de lo que en realidad sabes. Ese silencio no mide tu nivel técnico ni tu gramática: mide cómo produces inglés sobre la marcha, sin red, cuando la pregunta no es la que habías ensayado. Prepararte el inglés para entrevistas de trabajo tech va exactamente de eso — de la entrega bajo presión, no de pulir tiempos verbales sobre el papel.

Este post no va del "Tell me about yourself" ni es otro banco de frases por fase. Va de lo que casi nadie prepara: narrar tu experiencia en pasado sin caerte en los tiempos verbales, explicar una decisión técnica pensando en voz alta, recuperarte de un bloqueo en mitad de la respuesta, y cerrar la entrevista —tus preguntas, el salario, el remoto— con lenguaje firme. La parte conversacional, que es justo donde se decide la oferta.

Inglés para entrevistas de trabajo tech: lo que de verdad se evalúa es tu entrega bajo presión

Lo que delata al hispanohablante no tiene nada que ver con saber inglés. El fallo de raíz es traducir en la cabeza: en vez de tirar de frases hechas que ya tienes interiorizadas, construyes cada respuesta palabra por palabra desde el español. Eso es lento, suena forzado y, lo peor, alimenta el dead air — ese silencio incómodo mientras buscas la palabra, que el entrevistador interpreta como "no lo sabe" aunque lo sepas de sobra. Y por debajo va el clásico de los tiempos verbales: al contar experiencia mezclas present perfect y past simple, y el oído nativo lo pilla al instante.

El error de base es preparar la entrevista como un examen: memorizar respuestas palabra por palabra. Suena bien la primera vez. El problema llega cuando te repreguntan. Recitas tu respuesta perfecta sobre por qué elegiste una arquitectura, el entrevistador asiente y suelta un "Interesting — why did you choose that over the alternative?", y ahí se acabó el guion. No lo tenías ensayado, y como nunca practicaste producir sobre la marcha, te quedas en blanco. Defenderte en una entrevista en inglés no es tener un inglés perfecto. Es saber moverte cuando no te sale la palabra, cuando la pregunta se desvía, cuando hay que improvisar sobre algo que sí dominas técnicamente.

Contar tu experiencia con STAR (y en pasado, que es donde se cae)

STAR (Situation, Task, Action, Result) es el esqueleto estándar para responder preguntas de comportamiento, pero recitarlo como una lista mecánica suena a robot. El truco está en usarlo como guía interna mientras narras con naturalidad. Imagina que cuentas un incidente en producción: la situation es "teníamos un servicio que petaba bajo carga los lunes por la mañana"; la task, "me tocó encontrar la causa antes del siguiente pico"; la action, lo que hiciste; el result, el dato concreto con el que cierras. El error es soltarlo como "First... Second... Third...". Eso no es contar una historia, es leer bullets en voz alta.

Donde más se cae el hispanohablante es en los tiempos verbales. Cuando narras algo terminado en el pasado, va en past simple, no en present perfect. Dices "I worked on a microservice last year", no "I have worked on a microservice last year" — esa segunda frase chirría a cualquier nativo. El present perfect es para experiencia general sin tiempo concreto ("I've worked with Kafka"), no para una historia con fecha. Y cuidado con abusar del present continuous ("I was working, I was doing, I was deploying"): no todo lo pasado es continuo.

El result es donde más se nota la diferencia entre quien improvisa y quien lleva la historia preparada. Ten en la cabeza el detalle técnico real —no para soltarlo de carrerilla, sino para que el cierre sea concreto. Si el fix fue acotar el pool de conexiones de HikariCP, sabes exactamente a qué apuntar:

# application.yml — el cambio que cerró el incidente
spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      leak-detection-threshold: 2000   # ms; HikariCP avisa de conexiones no devueltas

Con eso claro, el result deja de ser vago. En vez de "in the end we fixed it", dices "we capped the pool at 20, turned on leak detection, and p99 dropped from four seconds back under 200ms". Un verbo concreto y un dato medible. Esa es la frase que el entrevistador recuerda cuando compara candidatos al terminar el día.

Los conectores narrativos son los que hacen que suenes a persona y no a esquema. Tenlos listos: "At that point...", "So what I ended up doing was...", "In the end we...", "Looking back, I'd probably...". Esa última es oro, porque demuestra reflexión sin que te lo pidan. Un buen entrevistador valora más un "Looking back, I'd have added monitoring earlier" que una respuesta donde todo salió perfecto.

Explicar tu proyecto y tus decisiones técnicas en voz alta

En la parte de system design o cuando te piden que describas un proyecto, lo que se juzga no es el resultado: es tu razonamiento. Y razonar en voz alta en inglés es una habilidad de idioma propia, con sus frases puente. Empieza dando contexto antes de lanzarte: "There's a bit of context I should give first" o "Let me walk you through how it works". Luego estructura en voz alta siguiendo un orden simple — contexto, decisión, por qué, qué harías distinto — para no perderte ni perder al entrevistador.

La frase clave para cualquier decisión técnica es la del trade-off, porque señaliza madurez: "The main trade-off here was X versus Y", y acto seguido lo aterrizas: "We went with Kafka over a simple queue because we needed replay and ordering guarantees". No basta con decir qué hiciste; di contra qué lo elegiste y qué te costó. Eso es lo que separa a un senior de alguien que solo sabe nombrar tecnologías. Es exactamente el mismo músculo que usas cuando justificas una decisión en un comentario de PR review — "I'd go with X over Y here because…" —, solo que en vivo y sin el lujo de reescribirlo tres veces antes de enviar.

Y ahí es donde llega la pregunta de seguimiento, la parte que casi nadie ensaya. Memoriza cómo se sale limpio de un bache así:

Entrevistador: "Why Kafka and not just a database table as a queue?" Tú: "Good question. The main trade-off was operational complexity versus guarantees. A DB table would've been simpler to run, but we needed ordered replay after failures, and bolting that onto a table gets messy fast. So we took the extra ops cost in exchange for ordering and replay. Honestly, if the volume had been low, I'd have started with the table."

Fíjate en lo que hace esa respuesta: reconoce la alternativa ("would've been simpler"), nombra el trade-off explícito y cierra con una reflexión honesta ("if the volume had been low..."). No defiende la decisión a muerte; la sitúa. Eso transmite criterio, no inseguridad.

Y no monologues. Una respuesta de cinco minutos sin pausas asusta. Suelta cada poco un "Does that make sense so far?" o un "Happy to go deeper on any part". Invitas feedback, controlas el ritmo y te das un respiro para pensar la siguiente frase. Cuando me tocó explicar una arquitectura sobre Kubernetes en una reunión internacional con el inglés al límite, lo que me salvó no fue el vocabulario técnico —ese lo tenía— sino estas frases puente: me daban el medio segundo que necesitaba para ordenar la idea en inglés en lugar de quedarme congelado a mitad de explicación.

Qué hacer cuando te bloqueas o no entiendes la pregunta

Lo primero: tener frases de rescate automáticas, tan interiorizadas que salgan solas cuando algo falla. Si no entiendes la pregunta, no respondas otra cosa con la esperanza de acertar. Pide aclaración: "Could you rephrase that?" o, mejor todavía, parafrasea de vuelta para confirmar: "Just to make sure I understand, are you asking about how we scaled it, or why we chose that approach?". Eso no te hace parecer perdido — te hace parecer alguien que se asegura antes de actuar, que es exactamente lo que quieren en un ingeniero.

Cuando necesitas pensar, no dejes silencio muerto: cómpralo en voz alta. "That's a good question, let me think for a second" o "Let me take a step back" te dan tiempo legítimo sin que parezca que te has bloqueado. Y si lo que falla es una palabra concreta que no te sale, no te frustres en silencio: descríbela. "I can't think of the exact term right now, but it's the thing that handles retries when a request fails". El entrevistador casi siempre te da la palabra ("backoff?", "a retry policy?") y sigues adelante sin que el bache se note.

Hay una asimetría que conviene interiorizar: un buen entrevistador valora muchísimo más que pidas aclaración a que respondas algo distinto de lo que te preguntó. Pedir que repitan señala que escuchas y que te importa entender bien. Responder por las ramas señala lo contrario. En la duda, pregunta.

El cierre que casi nadie prepara: tus preguntas y el salario

Cuando el entrevistador dice "Do you have any questions for us?", la entrevista no ha terminado: ha cambiado de manos. Es tu turno de demostrar nivel con lo que preguntas. Evita lo genérico —el "How is the team structured?" lo suelta todo el mundo y no dice nada de ti— y tira una pregunta con filo: "How do you handle code review and PR culture here?". Esa hace doble trabajo: te da información real sobre cómo se trabaja ahí dentro y, de paso, señala que el code review te importa de verdad. Y si quieres rematar, pregunta por lo que de verdad te vas a comer en el día a día: "What happens when a PR sits unreviewed for three days?". La respuesta te dice más de la cultura del equipo que cualquier página de careers.

Y luego está la parte que el contenido genérico despacha con un "lleva una cifra preparada", como si soltar un número fuera la habilidad. La habilidad es el lenguaje: hablar de dinero en inglés con firmeza y sin cerrarte puertas. Mantente flexible pero claro: "I'm open to discussing compensation based on the role's scope and the market". Y no tengas miedo de devolver la pregunta: "Could you share the band for this role?" es perfectamente normal y te da información antes de comprometerte a un número.

Para un puesto remoto internacional hay un detalle que el contenido genérico ignora: una cifra no significa nada hasta que confirmas en qué moneda y por qué periodo va. Antes de reaccionar a un número, aclara: "Just to confirm — is that gross annual, and in euros or dollars?". Suena a profesional que sabe que un salario remoto cruza divisas y fiscalidades distintas, no a alguien deslumbrado por un número que igual encoge a la mitad al pasarlo a tu moneda. Y el solapamiento horario suele salir, así que tenlo resuelto: "I'm comfortable overlapping a few hours with your timezone" transmite que eres consciente de la logística y que no será un problema. Controlar este tramo final en inglés —preguntas, salario, remoto— es lo que separa una entrevista que terminas improvisando de una que cierras tú.

Cuándo NO aplica nada de esto

Todo lo anterior va de entrega en directo, y hay formatos donde eso pesa poco. Si el proceso es 100% asíncrono —un take-home, mensajes escritos, una prueba técnica sin call— lo que te juzga es tu inglés escrito, no el hablado, y ahí mandan otras reglas: claridad en el PR, mensajes de Slack bien redactados, un README legible. Es una habilidad distinta y merece su propia preparación. Y ya que estamos: a mí los take-home me parecen bastante más justos que la call a contrarreloj, porque miden tu trabajo y no tus nervios delante de un desconocido — pero esa es otra guerra.

Tampoco apliques esto en un screening inicial con un recruiter no técnico: ahí el guion básico de presentación sobra y nadie espera que verbalices trade-offs. En un live coding puro pasa algo parecido — el silencio mientras piensas es esperado, y narrar cada línea hasta puede molestar; lo que se valora es el código, no tu fluidez verbal. Y si el rol es junior y local, donde el inglés es un nice to have y no decisivo, no te obsesiones con esto: prepárate lo técnico y duerme tranquilo.

Un aviso para terminar: dominar el inglés para entrevistas de trabajo tech te abre la puerta, pero la entrevista es solo el primer día. Si quieres seguir afinando esta fase concreta, tienes más material sobre entrevistas en inglés para repasar antes del día clave. Y si el equipo trabaja en inglés a diario, después vienen las frases del daily, los PR reviews y los Slack DMs de cada jornada. Eso no se improvisa una tarde — se entrena con constancia.

Preguntas frecuentes

¿Puedo llevar las respuestas escritas y leerlas durante la entrevista? Puedes llevar un par de notas con datos concretos —cifras de tu proyecto, nombres de tecnologías— y es lo normal. Lo que no funciona es leer respuestas enteras: se nota muchísimo en el ritmo y la entonación, y te hunde en cuanto llega la primera repregunta fuera de guion.

¿Qué hago si no entiendo el acento del entrevistador? Pide que reformule sin dramatizar: "Sorry, could you rephrase that?". Es totalmente legítimo, sobre todo en equipos internacionales donde el propio entrevistador a menudo tampoco es nativo. Pedir aclaración nunca resta; responder otra cosa por no preguntar, sí.

¿Está mal pedir un segundo para pensar en inglés? Al contrario. "Let me think for a second" es lo que hace un profesional antes de una respuesta meditada. Lo que resta es el silencio sin explicar; un silencio anunciado en voz alta es señal de criterio, no de duda.