Felix Rieseberg, responsable de ingeniería en Anthropic, ha dejado de hacer pruebas de programación en las entrevistas de su equipo. Lo cuenta en un post publicado el 27 de octubre en su blog, con un argumento muy simple: Claude ya resuelve esas pruebas mejor que los candidatos, así que no sirven para distinguir a nadie.
Rieseberg no es un empleado cualquiera. Ha dirigido la ingeniería de Claude.ai, de Cowork y de la app de escritorio de Claude Code, y antes trabajó en Notion, Stripe, Slack y Microsoft. Cuando alguien así entierra la entrevista técnica, conviene escucharle.
Puntos clave
- La decisión: este mes de octubre, Rieseberg dejó de pedir pruebas de código a los candidatos de su equipo en Anthropic.
- El motivo: poner un pequeño reto de React tiene tan poco sentido como preguntar por ensamblador, porque Claude es mejor en las dos cosas.
- Su tesis: ha visto a ingenieros con poca experiencia adelantar a gente que probablemente programa mejor y lleva más años. Lo resume en una frase, el hambre gana a la antigüedad.
- El ejemplo: la app de escritorio de Claude Code nació de un prototipo que dos ingenieros recién llegados montaron en un fin de semana. La primera versión pública salió unos ocho días después.
Por qué la prueba de código ha dejado de medir
Rieseberg reconoce que la prueba técnica funcionaba, aunque poco. Saber definir un problema rápido y dar con una solución elegante predecía, de forma débil pero útil, quién iba a rendir en sus equipos. Eso se ha roto. Sus mejores constructores triunfan sean como sean de buenos en esos ejercicios.
La lógica es la de cualquier examen. Si una herramienta que todo el mundo tiene a mano resuelve la prueba, la prueba solo mide si el candidato la ha usado o no. Y en un trabajo donde vas a usar Claude ocho horas al día, penalizar a quien lo usa no tiene mucho sentido.
Lo que no dice es con qué la ha sustituido. Admite que todavía no ha dado con la forma de entrevistar a gente que construye bien con IA. De momento mira currículums y portfolios buscando pequeños prototipos que demuestren gusto, empatía con el usuario y criterio. Y pide a quien haya encontrado algo mejor que se lo cuente.
La contraria al pesimismo sobre los juniors
Lo llamativo del post es el tono. Llevamos meses de datos malos para los perfiles junior. Un estudio de Stanford midió que el empleo de 22 a 25 años cae un 19% en las ocupaciones más expuestas a la IA, y el propio informe de Anthropic sobre empleo contaba que la empresa contrata menos juniors y sus agentes ya trabajan 6 a 1. The Rundown recordaba hoy que el cofundador de Anthropic Jack Clark llegó a decir que la IA hace "algo más dudoso" el valor de los juniors.
Rieseberg dice lo contrario desde dentro de la misma casa. Su argumento es que antes un recién llegado tenía buenas ideas y ninguna voz. Para que la empresa apostara por tu propuesta había que ganarse estatus durante años, porque ejecutar era caro y alguien tenía que dar luz verde. Ahora ejecutar es barato, y un prototipo que funciona convence más que cualquier documento de requisitos.
Aclara además que "junior" es la palabra equivocada. Su consejo es para cualquier ingeniero sin capital social, sin estatus y sin poder dentro de la organización.
Los cinco consejos
El post termina con una lista práctica. La resumo:
1. Impacto de negocio antes que tareas del backlog. Entiende qué quiere conseguir tu empresa, o tu departamento si es grande. Una buena pista es saber qué objetivos tiene el jefe de tu jefe. 2. Elige una idea radical. Algo que, si sale bien, cambie mucho las probabilidades de que la organización llegue a esos objetivos. 3. Constrúyela en un fin de semana. Ha visto a grupos pequeños e ingenieros solos saltarse el proceso de requisitos, aprobaciones y reuniones con diseño a base de llegar con algo que funciona. 4. Una sola idea por prototipo. El error típico es meter tres ideas buenas entre veinte malas. El prototipo sirve para que la dirección entienda la oportunidad y vea que tú puedes llevarla. 5. Usa tu mirada de recién llegado. Ves fricciones que los veteranos ya no ven, y no conoces los motivos por los que algo se considera imposible.
Para el punto 5 cuenta una anécdota propia. En su entrevista en Notion le pidieron diseñar un modo sin conexión, una pregunta trampa porque todo el mundo daba por hecho que el fundador nunca lo permitiría. Nadie lo había comprobado. Él preguntó, y la resistencia del fundador resultó no ser tal.
Lo que este post no dice
Conviene leerlo con un poco de distancia. Es la opinión de un manager, no una política de Anthropic, y está escrita para ingenieros. Tampoco resuelve el problema de fondo: si la prueba técnica ya no filtra y el sustituto todavía no existe, los procesos de selección van a pasar una temporada a ciegas.
Y hay un sesgo evidente. Anthropic vende la herramienta que hace innecesaria la prueba. Que uno de sus responsables diga que la herramienta es mejor que los candidatos es coherente con su negocio. No por eso es falso.
Por qué importa
Si contratas perfiles técnicos en España, la pregunta es incómoda: ¿qué estás midiendo con tu prueba de código? Si el candidato puede resolverla con Claude o ChatGPT en diez minutos, estás midiendo si ha decidido no usarlos durante la entrevista.
Una alternativa que puedes probar en el próximo proceso es darle al candidato un problema real de tu negocio, dejarle usar la IA que quiera y pedirle un prototipo en un tiempo acotado. Luego, en la conversación, pregúntale por qué eligió ese enfoque y qué descartó. Ahí se ve el criterio, que es justo lo que la máquina todavía no pone.
Y no aplica solo a programadores. La idea de que el prototipo sustituye al documento de requisitos vale para marketing, operaciones o finanzas. Si alguien de tu equipo llega con una herramienta funcionando en vez de con una propuesta, ese es el perfil que Rieseberg está buscando.
Fuente original: felixrieseberg.com
Relacionado
