Hay algo curioso ocurriendo actualmente en el mercado tecnológico.

Abres LinkedIn, Get on Board, Wellfound o prácticamente cualquier plataforma de empleos y empiezas a encontrar lo mismo:

  • Senior Frontend Developer.
  • Senior Backend Developer.
  • Senior DevOps Engineer.
  • Senior Software Engineer.
  • Senior Full Stack Developer.

Senior. Senior. Senior.

Pareciera que, de repente, todas las empresas necesitan exclusivamente desarrolladores senior. El problema es bastante evidente: no existen tantos seniors como posiciones que quieren llenar las empresas.

Y mientras las compañías compiten por encontrar al candidato con cinco, siete o diez años de experiencia, existe otro grupo intentando descubrir cómo rayos conseguir esos cinco años de experiencia si nadie quiere darle el primero.

Los juniors.

Por eso suelo decir, medio en serio y medio como provocación, que si no encuentras un senior quizás deberías comenzar a mirar con más atención a los buenos juniors. No porque dos juniors mágicamente se conviertan en un senior. La experiencia no funciona así.

Un senior no solamente escribe código. Ha tomado malas decisiones, ha roto cosas, ha visto sistemas crecer, ha mantenido código que escribió otra persona, ha tenido que corregir arquitecturas, investigar problemas de producción y aprender cuándo una solución técnicamente perfecta es una pésima decisión para el negocio. Eso no se sustituye contratando más personas.

Pero también creo que muchas empresas están ignorando algo importante: un buen junior, acompañado correctamente, puede crecer muchísimo más rápido de lo que pensamos.

Y precisamente por eso creo que esta es, al mismo tiempo, la peor y la mejor época para ser junior.

La peor época para entrar

Es difícil ignorar la situación. Muchas posiciones que hace algunos años podían ser junior o mid ahora aparecen publicadas buscando perfiles senior.

Las empresas quieren reducir riesgos. Quieren contratar personas que puedan integrarse rápidamente, trabajar con cierta independencia y comenzar a producir resultados cuanto antes. Desde la perspectiva del negocio tiene sentido. Desde la perspectiva de quien intenta entrar a la industria, puede ser desesperante.

Porque aparece aquella pregunta que probablemente todo desarrollador se hizo alguna vez:

“¿Cómo consigo experiencia si para conseguir un trabajo me piden experiencia?”

Y la respuesta que daría hoy es muy diferente a la que habría dado hace diez años. Porque ya no necesitas esperar a que una empresa te permita comenzar a resolver problemas.

Puedes comenzar ahora.

El software siempre empieza con un problema

Cuando alguien comienza a programar suele cometer un error bastante común: pensar primero en qué tecnología quiere utilizar.

  • “Quiero hacer algo con React.”
  • “Quiero practicar Next.js.”
  • “Quiero aprender Python.”
  • “Quiero hacer una API con NestJS.”

Está bien querer aprender una tecnología, pero los productos reales normalmente no comienzan ahí.

Comienzan con un problema.

Prácticamente todas las empresas existen porque alguien identificó una necesidad que podía satisfacer. Necesitamos agua potable, existen empresas que la producen y distribuyen. Necesitamos alimentos, existen supermercados y sistemas completos de distribución. Necesitamos movernos, aparecieron soluciones de transporte. Necesitamos comunicarnos con personas que pueden estar al otro lado del planeta y hoy tenemos sistemas capaces de hacerlo prácticamente en tiempo real.

Software no es diferente.

Detrás de cada aplicación hay un problema.

Y si eres junior buscando qué construir, probablemente tienes decenas de problemas alrededor esperando una solución. Observa:

  • Tu trabajo.
  • Tu universidad.
  • Tu familia.
  • Un pequeño negocio.
  • La administración de tu casa.
  • Algo que haces repetidamente en Excel.
  • Algo que alguien todavía lleva anotado en una libreta.
  • Una tarea aburrida que podría automatizarse.

Ahí pueden existir mejores proyectos para tu portafolio que otro clon de Netflix.

La pregunta deja de ser:

“¿Qué proyecto puedo hacer?”

Y comienza a ser:

“¿Qué problema puedo resolver?”

Ese pequeño cambio desarrolla algo muchísimo más importante que aprender otro framework:

criterio.

Hoy aprender es completamente diferente

Cuando comencé a programar, alrededor de 2013, 2014 y 2015, aprender era una experiencia bastante diferente. Había cursos, libros, documentación y muchísimo contenido en internet, claro.

Pero cuando algo no funcionaba comenzaba la peregrinación:

  • Stack Overflow.
  • GitHub Issues.
  • Foros.
  • Blogs.
  • Videos.

