Proceso y entrevistas

¿Cómo es la entrevista técnica con una empresa de Estados Unidos?

22 de agosto de 2026 · Equipo Talento Bilingüe · 22 min de lectura

Llevas ocho años programando y te tumbó un ejercicio de algoritmos que no habías vuelto a tocar desde la universidad. No fue que no supieras resolverlo — a los cinco minutos ya tenías la lógica clara en la cabeza. Fue que tenías que explicarla en inglés, en voz alta, con alguien mirando tu pantalla en tiempo real, mientras una parte de tu cerebro seguía traduciendo internamente antes de hablar. Saliste de esa llamada sabiendo que el código estaba bien y sin saber si el resto había estado a la altura. Esa sensación —dominar el oficio y no saber cómo se juzga este formato específico— es la que resuelve este artículo.

Si ya pasaste el video de presentación y el screening con el recruiter, llegaste a la etapa que de verdad filtra: la entrevista técnica. Es el paso 3 de un proceso de 5 etapas que en total toma entre 2 y 6 semanas, según el mapa completo de cómo es el proceso de selección con una empresa de Estados Unidos. Pero esa etapa 3 no es una sola cosa: puede ser un coding test cronometrado, un proyecto para resolver en casa, una conversación sobre patrones de diseño, o una sesión de system design si el rol es senior. Cada formato mide algo distinto, y prepararte para el equivocado es la manera más común de llegar con el conocimiento correcto y el enfoque incorrecto.

¿Qué formatos de entrevista técnica usan las empresas de Estados Unidos?

Usan sobre todo cuatro: coding test estilo LeetCode, take-home, evaluación de patrones de diseño, y system design — este último reservado casi siempre para perfiles senior. Para roles que no son de programación, el equivalente es una prueba de habilidades diseñada para ese oficio específico.

Ninguna empresa usa los cuatro formatos técnicos en la misma entrevista. Lo normal es que combinen uno o dos según el rol y el tiempo que tengan asignado para esa etapa. Si aplicaste a un puesto junior o mid, es más probable que te toque el coding test o el take-home. Si aplicaste a algo senior, el system design entra en la conversación con más peso, aunque no reemplaza del todo al resto — puede aparecer una ronda de cada uno. Dos plataformas que dan coaching a candidatos latinos para este tipo de procesos, Tecla y Puente Talent, preparan a su gente específicamente para saber cuál de estos formatos les espera antes de llegar a la llamada; Turing, además de ese acompañamiento, aplica sus propios assessments técnicos como parte de su proceso interno de certificación de talento.

El coding test estilo LeetCode: qué mide en realidad

Un coding test mide si puedes traducir un problema en palabras a una solución en código, explicando el razonamiento mientras lo haces — no si memorizaste la solución de memoria. La diferencia es más importante de lo que parece: dos candidatos pueden llegar al mismo código y salir con evaluaciones completamente distintas según cómo llegaron ahí.

Lo incómodo que hay que decir de frente: este formato mide una habilidad real, pero distinta de saber programar bien. Puedes tener años construyendo sistemas en producción, resolviendo bugs difíciles de rastrear, tomando decisiones de arquitectura que le ahorraron dinero a una empresa, y aun así trabarte frente a un problema de algoritmos que no se parece a nada de lo que haces en tu trabajo diario. Eso no te hace peor desarrollador. Te hace alguien que no ha practicado un tipo de ejercicio específico últimamente. La entrevista no está midiendo tu carrera completa en una sola sesión — está midiendo si puedes pensar con estructura bajo presión y comunicarlo mientras lo haces.

Lo que sí puedes controlar es el proceso, no la dificultad del problema:

• Antes de escribir una línea, repite el problema con tus propias palabras en voz alta. Esto confirma que entendiste lo que te pidieron y le da al entrevistador la oportunidad de corregirte si vas por el camino equivocado, algo que agradecerás quince minutos después.
• Pregunta por los casos límite antes de programar: ¿qué pasa si la entrada viene vacía? ¿puede haber números negativos? ¿el arreglo puede tener duplicados? Estas preguntas no son un truco para ganar tiempo — son exactamente lo que un desarrollador con experiencia hace antes de escribir código en un trabajo real.
• Empieza por la solución que sabes que funciona, aunque no sea la más eficiente. Un código de fuerza bruta que corre y que puedes mejorar después vale más que un silencio de diez minutos buscando la solución óptima desde el principio.
• Nombra la complejidad de tu solución (tiempo y espacio) sin que te lo pidan. Es la señal más rápida de que entiendes lo que estás escribiendo, no solo que lo copiaste de un patrón memorizado.

