Dejá de memorizar Java

La parálisis por análisis

En mis primeros años mi rutina de preparación de entrevistas era siempre la misma. Tenía una lista de preguntas comunes o frecuentes de entrevistas — que iba haciendo crecer cada vez que me encontraba con un tema nuevo — guardada en un PDF que leía repetidamente. ¿Qué diferencia hay entre una LinkedList y un ArrayList en términos de memoria? ¿Qué hace exactamente transient? ¿Cómo funciona el Garbage Collector en tal versión de Java?

Tenía un convencimiento de que si no soltaba la respuesta técnica perfecta al instante, el entrevistador iba a ver “a través de mí” y descubriría que era un impostor, que no estaba listo para ese puesto o esa empresa. Fue una época de parálisis pura. Me enfocaba tanto en saber casi de memoria los temas que ni me daba cuenta de que no era lo realmente importante.

Memorizar Java — o cualquier lenguaje — no te hace un experto; te hace una enciclopedia con patas. Y en la industria, las enciclopedias no resuelven problemas reales.

Obvio que es fundamental tener teoría en la cabeza y saber dónde estamos parados, pero no lo es todo. Eso es algo que sólo te da la experiencia con el tiempo.

La trampa del “Sesgo de Acción” en entrevistas técnicas

Después de años de trabajo y muchas entrevistas (spoiler: si no te va bien en alguna, no pasa nada; vienen muchas más por delante), fui comprendiendo algo: los equipos que realmente construyen cosas grandes no buscan gente que sepa recitar documentación. Buscan personas que no se bloqueen ante la incertidumbre, que tengan iniciativa, que quieran aprender y que se adapten.

Muchos devs junior sienten que si no están escribiendo código, no están trabajando. Ese “Sesgo de Acción” es el que te mata en una entrevista. Intentás demostrar lo que sabés para llenar el silencio, en lugar de demostrar cómo pensás. Usualmente, una buena entrevista no es “pregunta y respuesta”, es más una conversación entre colegas.

En una empresa para la que trabajé, mi líder técnico venía de tomar una entrevista a un candidato a senior developer y me comentó, bastante molesto, que hizo la pregunta: “¿Cómo manejás un error en un flujo de pago donde el banco nos confirma, pero nuestra base de datos falla al persistir?”. Bastante abierta, por cierto, como para ver cómo razonaba.

La respuesta lo sorprendió por lo básica: “Haría un try-catch, y si falla, envío un error al cliente”.

No estaba mal, pero para un puesto senior, suena a muy poco. Simplemente respondió como alguien que se limita a programar.

Nuestra realidad es otra: viene nuestro cliente con diez ocurrencias — la mayoría, una locura — y uno tiene que sentarse a pensar qué vale la pena y qué no, qué prioridades tenemos, que recursos hay y, recién ahí, ver de qué manera hacemos “magia” y podemos construir una solución.

El criterio como ventaja competitiva: El arte del Trade-off

Solemos caer en la trampa de creer que el diseño es elegir la “mejor” tecnología. Error. El diseño es elegir la que menos problemas te va a dar a largo plazo. Nos centramos tanto en que algo funcione hoy, que olvidamos que casi todo lo que hagas, tarde o temprano, va a sufrir modificaciones.

Recuerdo cuando empecé a aprender sobre microservicios. Me llamaba mucho la atención la arquitectura distribuida, en particular la que acabo de mencionar, porque “era lo que usaba Netflix” en su época de mayor transformación.

Tomé un curso excelente, con un profesor que sabía muchísimo, donde todo parecía la solución perfecta. Hasta que, por la mitad, el profesor empezó a hablar de problemas de orquestación, red, observabilidad, transaccionalidad distribuida, etc. Ahí entendí que hay un montón de cosas que debés resolver antes de siquiera empezar a escribir la lógica de negocio.

Elegir la decisión que mejor cuide al equipo y al negocio es mucho más valioso que elegir la que suena más “pro” en la entrevista. Eso es madurez técnica: entender que cada línea de código es un pasivo de mantenimiento.

El costo oculto de la “Elegancia Técnica”

He visto sistemas escritos con muchísima calidad y esmero, pero llenos de patrones complejos (Strategy, Observer, Factories por doquier) para resolver cosas simples que se hacían con un if. No digo que no sea bueno, pero hay que saber priorizar.

Si escribís código que solo vos podés mantener, no sos un buen desarrollador, sos un problema para el equipo. La verdadera elegancia es la simplicidad. En la vida real, un senior te va a agradecer más un código aburrido, legible y fácil de testear que un sistema “sofisticado” que requiere un mapa y una brújula para entender el flujo de datos. Si tu código necesita una charla de dos horas para explicarse, probablemente esté mal diseñado.

El arte de decir “No sé”

Para mí, este es el punto más importante. En mi humilde opinión, la mejor defensa ante un entrevistador no es la soberbia del que sabe todo, sino la honestidad del que sabe qué camino tomar cuando se pierde.

Cuando te pregunten algo como: “¿Cómo optimizarías el lockeo en una tabla de alta concurrencia en SQL?” y no tengas ni idea, no inventes. Probá diciendo: “Nunca me enfrenté a ese nivel de concurrencia específica, pero si tuviera que abordarlo hoy, analizaría primero si el problema se resuelve con un cambio de aislamiento en la transacción o si necesitamos mover esto a un sistema de colas. ¿Cómo manejan ustedes estos casos acá?”.

O simplemente “No lo sé, la verdad nunca trabajé con eso y conozco del tema. ¿Podrías explicarme? Lo voy a anotar así después lo investigo, porque me interesa”. Te puedo asegurar que eso suma muchísimos más puntos que si tratas de mentir o de escaparte de ahí.

Eso demuestra que te gusta investigar, preguntar y razonar. Esa actitud es la que te consigue el puesto, no la respuesta de manual.

Dejando el miedo atrás

La próxima vez que tengas una entrevista, hacé este ejercicio: no vayas a demostrar lo que sabés, andá a ver si el problema que ellos tienen es uno que vos querés (y te sentís capaz de) resolver. Esa pequeña diferencia en tu postura cambia toda la dinámica.

No es cuestión de saberlo todo, es cuestión de saber dónde estás parado. Si no lograste el puesto, no pasa nada; al menos te llevaste una experiencia más. Anotate las cosas que no supiste responder y repasalas. Con el tiempo, le vas perdiendo el miedo. ¡No dejes de creer en vos, tarde o temprano lo vas a lograr!

Si llegaste hasta acá, te agradezco y espero que te haya servido. A veces, compartir experiencias es más valioso que la misma teoría que publican todos.