37signals rechazó la contratación de programadores basada en acertijos y probó a los candidatos en el puesto

En febrero de 2013, 37signals publicó «Why we don't hire programmers based on puzzles and tricks» en el blog de su empresa, y la publicación llegó a Hacker News ese mismo día. El debate se abrió con los fracasos de la contratación basada en trivia: a un entrevistado de Microsoft que se había preparado con How Would You Move Mount Fuji? le pidieron escribir strcmp() de C de memoria; las entrevistas de Amazon se apoyaban en recitar la notación Big-O y en «contar todas las estrellas del universo», y los entrevistadores a menudo solo buscaban «preguntas de entrevista de programación» sin preguntarse qué demostraban las respuestas.

La contrapropuesta de 37signals fue rechazar el género de plano: no contratar basándose en acertijos y trucos. Los comentaristas describieron la alternativa como «probarlos en el puesto» —poner a los candidatos frente a trabajo real en lugar de rompecabezas sintéticos—. Los profesionales impulsaron la misma dirección con mecanismos concretos: ITA Software consideraba las pruebas presenciales mucho menos útiles que leer código que alguien había escrito fuera de línea, y un responsable de contratación estructuró las entrevistas en torno a un día de programación en pareja que planteaba tres preguntas: ¿pueden hacer el trabajo?, ¿encajan en el equipo? y ¿pueden adaptarse cuando cambian las reglas del juego?

Las dos pruebas miden cosas distintas. La trivia y los rompecabezas admiten preparación —existe toda una tradición de preguntas esperadas y libros de preparación— y seleccionan por memoria y aplomo bajo presión artificial. Los comentaristas señalaron que los pensadores de estilo perspicaz pueden fracasar en una hora de preguntas procedimentales y, sin embargo, rendir bien en una tarea real más larga, y que un candidato en medio de un ataque de pánico podría fallar FizzBuzz y seguir siendo un buen programador. El trabajo observado responde a la pregunta que la trivia no puede: cómo lee la persona una base de código desconocida, detecta errores, escribe código y trabaja con desconocidos.

Eliminar el calvario de los acertijos: probar a los candidatos en el puesto y dejar que el trabajo real, no la memoria, decida las contrataciones

Las pruebas de acertijos admiten preparación: una tradición de preguntas esperadas y libros de preparación permite a los candidatos ensayar, de modo que la prueba mide preparación y memoria, no capacidad para el puesto.

Probar a los candidatos en el puesto observa el trabajo real —leer una base de código real, detectar errores, escribir código y colaborar—, evidencia que ningún rompecabezas puede producir.

La presión artificial distorsiona los resultados: los candidatos de estilo perspicaz y los ansiosos pueden fracasar en acertijos de una hora y, sin embargo, rendir bien en trabajo real durante un periodo más largo.

La postura pública señala lo que la empresa valora y abrió un debate de 442 comentarios que puso a prueba la idea en público.

Cuando una prueba de contratación mide la preparación más de lo que lo hace el puesto, cambia la evidencia: prueba a los candidatos con trabajo real y deja que el desempeño decida

El ensayo obtuvo 648 puntos y 442 comentarios en Hacker News, lo que convirtió a 37signals en el punto de referencia del bando antiacertijos. Los defensores decían que los rompecabezas difíciles revelan la resolución de problemas bajo presión; los opositores contraponían un día de programación en pareja, FizzBuzz como filtro negativo barato y la práctica de ITA de leer código escrito fuera de línea. El enfoque de prueba se consideró bueno pero poco práctico para empleadores menos conocidos que aún necesitan acertijos como imán de talento. En el debate no aparece ningún resultado medido de contratación; el efecto fue normativo: «probarlos en el puesto» se convirtió en la principal alternativa a las entrevistas de trivia.