Has cerrado una contratación senior. El CV era sólido, la entrevista técnica fue fluida, el take-home parecía correcto y las referencias no levantaron banderas. Dos meses después, esa persona sigue bloqueando decisiones, no prioriza bien, se atasca cuando hay ambigüedad y genera más carga al equipo de la que resuelve.
Eso pasa porque muchas startups siguen evaluando talento tech como si el trabajo real fuese una suma de respuestas correctas. No lo es. Un senior backend no vive de resolver preguntas sueltas. Un ML engineer no aporta por saber una librería concreta. Un DevOps no demuestra criterio en una conversación amable, sino cuando hay presión, información incompleta y trade-offs de negocio.
Ahí entra el assessment center. No como ritual de RR. HH. ni como teatro corporativo, sino como una forma de observar conducta en situaciones que se parecen al puesto. Si contratas perfiles de alto impacto, necesitas ver cómo piensan, cómo deciden y cómo colaboran cuando el contexto se vuelve incómodo.
Por qué las entrevistas ya no son suficientes para el talento tech
Las entrevistas fallan donde más duele: en lo que no se puede fingir durante una hora. Un candidato puede explicar bien cómo escalar una arquitectura y luego hundirse al tener que defender prioridades frente a producto, alinear a dos seniors en desacuerdo o comunicar un incidente sin dramatizar ni esconder riesgos.
En startups españolas esto se nota más. Los equipos son pequeños, los roles se solapan y casi nadie trabaja con una definición de puesto perfectamente estable. Contratas a una persona para backend y en tres semanas está opinando sobre observabilidad, deuda técnica, roadmap y contratación. Si solo validas conocimiento técnico aislado, estás dejando fuera la mitad del trabajo.
El assessment center sirve justo para eso. Pone al candidato en una simulación razonable y te obliga a observar comportamiento, no relato. Si aún estás afinando tus procesos de selección técnicos, este método encaja mejor en roles donde el error de contratación cuesta meses de velocidad.
No es una moda de LinkedIn
Los assessment centers no nacieron en RR. HH. moderno. Tienen un origen operativo. Según la historia de los assessment centers, Alemania los utilizó en 1916 para seleccionar oficiales, la OSS de Estados Unidos los adoptó en la década de 1940 para reclutar espías, y su adopción empresarial en España llegó en los años 80 con empresas como Carrefour. Ese mismo repaso señala que el 34% de las empresas en mercados con fuerte influencia en España los utilizaban en 2020 para contratar managers y profesionales.
Eso importa por una razón simple. No estás introduciendo una rareza. Estás usando un método con recorrido, refinado para observar competencias complejas cuando una entrevista convencional se queda corta.
Si el puesto exige decidir bajo presión, colaborar con fricción y moverse en ambigüedad, evaluarlo solo con entrevistas es una concesión peligrosa.
Lo que una buena entrevista no te enseña
Hay señales que aparecen solo cuando el candidato tiene que actuar:
- Priorización real. No lo que dice que haría, sino qué decide primero cuando todo parece urgente.
- Comunicación técnica con negocio. Si sabe traducir riesgo técnico en impacto entendible.
- Colaboración con desacuerdo. Si escucha, empuja, negocia o se atrinchera.
- Criterio bajo presión. Si improvisa sin estructura o mantiene claridad cuando faltan datos.
Por eso el assessment center no sustituye todo lo demás. Corrige una carencia muy concreta: la distancia entre “responde bien” y “rinde bien”.
Objetivos realistas para tu assessment center
El error más común es pedirle al assessment center algo que no está diseñado para dar. Mucha gente lo vende como si fuese una radiografía profunda del candidato. No lo es. Sirve mucho para decidir si contratar. Sirve bastante menos para explicar con precisión quirúrgica qué competencia concreta falla y por qué.
La paradoja que conviene entender pronto
La guía de assessment centers de OPM recoge una idea clave: los assessment centers tienen una validez predictiva de 0.4-0.6 para éxito laboral, por encima de las entrevistas no estructuradas, que rondan 0.3. Pero esa capacidad predictiva no viene de medir con fiabilidad competencias individuales estables, sino del rendimiento general que la persona muestra en los ejercicios.
Traducido para un CTO: el método es bueno para responder “¿deberíamos contratar a esta persona para este contexto?” y bastante flojo para responder “¿qué nivel exacto tiene en liderazgo técnico, influencia, arquitectura y coaching por separado?”.
Ese matiz cambia el uso correcto del assessment center.
Regla práctica: si quieres decidir entre contratar o no contratar a un perfil senior de alto impacto, úsalo. Si quieres generar un informe de desarrollo fino, estás forzando la herramienta.
Qué sí deberías pedirle
Un assessment center bien diseñado debería ayudarte a tomar decisiones como estas:
- Contratación crítica. Tu primer Staff Engineer, tu Lead de Plataforma, tu ML Engineer más senior.
- Promoción interna. Alguien técnicamente fuerte que quizá va a liderar equipo y aún no sabes si tendrá tracción.
- Comparación entre finalistas. Dos candidatos sólidos en papel, pero con dudas sobre encaje operativo.
Lo que buscas no es “mapear el talento”. Buscas reducir riesgo en una decisión cara.
Qué no deberías esperar
Hay tres expectativas que suelen romper el proceso:
- Esperar feedback detallado por competencia
Si sales del assessment center creyendo que ya sabes el nivel exacto de una persona en arquitectura, backend, DevOps y liderazgo por separado, probablemente estás leyendo demasiado en observaciones limitadas. - Usarlo para cualquier vacante
Para perfiles junior o contratación de volumen, el coste operativo rara vez compensa. Ahí funcionan mejor procesos más ligeros y muy estructurados. - Pensar que reemplaza la entrevista
No la reemplaza. La mejora. El assessment center gana valor cuando llega después de un filtrado serio y una entrevista estructurada previa.
La pregunta correcta
La mayoría de procesos se vuelven ineficientes porque intentan aprender demasiado sobre el candidato. Eso suena riguroso, pero suele ser ruido. En un puesto senior, la pregunta útil es más estrecha:
¿Esta persona puede resolver problemas reales en nuestro contexto, con nuestro nivel de caos y con nuestro equipo actual?
Si el assessment center no está construido para responder eso, sobra complejidad.
Diseño de ejercicios técnicos que simulan la realidad
Diseñar un assessment center para perfiles tech no consiste en coger dinámicas genéricas y cambiarles el título. Un role-play de ventas reciclado no te va a decir nada útil sobre un senior platform engineer. La calidad del proceso depende del realismo del ejercicio.
La referencia útil aquí no es “hacer una prueba técnica más completa”. Es construir situaciones en las que el candidato tenga que priorizar, decidir, comunicar y justificar. Si además ya trabajas con una entrevista estructurada para perfiles técnicos, el assessment center debe complementar lo que esa entrevista no ve.
Empieza por el problema del puesto
No diseñes ejercicios desde competencias abstractas. Diseña desde problemas reales del rol.
Si buscas un Senior Backend, piensa en qué fricciones tendrá en los primeros meses. Quizá una API heredada, dependencias entre squads, decisiones de escalado con producto empujando fechas. Si buscas un ML Engineer, probablemente te importe menos que memorice teoría y más cómo maneja datos imperfectos, expectativas de negocio y limitaciones de despliegue.
Un buen ejercicio tiene tres rasgos:
- Contexto reconocible. El candidato entiende que eso podría pasar en tu empresa.
- Información incompleta. Igual que en el trabajo.
- Trade-offs visibles. No hay una respuesta impecable, hay decisiones defendibles.
Tres ejercicios que sí aportan señal
Para DevOps o Platform Engineer
Plantea un incidente en producción. No hace falta teatralidad. Basta con una secuencia de síntomas, métricas parciales y mensajes de Slack simulados de producto o soporte.
Ejemplo de enunciado:
- Escenario. El tiempo de respuesta sube de forma repentina en un servicio crítico. Hay errores intermitentes, el equipo de negocio presiona por impacto en clientes y un deploy reciente genera sospechas.
- Tarea. En tiempo limitado, el candidato debe proponer hipótesis, pedir datos, priorizar acciones y comunicar un plan de contención.
- Qué observas. Orden mental, criterio de escalado, comunicación bajo presión, foco en mitigación antes que lucimiento técnico.
Muchos candidatos fuertes técnicamente suspenden aquí por una razón simple: se obsesionan con encontrar la causa raíz antes de estabilizar el sistema.
Para ML Engineer o Applied Scientist
Dale un dataset desordenado, una métrica de negocio ambigua y restricciones reales. No conviertas el ejercicio en un concurso de notebooks.
Ejemplo:
- Recibe un conjunto de datos con ruido, variables inconsistentes y una petición del negocio poco madura.
- Tiene que explicar qué validaría primero, qué riesgos ve, qué simplificaciones haría y cómo defendería un enfoque inicial.
- Si quieres elevar el nivel, añade una objeción de producto tipo “necesitamos algo usable pronto” y otra de ingeniería tipo “no podemos mantener un pipeline frágil”.
Aquí no miras solo si sabe modelar. Miras si tiene juicio. Muchos perfiles de ML brillan en técnica aislada y flojean al aterrizar soluciones viables.
El mejor ejercicio técnico no es el más difícil. Es el que reproduce las tensiones reales del puesto.
Para Senior Backend o Staff Engineer
Una dinámica de diseño de sistemas funciona muy bien si la aterrizas. No pidas “diseña Twitter”. Eso genera respuestas de manual. Pide algo que huela a empresa real.
Ejemplo:
- Tu startup necesita rediseñar un servicio de ingestión porque el crecimiento del producto ha creado cuellos de botella.
- El candidato tiene que proponer una arquitectura inicial, identificar riesgos y defender prioridades frente a restricciones de tiempo y equipo.
- Si lo haces en formato grupal con otro candidato o con evaluadores actuando como stakeholders, aparecerán señales muy valiosas: cómo escucha, cómo cede, cuándo confronta y cómo explica complejidad.
Lo que conviene dejar fuera
Hay ejercicios que suenan sofisticados y luego no predicen casi nada útil en una startup:
- Puzzles algorítmicos desconectados del rol
- Presentaciones largas preparadas en casa
- Dinámicas de grupo genéricas sin conflicto técnico real
- Pruebas tan extensas que premian resistencia, no criterio
Este vídeo ofrece una referencia general para entender cómo se estructuran ejercicios observacionales y puede servir como punto de partida antes de adaptarlos al entorno técnico:
Un criterio sencillo para validar tu diseño
Antes de lanzar el proceso, hazte estas preguntas:
- ¿Este ejercicio se parece a una situación que el rol vivirá de verdad?
- ¿Obliga al candidato a decidir, no solo a opinar?
- ¿Permite observar conducta además de conocimiento?
- ¿Dos evaluadores podrían justificar por qué una actuación fue fuerte o débil?
Si la respuesta es no, no tienes un assessment center. Tienes una prueba con branding nuevo.
Ejecución remota, scoring y calendario
La mayoría de startups ya no contratan como si todo fuese presencial. Y eso cambia la ejecución. Según la referencia sobre assessment remoto y evaluación técnica, el 68% de las scaleups tecnológicas en España reportan dificultades para evaluar competencias técnicas en remoto, implementar herramientas específicas puede reducir el time-to-hire hasta en 35% , y el ecosistema vio un aumento del 42% en contrataciones remotas en 2025. Si tu proceso remoto es flojo, no estás compitiendo peor solo por imagen. Estás perdiendo velocidad y señal.
La buena noticia es que un assessment center remoto puede funcionar muy bien si controlas tres cosas: agenda corta, evaluadores calibrados y herramientas estables. Si no, se convierte en una maratón de videollamadas que castiga más la fatiga que el rendimiento.
Un formato remoto que suele funcionar
Para perfiles senior, media jornada suele ser suficiente. Más tiempo no siempre añade señal. A menudo añade ruido.
Un esquema práctico:
- Briefing inicial
Explicas contexto, reglas y tiempos. Corto y claro. Nada de confundir al candidato con instrucciones ambiguas para “ver cómo reacciona”. - Ejercicio individual
Diseño de sistema, análisis de incidente o caso técnico con documentación. - Descanso breve
Parece menor, pero evita que la fatiga contamine el desempeño final. - Ejercicio colaborativo
Pair programming, role-play con stakeholders o resolución compartida en FigJam o Miro. - Entrevista de debrief
Pides al candidato que explique decisiones, descarte alternativas y reconozca riesgos.
Si ya trabajas entrevistas por competencias, conviene alinear las observaciones del assessment con una guía de entrevistas por competencias para que el lenguaje de evaluación sea consistente.
Herramientas concretas que sí encajan
No hace falta inventar infraestructura. Hace falta elegir bien.
- Miro o FigJam para arquitectura, flujos y colaboración visual.
- CoderPad o HackerRank for Work para pair programming o ejercicios con código compartido.
- Slack o Discord para simular canales de comunicación, incidentes y mensajes cruzados.
- LeetCode Enterprise puede servir si ya lo usas, pero en assessment center conviene orientarlo a escenarios, no a retos abstractos.
La herramienta correcta es la que desaparece del proceso. Si el candidato pelea más con la plataforma que con el problema, la señal se degrada.
Un assessment center remoto falla antes por mala operación que por mal concepto.
Cómo puntuar sin montar un circo de evaluación
El scoring debe ser simple. Si metes diez competencias, nadie evalúa bien. Si usas etiquetas vagas, cada evaluador interpreta algo distinto.
Qué funciona mejor:
- Elige entre 3 y 5 competencias
Ejemplos útiles: priorización, comunicación, juicio técnico, colaboración, ownership. - Usa una escala corta
Una escala de 1 a 5 suele bastar si cada nivel tiene descriptores conductuales claros. - Pide evidencia, no impresiones
“Interrumpió, no escuchó restricciones y no reformuló el problema” vale. “No me transmitió seniority” no vale. - Haz calibración posterior
Los evaluadores comparan notas después del ejercicio, no durante.
Un ejemplo de rúbrica sencilla
Puedes usar algo así:
- Priorización
Distingue entre mitigación inmediata y solución completa. - Comunicación
Explica riesgos y decisiones con claridad para perfiles no técnicos. - Criterio técnico
Propone opciones razonables y reconoce trade-offs. - Colaboración
Escucha, integra señales y mejora la solución con otros.
No necesitas una rúbrica más compleja para tomar una decisión sólida. Necesitas que todos evalúen lo mismo.
Costes, legalidad y diversidad en el mercado español
El assessment center cuesta. Sobre todo tiempo de gente cara. Si involucras a un Staff Engineer, a un Engineering Manager y a alguien de talento, estás consumiendo foco operativo. Por eso no tiene sentido usarlo en cada vacante. Tiene sentido en contrataciones donde un error te sale mucho más caro que unas horas bien invertidas.
El problema no es solo económico. También es legal y reputacional. En España, un proceso opaco, improvisado o mal documentado no solo genera malas contrataciones. También multiplica sesgos y deja una trazabilidad pobre si alguien cuestiona cómo se tomó la decisión.
El coste real no está en la licencia
Muchos equipos se obsesionan con el coste de herramientas y se olvidan del coste dominante: el tiempo interno. Diseñar un buen caso, probarlo, alinear a evaluadores y revisar resultados exige disciplina. Si tu equipo no tiene ese músculo, el formato DIY puede salir “barato” y rendir peor que una entrevista estructurada bien hecha.
Dónde sí suele merecer la pena:
- Roles con impacto sistémico. Arquitectura, plataforma, ML aplicado al core del producto.
- Vacantes difíciles de comparar. Candidatos fuertes en CV pero inciertos en ejecución.
- Promociones delicadas. Subir a alguien a liderazgo sin evidencia conductual cuesta caro.
Dónde suele sobrar:
- Junior con onboarding fuerte
- Hiring de volumen
- Roles muy acotados y de baja ambigüedad
Diversidad y validez no son dos temas separados
La referencia sobre sesgos y evaluaciones validadas indica que en España el 29% de los procesos de selección en scaleups fallan en diversidad por evaluaciones no validadas. También recoge que combinar medidas como pruebas ciegas y pair programming ha aumentado las contrataciones diversas en 22% , aunque solo el 15% de las startups españolas usa herramientas validadas para este fin.
Ese dato debería incomodar a cualquier CTO. Si tu proceso “premia el talento” pero no está validado, es muy posible que esté premiando familiaridad, estilo de comunicación dominante o parecido cultural con el equipo actual.
Un assessment center bien hecho no elimina el sesgo por arte de magia. Lo reduce porque obliga a observar conductas en criterios comunes.
Qué haría para reducir riesgo legal y sesgo
No hace falta un comité enorme. Hace falta estructura.
- Define criterios antes de ver candidatos
Las competencias y ejemplos de conducta deben cerrarse antes del assessment. - Usa varias medidas
Ciego en la fase inicial, ejercicio técnico contextualizado y observación colaborativa funcionan mejor juntos que por separado. - Documenta evidencias
Cada decisión debe poder explicarse con hechos observables. - Forma a los evaluadores
No para convertirlos en psicólogos, sino para que no confundan afinidad con capacidad. - Revisa el lenguaje del caso
Si favorece experiencias muy específicas o referencias culturales innecesarias, estás sesgando sin darte cuenta.
En otros sectores regulados ya se ve el mismo patrón: cuando la decisión tiene impacto y complejidad, la metodología importa tanto como el contenido. Un buen ejemplo de análisis serio sobre decisiones sistémicas y criterios de evaluación es este estudio de Evenergia sobre movilidad sostenible. No trata recruiting, pero sí muestra algo útil: cuando el contexto es complejo, improvisar el marco de decisión sale caro.
Conclusión: ¿Merece la pena el esfuerzo para tu startup?
Sí, pero no siempre.
Merece la pena cuando contratas un perfil de alto impacto y el coste de equivocarte es muy superior al coste de montar un proceso más exigente. Tu primer Lead Engineer, un Senior DevOps que tocará fiabilidad, un ML Engineer que condicionará producto y datos. Ahí el assessment center tiene sentido porque te deja ver comportamiento en contexto, no solo discurso.
No merece la pena cuando estás cubriendo puestos junior, contratando volumen o resolviendo vacantes donde una entrevista estructurada, una prueba técnica bien acotada y referencias ya te dan señal suficiente. Forzar un assessment center en esos casos no es rigor. Es fricción.
La idea clave es esta: el assessment center no sirve para saberlo todo. Sirve para tomar mejor una decisión concreta. Si lo diseñas con ejercicios realistas, evaluadores alineados y criterios claros, reduce riesgo. Si lo conviertes en un proceso largo, ambiguo y sobrecargado, solo añade coste.
Usa esta regla simple:
- Sí si el rol es senior, ambiguo y de impacto alto
- No si el rol es acotado, junior o urgente por volumen
- Tal vez si estás promocionando internamente y necesitas evidencia conductual adicional
No uses un assessment center para saberlo todo de un candidato. Úsalo para saber lo único que importa: si debes contratarlo o no.
Si necesitas diseñar un proceso de selección técnico que filtre mejor, mida comportamiento real y no le robe semanas a tu equipo, Kulturo ayuda a startups y scaleups en España a contratar perfiles de software, datos, IA, DevOps y ciberseguridad con criterios más sólidos y procesos más eficientes.