Cómo pasarse a frontend engineering desde otra carrera

Qué es realmente frontend engineering, a efectos de esta pregunta

Frontend engineering significa construir la parte de una aplicación web que se ejecuta en el navegador: la estructura HTML, el CSS que la estiliza, y el JavaScript (normalmente a través de un framework como React, Vue o Angular) que la hace interactiva. Está al lado de backend engineering, no por encima ni por debajo. El trabajo implica arquitectura de componentes, gestión de estado, comportamiento del renderizado en navegadores, accesibilidad, diseño responsivo, y cada vez más cierta familiaridad con herramientas de compilación como Vite o Webpack, control de versiones mediante Git, y colaboración con diseñadores a través de herramientas como Figma. Si la descripción del puesto que buscas no menciona al menos dos de estos aspectos concretos, puede que no sea un puesto frontend en absoluto — compruébalo antes de planificar en torno a ello.

No existe licencia, ni estatus colegiado, ni regulador. Nadie puede inhabilitarte. Eso es una buena y una mala noticia: buena porque no hay guardián con un temario que debas aprobar, mala porque tampoco hay una credencial que haga el trabajo de demostrar competencia por ti. La prueba tiene que venir de otro sitio, y ese es todo el problema del que trata este artículo.

Qué se transfiere, y qué no

Algunos orígenes tienen peso real y específico:

• Desarrolladores backend o full-stack que se pasan a trabajo frontend exclusivamente transfieren casi todo excepto CSS profundo y comportamiento específico del navegador. Esta es la ruta más corta y a menudo ni siquiera es un cambio de carrera — es un cambio de especialización.
• Ingenieros QA y especialistas en automatización de tests a menudo ya conocen el DOM, Selenium o Playwright, y cómo se rompen las interfaces. Lo que les falta es construir componentes desde cero, no testearlos.
• Diseñadores UI/UX que ya trabajan en código (no sólo Figma) a menudo tienen ventaja en CSS y maquetación, y un instinto para aquello a lo que sirve el trabajo frontend — cómo se siente al usarlo. Lo que normalmente les falta es lógica JavaScript y gestión de estado.
• Technical writers, analistas de datos, o científicos que programan en Python aportan pensamiento lógico y a veces scripting básico, pero el entorno del navegador, el DOM, y el modelo asíncrono de JavaScript son territorio desconocido que requiere tiempo real.
• Personas sin formación en programación — profesores, marketers, oficios — aportan habilidades blandas transferibles (atención al detalle, trabajo con stakeholders, disciplina de plazos) pero nada técnico se transfiere directamente. Esta no es una ruta más corta porque tu último trabajo fuera exigente de otras maneras.

Qué no se transfiere, independientemente del origen: familiaridad con las peculiaridades de JavaScript (closures, el event loop, el binding de this), la especificidad CSS y el modelo de caja, cómo renderizan y repintan realmente los navegadores una página, y la memoria muscular de depurar con las herramientas de desarrollo del navegador. Estas requieren horas prácticas. No hay conocimiento de dominio de otro campo que las sustituya, del modo en que, digamos, la experiencia clínica podría sustituir parcialmente algunos requisitos técnicos en informática sanitaria.

La vía de cualificación: no existe una formal, y esa es la parte difícil

Frontend engineering no tiene equivalente a un examen de abogacía, un sello de ingeniero profesional, o una colegiación de enfermería. Un grado en informática ayuda pero no es obligatorio y muchos ingenieros frontend en activo no lo tienen. Lo que existe en su lugar es un conjunto de puntos de prueba alternativos, ninguno de los cuales es suficiente solo:

• Un portfolio de proyectos desplegados y funcionando — no tutoriales seguidos paso a paso, sino cosas que construiste, depuraste, y de las que puedes explicar decisiones. Esta es la señal con más peso, porque es la única que demuestra que puedes hacer el trabajo en lugar de describirlo.
• Un certificado de bootcamp (General Assembly, Le Wagon, y similares) — estos pueden comprimir la curva de aprendizaje, pero el certificado en sí tiene poco peso con empleadores; lo que realmente miran es qué construiste durante y después.
• Contribuciones open-source — un pull request fusionado en un proyecto real es una señal más fuerte que un proyecto personal, porque la revisión de código de alguien más ya ha verificado tu trabajo.
• Actividad en GitHub y calidad del código — cada vez más comprobado directamente por quien filtra la candidatura, así que un perfil vacío o abandonado cuenta activamente en tu contra.

