La entrevista técnica es la instancia donde la empresa comprueba que el candidato sabe hacer lo que el CV dice que sabe hacer. A diferencia de la charla con recursos humanos, acá hay un problema concreto sobre la mesa: un ejercicio de código, un caso de negocio, una prueba de laboratorio, una clase modelo. Y a diferencia de lo que muchos candidatos suponen, la respuesta correcta es solo una parte de lo que se evalúa.
Esta guía describe los formatos más frecuentes de entrevista técnica, propone un plan de preparación de una a dos semanas, explica qué observa el evaluador además del resultado y recorre los errores que más descartes producen. Aplica a programación, pero también a finanzas, docencia, diseño, ingeniería y cualquier rubro donde exista una prueba práctica.
En esta guía
Qué es una entrevista técnica y cuándo aparece
En casi todos los procesos de selección con más de una etapa, la entrevista técnica llega después del primer filtro con recursos humanos y antes de la conversación final con la gerencia. La conduce alguien que hace o supervisa el trabajo del puesto: un líder técnico, un gerente de área, un profesional senior. Su objetivo es reducir la incertidumbre sobre una sola pregunta: si esta persona entra al equipo el lunes, ¿puede resolver los problemas reales del rol?
El nombre varía según el rubro. En tecnología se habla de entrevista técnica o "technical screen"; en consultoría, de "case interview"; en docencia, de clase de oposición o clase modelo; en salud y laboratorio, de prueba práctica o examen de competencias. El formato cambia, la lógica es la misma: mostrar el trabajo, no describirlo.
Los tipos más comunes de entrevista técnica
Conviene averiguar el formato exacto con anticipación. La mayoría de los reclutadores lo informa si se pregunta, y prepararse para un live coding cuando lo que viene es un take-home desperdicia una semana de esfuerzo.
Live coding o prueba en vivo
El candidato resuelve un ejercicio frente al evaluador, en un editor compartido o en pizarra, durante 45 a 60 minutos. Los problemas suelen ser de complejidad media: manipular estructuras de datos, recorrer una colección, diseñar una función con casos borde. Lo que pesa es el proceso: cómo se entiende la consigna, qué preguntas se hacen antes de escribir y cómo se reacciona ante un error propio.
Take-home o ejercicio para entregar
Se recibe una consigna por escrito y se entrega en dos a cinco días. Suele ser un proyecto pequeño pero completo: una API con dos endpoints, un análisis de un conjunto de datos, una propuesta de diseño para una pantalla. Acá no se evalúa velocidad sino criterio: legibilidad, pruebas, documentación breve y decisiones justificadas. Un README de diez líneas que explique qué se hizo y qué se dejó afuera por tiempo vale tanto como el código.
System design o diseño de sistemas
Reservado a perfiles con algunos años de experiencia. El evaluador plantea un problema abierto ("diseñar un sistema de notificaciones para un millón de usuarios") y espera que el candidato haga preguntas, delimite el alcance, proponga una arquitectura y discuta compromisos: consistencia contra disponibilidad, costo contra latencia. No hay respuesta única; se mide la capacidad de conversar sobre decisiones técnicas.
Caso de negocio
Habitual en consultoría, finanzas, marketing y producto. Se presenta una situación ("un cliente pierde un 10 % de ventas por trimestre, ¿qué se hace?") y se pide estructurar el análisis en voz alta, estimar magnitudes y llegar a una recomendación. Pesa más el orden del razonamiento que el número final, siempre que el número sea defendible.
Pruebas prácticas en otros rubros
Fuera de oficinas también hay entrevista técnica: la clase de 20 minutos frente a un jurado docente, la prueba de bandeja en gastronomía, el ejercicio de conciliación bancaria en un puesto contable, la traducción de una página con tiempo, el diagnóstico de una falla en un equipo. La preparación sigue la misma lógica que en tecnología: conocer el formato, practicar con tiempo y explicar lo que se hace mientras se hace.
Cómo prepararla en una o dos semanas
Con el formato confirmado, una o dos semanas alcanzan para llegar en condiciones si el tiempo se reparte con criterio. El plan que sigue asume unas 8 a 12 horas totales, distribuidas en sesiones cortas.
- Días 1 y 2: releer el aviso y detectar el temario. Cada tecnología, herramienta o competencia mencionada en la oferta es un tema probable. Conviene anotar cuáles se dominan y cuáles están flojas, y concentrar el estudio en las segundas.
- Días 3 a 6: practicar problemas del tipo esperado. Para live coding, dos o tres ejercicios diarios de dificultad media, con cronómetro y en voz alta. Para casos de negocio, un caso por día con estructura escrita. Para clases modelo, el guion completo de la clase ensayado frente a alguien.
- Días 7 y 8: repasar fundamentos del rol. Los conceptos que un evaluador senior espera que cualquiera del nivel maneje sin dudar. Las preguntas típicas por nivel están en la guía de preguntas de entrevista para programador junior.
- Días 9 y 10: simulacro completo. Una sesión con la duración y el formato reales, con otra persona o con un simulador, seguida de una revisión honesta de lo que salió mal.
- Víspera: descanso y logística. Entorno de desarrollo probado, cámara y micrófono verificados si es remota, y nada de estudiar temas nuevos.
El resto de la preparación no técnica (investigar la empresa, preparar preguntas propias) se cubre en la guía sobre cómo prepararse para una entrevista. No conviene saltearla: una entrevista técnica sigue siendo una entrevista.
Qué evalúan además de la respuesta
Un evaluador experimentado sabe que el ejercicio de 45 minutos es una muestra chica. Por eso observa señales que predicen el desempeño real mejor que el resultado del ejercicio en sí.
Razonamiento en voz alta. Es el factor que más pesa y el que menos se practica. Explicar qué se está pensando ("primero voy a validar la entrada, después resuelvo el caso general y al final veo los bordes") permite al evaluador seguir el proceso y ayudar si hace falta. El silencio prolongado, aunque termine en una solución correcta, deja al evaluador sin información.
Preguntas antes de empezar. Una consigna técnica casi siempre tiene ambigüedades intencionales. Preguntar por el tamaño de los datos, los casos borde o las restricciones de tiempo demuestra el hábito de entender el problema antes de resolverlo, que es exactamente lo que se espera en el trabajo real.
Reacción ante el error. Equivocarse durante la prueba es normal y, para el evaluador, es una oportunidad de ver algo valioso: si el candidato detecta el error solo, cómo lo corrige y si acepta una pista sin ponerse a la defensiva. Un candidato que se traba y pide un minuto para reorganizarse queda mejor que uno que insiste en un camino equivocado.
Las preguntas que hace el candidato al final. Preguntar cómo es el proceso de revisión de código, qué herramientas usa el equipo o cómo se decide qué construir muestra interés en el trabajo concreto. La guía sobre qué preguntar en una entrevista tiene ejemplos que sirven también para esta instancia.
Cuando no se sabe la respuesta, la peor salida es inventarla. Decir "no lo usé, pero entiendo que funciona así y lo verificaría de esta manera" transmite honestidad y método. Sostener una respuesta falsa ante las repreguntas es un descarte casi seguro.
Errores frecuentes en la entrevista técnica
Los descartes en esta etapa rara vez se deben a falta de conocimiento absoluto. Se deben a hábitos que un evaluador detecta rápido y que se corrigen con práctica.
| Así no | Así sí |
|---|---|
| Empezar a escribir código en cuanto se lee la consigna | Reformular el problema en voz alta y preguntar dos o tres cosas antes de escribir |
| Resolver en silencio durante diez minutos | Narrar el plan y cada decisión intermedia, aunque suene obvio |
| Optimizar desde el inicio y no terminar nunca | Entregar primero una solución que funcione, después mejorarla si sobra tiempo |
| Entregar un take-home sin pruebas ni README | Incluir pruebas mínimas y un README con decisiones y pendientes |
| Discutir una pista del evaluador | Tomarla, agradecerla y seguir; la pista es parte del ejercicio |
| Responder "no sé" y quedarse callado | Explicar cómo se averiguaría y qué se probaría primero |
| No preparar ninguna pregunta para el final | Llevar dos preguntas sobre cómo trabaja el equipo en el día a día |
Un error adicional, propio del take-home, es dedicarle tres veces más tiempo del sugerido. Los evaluadores lo notan y no necesariamente lo valoran: una entrega de 40 horas para una consigna de 6 sugiere dificultad para acotar, no dedicación.
Practicar el formato antes del día
La diferencia entre saber resolver un problema y resolverlo mientras alguien observa se nota en el primer intento. Por eso el simulacro completo de los días 9 y 10 no es opcional: reproduce la presión, obliga a hablar mientras se piensa y saca a la luz las muletillas y los baches.
Hay tres maneras de hacerlo. Con un colega que haga de evaluador, lo más realista pero difícil de coordinar. Grabándose con el teléfono mientras se resuelve un ejercicio en voz alta, útil para detectar silencios largos. O con un simulador de entrevista con IA que plantea preguntas técnicas del rol, repregunta sobre las respuestas y devuelve una evaluación al final. La guía sobre entrevista simulada con IA explica cómo aprovecharla. Dos rondas suelen alcanzar para que el razonamiento en voz alta deje de sentirse forzado.
Preguntas frecuentes
¿Cuánto dura una entrevista técnica?
Depende del formato. Un live coding o una entrevista de system design dura entre 45 y 90 minutos. Un take-home se entrega en dos a cinco días, con una carga sugerida de 4 a 8 horas de trabajo. Los casos de negocio suelen ocupar entre 30 y 45 minutos por caso.
¿Qué pasa si no se llega a terminar el ejercicio?
No es un descarte automático. Muchos ejercicios están diseñados para no terminarse en el tiempo asignado, precisamente para ver cómo el candidato prioriza y comunica. Una solución parcial, bien explicada y con los pendientes identificados, suele evaluarse mejor que una completa lograda en silencio.
¿Se puede usar internet o documentación durante la prueba?
En un take-home, sí, y se espera que se use. En un live coding depende de la empresa: algunas lo permiten explícitamente, otras no. Conviene preguntarlo antes de empezar; la pregunta en sí no resta puntos.
¿Cómo prepararse si el aviso no dice qué tipo de prueba hay?
Preguntar al reclutador. Es una consulta normal, se responde casi siempre y evita preparar el formato equivocado. Si no hay respuesta, lo más seguro es asumir un ejercicio en vivo de dificultad media sobre las tecnologías o competencias centrales del aviso.
¿Hay entrevista técnica fuera de programación?
Sí, con otros nombres: clase modelo en docencia, caso de negocio en consultoría y finanzas, prueba práctica en gastronomía, salud, oficios y laboratorio. La lógica de preparación es la misma: conocer el formato, practicar con tiempo real y explicar lo que se hace mientras se hace.