Desarrollador frontend Preguntas de entrevista & Respuestas

Respuesta modelo

El equipo de diseño entregó mockups para una tabla de datos con scroll infinito, ordenación en tiempo real, edición en línea y transiciones animadas en las filas, todo sobre un conjunto de datos de más de 100.000 registros. Hice un prototipo y comprobé que el renderizado del DOM más las animaciones para tantas filas dejaban el rendimiento por debajo de 10 fps en dispositivos de gama media. En lugar de limitarme a decir que era imposible, desarrollé dos alternativas: una con renderizado virtualizado (react-window) que mantenía el scroll fluido pero simplificaba las animaciones, y otra con paginación que conservaba todos los efectos visuales. Le hice una demostración al diseñador con métricas de rendimiento. Elegimos el enfoque virtualizado con transiciones de fila simplificadas. El diseñador agradeció ver el compromiso de forma visual en lugar de escuchar un «no» abstracto. La implementación final gestionó más de 100.000 filas a 60 fps con toda la funcionalidad principal intacta.

Respuesta modelo

La página de inicio de nuestra tienda online tenía un Largest Contentful Paint de 4,2 segundos, y los datos de conversión mostraban una caída del 7% en las compras por cada segundo adicional de carga. Identifiqué tres cuellos de botella: una imagen hero de 2 MB, 800 KB de JavaScript síncrono y un archivo CSS bloqueante que importaba hojas de estilo sin usar. Convertí la imagen hero a WebP con srcset responsivo, dividí el bundle de JavaScript con importaciones dinámicas (reduciendo la carga inicial un 65%) e inserté el CSS crítico en línea cargando el resto de forma asíncrona. El LCP bajó a 1,1 segundos. En el mes siguiente, la tasa de conversión aumentó un 9% y la tasa de rebote disminuyó un 15%. El esfuerzo total de ingeniería fue de 4 días, uno de los proyectos con mayor retorno de inversión en los que he trabajado.

Respuesta modelo

Construí una librería de componentes React compartida para una empresa con 4 equipos de producto, cada uno implementando sus propios botones, modales y formularios. Empecé auditando los componentes existentes en todos los productos: teníamos 12 variantes de botón diferentes. Las consolidé en 4 (primario, secundario, fantasma, peligro) con tamaños y espaciados consistentes. Usé TypeScript para el tipado estricto de props, Storybook para documentación y pruebas visuales, y Chromatic para pruebas de regresión visual. Versioné la librería con versionado semántico y la publiqué en un registro npm privado. La adopción fue la parte más difícil: organicé sesiones de consulta semanales, creé una guía de migración para cada producto y envié PRs para mostrar a los equipos cómo reemplazar sus componentes personalizados. Tras 4 meses, todos los equipos usaban la librería compartida, la consistencia visual del diseño mejoró y el tiempo de desarrollo de nuevas funcionalidades disminuyó porque los desarrolladores dejaron de reconstruir componentes comunes.

Respuesta modelo

Recibimos informes de errores indicando que nuestra validación de formularios no funcionaba en Safari iOS. El problema: estábamos usando el método reportValidity() de la Constraint Validation API, que Safari admitía pero gestionaba de forma diferente: mostraba el tooltip de error pero no impedía el envío del formulario en iOS. Tracé el error hasta un problema de renderizado de WebKit donde el tooltip aparecía detrás del teclado virtual. Mi solución tuvo tres partes: reemplacé los tooltips de validación nativos con mensajes de error personalizados en línea (mejor UX de todas formas), añadí una capa de validación en JavaScript como alternativa y configuré pruebas cross-browser con BrowserStack en nuestro pipeline de CI para detectar problemas específicos de Safari de forma temprana. También creé una lista de verificación de compatibilidad para el equipo que cubría Safari iOS, Chrome Android, Firefox y Edge. La corrección resolvió más de 40 informes de errores relacionados con Safari de una sola vez.

Respuesta modelo

