La entrevista técnica en la era de la IA

• En un contexto donde las herramientas de IA están penetrando rápidamente incluso en la escritura y revisión de código, en las entrevistas se debe excluir por defecto el uso de IA y evaluar principalmente capacidades fundamentales
• Una buena entrevista se evalúa en dos ejes: calidad de señal (signal quality) y costo para la empresa (cost to company), y ambos factores no son completamente independientes
• Los tipos de entrevista se dividen en cuatro: Take-home, Live exercise, Presentation, Actual work, y cada uno tiene distinta calidad de señal y costo
• Con la programación con IA, los take-home se vuelven demasiado fáciles y aumenta la carga de revisión, y cuando las preguntas se filtran la IA también actúa como un coach muy potente
• La habilidad con IA no es más que una instrumental skill (habilidad instrumental), por lo que las empresas deben concentrarse en evaluar foundational skill (capacidades fundamentales)

---

Argumento central

• Ante la rápida evolución de los modelos y herramientas de IA, surge la duda de si los ingenieros seguirán escribiendo y revisando código dentro de 6 meses, y si una habilidad central desaparece, ¿también debería evolucionar la forma de entrevistar?
• La mayoría de las empresas optó por mantener el statu quo, incluidas algunas que lideran esta revolución
  • La guía de contratación de Anthropic exige que los take-home se completen "sin Claude, salvo indicación contraria"
• Algunas empresas permiten, recomiendan o incluso exigen el uso de IA, y la destreza con IA en sí misma llega a convertirse en tema de entrevista
• La conclusión es que se debe excluir en general la IA de las entrevistas, y se presentan formas concretas de adaptar las entrevistas a la era de la IA

Dos dimensiones de una buena entrevista

• Calidad de señal (Signal quality)

  • La capacidad de identificar candidatos fuertes para un conjunto dado de competencias e ignorar el ruido (elementos no centrales para el rol o fáciles de enseñar)
  • Resistencia a la preparación (Invulnerability to preparation): si el desempeño depende de cuánto se preparó o esforzó alguien, entonces solo se obtiene señal sobre esa característica
  • Realismo (Realism): la entrevista debe parecerse al trabajo cotidiano, aunque eso no sea un fin en sí mismo. Las entrevistas de "algorithm & data structure" han sobrevivido mucho tiempo aunque no se usen de forma directa en el trabajo real
  • Igualdad (Equality): algunos candidatos parten con ventaja por experiencia previa en el dominio, mentoría pagada, más tiempo libre, preguntas filtradas en línea o contactos que pasaron recientemente por el proceso. Idealmente, el entorno debe ser justo para todos
  • Dificultad (Difficulty): una buena entrevista debe ser lo bastante difícil como para que muchas personas fallen. Lo ideal son problemas amplios y ambiguos que requieran varias ideas

• Costo para la empresa (Cost to company)

  • Las preguntas de entrevista requieren una inversión considerable de tiempo: diseñar borradores y aprobarlos mediante pruebas, redactar scorecards por rol y nivel, probar con candidatos internos y externos, documentar y capacitar a entrevistadores
  • Las preguntas y scorecards se calibran continuamente, por lo que la inversión debe sostenerse
  • Dificultad (Difficulty): crear preguntas ya es difícil, pero crear preguntas suficientemente difíciles lo es aún más. Tanto las demasiado fáciles como las demasiado difíciles desperdician el tiempo de todos
  • Atractivo para el candidato (Appeal to candidate): procesos que consumen demasiado tiempo o preguntas aburridas hacen que buenos ingenieros se alejen y reducen la conversión. Las preguntas también revelan la cultura de ingeniería
• Ambas dimensiones no son completamente independientes; por ejemplo, la dificultad afecta a ambas. Una entrevista difícil puede hacer destacar a candidatos fuertes, pero también causar false negatives (rechazos erróneos)
• Una entrevista no necesita ser perfecta, y siempre existirán false negatives y false positives. Los false negatives son difíciles de identificar, pero con un buen onboarding y metas claras para el primer semestre, los false positives pueden resolverse rápidamente

Clasificación de tipos de entrevista

• Take-home

  • El candidato entrega (1) una solución a un problema ambiguo (por ejemplo, una especificación de producto) respetando (2) algunas restricciones técnicas (por ejemplo, una lista de lenguajes de programación)
  • A menudo esto continúa con una entrevista de review donde el candidato presenta el trabajo y hace cambios en el momento
  • Calidad de señal: (antes de la IA) alta — ofrece señal amplia sobre diseño, programación, detalle, pruebas, etc., y dedicar 6 horas o más también demuestra motivación
  • Costo para la empresa: medio — la evaluación puede automatizarse y el entregable (código) puede revisarse de forma asíncrona, aunque puede espantar candidatos
  • Es muy vulnerable tanto a la IA como a personas altamente motivadas

