Buscar trabajo como desarrollador en 2026 es un trabajo en sí mismo

Pensé que lo difícil sería aprender a programar

Cuando empecé a tomar el desarrollo web en serio, la dificultad parecía bastante clara. Había que entender HTML y CSS más allá de copiar ejemplos, aprender JavaScript, acostumbrarse a los errores, descubrir por qué algo funcionaba en una pantalla y se rompía en otra, y aceptar que cada respuesta abría tres preguntas nuevas. Era mucho, pero al menos el trabajo tenía una relación directa con el resultado: estudiaba, practicaba y podía ver una interfaz mejor que la anterior.

Durante un tiempo asumí que, si lograba construir cosas reales y resolver problemas sin depender de una receta, llegaría el momento de mostrarlo y conversar con alguien. No esperaba que fuera automático. Sí esperaba que la parte central siguiera siendo demostrar que podía hacer el trabajo.

Buscar una oportunidad en 2026 me ha obligado a ajustar esa idea. Saber programar sigue siendo indispensable, pero ya no se siente como toda la prueba. Antes de que exista una conversación, también hay que demostrar que puedo presentar lo que sé, explicar cómo pienso, navegar requisitos muy distintos y convertir meses de aprendizaje en señales que alguien pueda revisar con rapidez.

Abrir una vacante cambia la escala del problema

Una descripción de puesto puede empezar con una tecnología que conozco y, pocas líneas después, acumular frameworks, nube, pruebas, bases de datos, automatización, diseño de sistemas, metodologías, inglés y experiencia en producción. Algunas listas describen un equipo entero mejor que a una sola persona. Otras son razonables, pero usan el mismo espacio para lo esencial, lo deseable y lo que quizá aparecerá una vez al año.

No creo que todas las empresas publiquen vacantes de la misma forma ni que cada requisito sea una barrera rígida. También entiendo que una descripción intenta cubrir necesidades reales y reducir incertidumbre. Mi experiencia al leerlas, sin embargo, es que separar “puedo aportar aquí” de “todavía necesito aprender esto” se vuelve otra habilidad. Aplicar exige criterio, no solo coincidencia de palabras.

La palabra “junior” tampoco resuelve la ambigüedad. A veces aparece junto a expectativas de experiencia sustancial en productos reales, decisiones técnicas y autonomía. Eso no vuelve ilegítima la vacante, pero sí hace difícil saber cuándo el potencial cuenta y cuándo la experiencia previa es, en la práctica, el filtro principal.

Un proyecto ya no habla por sí solo

Tener proyectos ayuda, pero una captura y una lista de tecnologías dicen poco sobre el trabajo que hubo detrás. ¿Qué problema intentaba resolver? ¿Qué decisión fue propia? ¿Qué restricción cambió el diseño? ¿Qué falló? ¿Cómo se validó? ¿Qué parte volvería a hacer de otra manera? Si no puedo responder, el proyecto puede verse terminado sin demostrar demasiado.

Eso me parece una exigencia saludable. Escribir código es solo una parte del desarrollo. Entender arquitectura, accesibilidad, rendimiento, degradación progresiva y mantenimiento importa precisamente cuando algo deja de ser un ejercicio aislado. El problema aparece cuando preparar la explicación consume tanto tiempo que el proyecto empieza a existir para la presentación y no para el aprendizaje.

Este portfolio se convirtió en una respuesta a esa tensión. No quería una galería que dijera “sé usar estas herramientas”. Quería dejar evidencia de decisiones: por qué una ruta conserva contenido sin JavaScript, cómo una animación devuelve el estado estable a CSS, por qué un proyecto confidencial no necesita una interfaz falsa para parecer real. La explicación también es trabajo, pero intento que nazca de lo que construí y no de una historia añadida después.

La búsqueda tiene su propio backlog

El currículum necesita una versión clara. LinkedIn pide otra forma de contar lo mismo. Cada plataforma vuelve a solicitar datos que ya están en el CV. Algunas aplicaciones requieren una carta; otras, respuestas específicas; otras, crear una cuenta para completar un formulario. Luego está el registro personal: qué vacante era, cuándo apliqué, qué versión envié y qué necesito preparar si existe una siguiente etapa.