El Virtual DOM es una representación JavaScript ligera del DOM real. Cuando el estado cambia, React crea un nuevo árbol del Virtual DOM y lo compara con el anterior: esto es la reconciliación. React usa un algoritmo heurístico de O(n): compara los árboles nivel a nivel, asume que elementos de tipos diferentes producen árboles distintos (y los elimina por completo) y usa las props «key» para identificar qué elementos de una lista han cambiado, se han movido o han sido eliminados. Cuando la comparación detecta una diferencia, React agrupa el conjunto mínimo de operaciones DOM reales necesarias. Esto es más rápido que manipular el DOM real directamente porque las operaciones DOM son costosas (desencadenan recálculo del layout, pintura y composición), mientras que la comparación de objetos JavaScript es barata. La implicación práctica clave: usa siempre keys estables y únicas para los elementos de lista (no índices de array), evita crear nuevas referencias de objetos o funciones en el render (anulan la memoización) y usa React.memo, useMemo y useCallback cuando el perfilado muestre renderizados innecesarios.

Respuesta modelo

Flexbox es unidimensional: gestiona el layout en una fila o en una columna. Grid es bidimensional: gestiona filas y columnas al mismo tiempo. Uso Flexbox para el layout a nivel de componente: alinear elementos en una barra de navegación, espaciar botones en una barra de herramientas, centrar contenido vertical y horizontalmente. Flexbox es ideal cuando el tamaño del contenido debe determinar el layout. Uso Grid para el layout a nivel de página: definir la estructura general de la página, crear cuadrículas de tarjetas complejas, construir layouts de panel con múltiples regiones. Grid es ideal cuando quieres que el layout defina la ubicación del contenido. En la práctica, combino ambos: Grid para el macro layout (cabecera, barra lateral, contenido principal, pie de página) y Flexbox para el micro layout dentro de cada celda de la cuadrícula. El error habitual es recurrir a Grid para una fila simple de elementos o usar trucos con Flexbox (márgenes negativos, pseudoelementos) cuando Grid sería más limpio.

Respuesta modelo

Categorizo el estado según su naturaleza y elijo las herramientas en consecuencia. Estado local de UI (campos de formulario, estados de toggle, visibilidad de modales): useState o useReducer. Lo mantengo en el componente que lo gestiona y solo lo elevo cuando es realmente necesario. Estado del servidor (datos de APIs): React Query o SWR. Estas librerías gestionan la caché, el refresco, las actualizaciones optimistas y los estados de carga y error mucho mejor que los patrones manuales con Redux. Nunca pongo datos del servidor en el estado global. Estado global del cliente (tema, autenticación, preferencias del usuario): React Context para actualizaciones poco frecuentes (tema, idioma) o Zustand para estado que cambia a menudo y necesita suscripción selectiva para evitar renderizados innecesarios. Estado en la URL (filtros, paginación, parámetros de búsqueda): useSearchParams de React Router. El estado vive en la URL, lo que permite guardar marcadores y compartir enlaces. El antipatrón que evito: poner todo en un único store global. Genera acoplamiento, complica las pruebas y suele provocar que los componentes se rendericen cuando cambia un estado no relacionado. Cada categoría de estado tiene la herramienta adecuada; el arte está en elegir correctamente.

Respuesta modelo

Un closure es una función que retiene acceso a las variables de su ámbito externo incluso después de que la función externa haya terminado de ejecutarse. La función interna «cierra» sobre las variables que referencia. Un ejemplo práctico: una función debounce. Cuando escribes debounce(fn, delay), la función devuelta tiene acceso a la variable timer definida en el ámbito de debounce. Cada vez que se llama a la función devuelta, cancela el temporizador anterior y establece uno nuevo. La variable timer persiste entre llamadas gracias al closure: no la recoge el recolector de basura mientras exista la función devuelta. Otro uso en el mundo real: el hook useState de React. Cuando llamas a setCount(count + 1), el valor de count proviene del closure creado cuando el componente se renderizó. Por eso los closures obsoletos son un error habitual en React: si usas count dentro de un useEffect sin incluirlo en el array de dependencias, el efecto cierra sobre el valor inicial y nunca ve las actualizaciones.

Respuesta modelo

