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 · 25 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 que de verdad te van a poner

Aquí conviene decir algo que casi ningún artículo en español dice, y que cambia para quién es todo lo anterior: en los procesos reales de contratación bilingüe hacia Estados Unidos, el perfil de desarrollo de software es la excepción, no la norma. En nuestra propia base de perfiles —medio centenar de personas que han pasado por procesos de este tipo— prácticamente ninguna es de programación. La enorme mayoría entra a asistencia ejecutiva, contabilidad, operaciones, atención al cliente, ventas o gestión de casos.

Es una muestra nuestra, no una estadística del mercado. Pero si tu perfil es alguno de esos,

la entrevista técnica que te espera no tiene nada que ver con algoritmos.

Y aquí está el dato duro que vale por todo el artículo. En un proceso real, un cliente estadounidense rechazó a todos los candidatos que se le presentaron por cuatro motivos. Uno de los cuatro fue no manejar las herramientas del puesto. No fue falta de experiencia ni falta de inglés: fue no saber usar el gestor de tareas, la herramienta de diseño simple y el CRM que se usaban todos los días en ese trabajo.

Es, con diferencia, la razón de rechazo más fácil de eliminar: casi todas esas herramientas tienen plan gratuito y se aprenden lo suficiente en una tarde. Nadie te va a pedir que seas experto; te van a pedir que no sea la primera vez que las abres.

Las herramientas que aparecen una y otra vez, por familia de cargo:

MIS HERRAMIENTAS — marca las que ya abriste al menos una vez

TODOS LOS CARGOS
[ ] Google Workspace (Docs, Sheets, Drive, Calendar)
[ ] Slack
[ ] Zoom o Google Meet
[ ] Un gestor de tareas (Trello, Asana, ClickUp, Notion)

ASISTENCIA EJECUTIVA Y OPERACIONES
[ ] Manejo de calendarios con varias zonas horarias
[ ] Un diseñador simple tipo Canva
[ ] Automatizaciones básicas (Zapier o Make)

CONTABILIDAD
[ ] QuickBooks
[ ] Excel o Sheets con tablas dinámicas
[ ] Conciliación bancaria

CUSTOMER SERVICE Y VENTAS
[ ] Un CRM (HubSpot, Salesforce, GoHighLevel)
[ ] Un sistema de tickets (Zendesk, Freshdesk, Intercom)
[ ] Marcador o softphone

Si vas a hacer una sola cosa esta semana antes de aplicar, que sea esta: abre las tres o cuatro de tu cargo, haz una tarea de verdad en cada una y guarda una captura. Eso te saca de una de las cuatro razones reales de rechazo, y no depende de tu experiencia ni de tu inglés.

Las mismas reglas del take-home 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, pregunta por los límites antes de invertir horas.

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

Si tu perfil es asistencia, operaciones, contabilidad o atención al cliente, la referencia no son las cifras de seis dígitos que circulan en internet: esas corresponden a ingeniería y producto, que es otra familia de cargos. El desglose por familia está en cuánto paga una empresa de Estados Unidos, y cómo llegar a tu número, en la guía para negociar tu tarifa.

Si tu perfil sí es de desarrollo, los rangos típicos por seniority 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 o más, variando según empresa, contrato y país.

Sea cual sea tu caso, hay un detalle del proceso que conviene saber antes de sentarte a negociar: el salario que esperas es un campo de la ficha de entrevista. El número que digas queda escrito y viaja con tu proceso. Por eso el trabajo no es adivinar el rango del mercado, es llegar con tu número pensado y poder sustentarlo.

Si todavía estás aplicando: empresas de Estados Unidos que contratan desde Latinoamérica y empleos.

Desde adentro: para este avatar la “técnica” es prueba de herramientas

En nuestra base, de cada diez personas que entran a estos procesos, casi ninguna es de desarrollo de software. Si estás preparando algoritmos para una vacante de asistente, estás estudiando para el examen equivocado.

La prueba que sí llega: gestor de tareas, hoja de cálculo, CRM, sistema de tickets, o el software contable del puesto. No manejar las herramientas fue una de las cuatro razones reales de rechazo de una terna — y es la más barata de cerrar. Reading y Speaking se califican aparte; la clínica de ventas /10 aparece aunque el cargo no sea ventas (soltura fuera de guion). Ingeniería, cuando aparece, se rotula como excepción.

Tu ruta, en orden, la semana antes de la prueba

1. Nombra el cargo real (asistencia, CS, ventas, bookkeeping, casos). No prepares LeetCode si no es desarrollo.
2. Lista las tres herramientas del aviso y abre una cuenta de prueba en la de más peso.
3. Haz una tarea corta (una reunión que choca, un ticket, una conciliación) y nómbrala en voz alta en inglés.
4. Practica hablar sin leer. Leer un guion es un rechazo real y se nota en la prueba de habilidades.
5. Ten diadema probada. Sin ella no tomas llamadas el día uno; la prueba tampoco.

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.

<!-- D18: ruta de 5 pasos la semana antes de la prueba de herramientas -->