Una pregunta de hacía seis años que parecía hablar exactamente de tu problema hasta que descubrías que utilizaba otra versión de la librería.

Probabas una solución. No funcionaba. Probabas otra. Rompías otra cosa. Y volvías a investigar.

No digo esto porque aquella época fuera mejor. Tampoco creo que sufrir innecesariamente convierta automáticamente a nadie en mejor desarrollador. Simplemente eran las herramientas que teníamos.

Hoy existe algo que cambia radicalmente la experiencia de aprendizaje de una persona que está comenzando:

la inteligencia artificial.

Ahora puedes tener prácticamente un tutor disponible mientras estudias.

No entendiste closures. Pregúntale.

La explicación sigue siendo demasiado compleja:

“Explícamelo como si acabara de comenzar JavaScript.”

Todavía no lo entiendes:

“Ponme un ejemplo de la vida real.”

Ahora entendiste el ejemplo pero no sabes cómo llevarlo a código:

“Vamos a implementarlo paso por paso.”

Puedes hacer esto con arquitectura, bases de datos, testing, APIs, autenticación, patrones de diseño, Git, Docker, algoritmos o prácticamente cualquier concepto con el que estés trabajando.

Y puedes preguntar veinte veces. Cincuenta. Cien.

Sin sentir que estás retrasando una clase porque los demás ya entendieron.

Ese cambio es enorme.

Pero usar IA no significa dejar que piense por ti

Aquí también existe una trampa.

Tener ChatGPT, Copilot, Claude, Gemini, DeepSeek, Grok o cualquier otra herramienta abierta mientras programas no te convierte automáticamente en mejor desarrollador. De hecho, puedes conseguir exactamente el resultado contrario.

Puedes terminar construyendo aplicaciones enormes que funcionan aparentemente bien y no tener la menor idea de por qué funcionan.

Ese no debería ser el objetivo.

La inteligencia artificial debería acelerar tu aprendizaje, no sustituirlo.

Si genera un código que no entiendes, pregúntale qué está haciendo. Si propone una arquitectura, pregúntale por qué.

Pregúntale:

  • Qué otras alternativas existen.
  • Qué ventajas tiene.
  • Qué problemas puede provocar.
  • Qué dice la documentación oficial.
  • Qué buenas prácticas existen.
  • Qué pasaría si el sistema tuviera cien usuarios.
  • Qué cambiaría con cien mil.
  • Qué partes deberían tener pruebas.
  • Qué problemas de seguridad estás ignorando.

Esa conversación es donde realmente comienza el aprendizaje.

Uno de los hábitos que más recomiendo sigue siendo exactamente el mismo que recomendaba antes de que existiera esta generación de inteligencia artificial:

leer documentación.

La IA puede ayudarte a entenderla. Puede resumirla. Puede ponerte ejemplos. Puede explicarte conceptos que todavía no dominas. Pero deberías acostumbrarte a ir a la fuente y entender cómo funciona aquello que estás utilizando.

Porque escribir código nunca ha sido la parte más difícil de ser desarrollador.

La parte difícil es saber qué código deberías escribir y por qué.

Tu portafolio debería demostrar cómo piensas

Por eso tampoco creo demasiado en un portafolio compuesto solamente por screenshots bonitos. Una aplicación funcionando está bien.

Pero detrás de ella existe algo potencialmente mucho más interesante:

las decisiones que tomaste para construirla.

Supongamos que encontraste un problema y decidiste desarrollar una solución.

Documenta el proceso:

  • ¿Qué problema encontraste?
  • ¿Por qué decidiste solucionarlo?
  • ¿Cuál fue tu primera aproximación?
  • ¿Qué tecnologías elegiste y por qué?
  • ¿Qué salió mal?
  • ¿Qué cambiaste?
  • ¿Qué aprendiste?
  • ¿Qué harías diferente si comenzaras nuevamente?

Incluso puedes escribir sobre ello. Crear un pequeño blog dentro de tu propio portafolio e ir publicando lo que estás aprendiendo.

Imagínate ahora desde la perspectiva de una persona que está evaluando candidatos.

En lugar de recibir solamente un CV diciendo:

“React, JavaScript, Node.js, PostgreSQL.”

Entra a tu website y encuentra tres proyectos reales:

  • Puede ver el código.
  • Puede utilizar las aplicaciones.
  • Puede leer por qué las construiste.
  • Puede ver los problemas que encontraste.
  • Puede entender cómo investigaste.
  • Puede ver cómo evolucionó tu manera de pensar.