Primero, verificaría mi comprensión tanto del requisito de diseño como de la limitación de la API. A veces lo que parece una limitación es en realidad un endpoint diferente o un parámetro de consulta que aún no he encontrado. Consultaría la documentación de la API y hablaría con el desarrollador backend. Si la limitación es real, evaluaría tres opciones. Primera: ¿puede el frontend derivar los datos necesarios a partir de las respuestas existentes de la API? A veces un cálculo o transformación en el lado del cliente lo resuelve sin cambios en el backend. Segunda: ¿es factible un cambio en la API backend dentro del plazo? Si es una adición simple, lo comentaría con el equipo backend para ver si podemos coordinarlo. Tercera: ¿podemos ajustar el diseño para que funcione con los datos disponibles sin comprometer la experiencia de usuario? Presentaría la limitación y las alternativas al diseñador y al PM con mi recomendación. Lo que no haría: parchearlo con múltiples llamadas a la API, joins en el lado del cliente o trucos de caché que generan deuda técnica. Si la solución correcta es un cambio en el backend, defenderlo es parte de mi trabajo.

Respuesta modelo

Evitaría el vocabulario técnico por completo. Usaría una analogía: «Es como pedir añadir una puerta a una habitación: la puerta en sí es sencilla, pero implica mover el cableado eléctrico y posiblemente ajustar la pared de carga del edificio.» Luego sería concreto con los plazos: «El botón en sí son 30 minutos de trabajo. Pero los datos que necesita no existen aún en el sistema, y construir el flujo para obtenerlos son aproximadamente 2 semanas.» También presentaría opciones: «Podríamos lanzar una versión más sencilla que use los datos existentes la semana que viene, o la versión completa que imaginas en 3 semanas. ¿Cuál prefieres?» La clave es ser honesto sobre la complejidad sin hacer que el stakeholder se sienta torpe por preguntar. No necesita entender por qué es complejo: necesita entender el plazo y sus opciones.

Respuesta modelo

Lo evaluaría en cinco dimensiones, no por el hype. Primera, preparación del equipo: ¿cuánto tiempo de aprendizaje requiere el nuevo framework? Si el equipo conoce React y estamos considerando Svelte, eso supone entre 4 y 6 semanas de productividad reducida. ¿El calendario es suficientemente flexible? Segunda, madurez del ecosistema: ¿existen librerías para el enrutamiento, la gestión del estado, el manejo de formularios y las pruebas? ¿Podemos encontrar respuestas en Stack Overflow? Tercera, contratación: ¿podemos encontrar ingenieros que conozcan este framework? React tiene un grupo de talento mucho mayor que Solid o Qwik. Cuarta, rendimiento: ¿resuelve el nuevo framework un problema de rendimiento real que tenemos? Si nuestra aplicación React ya es suficientemente rápida, cambiar por benchmarks es una optimización prematura. Quinta, longevidad: ¿cuenta con el respaldo de una organización o comunidad estable? ¿Cuál es la frecuencia de commits, el número de contribuidores y la adopción empresarial? Haría un prototipo de una funcionalidad representativa en el framework actual y en el propuesto, mediría la velocidad de desarrollo real y el rendimiento, y presentaría la comparación al equipo. La decisión debe basarse en datos, no en tendencias.

Respuesta modelo

Lo abordaría de forma proactiva en lugar de esperar a que se convierta en un problema. Compilaría una lista breve de problemas de accesibilidad concretos que puedo ver en los mockups: estados de foco ausentes, contraste de color insuficiente, iconos sin etiquetas de texto, campos de formulario sin etiquetas visibles. Luego lo comentaría con el diseñador de forma constructiva: «He detectado algunos problemas de accesibilidad que deberíamos resolver antes del desarrollo. Aquí están los puntos concretos.» Propondría soluciones, no solo problemas: «Este botón necesita un anillo de foco; aquí te muestro cómo podría verse. Este texto tiene un contraste de 3,2:1 pero necesita 4,5:1; oscurecerlo dos tonos lo resolvería.» Si el diseñador objeta por los plazos, explicaría el riesgo legal y de negocio: las demandas por accesibilidad están en aumento, y corregir la accesibilidad después del desarrollo cuesta entre 3 y 5 veces más que incluirla desde el principio. También configuraría verificaciones de accesibilidad automatizadas (axe-core en CI) para evitar regresiones.