• Live exercise

  • Incluye algorithm & datastructure, live coding, system design, postmortem review, etc., normalmente de 1 hora o más. Problemas como "diseñar la arquitectura de Netflix" o "escribir un rate-limiter" se resuelven en vivo frente al entrevistador
  • Calidad de señal: media — si está bien diseñada y conducida puede ser objetiva, pero la señal suele concentrarse en un solo tema
  • Costo para la empresa: medio — para ser menos vulnerable a la preparación del candidato se necesita una gran variedad de preguntas
  • Para reducir costos, algunas empresas usan servicios automatizados

• Presentation

  • El candidato elige tanto el problema como la respuesta con formatos como "explica un proyecto que lideraste", "diagrama de arquitectura" o "cuéntame sobre una experiencia"
  • Calidad de señal: baja — hay muchos modos de falla
    • Nunca trabajó en un problema interesante (por ejemplo, alguien junior), elige un problema aburrido, exagera su impacto o contribución, se prepara poco para presentar, comunica bien pero no ejecuta, o el entrevistador no tiene suficiente conocimiento del dominio y evalúa de forma incorrecta
  • Costo para la empresa: bajo — desde el punto de vista de calibración no hay mucho que preparar
  • La baja calidad de señal puede mitigarse con preguntas retrospectivas como "¿qué harías distinto?" o hipotéticas como "¿qué pasaría si cambiamos el requisito X?". En ese caso se parece más a un live exercise no calibrado y exige más esfuerzo y especialización del entrevistador

• Actual work (no es un tipo de entrevista)

  • Es un formato de trabajar juntos durante una semana con pago. Lo usan empresas como Linear
  • Calidad de señal: alta / Costo para la empresa: alto
• La mayoría de las empresas mezcla estos tipos, y Live exercise domina

La filtración de preguntas es cuestión de tiempo (independientemente de la IA)

• La filtración de preguntas es cuestión de tiempo, y sitios como Glassdoor terminan listando todos los secretos de entrevista. Algunos candidatos incluso pasan por entrevistas para vender las preguntas
• Si se ignora, la señal se debilita y el principal determinante del desempeño se convierte en "¿investigó nuestro proceso de entrevistas?"

• Tácticas de respuesta

  • Controlar la preparación (Control the preparation): incluir presentation en la mezcla o dar guías precisas (por ejemplo, "system design centrado en bases de datos", "algoritmos sobre grafos") para crear un entorno justo
  • Diversificar preguntas por tipo: archivar regularmente las preguntas antiguas. Si el candidato no puede predecir exactamente la pregunta, debe ampliar el alcance de su preparación, y ese es el objetivo. Pero no es gratis
  • Hacer más difícil la filtración (Make it harder to leak): hacer la entrevista onsite, usar whiteboard y ubicar las preguntas más vulnerables al final del proceso (hay menos candidatos y baja la probabilidad de filtración)

La programación con IA amenaza el modelo actual de entrevistas

• (1) Los take-home se vuelven demasiado fáciles para el candidato y demasiado caros para la empresa

  • En 2026, es muy probable que la mayoría de las entregas sean generadas o asistidas por IA, y las tareas que hoy resisten probablemente caerán con la siguiente generación de modelos
  • Como resultado, la mayoría de los candidatos superará la primera etapa, así que revisar todo consumirá mucho tiempo. Revisar con IA entregas generadas por IA no tiene sentido
  • La programación con IA traslada el costo de la entrevista del entrevistado al entrevistador
    • Se cita la ley de Brandolini: la energía necesaria para refutar mal código es un orden de magnitud mayor que la necesaria para producirlo

• (2) Si escribir código toma menos tiempo, es natural reducir el peso del live-coding

  • Así como ya no escribimos lenguaje máquina y usamos lenguajes de más alto nivel, también parece razonable alinear las herramientas permitidas en la entrevista con las del trabajo diario

• (3) Cuando las preguntas se filtran, la IA es un coach muy potente

  • Antes encontrar preguntas y prepararse requería mucho tiempo y recursos; ahora la IA ofrece la ayuda más potente y más barata

Cómo el modelo clásico de evaluación escolar resistió a la tecnología

