Descríbeme tu flujo de trabajo típico en desarrollo 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.

¿Cómo abordas la depuración de un problema de interfaz que solo aparece en ciertos navegadores?

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.

¿Cómo gestionas las revisiones de código, tanto al dar como al recibir feedback?

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.

Cuéntame sobre una vez que tuviste que depurar un problema de rendimiento en una aplicación frontend.

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

Describe cómo trabajas con los diseñadores para implementar una funcionalidad de interfaz.

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.

¿Cómo te mantienes al día con el ecosistema frontend sin distraerte con cada nuevo framework?

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.

Dame un ejemplo de una situación en la que tuviste que equilibrar entregar rápido con mantener la calidad del código.

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.

¿Cómo optimizarías una página para los Core Web Vitals?

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.

¿Cómo abordas la accesibilidad en un proyecto frontend?

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.

¿Cómo estructuras la arquitectura de componentes en una aplicación React grande?

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.

Preguntas de entrevista Desarrollador frontend

Desarrollador frontend

Las entrevistas para Desarrollador frontend evalúan tu dominio de JavaScript y TypeScript, tu capacidad para construir interfaces accesibles y de buen rendimiento, y cómo piensas sobre la arquitectura de componentes y las pruebas. Los entrevistadores buscan ejemplos concretos de problemas reales que hayas resuelto. Esta guía cubre las preguntas más frecuentes y las respuestas que demuestran una experiencia genuina.

Preguntas conductuales para puestos de Desarrollador frontend

Lo que buscan los reclutadores en las entrevistas para Desarrollador frontend

Lo que los responsables de selección buscan realmente en los candidatos a Desarrollador frontend:

El proceso de resolución de problemas, no solo las soluciones. Describe tu método de depuración y toma de decisiones paso a paso. Los candidatos que saben articular su razonamiento destacan sobre los que simplemente dan la respuesta correcta.
Conciencia sobre rendimiento y accesibilidad. No son extras. Los entrevistadores de empresas de producto esperan que consideres los Core Web Vitals, el cumplimiento de WCAG y el tamaño del bundle como parte del trabajo diario.
Colaboración con diseñadores y otros ingenieros. El desarrollo frontend se sitúa en la intersección del diseño y la ingeniería. Muestra que puedes trabajar con fluidez en ese espacio sin fricciones.
Pragmatismo con las herramientas. La capacidad de evaluar un nuevo framework de forma crítica y decidir no adoptarlo vale más que el entusiasmo por cada nueva versión.
Evidencia de que escribes pruebas. Los candidatos que tratan las pruebas como algo secundario raramente superan un panel de ingenieros senior.

Preguntas que puedes hacer al entrevistador

→¿Cómo es la stack frontend hoy en día, y hay migraciones o esfuerzos de modernización planificados?

→¿Cómo aborda el equipo los presupuestos de rendimiento y los Core Web Vitals en la práctica?

→¿Cómo se toman las decisiones de frontend y diseño? ¿Hay un design system y quién es su responsable?

→¿Cómo es la cultura de pruebas aquí y qué cobertura se persigue?

→¿Cuál es el mayor reto frontend al que se enfrenta el equipo ahora mismo?

Desarrollador frontend

Preguntas de entrevista habituales para Desarrollador frontend

Preguntas conductuales para puestos de Desarrollador frontend

Preguntas técnicas para candidatos a Desarrollador frontend

Lo que buscan los reclutadores en las entrevistas para Desarrollador frontend

Preguntas que puedes hacer al entrevistador

Practica estas preguntas antes de tu entrevista

Puestos relacionados