Ninguna de esas tareas es absurda por separado. Juntas forman una carga de trabajo real. Hay que leer con atención, adaptar sin inventar, revisar enlaces, evitar errores y decidir cuánto tiempo merece cada oportunidad. En días malos, la búsqueda produce muchas acciones y poca sensación de avance, porque el resultado depende de decisiones que ocurren fuera de mi pantalla.

A eso se suman las pruebas técnicas y la preparación para entrevistas. Conviene repasar fundamentos, practicar cómo explicar una decisión y estar listo para resolver algo bajo tiempo. También conviene no convertir cada posible entrevista en semanas de preparación anticipada. Encontrar ese límite sigue siendo difícil para mí.

Demostrar antes de conversar

La sensación más extraña es que una parte importante de la evaluación ocurre antes de que alguien decida hablar conmigo. El CV debe pasar una lectura rápida. El perfil tiene que ser coherente. Los proyectos deben cargar, explicar su alcance y mostrar criterio. La aplicación necesita responder a la vacante sin sonar fabricada. Todo eso intenta contestar una pregunta que todavía nadie me ha hecho directamente: ¿puede esta persona aportar aquí?

No lo digo como una acusación. Revisar candidatos cuesta tiempo y las empresas necesitan filtros. Desde mi lado, el efecto es claro: cada evidencia debe funcionar sin contexto adicional. Eso favorece resultados fáciles de escanear, pero el desarrollo real suele estar lleno de matices. Una decisión correcta puede verse menos espectacular que una demo; una restricción bien manejada puede ser invisible; una solución mantenible puede necesitar más explicación que una lista de librerías.

Aprender a comunicar esas cosas también forma parte del oficio. Solo intento no confundir comunicación con espectáculo. No quiero prometer una seguridad que todavía estoy construyendo ni disfrazar trabajo de laboratorio como experiencia de cliente.

La IA acelera la producción, no reemplaza la responsabilidad

La IA ya forma parte de mi flujo. Puede ayudarme a investigar una API, comparar enfoques, producir un primer prototipo, encontrar una hipótesis de error o revisar si omití un caso. También puede explicar un concepto de otra manera cuando la documentación todavía no termina de encajar. Bien usada, reduce fricción y permite explorar más.

Pero producir más rápido cambia la pregunta. Si puedo generar una función, una interfaz o una explicación en minutos, importa todavía más saber si encaja con el sistema. Tengo que reconocer supuestos incorrectos, buscar defectos, revisar accesibilidad, probar estados de fallo y entender qué código estoy aceptando. Cuando el resultado rompe algo, no puedo delegar la responsabilidad a la herramienta.

Eso también afecta cómo intento mostrar mi trabajo. No tiene sentido fingir que desarrollo sin asistencia, pero tampoco basta decir que sé usar IA. Lo importante es qué decisiones conservo, qué rechazo, cómo verifico el resultado y si puedo explicarlo sin esconderme detrás del prompt. La velocidad es útil. El criterio y la propiedad sobre el resultado siguen siendo míos.

El peligro de convertirse en candidato en vez de desarrollador

Este es el conflicto que más me preocupa. Es fácil llenar la semana con tareas que parecen productivas: ajustar el CV, reescribir el titular de LinkedIn, buscar vacantes, completar formularios, adaptar cartas, practicar respuestas y prepararse para pruebas. Todo tiene una justificación. Al final de la semana, sin embargo, puedo descubrir que no construí nada, no depuré nada difícil y no aprendí una idea que pudiera aplicar.

Entonces aparece un ciclo incómodo. Para ser mejor candidato necesito mejores proyectos y mejor criterio. Para presentar esos proyectos necesito dedicar tiempo a ser candidato. Cuanto más incierta se siente la búsqueda, más fácil es optimizar la presentación. Y cuanto más optimizo la presentación, menos tiempo queda para la actividad que originalmente quería presentar: desarrollar.