Hay una cuestión genuinamente disputada aquí que vale la pena nombrar claramente: ¿produce la velocidad de un bootcamp (típicamente unos pocos meses, a tiempo completo) candidatos comparables a autodidactas que tardan uno o dos años? Los empleadores discrepan, y no hay datos independientes, ciegos a empleadores, que lo resuelvan. Lo que no se disputa es que ninguna ruta reemplaza haber construido cosas que funcionan.

Qué tiene que superar la candidatura de alguien que cambia de carrera

La candidatura de alguien que se pasa a frontend engineering enfrenta un problema específico, estructural: el formato de CV que te contrató en tu último campo está trabajando contra ti aquí. Quien filtra candidaturas frontend — a menudo otro ingeniero o un engineering manager, a veces ayudado por filtrado de palabras clave — busca señales como nombres de frameworks, enlaces a GitHub, y descripciones específicas de proyectos en las primeras líneas. Un CV que empieza con un título de trabajo y empleador de un campo no relacionado, con un enlace a portfolio enterrado al final, se lee (si se lee) con la suposición ya medio formada de que no estás cualificado.

Tres cosas que la candidatura tiene que hacer y que la de un candidato del mismo campo no:

1. Demostrar que puedes programar, no sólo que has estudiado programación. Esto significa un enlace funcional y desplegado (no una captura de pantalla) a algo construido con las tecnologías del anuncio de trabajo, colocado cerca del principio, no en la última línea del CV.
2. Explicar el cambio directamente, brevemente, una vez. No a la defensiva, no extensamente. Una línea sobre el porqué, luego pasar a la evidencia. Los empleadores que filtran candidaturas de cambio de carrera están acostumbrados a leer un párrafo de justificación antes de que aparezca habilidad real — cortar eso es en sí una señal de preparación.
3. Coincidir con el stack nombrado en el anuncio, no uno genérico. Si el puesto es React y TypeScript, un portfolio construido enteramente en JavaScript vanilla o jQuery no se transfiere del modo en que un cambiador de carrera a menudo asume. La contratación frontend es inusualmente específica de stack comparada con muchos puestos técnicos, porque los frameworks son genuinamente diferentes como para importar para el tiempo de onboarding.

Las candidaturas que llegan más lejos son las que se leen como si estuvieran escritas por alguien que ya hace el trabajo, no alguien pidiendo que le dejen entrar a intentarlo.

Cuánto tarda realmente

No existe cifra publicada fiable de tiempo hasta contratación específica para quienes cambian de carrera a puestos frontend, y sé escéptico de quien cite una con precisión — el rango depende enormemente del punto de partida y el esfuerzo, y nadie lo rastrea de manera que produzca una media fiable. Lo que puede decirse honestamente:

• Ir de ninguna formación en programación a un portfolio suficientemente fuerte para candidatearse creíblemente se describe comúnmente, a través de las páginas de resultados de proveedores de bootcamps (autoreportadas, así que trátalas con cautela), como seis meses a dos años de práctica consistente, casi diaria — no dos tardes por semana.
• Ir desde un puesto adyacente (QA, backend, diseño-con-código) es más rápido porque la curva de aprendizaje de JavaScript y herramientas es más corta — a menudo cuestión de meses de trabajo enfocado en lugar de años.
• La búsqueda de empleo en sí, una vez existe el portfolio, típicamente tarda más de lo que esperan quienes cambian de carrera, porque compites contra candidatos con historial de empleo reciente directamente relevante, no sólo habilidad similar.

Si esperas una ruta medida en semanas sin exposición previa a programación, esa ruta no existe. Este no es un campo donde un curso corto sustituya profundidad, porque el proceso de entrevista (un ejercicio de código en vivo o para llevar a casa es estándar para puestos frontend en la mayoría de empresas que contratan en serio) testea la profundidad directamente.

Qué hacer a continuación

Elige un framework que coincida con lo que tus puestos objetivo realmente anuncian — comprueba tres o cuatro anuncios del puesto que quieres y usa el nombre que aparezca más. Construye un proyecto real y desplegado en él, no un clon de tutorial, y pon el enlace en la parte superior de tu CV, por encima de tu historial laboral. Escribe la explicación de una línea de tu cambio de carrera y luego deja de explicar. Si candidateas ampliamente y no recibes respuestas, eso a menudo es el problema de formato de CV descrito arriba en lugar de un problema de habilidades — comprueba si las primeras líneas de tu candidatura tendrían sentido para alguien que nunca ha oído hablar de tu último trabajo. jobmarket.pro lee cada anuncio completo y prepara la candidatura desde tu perfil real, ajustada a lo que ese listado específico pide, si conseguir el formato y el ajuste correcto es la parte que te está estancando.