Cómo estudiar
El ciclo que funciona: cuánto pelear antes de mirar una pista, cómo repasar para no olvidar, y por qué treinta problemas con método rinden más que cien sin él.
6 min de lectura
La forma más común de estudiar para entrevistas técnicas es también la que peor funciona: abrir una lista de problemas, resolver los que salen, mirar la solución de los que no, y tachar. Al mes siguiente, los problemas que "ya hiciste" vuelven a no salir.
El problema no es la cantidad. Es que leer una solución produce la sensación de haber aprendido sin que haya pasado nada. Reconocer una solución es fácil; producirla desde cero es otra cosa, y es lo único que se te va a pedir en una entrevista.
El ciclo por problema
Para cada problema, en este orden:
1. Lee el enunciado y reformúlalo. En voz alta o por escrito, con tus palabras: qué entra, qué sale, qué casos raros hay. Si no puedes reformularlo, todavía no lo entendiste, y resolver algo que no entiendes no lleva a ningún lado.
2. Piensa antes de escribir. Veinte minutos. Sin editor. Papel, o la cabeza. Busca a qué se parece: ¿el array está ordenado? ¿pide un subarray contiguo? ¿pide todas las combinaciones? Esa búsqueda de parecido es exactamente lo que vas a hacer en la entrevista.
3. Si no aparece nada, abre la pista 1. Después vuelve a pensar quince minutos. Si sigues trabado, pista 2. Después pista 3.
4. Codea. Recién ahora. Y córrelo contra los tests.
5. Si después de la pista 3 no sale, lee la solución. Pero no pases al siguiente problema. Cierra la página y reescribe la solución de memoria, sin mirar. Si no te sale de memoria, no la entendiste, la reconociste.
6. Anota qué te faltó. Una línea. "No se me ocurrió que ordenar primero simplificaba todo." "Olvidé el caso del array vacío." Esa línea vale más que el código.
Veinte minutos pensando puede parecer mucho cuando estás trabado. Es el rato exacto en el que se aprende. Si te rindes a los tres minutos y abres la solución, el problema no te enseñó nada; solo te informó.
Repetición espaciada
Un problema resuelto una vez se olvida. Un problema resuelto tres veces con días de por medio se queda.
El esquema mínimo:
| Repaso | Cuándo | Qué haces |
|---|---|---|
| 1 | El mismo día, unas horas después | Reescribes la solución de memoria |
| 2 | A los 3 días | Resuelves desde cero, sin mirar nada |
| 3 | A las 2 semanas | Igual, y si sale limpio queda archivado |
Solo repasa así los problemas que te costaron. Los que salieron a la primera no necesitan repaso.
Basta una hoja de cálculo con cuatro columnas: problema, fecha, si salió sin ayuda, y qué te faltó. No hace falta ninguna herramienta especial.
El cuaderno de errores
Esta es la pieza que casi nadie tiene y la que más rinde.
Cada vez que fallas un problema, escribe una línea con el motivo, no con la solución. Después de veinte o treinta problemas vas a ver que tus errores se repiten en tres o cuatro categorías. Casi siempre son de este estilo:
- No reconocí el patrón.
- Reconocí el patrón pero me equivoqué en los índices.
- Olvidé un caso límite (vacío, un solo elemento, todos iguales, negativos).
- La solución era correcta pero demasiado lenta.
- Me perdí en la implementación y me enredé solo.
Saber cuál es tu categoría dominante te dice qué practicar. Si fallas por casos límite, no necesitas más problemas: necesitas hacer una lista de casos límite antes de codear. Si fallas por no reconocer el patrón, necesitas releer las lecciones, no resolver más ejercicios.
Cuántos problemas
Menos de los que crees, si los haces bien.
Treinta problemas trabajados con este ciclo, cubriendo todos los patrones del curso, preparan mejor que trescientos resueltos mirando soluciones. La razón: en la entrevista no te van a dar ninguno de los que hiciste. Te van a dar uno nuevo que se parece a alguno. Lo único que transfiere es el reconocimiento del patrón, y eso se entrena con profundidad, no con volumen.
Una señal concreta de que un tema está listo: puedes explicar en voz alta, sin mirar nada, cuándo aplica el patrón, cómo se ve el código típico y cuál es su complejidad. Si puedes hacer eso, resolver un problema nuevo de ese tema es cuestión de cuidado con los detalles.
Practica en voz alta
En la entrevista vas a tener que hablar mientras piensas, y es más difícil de lo que parece. Es una habilidad separada de resolver, y hay que entrenarla aparte.
Al menos en uno de cada cinco problemas, resuelve narrando: di qué estás mirando, qué se te ocurre, por qué descartas una idea. Grábate si te ayuda. La primera vez vas a notar que te callas justo cuando piensas, que es exactamente el momento en que el entrevistador necesita oírte.
Un plan de ocho semanas
Si vas de cero y tienes una o dos horas por día:
| Semanas | Qué |
|---|---|
| 1 | Introducción, complejidad, arrays y strings |
| 2 | Búsqueda binaria, dos punteros, ventana deslizante, sumas de prefijo |
| 3 | Recursión, ordenamiento, hashing |
| 4 | Listas enlazadas, pilas y colas, intervalos |
| 5 | Árboles binarios, BFS, DFS, heap |
| 6 | Grafos, backtracking |
| 7 | Programación dinámica, greedy |
| 8 | Repaso con repetición espaciada y problemas mezclados sin saber el tema |
Esa última semana es la más parecida a una entrevista real, porque el problema no viene etiquetado. Resolver un problema de ventana deslizante sabiendo que estás en el tema de ventana deslizante es mucho más fácil que reconocerlo desde cero.
Si tienes menos tiempo, no comprimas: recorta temas. Es mejor dominar diez patrones que rozar veinte.
Errores de estudio frecuentes
- Saltar directo a los problemas sin leer la lección. Duplica el tiempo y baja lo que aprendes.
- Resolver solo problemas fáciles porque salen y da gusto. El progreso está donde te trabas.
- Resolver solo difíciles para "aprovechar el tiempo". Sin las bases, terminas leyendo soluciones.
- Estudiar sin correr el código. Los off-by-one se descubren ejecutando.
- No repasar. Sin repaso, un mes después estás donde empezaste.
- Medir el progreso en problemas resueltos en vez de en patrones que puedes explicar de memoria.
Inicia sesión para guardar el progreso de esta lección.