Cómo prepararte para una entrevista de programación sin asistencia de IA

La mayoría de las entrevistas técnicas todavía no permiten asistencia de IA. Sin Copilot, sin una pestaña de ChatGPT abierta en un segundo monitor, a veces ni siquiera autocompletado más allá del resaltado básico de sintaxis. Si la mayor parte de tu día real de programación involucra un asistente que termina tus pensamientos, esa brecha entre "puedo construir esto" y "puedo escribir esto desde un editor en blanco mientras alguien observa" puede ser mucho más grande de lo que parece en el día a día.

Esto no tiene que ver con inteligencia ni nivel de experiencia. Tiene que ver con un tipo específico de práctica: recordar sintaxis exacta, nombres de métodos y estructura de bucles de memoria, bajo presión leve de tiempo, algo que el autocompletado silenciosamente se encargó de hacer por ti. Esa habilidad no se erosiona porque te volviste peor programando. Se erosiona porque dejaste de ejercitar ese músculo en particular, de la misma forma en que cualquier habilidad que delegas durante meses eventualmente se oxida.

Por qué esto agarra a la gente desprevenida

Normalmente es invisible hasta el momento exacto en que importa. Envías funcionalidades reales constantemente, revisas código con fluidez, depuras problemas de producción bajo presión real, y nada de eso requiere escribir un bucle desde cero sin ayuda. Luego una entrevista (o una laptop rota, o un pizarrón) le quita el asistente, y la brecha aparece de golpe, sin calentamiento.

Qué hacer realmente con el tiempo que tienes

Si tienes unos días en lugar de unos meses, lo de mayor impacto que puedes hacer es acotar: no intentes reaprender todo, apunta a los reflejos específicos que el autocompletado ha estado haciendo por ti.

• Apaga la asistencia antes de la entrevista, no durante ella. La primera vez que escribas código sin la red de seguridad no debería ser mientras alguien te observa y hay una decisión en juego. Haz ese ajuste en privado, con anticipación, las veces suficientes para que deje de sentirse incómodo.
• Practica desde un editor genuinamente en blanco. No un fragmento a medio terminar que estás completando, sino un archivo vacío y una consigna en lenguaje simple, exactamente como te la daría un entrevistador. Lo que está oxidado es la recuperación, no la lógica.
• Prioriza sesiones cortas y frecuentes por sobre largas y ocasionales. Quince minutos enfocados escribiendo código de verdad sin ayuda, todos los días, reconstruye el reflejo más rápido que una sesión agotadora de tres horas la noche anterior.
• Di la sintaxis en voz alta mientras la escribes. Suena raro, pero te obliga a recuperar de verdad el nombre exacto del método o la estructura del bucle en lugar de que tus dedos hagan coincidencia de patrones hacia lo que el autocompletado suele sugerir.

Enfócate en tus puntos débiles reales, no en terreno cómodo

Es tentador calentar escribiendo el tipo de código que ya escribes con fluidez. Se siente productivo pero no cierra la brecha real. El enfoque más útil, aunque un poco incómodo, es notar exactamente dónde duda tu mano: ¿son los métodos de arreglos? ¿El formateo de cadenas? ¿La forma específica en que tu lenguaje objetivo maneja la igualdad o la veracidad (truthiness)? Esas dudas pequeñas y específicas suelen ser las mismas que aparecen bajo presión de entrevista, así que vale la pena apuntarles deliberadamente en lugar de evitarlas.

Aquí es también donde cambiar entre lenguajes bajo presión se vuelve genuinamente peligroso: recurrir al len() de Python en un ejercicio de JavaScript, o al in de Python cuando quieres decir el .includes() de JavaScript. No es un error de lógica, es sintaxis incorrecta dicha con confianza, y un entrevistador que te vea escribirla lo interpretará muy distinto a un simple error de tipeo.

Haz que la práctica refleje la restricción real

El punto entero es cerrar la brecha específica que una entrevista va a exponer, así que la práctica debería coincidir con esa restricción lo más posible: sin asistencia, consciente del tiempo, y honesta sobre lo que realmente te salió mal en lugar de lo que se sintió suficientemente cerca. Esa es exactamente la premisa sobre la que se construyó SoloScript: ejercicios cortos y sin asistencia que detectan la diferencia entre "la idea correcta, sintaxis equivocada" y un error de lógica real, para que practiques exactamente lo que una entrevista va a evaluar en lugar de resolución de problemas general que probablemente no perdiste.