¿Cómo decides cuándo usar un framework o librería frente a escribir algo desde cero?

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.

¿Cómo abordas la optimización del rendimiento en una aplicación web?

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.

¿Cómo abordas la autenticación y la autorización en una aplicación web?

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.

Cuéntame sobre una funcionalidad full-stack que hayas construido de extremo a extremo. Explícame las decisiones que tomaste.

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.

Describe una ocasión en que tuviste que depurar un problema difícil en producción. ¿Cómo lo abordaste?

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.

Da un ejemplo de una decisión técnica que tomaste y que cambiarías en retrospectiva.

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.

¿Cómo abordas el diseño de una API REST?

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.

¿Cómo redactas y mantienes pruebas para código full-stack?

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.

¿Cómo gestionas el diseño de base de datos y las migraciones en un sistema de producción?

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.

Desarrollador full-stack

Las entrevistas para Desarrollador Full-Stack cubren los fundamentos de front-end y back-end, el pensamiento sobre el diseño de sistemas y tu capacidad para tomar decisiones técnicas sólidas en toda la capa de producto. Los entrevistadores quieren ver que puedes construir funcionalidades de extremo a extremo, depurar a través de la pila y trabajar eficazmente con los equipos de producto y diseño. Esta guía cubre las preguntas más frecuentes y las respuestas que demuestran experiencia real full-stack.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Preguntas de entrevista habituales para Desarrollador full-stack

Preguntas conductuales para puestos de Desarrollador full-stack

Preguntas técnicas para candidatos a Desarrollador full-stack

Lo que buscan los reclutadores en las entrevistas para Desarrollador full-stack

Los desarrolladores full-stack que destacan pueden razonar sobre las compensaciones a través de toda la pila, no solo ejecutar dentro de una capa. Busca candidatos que expliquen por qué tomaron una decisión técnica, no solo qué construyeron. Pídeles que describan una funcionalidad real que poseen de extremo a extremo y sondea el razonamiento en cada capa. Los mejores desarrolladores full-stack también están cómodos admitiendo que son más fuertes en un lado de la pila que en el otro.

Preguntas que puedes hacer al entrevistador

→¿Cómo es la pila tecnológica actual y hay alguna migración o refactorización planificada?
→¿Cómo se divide el trabajo de front-end y back-end en el equipo?
→¿Cómo es la cobertura de pruebas y cuál es el enfoque del equipo respecto a la calidad?
→¿Cómo se gestionan los despliegues en producción y cómo funciona la guardia?
→¿Cómo es una funcionalidad típica de extremo a extremo, desde el ticket hasta la producción?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis para empezar. Sin compromiso.

Puestos relacionados

Ingeniero de software

Tech9 preguntas

Desarrollador frontend