Preguntas de entrevista Desarrollador frontend

Mi flujo de trabajo empieza por entender los requisitos y cualquier especificación de diseño antes de escribir una sola línea de código. Divido la interfaz en componentes desde el principio, distinguiendo los que gestionan estado de los puramente presentacionales. Uso TypeScript desde el inicio, así que las definiciones de tipos preceden a la implementación. Para el control de versiones trabajo en ramas de corta duración, mantengo los commits pequeños y enfocados, y abro pull requests para revisión antes de hacer merge. Ejecuto el componente en aislamiento con Storybook cuando el equipo lo usa, escribo pruebas unitarias con Jest y React Testing Library mientras construyo, y hago una comprobación manual entre navegadores antes de marcar algo como listo.

Empiezo por reproducir el problema de forma fiable, anotando exactamente qué navegadores y versiones están afectados. Una vez que puedo reproducirlo de manera consistente, uso las DevTools del navegador para inspeccionar el DOM, revisar diferencias de CSS y buscar errores en la consola. Asilo el componente que falla y lo reduzco a una reproducción mínima para descartar interacciones con otro código. Para los bugs de CSS reviso propiedades con incompatibilidades conocidas en MDN o Can I Use. Para los problemas de JavaScript busco diferencias en APIs o comportamiento de eventos específicos de cada navegador. Una vez identificada la causa raíz, aplico la corrección sin romper otros navegadores y añado un caso de prueba para evitar regresiones.

Cuando reviso el código de otra persona me centro en la corrección, la mantenibilidad y el rendimiento, no en las preferencias de estilo, que debe gestionar un linter. Intento hacer preguntas en lugar de exigir cambios: "¿Has considerado el enfoque X por la razón Y?" funciona mejor que un rechazo directo. Siempre reconozco lo que funciona bien antes de señalar problemas. Cuando recibo feedback lo trato como información, no como crítica. Si no estoy de acuerdo con un comentario explico mi razonamiento claramente una vez y luego me remito al revisor. El objetivo es entregar mejor código, no tener razón. También actúo sobre los patrones que veo repetidamente en mis propias revisiones y ajusto mi enfoque antes del siguiente PR.

Teníamos un panel de control en React que tardaba más de cuatro segundos en ser interactivo en dispositivos de gama media. Empecé perfilándolo en Chrome DevTools, lo que reveló un bundle de gran tamaño y un árbol de componentes que se re-renderizaba mucho más de lo necesario. El análisis del bundle mostró que importábamos una librería de gráficos completa para dos tipos de gráficos. La reemplacé por una alternativa más ligera y usé importaciones dinámicas para separar los gráficos en un chunk independiente. Para los re-renders usé React.memo y moví los cálculos costosos a useMemo con los arrays de dependencias correctos. Tras esos cambios la carga inicial bajó a menos de 1,5 segundos y el Largest Contentful Paint mejoró un 60%.

Intento involucrarme antes de que los diseños estén finalizados en lugar de recibir una especificación completa para implementar. La participación temprana me permite señalar restricciones técnicas: por ejemplo, si una animación es bonita en Figma pero requiere una propiedad CSS que fuerza un repintado completo en cada frame, es más sencillo ajustar el diseño que luchar contra el navegador después. Durante la implementación comparto versiones tempranas en lugar de esperar a tener algo perfecto, porque los diseñadores suelen detectar en el navegador cosas que no vieron en la maqueta estática. También pregunto por los estados de interacción desde el principio: hover, foco, carga, error y estados vacíos son fáciles de pasar por alto en los diseños.

Separo la señal del ruido centrándome primero en los estándares y especificaciones del navegador. Las nuevas API como View Transitions o Popover representan capacidades reales de la plataforma, no opiniones de framework, así que las priorizo. Para los frameworks, sigo las notas de versión y los RFCs de las herramientas que ya uso. Mantengo una lista corta de fuentes de confianza: las actualizaciones de MDN, el repositorio de propuestas TC39 y algunos ingenieros cuyo pensamiento respeto. Cuando una nueva herramienta gana adopción significativa paso unas horas construyendo algo pequeño con ella para formarme mi propia opinión. He rechazado adoptar varias herramientas que resultaron no encajar con las necesidades de nuestro equipo. Ser selectivo con lo que aprendes es tan importante como aprender.

Durante un lanzamiento de producto teníamos tres días para construir una funcionalidad que normalmente habría llevado una semana. Tuve una conversación directa con el equipo sobre los compromisos: acordamos no escribir pruebas unitarias para los nuevos componentes, usar un enfoque de estado más sencillo que sabíamos que necesitaría refactorización, y aplazar las mejoras de accesibilidad más allá de la navegación por teclado. Creé inmediatamente un ticket de deuda técnica con los elementos aplazados y el coste estimado de la limpieza para que no se olvidara. Lanzamos a tiempo. Dos semanas después del lanzamiento retomé el ticket y completé la refactorización con cobertura de pruebas completa y mejoras ARIA. La clave es hacer el compromiso explícito y rastreable, no invisible.

Empiezo midiendo el estado actual con Lighthouse y el Chrome User Experience Report para entender qué métricas fallan en sesiones de usuarios reales, no solo en condiciones de laboratorio. Para el Largest Contentful Paint reviso si la imagen principal o el encabezado se carga con la prioridad correcta: debe tener fetchpriority="high" y no estar en lazy-loading. Para las fuentes uso font-display: swap y precargo el subconjunto crítico. Para el Cumulative Layout Shift audito cualquier elemento cuyo tamaño lo determina contenido cargado después del renderizado inicial. Para el Interaction to Next Paint perfilo la ejecución de JavaScript en dispositivos lentos y busco tareas largas para dividir con scheduler.yield o mover a un web worker. También reviso scripts y hojas de estilo que bloquean el renderizado y pueden diferirse.

La accesibilidad es algo que integro desde el principio, no que audito al final. Uso HTML semántico como base: un documento bien estructurado con una jerarquía de encabezados correcta, regiones de referencia y elementos de formulario nativos cubre una gran parte de los requisitos de accesibilidad sin ARIA. Cuando uso ARIA sigo la primera regla: no usar ARIA si un elemento nativo puede hacer el trabajo. Para los componentes interactivos verifico que toda la funcionalidad sea accesible por teclado y que el foco se gestione correctamente cuando aparecen modales o contenido dinámico. Pruebo con un lector de pantalla al menos una vez por funcionalidad. También ejecuto comprobaciones automatizadas con axe-core como parte de la suite de pruebas. Las herramientas automatizadas detectan aproximadamente el 30 al 40% de los problemas, así que las pruebas manuales son imprescindibles.

Pienso en los componentes en términos de su responsabilidad. Los componentes presentacionales reciben props y renderizan la interfaz, sin conocimiento de la procedencia de los datos. Los componentes contenedor gestionan la obtención de datos y el estado, y los pasan hacia abajo. Las primitivas de UI compartidas viven en una carpeta de design system y se mantienen genéricas. Los componentes específicos de una funcionalidad viven junto a esa funcionalidad, no en una carpeta compartida, porque la co-localización facilita entender el alcance y eliminar código de forma segura. Para el estado lo mantengo tan cerca de donde se usa como sea posible: estado local primero, luego contexto, luego un store global solo cuando es realmente necesario. También presto atención a la superficie de API de cada componente, manteniendo las props mínimas.