No he resuelto esa tensión con una fórmula. Intento proteger bloques de trabajo para construir, incluso cuando aplicar parece más urgente. A veces significa mejorar una interacción existente en lugar de iniciar otro proyecto. Otras veces significa documentar una decisión, corregir un fallo de ciclo de vida o eliminar código muerto con evidencia. Son avances menos visibles que enviar una aplicación, pero mantienen vivo el oficio.

Construir cosas reales mientras busco

“Proyecto real” no tiene que significar una plataforma enorme ni una marca conocida. Para mí significa que hay restricciones, usuarios posibles, contenido que no puedo inventar y consecuencias si tomo una mala decisión. Puede ser un trabajo profesional cuya información debe permanecer confidencial, una herramienta pequeña, un experimento que reconoce sus límites o este mismo portfolio funcionando como sistema público.

Seguir construyendo me da algo que la búsqueda no siempre ofrece: retroalimentación directa. Si un enlace está roto, puedo encontrarlo. Si el diseño desborda en móvil, puedo medirlo. Si una animación deja estado inline después de ser cancelada, puedo definir quién debe poseer el estado final. El problema no desaparece porque yo lo describa bien; tengo que resolverlo.

También evita que cada proyecto se convierta en una actuación para reclutamiento. Quiero que lo que muestro sea útil como evidencia, pero primero debe ser útil para aprender y mejorar. Una interfaz hecha solo para parecer compleja enseña menos que un sistema sencillo cuyos fallos tuve que entender.

La disciplina de explicar sin inflar

Buscar trabajo empuja a usar palabras grandes: impacto, arquitectura, liderazgo, escalabilidad. Algunas corresponden al trabajo; otras pueden hacer que una experiencia pequeña parezca algo que no fue. Me interesa aprender a describir alcance sin reducirlo, pero también sin convertir cada decisión en una transformación empresarial.

Puedo decir que construí un portfolio multipágina bilingüe, que definí contratos de mejora progresiva y que probé rutas con automatización de navegador. No necesito afirmar que diseñé una plataforma global. Puedo hablar de un proyecto profesional reservado sin publicar detalles privados. Puedo mostrar laboratorios técnicos como laboratorios, no como clientes.

La honestidad quizá no produce la frase más impresionante, pero hace posible una conversación técnica real. Si alguien pregunta por una decisión, quiero poder recorrer el código, explicar el contexto y reconocer dónde termina mi experiencia.

El portfolio también se volvió trabajo

Hay una ironía evidente: construí el portfolio para buscar trabajo y luego el portfolio se convirtió en otro trabajo. Necesita contenido, arquitectura, accesibilidad, revisión visual, metadatos, rutas equivalentes, pruebas y mantenimiento. Puede absorber tiempo indefinidamente si lo uso para evitar la incomodidad de aplicar.

Estas Engineering Notes cumplen una función parecida. No son documentación exhaustiva ni una estrategia de contenido. Son pausas para registrar qué aprendí, qué tensión apareció y por qué tomé una decisión. Si una nota me obliga a entender mejor lo que hice, también mejora la evidencia.

Lo que sí puedo controlar

No sé qué aplicación se convertirá en una conversación ni qué conversación se convertirá en una oportunidad. Tampoco sé si la persona correcta llegará por una vacante, un proyecto compartido, una recomendación o una ruta que todavía no estoy mirando. Fingir certeza no haría la búsqueda más corta.

Lo que sí puedo controlar es seguir desarrollando criterio, construir cosas que sobrevivan a una revisión técnica y presentar la experiencia que realmente tengo. Puedo cuidar el tiempo para que aplicar no reemplace aprender. Puedo usar IA para avanzar más rápido sin entregar la decisión final. Puedo aceptar que buscar trabajo es trabajo y, al mismo tiempo, impedir que ocupe todo el espacio.

Este portfolio, los proyectos y estas notas forman parte de ese proceso. No garantizan la oportunidad. Dejan un rastro verificable de cómo pienso, qué construyo y qué hago cuando algo no funciona. Mientras todavía no sé cuál será la aplicación correcta, ese es el tipo de evidencia que puedo seguir haciendo mejor.