Preguntas de entrevista Desarrollador full-stack

Parto del alcance del problema. Si el problema está bien definido y una librería madura lo resuelve de forma fiable, uso la librería: reinventar problemas ya resueltos desperdicia tiempo e introduce código no probado. Los factores que evalúo son: ¿cuán bien mantenida está la librería (commits recientes, issues activos, comunidad grande?), ¿se ajusta a nuestros requisitos de escala, y cuál es el coste en bundle si estamos en el front-end? Soy especialmente cauteloso con incluir dependencias grandes para pequeñas utilidades. Para un caso de formateo de fechas no añadiría una librería de utilidades completa si la API nativa Intl gestiona el caso de uso. Para cosas como la gestión de estado o el manejo HTTP, una librería consolidada suele ganar porque esas superficies están llenas de casos límite. También considero la propiedad a largo plazo.

Siempre empiezo midiendo antes de optimizar. La optimización prematura basada en suposiciones lleva a cambios que hacen el código más difícil de leer sin mejorar la experiencia de usuario. Mi kit de herramientas empieza con Lighthouse y las DevTools del navegador para el front-end: miro los Core Web Vitals (LCP, INP y CLS). Para el back-end perfilo consultas lentas, reviso los problemas N+1 en los patrones de acceso a la base de datos y compruebo si los cálculos costosos se repiten innecesariamente. Soluciones habituales de front-end: división del código y carga diferida, optimización de imágenes y reducción de re-renders innecesarios. En el back-end: indexación de consultas, caché en la capa apropiada y mover el procesamiento pesado a jobs en segundo plano. Documento las líneas base de rendimiento antes y después de cualquier trabajo de optimización.

Trato la autenticación y la autorización como preocupaciones diferentes. La autenticación responde a "¿quién eres?" y la autorización a "¿qué tienes permitido hacer?" Para la autenticación me decanto por defecto por un proveedor bien mantenido (como Auth0, Supabase Auth o Clerk) en lugar de desarrollarlo desde cero, porque la gestión de sesiones, la rotación de tokens y los flujos OAuth tienen demasiados casos límite de seguridad. Uso JWT para autenticación sin estado con tiempos de expiración cortos y los almaceno en cookies HTTP-only para evitar el acceso XSS. Para la autorización implemento control de acceso basado en roles en la capa de API, no solo en el front-end. El control del lado del front-end es una comodidad de UX, no un control de seguridad.

Construí un sistema de notificaciones en tiempo real para un panel de control interno. Los requisitos eran: enviar notificaciones a los usuarios cuando ocurriera un evento en un sistema conectado, mostrar el número de notificaciones no leídas en la barra de navegación y marcarlas como leídas al hacer clic. Para el back-end elegí WebSockets sobre el polling porque necesitábamos entrega en tiempo real y el número de usuarios conectados era suficientemente bajo para que la sobrecarga de conexión no fuera un problema. Construí un event emitter en Node.js que escuchaba los eventos de cambio de base de datos a través de un disparador de Postgres y los enviaba a través de una conexión de socket al cliente. En el front-end usé React Context con un patrón reducer para las actualizaciones optimistas de marcar como leído. Añadí un endpoint REST de respaldo para obtener la lista inicial al cargar la página. La funcionalidad se lanzó sin regresiones y redujo los tickets de soporte aproximadamente un 70% en el primer mes.

Teníamos un problema en producción donde un subconjunto de usuarios recibía datos obsoletos en una página de mucha lectura, pero solo después de estar activos más de 30 minutos en la misma sesión. Primero reproduje el problema localmente con una sesión de larga duración. Luego aislé la ruta de código afectada: los datos se obtenían al montar el componente y se almacenaban en estado local sin lógica de actualización. La causa raíz era una caché a nivel de sesión que se había aplicado a un tipo de dato que podía cambiar durante una sesión. La corrección fue añadir un disparador de invalidación de caché en el evento de mutación relevante. También añadí una alerta de monitorización para la tasa de éxito de caché en ese endpoint para detectar cualquier regresión futura. Tras la corrección, el problema se resolvió para el 100% de los usuarios afectados en un único despliegue.

Al inicio de mi carrera construí una funcionalidad usando renderizado del lado del cliente para una página que necesitaba posicionarse en los resultados de búsqueda. Elegí CSR porque el equipo ya usaba una SPA en React y quería mantener la coherencia con la arquitectura existente. Seis meses después descubrimos que la página no se indexaba correctamente porque el crawler no ejecutaba JavaScript de forma fiable. Tuvimos que reconstruir usando renderizado del lado del servidor. La reconstrucción tardó tres semanas y retrasó otras funcionalidades. La lección fue identificar siempre los requisitos de renderizado antes de elegir una arquitectura: CSR, SSR, SSG e ISR tienen casos de uso específicos y la decisión debe ser deliberada. Ahora añado una pregunta sobre la estrategia de renderizado a mi lista de verificación para cualquier nueva página o ruta.

Sigo un diseño orientado a recursos donde los endpoints representan entidades, no acciones. Uso correctamente los verbos HTTP: GET para lecturas, POST para creaciones, PUT/PATCH para actualizaciones, DELETE para eliminaciones. Para los códigos de estado sigo el estándar: 200 para éxito, 201 para creado, 400 para errores del cliente, 404 para no encontrado, 401 para no autenticado, 403 para no autorizado, 500 para errores del servidor. Siempre versiono las APIs desde el principio. Para la paginación uso la paginación por cursor para grandes conjuntos de datos en lugar de la paginación por offset, porque la paginación por offset se vuelve inconsistente cuando se añaden o eliminan registros durante la paginación. También documento el contrato de API antes de construirlo: fuerza un pensamiento más claro.

Sigo una pirámide de pruebas: muchas pruebas unitarias, menos pruebas de integración y un pequeño número de pruebas end-to-end. Las pruebas unitarias cubren funciones puras y renderizado aislado de componentes. Las pruebas de integración cubren rutas de API con una base de datos de prueba y la lógica de la capa de servicios. Las pruebas end-to-end cubren solo los recorridos de usuario críticos: inicio de sesión, acción principal y flujo de conversión, usando herramientas como Playwright. Para la cobertura no persigo un objetivo en porcentaje; busco cubrir cada resultado visible para el usuario y cada estado de error. También escribo pruebas antes de corregir errores: una prueba fallida que reproduce el error es la prueba de que la corrección funciona y un salvaguarda contra las regresiones.

Diseño los esquemas pensando en la evolución futura: las columnas que admiten null son más baratas de añadir después, las restricciones de clave foránea se aplican mejor en la base de datos que en el código de la aplicación, y añadir un índice a una tabla de producción existente requiere cuidado para evitar bloqueos. Para las migraciones uso una herramienta dedicada (como Flyway, Alembic o el sistema de migración del ORM) en lugar de ejecutar SQL sin procesar manualmente, y cada migración está bajo control de versiones y se revisa antes de producción. También distingo entre migraciones de esquema y migraciones de datos: los cambios de esquema deben ser retrocompatibles donde sea posible para que una reversión sea segura. Uso un patrón añadir-antes-de-eliminar para los cambios de columna. Siempre pruebo las migraciones con un snapshot de los datos de producción antes de aplicarlas.