Eso comienza a responder muchas preguntas de una entrevista antes de que la entrevista ocurra.

No te cases demasiado temprano con una tecnología

Otro error bastante común cuando estamos comenzando es definirnos completamente por una herramienta.

“Soy desarrollador React.”

Perfecto.

Pero React es una herramienta.

JavaScript también lo es.

  • Python.
  • PHP.
  • Ruby.
  • Java.
  • Angular.
  • Next.js.

Todas son formas diferentes de expresar soluciones.

Por supuesto que debes conocer bien las herramientas con las que trabajas. Cada lenguaje tiene particularidades, ecosistemas, patrones y filosofías que necesitan tiempo para dominarse.

Pero existe algo debajo de todo eso que vale muchísimo más:

la lógica.

Si entiendes qué problema quieres resolver, cómo dividirlo, cómo fluye la información, qué responsabilidades tiene cada parte del sistema y qué resultado esperas obtener, aprender otra sintaxis comienza a ser muchísimo más sencillo.

Ya no partes desde cero.

Partes desde una pregunta diferente:

“Sé lo que quiero construir. ¿Cómo expresa este lenguaje esta solución?”

Ese cambio es enorme.

Por eso un buen junior no debería obsesionarse únicamente con coleccionar tecnologías. Debería obsesionarse con aprender a resolver problemas.

Mueve las manos

Puedes:

  • Ver trescientos cursos.
  • Guardar cuarenta playlists.
  • Comprar doce cursos de Udemy.
  • Leer cien artículos.
  • Preguntarle veinte cosas diferentes a ChatGPT.

Y continuar exactamente donde comenzaste.

Porque llega un momento donde tienes que cerrar el tutorial y construir algo.

Existen iniciativas como los 100 proyectos de JavaScript de Midudev que pueden servir para comenzar practicando con proyectos pequeños. Pero tampoco tienes que limitarte a proyectos que alguien más inventó.

Mira alrededor.

  • Encuentra problemas.
  • Construye cosas.
  • Primero pequeñas.
  • Después un poco más grandes.
  • Rompe código.
  • Arréglalo.
  • Refactorízalo.
  • Escribe tests.
  • Despliégalo.
  • Déjaselo utilizar a alguien.
  • Descubre que el usuario hizo exactamente aquello que estabas seguro de que nadie iba a hacer.
  • Corrígelo.

Eso también es experiencia.

Quizás todavía no sea experiencia laboral.

Pero definitivamente es experiencia desarrollando software.

Y cuando llegue una oportunidad laboral, no vas a presentarte simplemente diciendo:

“Estoy buscando mi primera oportunidad.”

Podrás decir:

“Todavía estoy buscando mi primera oportunidad profesional, pero esto es lo que ya sé construir.”

Hay una diferencia enorme entre ambas cosas.

Entonces, ¿qué hace bueno a un junior?

No creo que sea saberse veinte tecnologías.

Ni resolver LeetCode más rápido.

Ni tener el GitHub lleno de cuadrados verdes.

Ni escribir código sin consultar Google.

Mucho menos escribir código sin inteligencia artificial solamente para demostrar algo.

Para mí, un buen junior es alguien que tiene curiosidad:

  • Que pregunta.
  • Que investiga.
  • Que intenta entender.
  • Que acepta cuando no sabe algo.
  • Que busca documentación.
  • Que prueba.
  • Que rompe cosas y quiere descubrir por qué se rompieron.
  • Que recibe una corrección y la utiliza para mejorar.
  • Que poco a poco desarrolla criterio.

Y, sobre todo, alguien que mueve las manos.

Porque esta puede ser una época complicada para conseguir aquella primera oportunidad. Pero también tienes acceso a herramientas con las que generaciones anteriores de desarrolladores solamente podían soñar:

  • Documentación gratuita.
  • Cursos.
  • Repositorios open source.
  • Comunidades.
  • Proyectos completos.
  • Entornos gratuitos.
  • Cloud.
  • Inteligencia artificial.

Y una cantidad absurda de conocimiento disponible prácticamente al instante.

Por eso sigo pensando que esta es la peor y la mejor época para ser junior.

La peor si estás esperando que alguien aparezca y te dé permiso para comenzar.

La mejor si entiendes que puedes comenzar mucho antes de que llegue esa oportunidad.

Aprende. Investiga. Pregunta. Construye. Documenta. Equivócate. Corrige. Y vuelve a construir.

Porque quizás todavía no puedas colocar “Senior Software Engineer” en tu CV.

Pero puedes empezar desde hoy a desarrollar algo mucho más importante:

la forma de pensar que algún día te va a convertir en uno.