Prueba técnica tech: take-home vs live coding vs system design

Una Scale-up SaaS B2B en plena expansión necesitaba sumar tres ingenieros senior en un trimestre. El proceso técnico parecía riguroso: un take-home assignment que pedía construir una API completa con autenticación, tests, documentación y despliegue en contenedores. En el papel sonaba exhaustivo. En la práctica, tomaba entre seis y ocho horas a un candidato senior. El resultado fue silencioso pero brutal: el 70% de los finalistas más fuertes abandonaba el proceso al ver el alcance, y los que terminaban la prueba no siempre eran los mejores, sino los que tenían tiempo libre un fin de semana.

Al otro lado del espectro, un Retail A con un área de tecnología en crecimiento usaba live coding tipo acertijo: el candidato resolvía problemas de algoritmos de competencia, en pizarra compartida, observado por dos personas, contra reloj. La empresa contrataba a quien resolvía rápido el acertijo. Meses después descubría que varios de esos perfiles, brillantes invirtiendo árboles binarios, no lograban diseñar una solución de fondo ni comunicarse con el equipo. La prueba premiaba una habilidad que el rol casi no usaba y filtraba justo a las personas competentes que rendían mal bajo observación.

Los dos casos comparten un mismo error de raíz: eligieron un formato de prueba técnica antes de definir qué competencia querían medir. Uno tenía una take-home tan grande que medía disponibilidad; el otro tenía un live coding tan abstracto que medía tolerancia a la ansiedad. Este reporte ordena la decisión: qué evalúa de verdad cada formato, cuándo conviene cada uno, qué errores invalidan una prueba y cómo diseñar un work sample que prediga el desempeño sin ahuyentar a los mejores candidatos.

1. Qué evalúa de verdad una prueba técnica (y qué no)

Antes de comparar formatos, conviene fijar un principio que decide todo lo demás: una prueba técnica predice el desempeño en la medida en que se parece al trabajo real del rol. Es la lógica del work sample, el predictor de desempeño con más respaldo en la literatura de selección. Cuanto más cercana es la prueba a lo que la persona hará en el puesto, mejor predice; cuanto más abstracta, peor. Un acertijo de algoritmos de competencia mide preparación para entrevistas, no capacidad de construir el producto.

El error más común es confundir lo que la prueba parece medir con lo que realmente mide. Una take-home enorme parece medir rigor, pero termina midiendo disponibilidad de tiempo. Un live coding bajo presión parece medir capacidad técnica, pero a menudo mide tolerancia a la ansiedad de rendimiento. Una entrevista de conversación fluida parece medir seniority, pero mide capacidad de hablar de arquitectura, que no es lo mismo que decidirla. Toda prueba mide algo; el trabajo del diseñador del proceso es asegurarse de que mida la competencia correcta.

Por eso la primera pregunta nunca es "¿take-home, live coding o system design?", sino "¿qué competencia es crítica para este rol?". La ejecución limpia de código, las decisiones de arquitectura, la depuración bajo incertidumbre, la comunicación con el equipo y el ownership son competencias distintas, y cada formato mide unas mejor que otras. Definir la competencia primero es exactamente el rol del scorecard: sin él, la prueba mide cualquier cosa y la decisión se vuelve subjetiva. Cómo construir esa base está en el scorecard de contratación tech con evaluación estructurada, que ordena el resto del proceso.

2. Take-home assignment: cuándo funciona y cuándo ahuyenta a los seniors

El take-home assignment es una prueba que el candidato resuelve por su cuenta, de forma asíncrona, en su propio entorno y a su propio ritmo. Es el formato que mejor refleja cómo trabaja realmente un ingeniero la mayor parte del tiempo: sin nadie mirando por encima del hombro, con tiempo para pensar, con acceso a documentación. Bien hecho, entrega una señal rica sobre la calidad del código, la estructura de la solución y las decisiones que la persona toma cuando nadie la observa.

Funciona especialmente bien para roles donde el trabajo es mayormente asíncrono y la calidad del entregable pesa más que la velocidad bajo presión: backend, data engineering, roles de plataforma. También favorece a candidatos que rinden mal observados pero entregan trabajo sólido, un grupo grande y valioso que el live coding penaliza injustamente. Y permite evaluar dimensiones que un live coding corto no alcanza a tocar: cobertura de tests, manejo de errores, claridad de la documentación, decisiones de diseño con consecuencias.

