El debate está bien encaminado, pero hay un matiz que se está pasando por alto: la diferencia entre aprender y demostrar que sabes. Un grado o una certificación no te hacen mejor ingeniero, pero sí te dan un mecanismo de validación externa que, en muchos mercados, sigue siendo un filtro de entrada. No es justo, pero es real. Dicho esto, el problema no es el papel, sino la capacidad de defender decisiones con datos.
Estoy de acuerdo con el mensaje 3 en que el CLRS no es para leer de principio a fin, pero discrepo en que LeetCode con patrones sea suficiente. LeetCode entrena la resolución de problemas algorítmicos en un vacío, sin restricciones de negocio ni deuda técnica. Lo que realmente marca la diferencia es escribir código que otros mantengan. Y para eso no hay atajo: necesitas code reviews honestas, no solo katas.
Mi propuesta concreta: en lugar de otro CRUD o un rate limiter con Redis, monta un sistema de feature flags con consistencia eventual. Implementa el almacenamiento en Postgres con LISTEN/NOTIFY y un cache en Redis con invalidación por pub/sub. Mide la latencia de propagación bajo carga con wrk2 o k6. Documenta los trade-offs entre consistencia fuerte y disponibilidad. Eso te obliga a entender teoría de colas, particionado y fallos parciales. Y si en el camino necesitas un B-tree, lo estudias porque el problema lo exige, no porque un curso lo diga.
Sobre certificaciones: AWS SA o CKA valen si vas a vender consultoría o si tu cliente las exige. En producto, el badge es ruido. Pero ojo: hay empresas que filtran por título o certificación no por criterio técnico, sino por políticas de RRHH. Si tu objetivo es entrar en una de esas, el peaje es inevitable. Si no, invierte ese tiempo en un proyecto que puedas defender con métricas. La teoría sin aplicación se olvida, pero la aplicación sin teoría se estanca. El equilibrio está en dejar que el proyecto te empuje a la teoría, no al revés.
