Salario de Desarrollador·a Frontend
En España, el salario mediano de un puesto de Desarrollador·a Frontend es de 45.000 € brutos al año; la mitad central de los salarios está entre 35.000 € y 58.000 €.
De un vistazo
- Salario mediano45.000 €
- Plazo de contratación45–75 días
- Experiencia3–6 años
Salario de Desarrollador·a Frontend en España
Salario fijo bruto anual
- Percentil 25
- 35.000 €
- Mediana
- 45.000 €
- Percentil 75
- 58.000 €
| Nivel | Percentil 25 | Mediana | Percentil 75 |
|---|---|---|---|
| Junior | 23.000 € | 27.000 € | 32.000 € |
| Intermedio | 35.000 € | 45.000 € | 58.000 € |
| Senior | 48.000 € | 60.000 € | 75.000 € |
Para referencia: el Salario Mínimo Interprofesional (SMI) en España es de 1.221 € brutos al mes en 14 pagas desde el 1 de enero de 2026. (BOE-A-2026-3815: Real Decreto 126/2026, de 18 de febrero, por el que se fija el salario mínimo interprofesional para 2026)
Salario bruto anual de referencia para un·a Desarrollador·a Frontend de nivel intermedio (3 a 6 años de experiencia profesional) en pyme española. Madrid y Barcelona en entorno SaaS o scale-up tiran hacia arriba (52-70 k€); resto del territorio y sectores tradicionales tiran hacia abajo (30-40 k€). Stack moderno (React o Vue, TypeScript, Vite, tests automatizados, accesibilidad real) tira hacia arriba; stack legacy (jQuery, Angular 1, plantillas server-rendered sin componentes) tira hacia abajo. Los puestos frontend en España rara vez incluyen retribución variable estructural; algunas scale-ups ofrecen phantom shares o stock options.
Fuentes: INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software); InfoJobs, Estado del Mercado Laboral en España 2025; Manfred, Informe del Mercado Tech 2025
Cómo contratar a un·a Desarrollador·a Frontend para su pyme
Antes de redactar la oferta, plantéate tres preguntas de encuadre. Determinan qué perfil busca realmente y evitan los errores frecuentes en pyme tech española.
Pregunta 1: ¿Frontend Developer o UI Engineer? El·la Frontend Developer cubre la capa cliente de extremo a extremo: componentes, gestión del estado, integración con APIs, accesibilidad, rendimiento, tests. El·la UI Engineer se orienta más a la integración visual fina y al design system (próxima al diseño, menos a la arquitectura aplicativa). En pyme tech de menos de 10 personas desarrolladoras, Frontend Developer es casi siempre la opción correcta: el volumen de aplicación rara vez justifica la especialización pura. Si duda, opte por Frontend Developer con una orientación ligera (más bien arquitectura o más bien diseño) según la necesidad del momento.
Pregunta 2: ¿Stack-Fit o seniority? Un·a persona desarrolladora con experiencia sólida en React y TypeScript no se vuelve productiva de inmediato en Vue 3 con JavaScript o en Angular reciente; necesita 2-4 semanas de adaptación. Para un perfil mid-level pesa más la fit de stack que la seniority absoluta. Sé explícito·a con tu stack en la oferta (framework, gestión de estado, herramientas de build, design system); eso ya filtra perfiles mal encajados. Si tu stack se considera legacy (jQuery, Angular 1, plantillas server-rendered sin componentes), asúmelo y busca perfiles a los que les guste modernizar codebases en lugar de atraer perfiles decepcionados tras la incorporación.
Pregunta 3: ¿Qué nivel de exigencia tendrá en accesibilidad y rendimiento? Si tu producto se vende a empresas grandes, al sector público o a clientes europeos, la accesibilidad pasa de buena práctica a requisito (European Accessibility Act). Si tu producto vive del SEO o de un volumen masivo de tráfico móvil, el rendimiento web es un eje de negocio. En ambos casos, el perfil frontend ideal cambia: busca experiencia explícita en WCAG AA, en Web Vitals y en automatización (axe en CI, Lighthouse en cada PR). Si tu producto es interno o tras login, el listón es menos exigente, pero conviene explicitarlo desde la oferta para alinear expectativas.
Si las tres respuestas convergen hacia un·a Desarrollador·a Frontend a jornada completa (y no un·a UI Engineer o un·a Full-stack), consulta el modelo listo para usar en la sección Descripción del puesto, más abajo.
Plantilla de descripción del puesto de Desarrollador·a Frontend
[Nombre de empresa], pyme B2B del sector [sector] con sede en [ciudad], [X] personas en plantilla y [X] M€ de facturación, busca incorporar un·a Desarrollador·a Frontend al equipo técnico de [X] personas.
Misión
Diseñar, desarrollar y mantener la capa cliente del producto: componentes, integración con APIs, gestión del estado, accesibilidad, rendimiento percibido y tests. La persona trabaja en estrecha colaboración con producto, diseño y backend, y reporta a la [Tech Lead / CTO / Dirección Técnica].
Responsabilidades
- Entregar componentes y flujos de principio a fin: comprensión de la necesidad de producto, lectura del diseño con la persona Product Designer, implementación, tests, accesibilidad WCAG AA, despliegue y seguimiento en producción.
- Mantener la calidad de la capa cliente: revisión de las PRs de las personas compañeras, aplicación de convenciones, refactor al paso cuando proceda.
- Contribuir al design system: documentar nuevos patrones, proponer componentes cuando aparezca uso recurrente, mantener coherencia entre pantallas.
- Cuidar el rendimiento web: Web Vitals (LCP, INP, CLS), bundle, lazy loading, optimización de imágenes y de fuentes.
- Garantizar la accesibilidad básica en cada entrega (contraste, foco visible, jerarquía semántica, microcopy de errores) y participar en auditorías recurrentes.
- Contribuir a la resolución de incidentes en producción que afecten a la capa cliente (regresiones visuales, errores de hidratación, bugs específicos de navegador).
- Documentar las decisiones técnicas importantes y las zonas de complejidad no trivial.
Perfil
- Imprescindible: [3 a 6] años de experiencia profesional en desarrollo frontend; dominio sólido de al menos un framework moderno (React, Vue o equivalente) con TypeScript; experiencia de puesta en producción (despliegue, monitoring, gestión de incidentes); sensibilidad accesible (WCAG AA) y de rendimiento (Web Vitals).
- Valorable: familiaridad con nuestra stack [React, TypeScript, Vite o Next, design system propio]; experiencia en pyme o startup (alta autonomía); contribuciones a open source o side projects públicos; experiencia con tests automatizados (Vitest, Testing Library, Playwright).
- Excluyente: ninguna experiencia de puesta en producción en autonomía; rechazo a hacerse cargo de la accesibilidad o del rendimiento; rechazo sistemático de frameworks modernos.
Qué ofrecemos
- Retribución bruta anual: fijo [35-58] mil euros según experiencia. Sin variable estructural; eventualmente phantom shares o stock options según la fase de la sociedad.
- Modalidad: [jornada completa, híbrido 2-3 días por semana en oficina, base en [ciudad] / remote-friendly].
- Beneficios: [seguro médico, ticket restaurante, cheque transporte, días adicionales de vacaciones, política de teletrabajo, presupuesto de material, presupuesto de formación y conferencias].
- Stack: [a completar: framework frontend, TypeScript, gestión de estado, herramientas de build, design system, testing, CI/CD, monitoring].
¿Buscas a alguien para este puesto? Job Studio convierte la plantilla en una oferta lista para publicar, con banda salarial sugerida y formulario de candidatura.
Preguntas de entrevista para Desarrollador·a Frontend
15 preguntas estructuradas, agrupadas por tipo. Cada una indica la competencia que evalúa; despliégala para ver qué revela una buena respuesta.
Conductual 3
Describe el componente o flujo más complejo que diseñaste y construiste en tu último puesto. ¿Por qué era complejo y cómo lo abordaste?
Decisión técnicaLo que revela una buena respuesta
Capacidad de estructurar una decisión bajo incertidumbre: identificación de restricciones (rendimiento, accesibilidad, mantenibilidad), exploración de alternativas, validación con personas usuarias o con datos, documentación posterior. Bonus: la persona candidata menciona haber cambiado de opinión durante el proceso o haber refactorizado tras el primer release. Quienes describen un componente trivial con perspectiva grandilocuente revelan que nunca llegaron a enfrentarse a un caso realmente complejo.
Cuéntame un bug de frontend en producción que resolviste. ¿Cuál era el síntoma, cómo lo diagnosticaste y cuánto tiempo te llevó?
Depuración e investigaciónLo que revela una buena respuesta
Método de depuración estructurado: reproducción, DevTools (Network, Performance, React Profiler), bisección por commits o feature flags, hipótesis validadas con experimentos. Honestidad sobre la duración (un bug real de frontend rara vez se cierra en menos de 30 minutos cuando depende del estado, del cache del navegador o de una race condition). Bonus: la persona cita la causa raíz y el correctivo sistémico, no solo el hotfix.
Describe un momento en el que tuviste que refactorizar o reescribir un componente que tú mismo·a habías escrito unos meses antes. ¿Qué había pasado entre medias?
Aprendizaje y humildadLo que revela una buena respuesta
Humildad técnica y capacidad de aprender. Bonus: la persona identifica lo que habría hecho diferente desde el principio (separación de presentación y lógica, mejor tipado, abstracción más temprana o más tardía). Quienes afirman no haber tenido nunca que refactorizar su propio código mienten o no han mantenido código en producción durante el tiempo suficiente.
Situacional 3
Descubres en una code review un problema de accesibilidad serio (falta de foco visible, contraste insuficiente, jerarquía semántica rota) en una PR de un·a colega senior. ¿Cómo reaccionas?
Coraje técnicoLo que revela una buena respuesta
Capacidad de señalar una debilidad técnica sin bloquear: comentario factual en la PR (aquí está el problema concreto con referencia a WCAG, aquí está mi propuesta de corrección), propuesta de solución, escalado al tech lead si la PR se mergea pese al comentario. Quienes lo dejan pasar porque la otra persona es senior muestran falta de coraje técnico, especialmente grave en frontend donde la accesibilidad se degrada por acumulación de pequeñas concesiones.
Una persona Product Manager te pide una funcionalidad que según tu estimación lleva 3 semanas. La persona PM la quiere en 1 semana. ¿Cómo reaccionas?
Comunicación con productoLo que revela una buena respuesta
Clarificación de la necesidad antes de negociar el plazo (quizá el flujo se pueda partir en dos fases o simplificarse). Propuesta de opciones: MVP en 1 semana con accesibilidad y tests básicos, V2 en 2 semanas; recorte explícito de alcance; o aplazamiento si la calidad de frontend (accesibilidad, rendimiento, estados de error) no puede comprimirse sin generar deuda. Las respuestas tipo lo hago en 1 semana si trabajo el fin de semana son una bandera roja.
Te incorporas a una codebase frontend con deuda importante: componentes de 800 líneas, props drilling de 6 niveles, sin tests, sin design system, accesibilidad nula. ¿Cuál es tu plan a 30 días?
Pragmatismo y priorizaciónLo que revela una buena respuesta
Diagnóstico primero: no intentar arreglarlo todo a la vez. Priorización por riesgo e impacto (típicamente: cubrir con tests las zonas críticas, extraer hooks o lógica compartida antes que reescribir componentes enteros, abordar accesibilidad bloqueante en flujos clave). Validación con el equipo y la persona tech lead antes de avanzar. Quienes se lanzan a la reescritura completa muestran falta de pragmatismo.
Caso práctico 3
Diseño: queremos añadir a nuestra aplicación un sistema de notificaciones in-app con badge, panel desplegable y persistencia de leídas y no leídas. ¿Cómo lo diseñas en frontend?
Diseño de interacción frontendLo que revela una buena respuesta
Aclaraciones antes de proponer (volumen esperado, criticidad por tipo, persistencia tras recarga, sincronización entre pestañas, accesibilidad de lector de pantalla). Arquitectura coherente: gestión del estado (Context, Zustand, Redux según escala), polling frente a WebSocket frente a Server-Sent Events, optimistic update sobre leídas y no leídas, anuncio de notificaciones nuevas a tecnologías asistivas. Bonus: reconoce zonas de incertidumbre (haría un POC sobre la sincronización entre pestañas).
Rendimiento: tu aplicación tarda 6 segundos en pintar la primera pantalla útil. Tienes 1 semana para bajarla por debajo de 2 segundos. ¿Plan de acción?
Rendimiento webLo que revela una buena respuesta
Medir antes de optimizar: Lighthouse, Web Vitals (LCP, INP, CLS), waterfall de Network, bundle analyzer. Identificar el cuello de botella (bundle JS enorme, recursos sin lazy loading, render bloqueante, llamadas API en cascada). Priorizar por esfuerzo e impacto (code splitting, defer de scripts no críticos, precarga de fuentes críticas, imágenes responsive con formatos modernos). Las respuestas tipo añado lazy loading sin diagnóstico revelan optimización prematura.
Accesibilidad: la auditoría WCAG revela 60 issues en tu aplicación, repartidos entre nivel A y AA. Tienes un trimestre para llevarla a cumplimiento AA razonable. ¿Plan de acción?
AccesibilidadLo que revela una buena respuesta
Priorización por impacto y por origen: (1) issues bloqueantes para personas usuarias con discapacidad (contraste insuficiente, foco invisible, errores de formulario no anunciados), (2) issues sistémicos en componentes compartidos que se solucionan una vez y propagan a todo el producto, (3) issues puntuales en pantallas críticas (alta, pago, configuración). Bonus: la persona reconoce que la accesibilidad no se arregla una vez y propone un proceso recurrente (checklist en code review, tests automatizados con axe, audit por iteración).
Técnica 3
Explica la diferencia entre Server-Side Rendering, Static Site Generation, Incremental Static Regeneration y client-only. ¿Cuándo elegirías cada uno y por qué?
Fundamentos frontendLo que revela una buena respuesta
Comprensión clara de cada modelo y de su impacto en rendimiento, SEO y complejidad operativa. SSR: cada petición se renderiza en el servidor (bueno para contenido personalizado o muy dinámico, peor coste y latencia). SSG: páginas pregeneradas en build (óptimo para contenido estable). ISR: regeneración bajo demanda (compromiso entre ambos). Client-only: para apps internas o tras login sin necesidades SEO. Bonus: la persona menciona el coste real de la hidratación, los Web Vitals y la trampa del all-in en SSR sin medir.
¿Cuál es tu enfoque del testing en frontend? Describe tu último proyecto: cuántos tests, qué tipos (unitarios, componente, integración, end-to-end), qué cobertura y qué mide realmente.
Calidad del códigoLo que revela una buena respuesta
Comprensión de la pirámide adaptada a frontend (muchos tests unitarios y de componente, menos de integración, algunos end-to-end sobre flujos críticos). Conocimiento de herramientas (Vitest o Jest, Testing Library, Playwright o Cypress). Distinción entre cobertura y utilidad (90 por ciento de cobertura sobre snapshots vale menos que 60 por ciento sobre la lógica de negocio crítica). Bonus: la persona cita una vez en que un test evitó una regresión real en accesibilidad o en un flujo crítico.
Llegas a una codebase React mal organizada: componentes de 500 líneas, props drilling, lógica de negocio mezclada con presentación, sin tipado estricto. Plan a 60 días sin romper nada.
Pragmatismo y priorizaciónLo que revela una buena respuesta
Enfoque progresivo: (1) mapear componentes críticos y patrones recurrentes, (2) extraer hooks y lógica de negocio primero (impacto alto, riesgo bajo), (3) trocear componentes grandes por frontera de negocio (no por capricho técnico), (4) introducir gestión de estado solo donde el props drilling duela de verdad (Context o Zustand en pyme, Redux solo a partir de cierto volumen), (5) endurecer TypeScript por zonas, no de golpe. Quienes quieren migrar a Server Components desde el día 1 carecen de pragmatismo.
Valores 3
¿Cómo recibes una code review crítica sobre código del que estabas convencido·a de haber hecho bien?
CoachabilityLo que revela una buena respuesta
Apertura: capacidad de separar el código del ego personal. Bonus: la persona candidata cita una vez en que cambió de opinión gracias a una review. Quienes describen haber explicado su lógica a la persona reviewer en lugar de escucharla muestran una debilidad de coachability crítica para el trabajo en equipo en pyme.
¿Qué papel juegas en la transmisión técnica a perfiles junior o a las nuevas incorporaciones en frontend?
Mentoría y transmisiónLo que revela una buena respuesta
Postura activa de mentoría: pair programming, reviews pedagógicas (no solo aprobar y mergear), documentación de patrones, transmisión de buenas prácticas en accesibilidad y rendimiento. Quienes responden ayudo cuando me piden sin más concreción muestran una postura pasiva. En pyme con equipo frontend reducido, la capacidad de transmisión es clave para la sostenibilidad.
¿Cómo trabajas con un·a Product Designer? Describe una situación en la que devolviste un diseño con cuestionamientos.
Juego en equipo con diseñoLo que revela una buena respuesta
Postura de partenariado: cuestionamiento constructivo basado en viabilidad, rendimiento, accesibilidad o complejidad, propuesta de alternativas. Bonus: la persona cita un caso en el que aceptó el diseño inicial tras conversarlo (no está en oposición sistemática). Quienes describen a personas diseñadoras como gente que no entiende la técnica revelan debilidad de juego en equipo.
Salario y contratación por nivel
El mismo puesto en cada nivel: cuánto se paga, cuánta experiencia cabe esperar y cuánto suele durar la búsqueda.
Desarrollador·a Frontend Junior
- Salario fijo bruto anual
- 27.000 €23.000 € – 32.000 €
- Experiencia
- 0–2 años
- Plazo de contratación
- 30–55 días
Desarrollador·a Frontend (Intermedio)
- Salario fijo bruto anual
- 45.000 €35.000 € – 58.000 €
- Experiencia
- 3–6 años
- Plazo de contratación
- 45–75 días
Desarrollador·a Frontend Senior
- Salario fijo bruto anual
- 60.000 €48.000 € – 75.000 €
- Experiencia
- 7–12 años
- Plazo de contratación
- 55–90 días
Salario de Desarrollador·a Frontend por país
El mismo puesto y el mismo nivel en cada país que cubrimos, con cifras de fuentes del propio país.
| País | Mínimo | Valor central | Máximo |
|---|---|---|---|
| EspañaEsta página | 35.000 € | 45.000 € | 58.000 € |
| AlemaniaDeutsch | 48.000 € | 58.000 € | 72.000 € |
| FranciaFrançais | 42.000 € | 52.000 € | 65.000 € |
| Países BajosNederlands | 44.388 € | 51.864 € | 59.352 € |
| ItaliaItalianoItalia · sondaggio Crebs · Front-end Developer Mid-weight, anni non indicati | 32.000 € | — | 42.000 € |
Fuentes
- Alemania (consultado en mayo de 2026): Stepstone Gehaltsdaten Frontend-Entwickler:in Deutschland 2026 · Stepstone Gehaltsreport 2026 · Honeypot State of Software Engineering Germany 2025 · Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe
- Francia (consultado en mayo de 2026): APEC, Baromètre 2025 de la rémunération des cadres tech · Talent.io, Étude rémunération tech France 2025 · Welcome to the Jungle, Salaires développeur·euse Front-end France
- Países Bajos (consultado en agosto de 2026): Nationale Vacaturebank — salaris Front-end developer in Nederland
- Italia (consultado en octubre de 2026): Crebs, Guida Stipendi 2026: Media stipendi Front-end Developer in Italia (livelli Junior, Mid-weight e Senior; metodo del sondaggio) · Hays Italia Salary Guide 2026, Technology, Digital & New Media — Software Development, p. 70 (PDF Hays ospitato da QualEnergia; solo confronto) · Hays Italia Salary Guide 2026 (pagina ufficiale dell’edizione)
Dónde captar este perfil
LinkedIn
Recruiter Lite desde 170 € al mes; 200-400 € al mes adicionales para Job SlotsCanal principal para perfiles frontend en España, sobre todo en Madrid y Barcelona. El sourcing activo (Recruiter Lite con InMails que mencionen un componente publicado, una charla o una contribución pública) es bastante más eficaz que las ofertas pasivas: los buenos perfiles frontend apenas miran ya el feed de empleo. Filtra con precisión por framework (React frente a Vue frente a Angular), TypeScript y experiencia de puesta en producción antes de contactar. Las secuencias genéricas obtienen tasas de respuesta menores al 5 por ciento; los mensajes personalizados con referencia clara al producto y a la stack suben al 15-25 por ciento.
InfoJobs
Oferta destacada desde 199 € por publicación; packs multioferta desde 450 €El portal con mayor volumen de candidaturas activas en España, especialmente fuerte fuera de Madrid y Barcelona (Valencia, Sevilla, Zaragoza, Bilbao) y en perfiles frontend de pyme tradicional. Genera volumen, no siempre señal: filtra con CV semiestructurado, portfolio público (GitHub, CodeSandbox, sitio personal) y test técnico breve para no perder tiempo en cribado. Más eficaz para stacks mainstream (React, Vue, Angular reciente) que para nichos modernos (Svelte, Qwik, Solid). Útil como complemento de LinkedIn cuando se busca cubrir el puesto rápido.
Tecnoempleo, Manfred y comunidades tech ES
Tecnoempleo desde 195 € por publicación; Manfred sin coste de publicación, comisión sobre contrataciónBoards y comunidades tech de nicho con audiencia frontend cualificada. Tecnoempleo concentra perfiles tech españoles con preferencia por stacks modernas (React, TypeScript, Vue); Manfred funciona como reverse recruiting (los perfiles publican lo que buscan y las empresas se postulan), eficaz para perfiles senior que ya no usan LinkedIn activamente. Complemente con comunidades de Slack y Discord (Frontend España, React Madrid, MadridJS, BarcelonaJS) donde circulan ofertas dirigidas y las recomendaciones funcionan mejor que los anuncios pagados.
Manual de evaluación
El puesto de Desarrollador·a Frontend se evalúa en cinco etapas. La prueba técnica (etapa 3) y el ejercicio de revisión de código (etapa 4) son las más predictivas: alguien puede hablar de React o de accesibilidad durante una hora sin revelar si realmente sabe entregar un componente sólido en producción. Pon a la persona a trabajar sobre código real.
Etapa 1: Lectura del CV y del portfolio público
Busca coherencia entre lo que dice el CV y lo que muestra el portfolio público (GitHub, sitio personal, charlas, contribuciones a open source). Señales positivas: proyectos personales con commits regulares, componentes documentados, atención a la accesibilidad y al rendimiento. Señales negativas: GitHub vacío o solo con forks sin actividad, CV que enumera frameworks sin profundidad real, ausencia total de tests. La titulación pesa menos que los últimos 3-5 años de trabajo real en producción.
Etapa 2: Phone screen (30 min)
Solo tres preguntas: (1) describe el componente o flujo del que te sientas más orgulloso·a y cuál fue tu aportación concreta, (2) qué decisión técnica reciente sigue cuestionando hoy (humildad y retrospección), (3) por qué un cambio justo ahora. Salida: go o no-go en 5 minutos de debrief, no más. Evita las preguntas técnicas tipo trampa en esta fase.
Etapa 3: Prueba técnica acotada (2-3 horas)
Brief realista: implementar un componente o una pantalla pequeña con datos asíncronos, estados de carga y error, accesibilidad básica (foco, contraste, jerarquía semántica) y un test mínimo. Acota el tiempo a 2-3 horas y comunícalo de forma explícita; acepta soluciones incompletas pero bien argumentadas. Evita los ejercicios tipo concurso (reproduzca este Figma píxel a píxel sin contexto) o tipo LeetCode (algoritmos sin relación con el día a día).
Etapa 4: Revisión de código y diseño de interacción (60-90 min)
Sesión en directo en dos partes: 30-40 min de revisión del código entregado en la etapa 3 (¿por qué eligió este enfoque?, ¿cómo testearía este edge case?, ¿cómo escalaría este componente a 20 variantes?), seguidos de 20-50 min de discusión sobre un caso de diseño de interacción (cómo abordaría una lista virtualizada con 10 mil ítems, un formulario complejo con validación asíncrona, una accesibilidad en un menú anidado). Evalúa la capacidad de razonar en voz alta, de pedir aclaraciones y de iterar.
Etapa 5: Referencias (verificación estructurada)
Llama a dos referencias: un·a antiguo·a tech lead o engineering manager directo y un·a antiguo·a compañero·a de equipo (idealmente frontend o diseño). Plantea a ambas las mismas cuatro preguntas: ¿En qué destaca más?, ¿Para qué contrataría a una persona complementaria?, ¿La o lo volvería a contratar mañana y por qué?, ¿Un ejemplo de decisión técnica difícil tomada en autonomía? La cuarta pregunta es la que revela el verdadero indicio de autonomía y de criterio.
Cómo reconocer una gran contratación
| Competencia | Por debajo | En el nivel | Por encima |
|---|---|---|---|
| Solidez técnica frontend | Tropieza con los fundamentos (DOM, ciclo de vida de los componentes, gestión del estado, asincronía). Busca soluciones a base de prueba y error sin modelo mental claro. Difícil de subir a un framework nuevo. | Domina la stack actual en autonomía. Sabe aprender un framework nuevo en 2-4 semanas. Comprende los fundamentos del DOM, del estado y del rendimiento lo suficiente para depurar en profundidad cuando hace falta. | Referente técnico del equipo en frontend y capaz de saltar a una nueva stack en pocas semanas. Anticipa trampas clásicas (re-renders innecesarios, memory leaks, race conditions en hooks). Construye abstracciones útiles, no prematuras. |
| Accesibilidad y calidad de interacción | Ignora la accesibilidad o la trata como tarea final. No conoce los fundamentos (contraste, foco, jerarquía semántica, ARIA). Estados de error, vacío y carga descuidados. Interacciones rotas en teclado. | Aplica los fundamentos WCAG AA en cada componente nuevo: contraste, foco visible, jerarquía semántica correcta, gestión de errores anunciada. Trata estados de error, vacío y carga de forma explícita. Verifica navegación por teclado. | Referente de accesibilidad del equipo: integra checklist accesible en code review, automatiza con axe en CI, anticipa edge cases (lector de pantalla, zoom 200 por ciento, reducción de movimiento). Forma al equipo en buenas prácticas. |
| Rendimiento web y operación | Sin instrumentación de rendimiento. Bundles enormes, sin code splitting, sin lazy loading. Optimiza por intuición sin medir. No conoce los Web Vitals. | Mide antes de optimizar: Lighthouse, Web Vitals, bundle analyzer. Aplica code splitting, lazy loading y optimización de imágenes en los puntos críticos. Conoce el impacto de los terceros (analytics, A/B tests) en el rendimiento. | Optimización continua: budget de rendimiento documentado, alertas sobre regresión de Web Vitals, profiling regular de runtime. Sabe arbitrar entre experiencia y simplicidad técnica. Forma al equipo en cultura de rendimiento. |
| Calidad del código y disciplina de tests | Sin estrategia de testing clara; añade tests para subir cobertura. Componentes de 500 líneas, copy-paste, lógica mezclada con presentación. Tipado laxo o ausente. Reviews superficiales. | Pirámide de tests adecuada (unitarios, componente, e2e en flujos críticos). Código legible, hooks bien separados, tipado razonable. Reviews estructuradas con feedback accionable. Refactoriza al paso cuando es pertinente. | Referente de calidad del equipo: convenciones documentadas, automatización en CI (linters, type checkers, tests, axe, Lighthouse). Reviews pedagógicas que hacen progresar a perfiles junior. Sabe decir no a código que pasa los tests pero envejecerá mal. |
| Comunicación y juego en equipo | Explica mal su trabajo a perfiles no técnicos. Postura defensiva en reviews. Trabaja en silo, comparte poco contexto. Postura de oposición sistemática frente a producto o diseño. | Sabe explicar su trabajo a una persona PM o de diseño en lenguaje claro. Recibe la review de forma constructiva. Comparte contexto en revisiones de equipo y 1:1. Negocia plazos de forma transparente. | Puente entre frontend, producto y diseño. Modera debriefs técnicos, divulga arbitrajes (rendimiento, accesibilidad, deuda), negocia plazos de forma transparente. Referente del equipo en comunicación transversal. |
Errores comunes al contratar para este puesto
Contratar por dominio visual del CSS sin verificar fundamentos de JS
Un·a desarrollador·a frontend que reproduce un Figma píxel a píxel pero no entiende la asincronía, el ciclo de vida de los componentes o la gestión del estado no llega lejos en pyme tech española. La parte visual sigue siendo necesaria, pero los fundamentos de JavaScript y de TypeScript son los que sostienen el trabajo cuando el producto crece. Verifica la solidez técnica en la prueba y en la sesión de revisión de código, no solo el lustre del portfolio.
Subestimar la accesibilidad como criterio de cribado
Si tu producto se vende a empresas grandes, al sector público o a clientes europeos, la accesibilidad pasará pronto de buena práctica a requisito (European Accessibility Act, vigente desde junio de 2025 para muchos productos B2C, y obligatoria para licitaciones públicas). Contratar perfiles frontend sin sensibilidad accesible genera una deuda muy cara de recuperar a posteriori. Pregunta de forma explícita por experiencia WCAG AA, por uso de lector de pantalla y por automatización con axe.
Pedir pruebas técnicas de 8 horas o más
Una prueba de 8 horas se transforma en la práctica en 24 horas (con inversión emocional incluida), desmotiva a los mejores perfiles (que tienen otras opciones en paralelo) y no aporta mejor señal que una prueba bien construida de 2-3 horas. Mide la calidad del razonamiento, no la exhaustividad. Acota el tiempo esperado de forma explícita y acepta soluciones incompletas pero bien argumentadas.
Confundir Frontend Developer y UI Engineer
Algunas pymes españolas escriben Frontend Developer en la oferta pero esperan un perfil de integración pura (HTML, CSS, plantillas server-side) sin aplicación JS compleja. Otras esperan un·a ingeniero·a frontend que diseñe arquitectura de componentes, decisiones de estado y rendimiento. Los dos perfiles existen y no son intercambiables: el primero se siente sobrepasado en una SPA seria; el segundo se aburre maquetando emails. Encuadre el scope real desde la oferta para no atraer perfiles mal encajados.
Ignorar la fit con la stack y el ecosistema
Un·a desarrollador·a sólido·a en React más TypeScript no se vuelve productivo·a de inmediato en Vue 3 más JavaScript o en Angular reciente; necesita 2-4 semanas de adaptación. Para un perfil mid-level pesa más la fit de stack que la seniority absoluta. Sé explícito·a con tu stack en el anuncio (framework, gestión de estado, herramientas de build, design system); eso ya filtra perfiles mal encajados y reduce los abandonos tras la incorporación.