Desarrollador·a Frontend

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.

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.

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.

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.

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.

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.

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).

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.

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).

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.

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.

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.

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.

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.

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.