• Los exámenes de secundaria y universidad en Francia mantienen en general la misma forma
  • No se permite llevar materiales (clases, libros, etc.), casi no se permiten herramientas (especialmente calculadoras), el contenido no se divulga antes, no se puede adivinar (cada examen es distinto y se usa una sola vez), y se plantean problemas amplios y ambiguos
  • La esencia del examen de literatura francesa es la dissertation, donde se escribe un ensayo de 5 a 10 páginas a partir de una sola frase temática; existe desde 1830. Los exámenes de ciencias siguen un formato parecido con 3 o 4 problemas ambiguos
• Se complementa con otras formas de evaluación, como take-home, preguntas objetivas de conocimiento, trabajos grupales o presentaciones, pero son excepciones y no la regla
• Reaplicando la clasificación
  • Calidad de señal: alta — el espacio de preparación es muy amplio y exige esfuerzo sostenido
  • Costo: muy alto — hay que diseñar un tema y una guía de corrección nuevos para cada examen, y todos los candidatos presentan el mismo examen al mismo tiempo (algo totalmente poco realista para entrevistas en empresas)
• Lo interesante es que este modelo casi no cambió a pesar de avances enormes en herramientas cognitivas como copiar y pegar, internet, calculadoras o solvers
  • La educación debe enfocarse en capacidades fundamentales, no en las herramientas del momento, en línea con un modelo aristotélico centrado en el juicio (phronesis) más que en la memoria (mneme)

Por qué las empresas deberían restringir el uso de IA durante la entrevista

• Distinguir entre capacidades fundamentales y habilidades instrumentales

  • Foundational traits & skills son capacidades, actitudes y hábitos difíciles o costosos de construir
    • Capacidad intelectual bruta, experiencia profunda adquirida a lo largo de años de aprendizaje (sistemas distribuidos con millones de requests por segundo, convertir cientos de microservicios en un monolito, etc.), razonamiento de segundo orden y virtudes como ética profesional, integrity y resiliencia
    • Es conocimiento internalizado (fundamentals) que permite identificar, abstraer y resolver problemas, y sirve de base para adquirir más habilidades. Es lo que lleva a decir: "es inteligente, lo resolverá"
  • Instrumental skills se adquieren de forma barata o rápida
    • Dominio intermedio de un lenguaje de programación, uso adecuado de un editor de texto, búsqueda en documentación, ajuste de prompts para IA
  • En las entrevistas, a menudo se usan varias señales de habilidades instrumentales para verificar rasgos fundamentales del candidato, como la disposición a invertir en su productividad o su aprendizaje estructurado

• Razonamiento 1: la habilidad con IA no es una capacidad fundamental

  • Las herramientas de ingeniería han evolucionado constantemente, pero las entrevistas se han mantenido más o menos iguales (no existe un tipo de entrevista low-code; system design suele usar tecnologías básicas y no administradas)
    • Las mejores empresas no buscan dominio de una sola herramienta, y con el auge de los LLM se vuelve aún más importante el Expert Generalist
  • La misma razón explica por qué la especialización en un lenguaje de programación no suele ser tan importante en entrevistas. El lenguaje es solo una herramienta para un fin superior: resolver problemas
  • Con la IA pasa lo mismo: prompt/context engineering, definición de MCP/skills, multi-agent workflow, harness engineering y otras técnicas sutiles son habilidades instrumentales, y aun así requieren las mismas capacidades fundamentales necesarias para escribir, revisar y diseñar arquitecturas escalables
  • Las empresas contratan cerebros, no manos que le escriben instrucciones distraídamente a un agente de IA
  • Revisar y producir son dos caras de la misma moneda: revisar código, arquitectura o análisis exige capacidades parecidas a escribir, diseñar o analizar. Como todavía se necesitan humanos para generar y validar requerimientos de negocio, la revisión de código no desaparecerá pronto (una especificación suficientemente detallada ya es casi código)

• Razonamiento 2: la IA oculta rasgos y capacidades fundamentales

  • Se cita a Peter Drucker: no se puede contratar solo manos; siempre viene la persona completa
  • Se usa la distinción de Lewis Mumford entre tool (la persona domina) y machine (opera con su propia lógica y tiene agency). Si se usa demasiada IA, se vuelve casi imposible distinguir qué aportó realmente el ingeniero y qué aportó el modelo
  • Hay que desconfiar de ingenieros que usan la IA no como tool sino como machine. La IA es un salto de productividad mucho mayor que un simple autocompletado y puede externalizar la mayor parte del pensamiento. Incluso áreas supuestamente humanas como el "taste" están bajo presión, y hasta la lista de Fitts empieza a verse vieja
  • Como el pharmakon de Platón analizado por Derrida, la IA es remedio (automatiza refactors repetitivos, ahorra tiempo para aprender rarezas de librerías) y veneno (riesgo de atrofiar capacidades fundamentales)
  • Una entrevista que enfatiza demasiado la IA corre el riesgo de evaluar no al humano sino al modelo ("machine"). Por eso hay que diseñar ejercicios que pongan el razonamiento humano en el centro

