Un candidato mid-level, en una entrevista remota, responde a "¿Cuál es la diferencia entre switchMap y mergeMap?" con una definición perfecta, tras una pausa de tres segundos. Dos preguntas después le preguntas cuál de los dos usaría en una barra de búsqueda, y por qué. Silencio. La primera pregunta midió lo rápido que consulta a un asistente de IA; la segunda midió lo que de verdad necesitabas saber.
He estado a ambos lados de la mesa de entrevistas, y la pregunta que me hago cada vez más a menudo es sencilla: hoy, con un asistente de IA en cada editor, ¿siguen teniendo sentido las preguntas clásicas de entrevista?
Qué ha cambiado realmente
Las preguntas "de manual" — definiciones, diferencias entre dos conceptos, listas de características — siempre fueron una aproximación: se daba por hecho que quien conoce la teoría también sabe aplicarla. Era una aproximación aceptable cuando recordar costaba esfuerzo. Hoy recordar no cuesta nada: cualquier definición está a un prompt de distancia, durante la entrevista y sobre todo después, en el trabajo real.
Y ahí está precisamente la clave: el desarrollador que contratas trabajará con IA. Lo que importa ya no es lo que sabe de memoria, sino tres cosas que la IA no hace por él:
- Criterio: elegir entre dos soluciones correctas según el contexto.
- Verificación: darse cuenta de cuándo el código generado está mal, aunque compile.
- Contexto: entender el problema real antes de escribir una sola línea.
Mid y senior: las preguntas clásicas ya no bastan
Para un perfil mid o senior, las preguntas teóricas aisladas son casi inútiles: un buen candidato las supera, pero también uno mediocre con una segunda pantalla. No hay que eliminarlas del todo: hay que usarlas como punto de partida para profundizar. Estos son cinco formatos que funcionan.
1. Code review de código generado por IA
Dale al candidato un fragmento plausible, como los que un asistente produce a diario, y pídele que lo revise como haría con el pull request de un compañero:
// Product search bar
this.results$ = this.query$.pipe(
debounceTime(300),
mergeMap(q => this.api.search(q))
);El código funciona casi siempre. Un senior debería notar que con mergeMap una respuesta lenta para "ang" puede llegar después de la de "angular" y sobrescribir los resultados correctos: hace falta switchMap, que cancela la petición anterior. Puntos extra si pregunta qué pasa con una cadena vacía o con un error HTTP, que aquí cerraría el stream para siempre.
El mismo ejercicio funciona en el backend:
async function getOrders(userIds) {
const result = [];
for (const id of userIds) {
result.push(await db.orders.find({ userId: id }));
}
return result;
}Aquí se buscan las N consultas secuenciales, la falta de paginación y la propuesta de una única consulta con $in. No hay definición que recitar: o ves el problema o no lo ves.
2. Escenarios en lugar de definiciones
En vez de "¿Qué es la change detection?" pregunta: "Una tabla con 5.000 filas se vuelve lenta cuando el usuario escribe en el filtro. Aquí tienes el profiler: ¿por dónde empiezas?". En vez de "¿Qué es Redis?": "Tenemos una caché en memoria y pasamos de una a tres instancias del backend. ¿Qué se rompe?". Las respuestas muestran enseguida si el candidato ha resuelto problemas similares o solo ha leído sobre ellos.
3. El relato de un problema real
"Cuéntame el bug más difícil que has resuelto en producción" sigue siendo una de las mejores preguntas, siempre que profundices con preguntas de seguimiento: ¿cómo te diste cuenta? ¿Qué hipótesis descartaste primero? ¿Qué cambiaste para que no volviera a ocurrir? Una experiencia vivida resiste cinco niveles de "por qué"; una historia preparada se cae en el segundo.
4. Pair programming con IA permitida
En lugar de prohibir las herramientas, permítelas y observa cómo se usan. Una tarea de 30-40 minutos sobre un pequeño repositorio real, con el asistente de IA activado. No evalúas el resultado sino el proceso: ¿el candidato lee el código antes de preguntar? ¿Escribe prompts precisos o genéricos? ¿Descarta una sugerencia errónea o la acepta porque compila? ¿Añade un test?
5. Compromisos y decisiones
En un senior cuenta la capacidad de decidir bajo restricciones: "Tenemos dos semanas y un equipo de tres personas: ¿reescribimos el módulo o lo blindamos con tests?". No hay una respuesta correcta: hay un razonamiento que sopesa riesgo, coste y reversibilidad, y eso es exactamente lo que quieres oír.
Junior: cómo debería ser la entrevista
Con los juniors el problema es el contrario. No tienen experiencia que contar, y un code review complejo los penalizaría injustamente. Pero precisamente para ellos el riesgo de la IA es mayor: es fácil producir código que funciona sin entenderlo. Por eso la entrevista debe medir comprensión y capacidad de aprendizaje, no la cantidad de conocimientos.
Un esquema de 60 minutos que uso y recomiendo:
| Tiempo | Actividad | Qué evalúa |
|---|---|---|
| 10 min | Un proyecto personal o universitario: qué hiciste tú, qué harías de otra forma | Autoconciencia, honestidad |
| 15 min | Leer un código breve y predecir su salida, línea por línea | Fundamentos reales |
| 20 min | Pequeña tarea con IA permitida, luego preguntas sobre cada línea escrita | Comprensión, verificación |
| 10 min | La documentación de una API nunca vista: usarla en un caso sencillo | Capacidad de aprender |
| 5 min | Preguntas del candidato | Curiosidad, interés |
Un ejemplo de ejercicio de lectura, perfecto para un junior de JavaScript:
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0);
}
// ¿Qué imprime? ¿Y si usamos let en lugar de var?No importa que el junior sepa la respuesta de memoria (3 3 3, luego 0 1 2): importa que, con algo de guía, llegue a explicar por qué — el scope de la variable y la ejecución asíncrona. Es una pregunta clásica, pero usada para hacer razonar, no para comprobar un recuerdo.
En la parte con IA, la pregunta clave llega después del código: "¿Qué pasa si el array está vacío? ¿Y si llega null?". Un junior que lo ha entendido razona, aunque se equivoque; uno que solo ha pegado la respuesta no sabe por dónde empezar. En ambos casos obtienes una información valiosa.
Pregunta clásica → versión actualizada
| Pregunta clásica | Versión actualizada |
|---|---|
| ¿Qué es un closure? | Este código tiene un memory leak: ¿dónde y por qué? |
| ¿Diferencia entre SQL y NoSQL? | Para este caso de uso, ¿cuál eliges y qué pierdes? |
| ¿Cuáles son los principios SOLID? | Esta clase es difícil de testear: ¿cómo la reestructurarías? |
| ¿Qué es el lazy loading? | El bundle inicial pesa 4 MB: ¿qué revisas primero? |
| ¿Cómo funciona un JWT? | Un token robado sigue siendo válido 30 días: ¿qué cambias? |
Qué eliminar (o casi)
- Definiciones de memoria como única prueba: miden la búsqueda, no la competencia.
- Ejercicios para casa de 8 horas: una IA los completa en media hora, y penalizan a quien tiene menos tiempo libre.
- Live coding sin internet ni herramientas: evalúa una situación que no existe en el trabajo real.
- Prohibir la IA en la entrevista y exigirla desde el primer día: es incoherente, y los mejores candidatos lo notan.
En resumen
Las preguntas clásicas no han muerto, pero por sí solas ya no miden lo que importa. Para mid y senior hacen falta code reviews, escenarios reales y decisiones bajo restricciones, a ser posible con la IA sobre la mesa para ver cómo la gestionan. Para los juniors hacen falta ejercicios de lectura de código, preguntas sobre el "por qué" y una prueba de aprendizaje: no cuánto saben ya, sino con qué rapidez y honestidad aprenden. En un mundo en el que el código se genera en segundos, el verdadero talento es saber cuándo ese código está mal. Si te estás preparando desde el otro lado de la mesa, encontrarás las preguntas técnicas organizadas por nivel en la guía de las 25 preguntas de entrevista frontend/Angular.