La preparación técnica de fondo —practicar estructuras de datos, recorridos, recursión, programación dinámica— sigue el camino que ya conoces si llevas años en esto: repetición espaciada, problemas variados, revisar tus propias soluciones días después para ver qué se te olvidó. Lo que cambia frente a una entrevista en inglés no es el contenido técnico. Es la capa de encima, y esa capa tiene su propia sección más abajo porque se prepara distinto.

Pensar en voz alta en inglés mientras programas: la habilidad que de verdad evalúan

La habilidad que en realidad se juzga en una entrevista técnica en inglés no es resolver el problema — es narrar tu razonamiento mientras lo resuelves, en un idioma que no es el tuyo, sin que el esfuerzo de traducir se coma tu capacidad de pensar. Son dos tareas cognitivas corriendo al mismo tiempo, y la mayoría de los candidatos latinos con inglés sólido nunca practicó hacerlas juntas.

Piensa en la diferencia entre dos escenarios. En el primero, programas en silencio, terminas, y explicas lo que hiciste al final: eso es cómo trabajas solo, un viernes en la tarde, sin nadie mirando. En el segundo, narras cada decisión mientras la tomas: "voy a usar un diccionario acá porque necesito buscar esto en tiempo constante", "este caso me preocupa porque el arreglo podría venir vacío, lo reviso primero". El segundo escenario es el que un entrevistador estadounidense espera, porque en el trabajo remoto real vas a tener que hacer exactamente eso en una llamada de pair programming o revisando un pull request con el equipo: pensar en voz alta, en inglés, sin que se note el esfuerzo.

Cómo se practica esto de verdad, sin depender de que alguien más esté disponible para simular la entrevista:

• Resuelve problemas de práctica narrando en inglés en voz alta, grabándote con el celular. No para memorizar frases — para escuchar dónde te quedas trabado buscando una palabra y perdiendo el hilo de lo que estabas explicando.
• Construye un vocabulario técnico de quince a veinte frases que uses todo el tiempo en este tipo de ejercicio: "let me walk through my approach", "I'll start with a brute force and optimize from there", "this edge case worries me because...", "let me trace through an example". Tenerlas ya armadas te libera de construirlas desde cero bajo presión.
• Practica con alguien, aunque sea otro desarrollador latino en las mismas condiciones que tú: el objetivo no es que la otra persona hable con fluidez de nativo, es que ensayes la narración en voz alta con alguien escuchando y haciendo preguntas.
• Si te trabas buscando una palabra específica en inglés, para y descríbela con otra: "the thing that stores key-value pairs" en vez de congelarte quince segundos buscando "dictionary". Un entrevistador entiende una descripción torpe. No entiende un silencio sin explicación.
• Practica el mismo problema dos veces: la primera para resolverlo, la segunda solo para narrar la solución ya conocida en voz alta y en inglés, cronometrándote. Notarás que la segunda vez el idioma deja de ser el cuello de botella — y esa es la sensación que necesitas replicar el día de la entrevista real.

Esta habilidad no se adquiere leyendo sobre ella. Se adquiere haciéndola, en voz alta, muchas veces, antes de que la primera vez sea con dinero real sobre la mesa.

El take-home: cómo distinguir un proyecto legítimo de trabajo gratis disfrazado

Un take-home legítimo tiene un alcance claro, un plazo razonable frente a ese alcance, y un propósito evaluativo — no construir una funcionalidad que la empresa después usa en producción sin pagarte por ella. La línea entre ambas cosas a veces es difusa, y hay empresas que se aprovechan exactamente de esa zona gris con candidatos que necesitan el trabajo y no quieren arriesgar el proceso preguntando.

Señales de que un take-home se pasó de la raya:

• Te piden una funcionalidad completa, con manejo de errores, pruebas automatizadas, documentación y despliegue, para "un ejercicio de dos horas" que en la práctica toma dos días.
• El alcance suena sospechosamente parecido a un problema real que la empresa mencionó tener en la entrevista anterior — no un ejercicio genérico, sino algo que resolvería un dolor específico de su producto actual.
• No hay plazo definido ni límite de horas sugerido, lo que en la práctica traslada todo el riesgo de "cuánto tiempo es razonable" a tu criterio, y a tu ansiedad de hacerlo bien.
• Te piden entregar el código bajo una licencia que cede derechos amplios sobre lo que construiste, o te piden integrarlo directamente contra su repositorio real en vez de un entorno aislado para la prueba.