El problema del take-home no es el formato, es el alcance. Cuando la prueba pide construir un sistema completo que toma seis u ocho horas, deja de medir capacidad y empieza a medir disponibilidad. Los candidatos senior, que tienen ofertas abiertas y poco tiempo, simplemente abandonan, y el proceso se queda con quien tuvo un fin de semana libre. Una take-home respetuosa se acota a una a tres horas de trabajo efectivo, indica el tiempo esperado con honestidad y permite que la persona explique en una conversación posterior lo que no alcanzó a implementar. Esa conversación sobre el resultado suele dar tanta señal como el código mismo, y respeta el tiempo del candidato.

3. Live coding y pair programming: qué mide y sus trampas

El live coding y el pair programming evalúan al candidato en tiempo real: la persona resuelve un problema mientras conversa con uno o dos evaluadores. Su valor es único porque permite observar lo que ningún entregable muestra: cómo piensa en voz alta, cómo descompone un problema, qué pregunta antes de empezar, cómo reacciona cuando se le cambia un requisito a mitad de camino y cómo comunica su razonamiento. Para roles donde la colaboración estrecha es central, el pair programming entrega señal directa sobre cómo será trabajar con esa persona.

La trampa aparece cuando el live coding se convierte en un acertijo de algoritmos de competencia bajo presión. Ahí el formato deja de medir capacidad técnica y empieza a medir dos cosas indeseables: la tolerancia a la ansiedad de rendimiento y la cantidad de horas que la persona dedicó a practicar ese tipo de problemas. Un ingeniero senior excelente puede llevar años sin invertir un árbol binario de memoria, porque no es lo que hace su trabajo. Penalizarlo por eso produce una señal ruidosa y una experiencia de candidato pobre que aleja precisamente a los perfiles más buscados.

El live coding bien diseñado evita el acertijo y usa un problema realista y acotado, parecido a algo que la persona haría en el puesto: extender una función existente, depurar un bug en un fragmento de código real, modelar una pequeña parte del dominio. Permite buscar documentación, prioriza el razonamiento sobre la velocidad y trata la sesión como una colaboración, no como un examen. Conducido así, mide comunicación, pensamiento estructurado y capacidad de reacción, sin castigar a quien se pone nervioso resolviendo problemas artificiales. Para líderes que no programan, evaluar este tipo de señal sin caer en la trampa de la fluidez verbal es justamente el foco de cómo evaluar candidatos tech siendo no técnico.

4. System design: el formato que separa senior de semi-senior

La system design interview es una conversación estructurada en la que el candidato diseña la arquitectura de un sistema a partir de requisitos deliberadamente abiertos. No hay una única respuesta correcta: se evalúa cómo la persona acota el problema, qué preguntas hace antes de diseñar, qué componentes propone, cómo justifica los trade-offs, cómo dimensiona, qué fallas anticipa y qué prioriza cuando los recursos son limitados. Es el formato más cercano al trabajo real de un ingeniero senior, porque su día a día son decisiones de diseño con consecuencias, no algoritmos de competencia.

Es, además, el formato que mejor separa a un senior real de un semi-senior con seniority inflado. La razón es estructural: un semi-senior puede haber escrito mucho código bajo decisiones que tomaron otros, pero rara vez ha enfrentado la ambigüedad de diseñar un sistema desde cero. En una system design interview esa diferencia aparece rápido. El senior real navega la ambigüedad, expone supuestos, prioriza y defiende decisiones; el seniority inflado pide especificaciones cerradas, repite patrones que vio sin entender por qué, y se queda sin recursos cuando se le presiona un trade-off.

El formato tiene un límite claro: no tiene sentido para roles junior, donde la persona todavía no ha enfrentado decisiones de arquitectura reales y el ejercicio mide teoría memorizada en lugar de criterio. Para roles senior, staff, tech lead y arquitectura, en cambio, la system design interview es difícilmente reemplazable. Conviene conducirla con una rúbrica explícita —porque sin ella es muy fácil premiar al candidato que simplemente habla con confianza— y como parte de un panel, no como juicio de un solo evaluador. Distribuir esa evaluación entre varios criterios y personas es la lógica del hiring committee con cinco evaluadores, que evita que una sola conversación con buena química defina la contratación.

5. Tabla comparativa de los tres formatos

Cada formato tiene un perfil distinto de fortalezas, costos y riesgos. La siguiente tabla resume qué mide mejor cada uno, su impacto en la experiencia del candidato y su valor predictivo, para que la elección deje de ser por costumbre y pase a ser por diseño.

