Desarrollador·a Frontend
Descripción de puesto, salario, sourcing, 15 preguntas de entrevista y plan 30/60/90 para contratar un·a Desarrollador·a Frontend en pymes españolas.
Compilado por el equipo de Join a partir de datos públicos y de nuestra experiencia en contratación.
Actualizado
De un vistazo
- Salario mediano 45.000 € 35.000 € – 58.000 €
- Plazo de contratación 45–75 días
- Experiencia 3–6 años
Cómo contratar a un·a Desarrollador·a Frontend para su pyme
Antes de redactar la oferta, plantéese 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. Sea explícito·a con su stack en la oferta (framework, gestión de estado, herramientas de build, design system); eso ya filtra perfiles mal encajados. Si su stack se considera legacy (jQuery, Angular 1, plantillas server-rendered sin componentes), asúmalo y busque 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 su 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 su 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: busque experiencia explícita en WCAG AA, en Web Vitals y en automatización (axe en CI, Lighthouse en cada PR). Si su 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), pase al modelo de oferta a continuación.
Modelo de descripción de puesto
Desarrollador·a Frontend: capa cliente y experiencia de uso en pyme
[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].
Banda salarial
Salario fijo bruto anual
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
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. Filtre 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: filtre 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. Ponga a la persona a trabajar sobre código real.
-
Etapa 1: Lectura del CV y del portfolio público
Busque 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) describa el componente o flujo del que se sienta más orgulloso·a y cuál fue su 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. Evite 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. Acote el tiempo a 2-3 horas y comuníquelo de forma explícita; acepte soluciones incompletas pero bien argumentadas. Evite 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úe la capacidad de razonar en voz alta, de pedir aclaraciones y de iterar.
-
Etapa 5: Referencias (verificación estructurada)
Llame 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). Plantee 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.
Preguntas de entrevista estructuradas
-
Conductual Decisión técnica Describa el componente o flujo más complejo que diseñó y construyó en su último puesto. ¿Por qué era complejo y cómo lo abordó?
Lo que revela una buena respuestaCapacidad 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.
-
Conductual Depuración e investigación Cuénteme un bug de frontend en producción que resolvió. ¿Cuál era el síntoma, cómo lo diagnosticó y cuánto tiempo le llevó?
Lo que revela una buena respuestaMé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.
-
Conductual Aprendizaje y humildad Describa un momento en el que tuvo que refactorizar o reescribir un componente que usted mismo·a había escrito unos meses antes. ¿Qué había pasado entre medias?
Lo que revela una buena respuestaHumildad 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 Coraje técnico Descubre 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 reacciona?
Lo que revela una buena respuestaCapacidad 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.
-
Situacional Comunicación con producto Una persona Product Manager le pide una funcionalidad que según su estimación lleva 3 semanas. La persona PM la quiere en 1 semana. ¿Cómo reacciona?
Lo que revela una buena respuestaClarificació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.
-
Situacional Pragmatismo y priorización Se incorpora 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 su plan a 30 días?
Lo que revela una buena respuestaDiagnó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 Diseño de interacción frontend 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ña en frontend?
Lo que revela una buena respuestaAclaraciones 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).
-
Caso práctico Rendimiento web Rendimiento: su aplicación tarda 6 segundos en pintar la primera pantalla útil. Tiene 1 semana para bajarla por debajo de 2 segundos. ¿Plan de acción?
Lo que revela una buena respuestaMedir 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.
-
Caso práctico Accesibilidad Accesibilidad: la auditoría WCAG revela 60 issues en su aplicación, repartidos entre nivel A y AA. Tiene un trimestre para llevarla a cumplimiento AA razonable. ¿Plan de acción?
Lo que revela una buena respuestaPriorizació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 Fundamentos frontend Explique la diferencia entre Server-Side Rendering, Static Site Generation, Incremental Static Regeneration y client-only. ¿Cuándo elegiría cada uno y por qué?
Lo que revela una buena respuestaComprensió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.
-
Técnica Calidad del código ¿Cuál es su enfoque del testing en frontend? Describa su último proyecto: cuántos tests, qué tipos (unitarios, componente, integración, end-to-end), qué cobertura y qué mide realmente.
Lo que revela una buena respuestaComprensió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.
-
Técnica Pragmatismo y priorización Llega 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.
Lo que revela una buena respuestaEnfoque 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 Coachability ¿Cómo recibe una code review crítica sobre código del que estaba convencido·a de haber hecho bien?
Lo que revela una buena respuestaApertura: 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.
-
Valores Mentoría y transmisión ¿Qué papel juega en la transmisión técnica a perfiles junior o a las nuevas incorporaciones en frontend?
Lo que revela una buena respuestaPostura 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.
-
Valores Juego en equipo con diseño ¿Cómo trabaja con un·a Product Designer? Describa una situación en la que devolvió un diseño con cuestionamientos.
Lo que revela una buena respuestaPostura 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.
Cómo reconocer a un·a excelente Sales Manager
| 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. |
Plan de 30/60/90 días
Día 30
- Setup completo del entorno local y despliegue de una PR (aunque trivial) validada en producción
- Lectura y comprensión del código de los 3 componentes o flujos más críticos del producto
- Primer 1:1 documentado con la persona tech lead sobre convenciones, deuda identificada y prioridades
- Primera PR sustantiva (corrección de bug o componente pequeño) revisada y mergeada
Día 60
- Entrega de un componente o flujo completo de principio a fin (diseño aterrizado, accesibilidad, tests, despliegue) en autonomía
- Primera review de PR de un·a compañero·a con feedback estructurado, no solo clic en aprobar
- Primer aporte al design system o a la documentación de patrones del equipo
- Primera contribución de rendimiento o accesibilidad medible (mejora de Web Vital, corrección de issue WCAG en flujo crítico)
Día 90
- Entrega regular (1-2 PRs por semana) con calidad validada por el equipo en review
- Primera decisión técnica en autonomía sobre un tema ambiguo (refactor, elección de librería, diseño de componente reusable)
- Mentoría informal de un·a junior o nueva incorporación (pair programming, reviews pedagógicas)
- Balance formal con la persona tech lead: rampa validada, plan de progresión sobre 1-2 ejes prioritarios
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. Verifique 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 su 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. Pregunte 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. Mida la calidad del razonamiento, no la exhaustividad. Acote el tiempo esperado de forma explícita y acepte 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. Sea explícito·a con su 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.
Preguntas frecuentes
-
¿Cuál es el salario de un·a Desarrollador·a Frontend en una pyme española?
La horquilla de referencia para un·a Desarrollador·a Frontend de nivel intermedio (3 a 6 años de experiencia) en pyme española se sitúa entre 35 y 58 mil euros brutos anuales (mediana en torno a 45 mil). Madrid y Barcelona en entorno SaaS o scale-up tiran hacia arriba (52-70 mil); resto del territorio y sectores tradicionales tiran hacia abajo. Este puesto no suele tener variable estructural en pyme; algunas scale-ups ofrecen phantom shares o stock options como complemento. Los perfiles con experiencia sólida en accesibilidad, rendimiento web y design systems se sitúan en la franja alta.
-
¿Cuál es la diferencia entre Desarrollador·a Frontend, Full-stack y UI Engineer?
El·la Frontend se centra en la interfaz de usuario y en la capa cliente: componentes, gestión del estado, accesibilidad, rendimiento percibido, integración con APIs. El·la Full-stack cubre frontend y backend a un nivel intermedio-avanzado. El·la UI Engineer suele orientarse a integración visual y design system (más cerca del diseño, menos de la arquitectura aplicativa). En pyme española, el título Frontend es el más usado para un perfil de espectro completo en la capa cliente. Verifique siempre el scope real del puesto, no solo el título.
-
¿Cuánto tiempo lleva contratar a un·a Desarrollador·a Frontend en España?
Cuente con 45 a 75 días entre la publicación de la oferta y la firma para un perfil mid-level. El mercado tech español sigue tenso en 2025-2026, sobre todo para perfiles con stack moderna (React o Vue, TypeScript, tests automatizados, sensibilidad accesible). Los plazos se alargan en agosto y en torno a las navidades, así como cuando hay procesos de varias etapas (prueba técnica más revisión de código más referencias). Reducir el plazo por debajo de los 45 días suele implicar sacrificar la prueba técnica, lo que degrada de forma significativa la calidad de la contratación.
-
¿Es necesaria una titulación específica para contratar a un·a Desarrollador·a Frontend?
No. El mercado frontend español acepta ampliamente perfiles autodidactas o procedentes de bootcamps (Ironhack, Le Wagon, 4Geeks, Adalab, Keepcoding) cuando suman 3-5 años de producción sólida. La titulación (ingeniería informática, máster) tranquiliza en perfiles junior pero pierde peso a partir de los 5 años de experiencia real. Evalúe sobre el código entregado, sobre la sesión de revisión y sobre el portfolio público, no sobre el pedigrí académico.
-
¿Qué obligaciones legales tiene una oferta frontend en España?
Cuatro obligaciones principales: (1) denominación neutra de género o con mención inclusiva (Estatuto de los Trabajadores y Ley de Igualdad); (2) registro horario obligatorio de la jornada (art. 34.9 del Estatuto de los Trabajadores, vigente desde 2019); (3) banda salarial visible en la oferta o comunicada antes de la primera entrevista (Directiva UE 2023/970 sobre transparencia retributiva, transposición antes del 7 de junio de 2026); (4) transparencia sobre cualquier herramienta de IA usada para el cribado y supervisión humana garantizada (EU AI Act, aplicable desde el 2 de agosto de 2026). Se aplica además el convenio colectivo correspondiente al sector y, en empresas con más de 50 personas, la cuota de reserva del 2 por ciento para personal con discapacidad.
-
¿Hay que hacer prueba técnica siempre?
Sí, pero corta (2-3 horas máximo) y realista. Una prueba bien diseñada es el mejor predictor del desempeño futuro, por delante de la titulación y del pedigrí. Evite las pruebas algorítmicas académicas sin relación con el día a día (LeetCode hard) y las pruebas tipo concurso (reproduzca este Figma sin contexto). Prefiera ejercicios que se parezcan al trabajo real: implementar un componente con datos asíncronos, estados de carga y error, accesibilidad básica y un test mínimo. Acote el tiempo esperado de forma explícita y acepte soluciones incompletas pero bien argumentadas.