• Razonamiento 3: la IA evoluciona demasiado rápido

  • Según Arthur Mensch (CEO de Mistral), los modelos de IA ganan alrededor de 1 año de experiencia en software engineering cada 12 meses. Ya casi no se escucha la broma de comparar agentes de IA con interns
  • La mayoría de las empresas no tiene capacidad para generar y mantener de forma continua preguntas resistentes a IA que obliguen a demostrar capacidades fundamentales. Si los modelos evolucionan cada mes y ni siquiera se tiene acceso a todos, crear preguntas que resistan siempre al mejor modelo es una batalla perdida
    • "Designing AI resistant technical evaluations" de Anthropic es un caso de estudio sobre pelear contra la IA, no contra candidatos
  • Diseñar take-home más difíciles es como permitir calculadoras pero poner ejercicios de cálculo mental más difíciles
  • Las mejores prácticas de IA también evolucionan cada mes, y a medida que los modelos entienden mejor las instrucciones, la importancia del prompt engineering disminuye. Que un candidato conozca la técnica más reciente no es una señal muy útil
  • En cambio, los fundamentals no cambian por definición

Respuestas a objeciones

• Sobre la crítica de que no hay datos: (1) hacer un experimento real con significancia estadística (un ensayo aleatorizado y controlado) es casi imposible, y ninguna empresa aceptaría los false negatives que eso produciría; (2) la mayoría de las decisiones de diseño de entrevistas no se basa en experimentos tipo ensayo clínico, sino en razonamiento abstracto
• Hacer trampa con IA (por ejemplo, durante la entrevista): si se prohibió explícitamente, usar herramientas de IA es motivo de rechazo inmediato
  • Se cita a Warren Buffett: al contratar se busca integrity, intelligence y energy; si falta integrity, las otras dos solo vuelven peligrosa a la persona. Si se va a contratar a alguien sin integrity, casi sería mejor que fuera tonto y flojo
• ¿Hay que evaluar candidatos con IA? No. (1) Es éticamente incorrecto: si se está contratando a un trabajador del conocimiento humano, una máquina no puede evaluarlo todo; (2) las evaluaciones con IA son no deterministas y conocidas por alucinar, así que al final igual habría que revisar la evaluación de la IA

Recomendaciones concretas para empresas

• No permitir el uso de IA en la mayoría de las entrevistas. No sobreenfatizar herramientas específicas y enfocarse en capacidades fundamentales
• Invertir en live exercise. No tienen por qué ser falsas, aburridas o de baja señal, ni necesariamente cortas. Reexaminar las entrevistas de data structure & algorithm, que siguen siendo de las más intelectualmente desafiantes. Diseñar ejercicios que exijan esfuerzo humano y mantener muchas preguntas para evitar la sobrepreparación en una sola
• Mezclar tipos de entrevista para obtener una señal amplia con buen costo-beneficio
• Ajustar los take-home. Prohibir explícitamente la IA o permitirla, pero sin perder tiempo revisando salidas generadas por IA. Un take-home debe continuar obligatoriamente con un live exercise basado en él, para que el candidato presente el trabajo, explique trade-offs, cambios de requisitos, escalabilidad, etc.
• Tener al menos una entrevista que evalúe capacidad de review. Es barata de producir, entrega señales interesantes y exige menos al candidato. Ejemplos: plan generado por IA, postmortem, codebase existente (Bug squash), documento de requerimientos de producto, análisis de trade-offs, review de arquitectura del sistema
• Considerar llevar a los candidatos onsite. Es la forma más simple de evitar trampas y también dificulta un poco la filtración de preguntas. Aplica solo a empresas con RTO (regreso a la oficina)
• Dar guías claras de preparación para crear un entorno más justo

[roxie]

A mí me parece bueno para trabajar juntos una semana.

[linusjeh]

Ese texto también lo habrán escrito con IA, jaja

[jjpark78]

De todas formas, cuando se trabaja se va a usar IA, así que excluir eso no sé si tenga mucho sentido. Más bien, ¿no sería mejor eliminar las entrevistas remotas y hacerlas solo presenciales, evaluando con preguntas bien diseñadas y monitoreo cómo usa la IA y cómo piensa la persona en el lugar?

Incluso con el mismo problema, si ves cómo redacta los prompts, puedes saber mucho sobre esa persona.