Ningún formato gana en todo, y esa es la conclusión operativa: rara vez conviene usar uno solo. La combinación más sólida para la mayoría de los roles es un work sample corto y acotado para medir ejecución, seguido de una conversación sobre ese resultado y, para perfiles senior, una system design interview que evalúe el criterio de arquitectura. Cada pieza aporta una señal independiente, y juntas convierten la evaluación en una decisión defendible en lugar de una impresión.

6. Cómo elegir el formato según el rol y el nivel

La elección del formato no es cuestión de moda ni de copiar lo que hace otra empresa, sino de hacer coincidir el formato con la competencia crítica del rol y con el nivel del candidato. Una vez definida la competencia en el scorecard, la asignación se vuelve casi mecánica. Estos son los modelos de combinación más útiles según el tipo de rol.

Dos reglas atraviesan todos los casos. Primero, el formato debe escalar con el nivel: pedir system design a un junior mide teoría memorizada, y pedir solo un algoritmo a un senior desperdicia la oportunidad de evaluar lo que realmente lo distingue. Segundo, la experiencia del candidato pesa en la decisión: para roles senior muy demandados, un proceso pesado o irrespetuoso del tiempo hace que los mejores abandonen antes de la oferta, un costo invisible que casi nadie suma.

7. Errores que invalidan una prueba técnica

Una prueba técnica mal diseñada no es neutral: produce una señal falsa que se siente objetiva y que lleva a contratar mal con confianza. Estos son los errores que invalidan una evaluación, sin importar qué formato se elija.

El hilo común de los cinco errores es que rompen la comparabilidad. Una buena evaluación permite poner a dos candidatos lado a lado bajo el mismo criterio y decidir con fundamento. Una mala evaluación produce puntuaciones que no se pueden comparar porque cada una se generó con una vara distinta. Por eso la rúbrica calibrada antes de evaluar no es burocracia: es lo que convierte un conjunto de opiniones en una decisión defendible, y lo que más baja el riesgo de una contratación fallida.

8. Cómo diseñar un work sample que prediga desempeño

El work sample es el formato con mayor valor predictivo porque su principio es directo: hacer que la persona haga, en pequeño, lo que hará en el puesto. Diseñar uno bien no requiere construir un sistema completo; requiere aislar la tarea más representativa del rol y convertirla en un ejercicio acotado y evaluable. El proceso ordenado en pasos evita los errores más comunes y produce una señal limpia.

Un buen work sample respeta el tiempo del candidato tanto como evalúa su capacidad, porque la experiencia de la prueba es parte del resultado: un proceso respetuoso retiene a los perfiles más buscados, y uno abusivo los expulsa antes de la oferta. La señal que entrega, además, no termina en una nota: alimenta el panel y se compara contra el resto de la muestra, lo mismo que validan después las reference checks tech con preguntas estructuradas, que confirman con ex managers y pares si el nivel demostrado en la prueba se sostiene en el trabajo real.

9. Cómo una buena prueba técnica baja el riesgo de mis-hire

Todo lo anterior converge en un único objetivo de negocio: reducir el riesgo de una contratación fallida. Una prueba técnica bien diseñada es una de las palancas más potentes para eso, porque ataca el momento exacto en que se cuela el error: la confusión entre quien sabe hablar de tecnología y quien sabe ejecutarla. Cuando la prueba se parece al trabajo real, se evalúa con rúbrica y alimenta un panel calibrado, el seniority inflado deja de pasar desapercibido y la decisión se vuelve defendible. El costo de equivocarse es alto y se desarrolla en detalle en el costo real de una mala contratación tech, que cuantifica lo que está en juego.

Aquí es donde un headhunter tech especializado suma valor concreto. El primer mecanismo es el vetting técnico previo: filtra a los candidatos antes de que lleguen al panel, de modo que el equipo invierte tiempo solo en perfiles que ya pasaron una evaluación de fondo. El segundo es la disciplina del proceso: scorecard antes de entrevistar, work sample calibrado contra el mercado real del rol y panel con evaluadores alineados, que es lo que convierte una corazonada en una decisión defendible. El tercero, y el que más alinea incentivos, es la garantía de 90 días de reemplazo: si la persona no funciona dentro de ese periodo, el headhunter busca un reemplazo sin costo adicional. La garantía de 90 días traslada parte del riesgo restante desde la empresa hacia el especialista, que entonces no cobra por colocar a alguien, sino por colocar a alguien que se queda y rinde. Para los roles donde el rango de mercado entra en la decisión, la guía salarial tech 2026 entrega los rangos de referencia, y el formulario de contacto abre la conversación para revisar un proceso de evaluación concreto.

10. FAQ: preguntas que recibimos sobre pruebas técnicas para candidatos tech