Qué responder sin quemar el proceso, porque la respuesta importa tanto como el código:

Un mensaje corto y profesional funciona mejor que el silencio o que aceptar sin decir nada: "Quiero asegurarme de invertir el tiempo correcto en esto — ¿hay un límite de horas sugerido para el ejercicio?" es una pregunta razonable que cualquier empresa seria responde sin problema. Si la respuesta es evasiva o el alcance sigue sin acotarse después de preguntar, esa misma evasión ya es información sobre cómo esa empresa trata a la gente antes de contratarla — y vale la pena sopesarla contra lo que sabes de la vacante y de la empresa antes de decidir si sigues o te retiras. Fijar tú mismo un límite de horas y entregarlo con una nota que diga "trabajé en esto durante X horas, esto es hasta donde llegué en ese tiempo" también es una opción válida: comunica criterio profesional, algo que en sí mismo es parte de lo que están evaluando.

Lo incómodo que también hay que decir: no todo take-home extenso es abuso. Algunos roles —sobre todo los que exigen decisiones de arquitectura— necesitan un ejercicio más largo que un coding test cronometrado para evaluar algo real. La diferencia entre eso y trabajo gratis disfrazado no está en la duración sola, está en si el resultado termina usándose y en si el alcance fue honesto desde el principio sobre cuánto tiempo tomaría.

System design: qué esperan de un senior latino (y qué no)

En system design esperan que razones sobre trade-offs de arquitectura en voz alta, hagas preguntas para acotar el problema antes de diseñar, y manejes los conceptos base de sistemas distribuidos con soltura. No esperan que memorices las cifras exactas de infraestructura de una empresa específica ni que hayas operado sistemas a la escala de las compañías más grandes del mundo.

Esta distinción importa particularmente para un candidato latino senior, porque hay una ansiedad común y equivocada: pensar que el listón es haber trabajado ya en sistemas del tamaño de los que manejan las empresas más grandes de Silicon Valley. No es así. Lo que evalúan es tu forma de razonar frente a la ambigüedad, no tu currículum de escala previa.

Qué sí forma parte real de lo que se evalúa:

• Hacer preguntas de acotación antes de diseñar nada: ¿cuántos usuarios esperamos?, ¿qué tan crítica es la consistencia frente a la disponibilidad?, ¿hay un presupuesto de latencia específico? Un candidato que empieza a dibujar componentes sin acotar el problema primero muestra menos criterio que uno que tarda dos minutos en hacer las preguntas correctas.
• Conocer los bloques básicos y cuándo usarlos: cuándo cachear y qué invalidar, cuándo un balanceador de carga resuelve algo y cuándo no, las diferencias prácticas entre una base de datos relacional y una no relacional para un caso dado, qué implica particionar o replicar datos.
• Explicar trade-offs en vez de dar una respuesta única y cerrada: "podríamos resolver esto con una cola de mensajes si aceptamos algo de latencia adicional a cambio de desacoplar los servicios" muestra más criterio que llegar directo a un diagrama sin mencionar la alternativa que descartaste y por qué.
• Reconocer los límites de tu propio diseño en voz alta: decir "esto funciona hasta cierto volumen, pero si crece diez veces habría que revisar esta parte" es exactamente el tipo de honestidad técnica que un entrevistador senior valora más que una respuesta que suena segura pero no admite ningún punto débil.

Qué no forma parte de lo que se evalúa, aunque la ansiedad diga lo contrario: no necesitas conocer de memoria la arquitectura interna de un servicio específico de una empresa grande, ni recitar cifras exactas de tráfico que nunca has manejado, ni llegar con un diagrama ya armado y memorizado de antemano. Un system design que se siente como una conversación —con pausas para pensar, con correcciones sobre la marcha, con preguntas del entrevistador que cambian el rumbo— es más representativo de cómo se hace este trabajo en la vida real que uno que sale fluido de principio a fin porque lo ensayaste palabra por palabra.

Patrones de diseño: la conversación que se disfraza de pregunta técnica

Una entrevista sobre patrones de diseño no busca que nombres el patrón correcto de memoria — busca ver si reconoces un problema estructural en el código y sabes justificar por qué una solución conocida (o ninguna) le queda bien a ese caso específico. Es habitual que aparezca junto al coding test o dentro del take-home, no como una ronda aparte y separada.

