El Caso en Contra de Machacar LeetCode (y Qué Hacer en su Lugar)

El consejo estándar para prepararse para entrevistas es alguna versión de "machaca LeetCode hasta que haga clic" — elige un número, 100, 300, lo que se sienta serio, y trabájalo. No es exactamente mal consejo. Simplemente apunta al blanco equivocado para mucha gente que lo sigue.

Los problemas de LeetCode son muy buenos en una cosa específica: reconocer el patrón entre un enunciado de problema y una categoría de algoritmo. Encajan mucho peor con lo que realmente traba a la gente en el día a día, que es escribir código ordinario — una función, una clase, una pequeña funcionalidad — desde un archivo en blanco, sin buscador, bajo algo de presión de tiempo.

Lo que el volumen realmente entrena

Hacer trescientos problemas te enseña a reconocer rápido "esto es un problema de ventana deslizante" o "esto pide un hash map". Esa es una habilidad real y transferible para rondas de entrevista centradas en algoritmos. Es una habilidad mucho más estrecha que "poder escribir código con fluidez", y tratarla como un sustituto de la fluidez general para programar es donde el machaque deja de rendir como la gente espera.

La brecha que no cierra

El momento que realmente descarrila a la gente en entrevistas o en el trabajo casi nunca es "no conozco el algoritmo" — es algo más pequeño y mundano: olvidar la sintaxis exacta de una función del lenguaje que usas cada semana, trastabillar con manipulación básica de listas o strings que antes era automática, o congelarte ante un simple "escribe una función que haga X" sin ningún contenido algorítmico interesante. Ninguna cantidad de volumen en LeetCode toca esa brecha, porque los problemas de LeetCode están específicamente elegidos para tener contenido algorítmico interesante.

Cómo es la práctica deliberada en su lugar

• Practica lo aburrido a propósito. Bucles, manipulación de strings, operaciones básicas de estructuras de datos, escribir la firma de una función a partir de una descripción en lenguaje simple. No es emocionante, y por eso mismo es lo que se salta, y por eso mismo es donde pasa el bloqueo específicamente.
• Practica en el lenguaje que realmente usas, no en pseudocódigo. Gran parte de la práctica de algoritmos ocurre en un modelo mental independiente del lenguaje. El músculo que de verdad necesita entrenamiento es producir sintaxis correcta en tu lenguaje específico, sin ayuda, algo que la práctica a nivel pseudocódigo nunca toca.
• Practica que te detecten el error, no solo llegar a la respuesta correcta. LeetCode te dice si pasaste o no. No te dice "esto es sintaxis de Python en un archivo de JavaScript" o "usaste el método de lista equivocado para este lenguaje" — la retroalimentación específica y accionable que realmente corrige un hábito en vez de solo confirmar un resultado.
• Vuelve a lo que ya resolviste. El machaque centrado en volumen trata un problema resuelto como terminado y sigue adelante. Un segundo intento, sin ayuda, de algo que resolviste hace una semana pone a prueba la retención de una forma que resolver algo nuevo por primera vez nunca hace.

El volumen no es el enemigo — es la métrica equivocada

Nada de esto es un argumento en contra de practicar mucho — es un argumento en contra de medir la práctica por cantidad de problemas en vez de por lo que realmente se está entrenando. Trescientos problemas de algoritmos y cero minutos dedicados a código ordinario, sin ayuda, desde cero, deja exactamente la brecha que la mayoría descubre de la forma difícil, en una sala de entrevista, cuando lo que está en juego ya es alto.

SoloScript está construido específicamente alrededor de esa brecha — ejercicios cortos y ordinarios de programación en el lenguaje que realmente usas, que detectan los tropiezos de sintaxis y las brechas de hábito que un juez de algoritmos de pasa/no-pasa nunca fue diseñado para ver.