La forma más común en que se presenta es mostrarte un fragmento de código con un problema real —demasiadas condicionales anidadas, una clase que hace demasiadas cosas, un componente difícil de extender sin tocar el código existente— y pedirte que propongas cómo lo reestructurarías. Lo que buscan no es que sueltes el nombre en inglés de un patrón de un libro. Buscan que expliques qué problema concreto resuelve la reestructuración que propones, y que reconozcas cuándo aplicar un patrón sería sobre-ingeniería para un caso que en realidad es simple. Decir "acá no aplicaría ningún patrón adicional porque la complejidad no lo justifica" es, en muchos casos, mejor respuesta que forzar una solución elaborada donde no hace falta.

Si tu rol no es técnico: la prueba de habilidades equivalente

Para roles que no son de programación —marketing, ventas, soporte, diseño, operaciones— el equivalente de la entrevista técnica es una prueba de habilidades: una tarea representativa del trabajo diario del puesto, evaluada con el mismo peso que un coding test para un desarrollador. La lógica detrás es la misma: la empresa quiere ver el trabajo antes de contratarte, no solo escuchar que dices saber hacerlo.

Estas pruebas varían mucho según el oficio, pero comparten una estructura: te dan un caso o un material real (una campaña de anuncios para analizar, un ticket de soporte difícil para responder, una pieza de diseño para revisar y mejorar) y un plazo corto para entregar tu solución o tu análisis. Las mismas reglas del take-home técnico aplican acá: si el alcance parece desproporcionado frente al plazo, o si el material que te dan se parece sospechosamente a un problema real y actual de la empresa, vale la pena preguntar por los límites antes de invertir horas sin saber qué esperar a cambio.

Qué preparar según el formato que te toque

Ninguna de estas preparaciones reemplaza la base técnica que ya construiste en años de trabajo. Lo que hacen es traducir esa base a lo que un entrevistador de Estados Unidos necesita ver en el rato acotado de una sola llamada para confiar en que sabes lo que dices saber.

Te trabas en vivo: qué hacer cuando el problema no te sale

Cuando te trabas en una entrevista técnica en vivo, lo único que de verdad no se perdona es el silencio prolongado — no el error, no la duda, no cambiar de enfoque a mitad de camino. Un entrevistador puede trabajar con alguien que se equivoca y corrige en voz alta. No puede evaluar a alguien que se queda callado dos minutos mirando la pantalla sin decir en qué está pensando.

Qué hacer en el momento exacto en que sientes que te trabaste:

• Di en voz alta que te trabaste. Literalmente: "me quedé pensando en cómo abordar esta parte, dame un segundo" ya es información útil para el entrevistador y te compra el tiempo sin que el silencio se sienta como que perdiste el hilo por completo.
• Vuelve al problema original y repítelo con tus palabras. Muchas veces el bloqueo no es de conocimiento — es de haberte alejado demasiado del enunciado original mientras pensabas en la solución.
• Prueba con un ejemplo concreto y pequeño a mano, trazándolo paso a paso. Ver los números o los datos moverse casi siempre destraba una idea que resultaba abstracta e inmanejable en la cabeza.
• Si de verdad no ves el camino, dilo con honestidad y pide una pista: "no estoy viendo cómo optimizar esto más allá de la fuerza bruta, ¿hay alguna pista que me puedas dar sobre por dónde ir?". Pedir ayuda de forma puntual y específica se lee como criterio, no como debilidad — es exactamente lo que harías con un colega senior en un trabajo real.
• Nunca borres todo tu código para "empezar de cero" en silencio. Si vas a cambiar de enfoque, dilo primero: "esto no está funcionando, voy a probar con otra estructura" — y recién ahí borra.

Una entrevista donde te trabaste, lo dijiste, pediste una pista puntual y terminaste el problema con ayuda suele calificar mejor que una donde llegaste solo pero en silencio total durante los minutos difíciles. Esto no es una regla escrita en ningún lado que las empresas publiquen — es el patrón que describe cómo se siente del otro lado de la pantalla para quien evalúa: puede juzgar lo que ve y escucha, no lo que pasa dentro de tu cabeza mientras no dices nada.

Qué sigue después de la técnica: el filtro que nadie te explica bien

Si pasas la entrevista técnica, lo que sigue es la conversación con el cliente o el hiring manager — behavioral, culture fit, y un criterio que casi nunca se nombra en español con precisión: el "high agency". Ahí evalúan si resuelves problemas por tu cuenta sin que te lleven de la mano, más que si sabes la respuesta correcta a una pregunta hecha.

Esta etapa se prepara distinto de la técnica: con historias concretas de decisiones que tomaste sin que te lo pidieran, no con más práctica de algoritmos. El detalle completo de qué buscan exactamente en esa conversación, cómo se estructura, y cuánto dura la espera típica antes de la oferta final está en el desglose de las cinco etapas del proceso de selección con una empresa de Estados Unidos, que también cubre lo que viene antes de la técnica: el video de presentación y el screening inicial con el recruiter.

Antes de llegar a esa conversación, ten presente que el proceso completo —desde el primer contacto hasta la oferta firmada— también verifica cosas que no tienen nada que ver con tu código: tu nivel de inglés profesional sostenido en videollamada, no solo en un ejercicio puntual; la estabilidad de tu internet, tu cámara y tu micrófono; y un solapamiento de al menos seis horas con el horario de Estados Unidos. Si vives en México, Colombia, o cualquier país en un huso similar, ese solapamiento se cumple con margen — pero vale la pena tenerlo confirmado de tu lado antes de que te lo pregunten, no improvisado en la llamada.

Cuánto puedes ganar según tu nivel

Los rangos típicos por seniority para roles de desarrollo son: junior entre 30,000 y 42,000 dólares al año, mid entre 42,000 y 60,000, y senior entre 60,000 y 80,000 dólares o más. Estos números varían según la empresa, el tipo de contrato y el país donde vives, y conviene revisarlos con más profundidad en el desglose completo de cuánto paga una empresa de Estados Unidos a un desarrollador latino antes de negociar cualquier oferta que llegue después de pasar por todo este proceso.

Tener este contexto antes de la entrevista técnica también cambia cómo la vives: saber en qué rango debería caer la oferta si te va bien te quita presión de estar improvisando dos cosas a la vez — el problema técnico y la ansiedad económica de si esto vale la pena.

Dónde buscar estas vacantes si todavía no tienes ninguna en curso

Si todavía estás en la etapa de aplicar y no tienes una entrevista técnica agendada, vale la pena revisar primero qué empresas de Estados Unidos contratan de forma activa desde Latinoamérica para no perder tiempo preparándote para procesos de compañías que en la práctica no contratan fuera de Estados Unidos aunque su vacante diga "remoto". Y si prefieres ir directo a posiciones ya filtradas para este tipo de perfil, la sección de empleos del portal reúne vacantes activas que ya pasan ese primer filtro.

Preguntas frecuentes

¿Cuánto dura una entrevista técnica en promedio? No hay una cifra única: varía por empresa y por tipo de prueba —un coding test en vivo no dura lo mismo que un take-home con plazo de varios días, ni un system design se resuelve en el mismo tiempo que una conversación de patrones de diseño—. El rango de espera típico para toda la etapa 3 está detallado en el mapa completo de las cinco etapas del proceso de selección con una empresa de Estados Unidos.

¿Puedo pedir hacer la entrevista técnica en español? Es poco común que lo acepten, porque justamente lo que se evalúa incluye tu capacidad de comunicarte técnicamente en inglés, que es el idioma en el que vas a trabajar el día a día si te contratan. Pedirlo puede leerse como una señal de que el idioma todavía no está al nivel que el rol necesita.

¿Qué pasa si me va mal en el coding test pero bien en todo lo demás? Depende de cuánto peso le da esa empresa específica a ese formato frente al resto — no hay una regla universal. Algunas compensan un traspié puntual con un desempeño fuerte en las otras etapas; otras usan el coding test como filtro eliminatorio antes de seguir. Si no te dan feedback claro sobre esto, es información que puedes preguntar directamente al recruiter.

¿Los take-home siempre son gratis o alguna empresa paga por ellos? Varía. Algunas empresas, sobre todo para ejercicios más largos, ofrecen una compensación simbólica por el tiempo invertido. No es lo más común, pero preguntar si existe esa posibilidad es razonable y no debería afectar cómo te ven en el proceso.

¿El system design aplica también para un mid que aspira a un rol senior? Puede aparecer, aunque con menos peso que para alguien que ya certificó experiencia senior en su historial. Si tu nivel real está entre mid y senior, vale la pena repasar los conceptos base de todas formas, porque la pregunta puede entrar por cualquier lado de la entrevista.

Si después de leer esto te quedan dudas sobre contratos, impuestos o plataformas de pago que aparecen más adelante en el proceso, la sección de preguntas frecuentes del portal reúne las que más se repiten entre quienes ya pasaron por esta misma etapa.

---

Fuentes: el hilo de la comunidad r/CharruaDevs sobre cómo conseguir trabajo remoto para empresas de Estados Unidos, tecla.io y puentetalent.com.