¿Cómo decides qué lógica va en el frontend y qué lógica va en el backend?

Lógica que involucra seguridad, acceso a datos, reglas de negocio críticas o cálculos que no deben ser manipulables por el cliente siempre va en el backend. El frontend maneja presentación, interacciones de UI y validaciones de conveniencia (no de seguridad). La regla general: nunca confíes en datos que vienen del cliente sin validarlos también en el servidor.

¿Qué ventajas y limitaciones tiene un enfoque fullstack frente a equipos especializados?

Ventajas: menor coordinación, mayor velocidad en features pequeñas, visión coherente del sistema. Limitaciones: el fullstack raramente alcanza la profundidad de un especialista en cada capa. En sistemas de alta escala o con requerimientos de performance muy exigentes, la especialización aporta más valor. El fullstack es más efectivo en productos en crecimiento que en sistemas maduros de alto tráfico.

¿Cómo estructurarías un proyecto fullstack nuevo para que sea mantenible a medida que crece el equipo?

Separar responsabilidades desde el inicio: frontend y backend en proyectos distintos o con boundaries claros incluso en un monorepo. Definir contratos de API con tipado compartido (TypeScript, OpenAPI). Separar la lógica de negocio de los handlers HTTP y los componentes de UI. Establecer convenciones de naming, estructura de carpetas y proceso de code review antes de que el equipo crezca.

¿Cómo manejarías el estado de autenticación de un usuario a través de las capas frontend y backend?

El token de sesión o JWT se emite en el backend tras autenticación exitosa. En el frontend se almacena de forma segura (httpOnly cookie para máxima seguridad) y se envía en cada request. El backend valida el token en cada endpoint protegido. El frontend solo usa el estado de autenticación para decisiones de UI, nunca como control de acceso real.

¿Qué estrategia usarías para sincronizar los tipos de datos entre el frontend y el backend en TypeScript?

Definir los tipos o interfaces en un paquete compartido dentro de un monorepo (turborepo, nx) o publicarlos como paquete interno. Alternativamente, generar tipos automáticamente desde el schema de la API (OpenAPI → TypeScript con openapi-typescript, o tRPC para type-safety end-to-end sin generación de código).

¿Cómo abordarías el debugging de un bug que puede estar en el frontend, el backend o la capa de datos?

Aislar la capa del problema sistemáticamente: verificar si la API devuelve los datos correctos con una herramienta como Postman o curl antes de mirar el frontend. Si la API falla, revisar los logs del servidor y el query generado. Si la API es correcta pero el frontend muestra mal los datos, el bug está en la capa de presentación o transformación. El objetivo es reducir el espacio de búsqueda antes de revisar código.

¿Qué consideraciones tendrías al elegir entre un monorepo y repositorios separados para un proyecto fullstack?

Monorepo facilita compartir tipos, herramientas y pipelines, y permite cambios atómicos que afectan frontend y backend en un solo commit. Repositorios separados simplifican el acceso por equipo y los pipelines independientes. La decisión depende del tamaño del equipo y la frecuencia de cambios que afectan ambas capas. Para equipos pequeños o proyectos con mucho código compartido, el monorepo suele ganar.

¿Cómo priorizarías qué aprender para crecer como fullstack cuando tienes más fortaleza en una capa que en otra?

Identificar cuál es el cuello de botella en tu trabajo actual: si el frontend te bloquea para entregar features, prioriza ahí. Aprender la capa débil a través de tareas reales, no solo tutoriales. Buscar proyectos donde sea inevitable tocar esa capa. Un fullstack efectivo no necesita ser 10x en ambas capas, sino suficientemente competente para no depender de otro para avanzar.

¿Cómo implementarías una feature de upload de archivos que requiere cambios en frontend, backend y almacenamiento?

Frontend: input file con validación de tipo y tamaño antes de enviar, barra de progreso con XMLHttpRequest o fetch streaming. Backend: endpoint que valida el archivo (magic bytes, tamaño), lo sube a S3 o equivalente usando presigned URLs (el cliente sube directamente al storage, no al servidor), y guarda la referencia en BD. Nunca guardar archivos en el filesystem del servidor en producción.

¿Qué diferencias prácticas tiene usar tRPC frente a una API REST tradicional en un proyecto fullstack TypeScript?

tRPC elimina la capa de generación o mantenimiento de tipos de API: los tipos del backend se infieren automáticamente en el frontend sin codegen. El trade-off es que solo funciona cuando cliente y servidor comparten el mismo lenguaje (TypeScript) y típicamente el mismo monorepo. REST sigue siendo la opción correcta si la API debe ser consumida por clientes externos, móvil nativo o terceros.

¿Cómo manejarías la sincronización de datos en tiempo real entre el servidor y múltiples clientes en una app fullstack?

Para datos que cambian con frecuencia y baja latencia: WebSockets con Socket.io o WebSocket nativo. Para actualizaciones menos frecuentes: Server-Sent Events (unidireccional, más simple). Para casos donde la consistencia eventual es aceptable: polling con React Query o SWR. La elección depende de la frecuencia de actualización, el número de clientes concurrentes y la complejidad de infraestructura aceptable.

¿Cómo diseñarías la gestión de errores end-to-end para que los errores del backend se presenten de forma útil al usuario?

Definir un formato de error estructurado en el backend (código, mensaje, detalles opcionales). En el frontend, un interceptor o wrapper de fetch normaliza todos los errores a ese formato. Los componentes muestran mensajes de error específicos para errores de negocio (409 conflict, 422 validation) y mensajes genéricos para errores inesperados (500). Registrar los errores 5xx con contexto en un sistema de observabilidad.

¿Cómo implementarías autorización basada en roles donde el mismo sistema de permisos aplica tanto en el backend como en el frontend?

La fuente de verdad de los permisos es siempre el backend. El token incluye los roles del usuario como claims. El backend los valida en cada request protegido. El frontend usa los mismos claims para decisiones de UI (mostrar/ocultar elementos), pero nunca como control de acceso real. Una utilidad compartida de evaluación de permisos puede usarse en ambas capas para consistencia.

¿Qué estrategias de caching aplicarías en un stack fullstack para reducir la carga en la base de datos?

En el cliente: React Query o SWR con stale-while-revalidate para evitar requests repetidos. En el servidor: caché de respuestas de API con Redis para queries costosas con baja frecuencia de cambio. En la BD: índices correctos y query result cache del motor. La estrategia depende del perfil de lectura/escritura: datos que cambian poco y se leen mucho se benefician más del caching.

¿Cómo organizarías el testing en un proyecto fullstack para tener cobertura útil sin over-testing?

Backend: unit tests de lógica de negocio pura, tests de integración de endpoints con una BD de test real (no mocks). Frontend: tests de componentes con Testing Library enfocados en comportamiento de usuario, no en implementación. E2E con Playwright o Cypress para flujos críticos como registro, login y checkout. Evitar duplicar cobertura: si el backend tiene tests de integración sólidos, no es necesario mockear la API completa en el frontend.

¿Cómo abordarías la paginación de datos que se consumen tanto en una vista web como en una API pública?

Diseñar la paginación en el backend con un formato consistente (cursor o page-based con metadatos: total, next_cursor, has_more) que funcione para ambos consumidores. En la vista web, React Query o SWR pueden abstraer la paginación con useInfiniteQuery. El formato del response debe ser el mismo independientemente del consumidor; la diferencia está en cómo cada cliente lo presenta.

¿Cómo decidirías si un proyecto debería adoptar una arquitectura fullstack monolítica o separar el frontend y backend como proyectos independientes?

Monolito fullstack (Next.js, Nuxt, Remix): menor complejidad operacional, deploy unificado, ideal para equipos pequeños o productos donde el frontend y backend evolucionan juntos. Separación: necesaria cuando el backend debe ser consumido por múltiples clientes (web, móvil, terceros), cuando los equipos de frontend y backend son independientes, o cuando el escalado de cada capa requiere estrategias distintas. La separación tiene un costo real de coordinación que debe justificarse.

¿Cómo diseñarías la arquitectura de datos de una aplicación fullstack que necesita funcionar offline y sincronizarse cuando hay conexión?

Implementar una capa de almacenamiento local (IndexedDB via Dexie, SQLite con OPFS) que sirve como fuente de verdad en el cliente. Al reconectar, sincronizar con el servidor resolviendo conflictos con una estrategia definida: last-write-wins, CRDT, o resolución manual para conflictos de alto riesgo. El servidor debe exponer un endpoint de sync que acepte un vector de cambios y devuelva los cambios del servidor desde el último sync.

¿Cómo escalarías una aplicación fullstack construida inicialmente como monolito cuando empieza a tener cuellos de botella?

Antes de descomponer en microservicios, agotar las opciones dentro del monolito: escalado horizontal, optimización de queries, caching, CDN para assets estáticos. Si el cuello de botella es específico (ej. procesamiento de imágenes, envío de emails), extraer ese servicio primero. El strangler fig pattern permite extraer partes del monolito incrementalmente sin reescritura completa. La separación prematura añade complejidad sin resolver el problema real.

¿Cómo implementarías feature flags que controlen comportamiento tanto en el frontend como en el backend de forma coordinada?

Usar un servicio centralizado de feature flags (LaunchDarkly, Unleash, o propio). El backend evalúa los flags en el contexto del usuario y los incluye en la respuesta de un endpoint de configuración que el frontend consume al iniciar sesión. Ambas capas usan la misma evaluación. Nunca evaluar flags solo en el cliente para features con implicaciones de seguridad o facturación, ya que el cliente puede ser manipulado.

¿Cómo garantizarías la consistencia de datos en una aplicación fullstack con operaciones optimistas en el frontend?

Las actualizaciones optimistas en el cliente (React Query mutation con rollback) mejoran la experiencia de usuario pero requieren un mecanismo de reconciliación. Si el servidor rechaza la operación, el cliente debe revertir el estado local y notificar al usuario. Para operaciones críticas (pagos, reservas), evitar la UI optimista o implementar un mecanismo de confirmación antes de mostrar el resultado como definitivo. El backend es siempre la fuente de verdad.

¿Cómo estructurarías el manejo de sesiones y estado de autenticación en una aplicación Next.js con rendering tanto en servidor como en cliente?

Con App Router: las cookies httpOnly están disponibles en Server Components y Route Handlers via cookies() de next/headers. El servidor puede validar la sesión sin exponer el token al cliente. En Client Components, el estado de sesión se expone a través de un provider que consume un endpoint seguro o el contexto de next-auth. La regla: validación real de sesión siempre en el servidor, el cliente solo recibe lo que necesita para renderizar la UI.

Presentarse como fullstack sin poder profundizar en ninguna capa específica

Decir 'sé de todo' sin demostrar solidez en al menos una capa genera desconfianza. Los entrevistadores esperan que un fullstack tenga una capa de mayor fortaleza y pueda justificarlo. La amplitud sin ninguna profundidad es la señal más frecuente de un desarrollador que ha usado frameworks sin entender lo que hay debajo.

Ignorar la seguridad al diseñar features que atraviesan frontend y backend

Proponer soluciones como almacenar tokens en localStorage, validar permisos solo en el cliente o confiar en parámetros de URL para decisiones de autorización son errores graves. En un rol fullstack, el candidato debe demostrar que entiende el modelo de amenazas de cada capa.

No considerar el impacto de cambios de API en el frontend al proponer cambios en el backend

Un fullstack que propone breaking changes en una API sin mencionar la migración del frontend ni el versionado demuestra que trabaja en silos mentales a pesar de manejar ambas capas. La ventaja del fullstack es precisamente la visión end-to-end.

Asumir que fullstack significa que todos los proyectos deberían ser monolitos

Defender siempre el monolito como arquitectura correcta por comodidad, sin evaluar cuándo la separación de responsabilidades aporta más valor, es una señal de sesgo de experiencia limitada. El criterio correcto es elegir la arquitectura adecuada al contexto, no la más familiar.

No tener criterio sobre cuándo escalar la solución y cuándo llamar a un especialista

Un fullstack efectivo sabe cuándo un problema requiere a un DBA, un especialista en seguridad o un ingeniero de infraestructura. Proponer soluciones fullstack para problemas que requieren especialización profunda es tan problemático como no poder resolver nada sin especialistas.

Describir proyectos pasados sin poder explicar las decisiones de arquitectura de ninguna capa con profundidad

Es frecuente que candidatos fullstack describan proyectos completos pero no puedan explicar por qué eligieron esa base de datos, cómo modelaron el schema, o por qué estructuraron la UI de esa forma. Eso sugiere que ejecutaron sin comprender, lo que genera dudas sobre su capacidad para tomar buenas decisiones en el próximo proyecto.

Desarrollador Full Stack

Diseña y construye productos digitales de extremo a extremo, desde la interfaz hasta la infraestructura de datos.

Un Fullstack Developer tiene la capacidad de trabajar en todas las capas de una aplicación: frontend, backend y base de datos. No es necesariamente un experto absoluto en cada capa, pero posee el criterio técnico para tomar decisiones coherentes en todo el stack y reducir la fricción entre equipos. Es especialmente valioso en startups, equipos pequeños o proyectos donde la velocidad de entrega y la visión integral del producto son prioritarias. Colabora con diseñadores, product managers y DevOps para llevar features completas desde el diseño hasta producción.

JavaScriptTypeScriptReactNode.jsPostgreSQLDocker

Recluta al mejor Desarrollador Full Stack aquí

Empieza ahora

Responsabilidades Principales

•Implementar features completas que abarcan cambios en UI, lógica de negocio y modelo de datos de forma coherente.
•Diseñar e integrar APIs REST o GraphQL consumidas por el frontend que el mismo desarrollador construye.
•Modelar esquemas de base de datos y escribir queries optimizadas alineadas con los patrones de acceso del producto.
•Identificar y resolver problemas de rendimiento tanto en el cliente como en el servidor.
•Participar en decisiones de arquitectura evaluando el impacto en todas las capas del sistema.
•Mantener pipelines de CI/CD y garantizar que los cambios en cualquier capa pasen por testing automatizado antes de producción.

Habilidades Clave

Technical Skills

Desarrollo frontend con React, Vue o Angular y manejo de estado en aplicaciones de mediana y gran escala
Desarrollo backend con Node.js, Python o equivalente: APIs REST/GraphQL, autenticación y lógica de negocio
Bases de datos relacionales (PostgreSQL, MySQL) y no relacionales (MongoDB, Redis) con criterio para elegir según el caso
Contenerización con Docker y despliegue en plataformas cloud (AWS, GCP, Vercel, Railway)
TypeScript como lenguaje unificado entre frontend y backend para contratos de datos compartidos
Testing en ambas capas: unit tests, tests de integración de API y tests de componentes con Testing Library

Soft Skills

Visión de producto end-to-end para anticipar el impacto de una decisión técnica en la experiencia del usuario final
Autonomía para llevar una feature de principio a fin sin depender de otro equipo para cada capa
Comunicación clara al trabajar como puente entre especialistas de frontend, backend y diseño
Gestión del foco: saber cuándo profundizar en una capa y cuándo avanzar con una solución suficientemente buena
Adaptabilidad para cambiar de contexto entre capas del stack dentro del mismo día de trabajo
Criterio para identificar cuándo un problema requiere a un especialista en lugar de una solución fullstack

Casos de uso reales

Contexto

En startups o productos nuevos, la velocidad de iteración es más valiosa que la especialización. Un fullstack puede construir y validar features completas sin coordinación entre equipos separados.

Ejemplos reales

Aplicaciones web con autenticación, CRUD y dashboard en un solo repositorio
Landing pages con formularios conectados a un backend propio
Prototipos funcionales para validación con usuarios reales
Integraciones rápidas con servicios de terceros (Stripe, Twilio, SendGrid)

Contexto

Muchas empresas tienen aplicaciones donde frontend y backend conviven en el mismo repositorio. Un fullstack puede navegar y evolucionar ese codebase sin fricciones.

Ejemplos reales

Aplicaciones Rails, Django o Laravel con templates y lógica en el mismo stack
Migraciones incrementales de vistas server-rendered a componentes React
Optimización de queries y mejora de UI en el mismo ciclo de desarrollo
Resolución de bugs que atraviesan múltiples capas del sistema

Contexto

Conectar un producto con servicios de pago, notificaciones, analytics o autenticación de terceros requiere cambios en backend y frontend de forma coordinada.

Ejemplos reales

Implementación de checkout con Stripe: webhook en backend y UI de pago en frontend
Integración de OAuth2 con Google o GitHub desde el flujo de login
Setup de sistema de emails transaccionales con Resend o SendGrid
Implementación de feature flags con LaunchDarkly en cliente y servidor

Contexto

Las herramientas internas necesitan ser funcionales y mantenibles, no necesariamente perfectas en diseño. El fullstack puede entregar valor rápido sin depender de múltiples especialistas.

Ejemplos reales

Paneles de administración con gestión de usuarios, roles y contenido
Dashboards operacionales con tablas, filtros y exportación de datos
Herramientas de soporte para que el equipo de CS gestione cuentas y pedidos
Sistemas de reportes internos con visualizaciones básicas

Contexto

En equipos con ciclos de iteración cortos, un fullstack puede implementar una feature completa en un sprint sin esperar a que otro equipo termine su parte.

Ejemplos reales

Nuevas vistas con endpoints dedicados desarrolladas por la misma persona
Experimentos A/B que requieren cambios en UI y en lógica de tracking
Features de onboarding con lógica en backend y flujo guiado en frontend
Integraciones de analytics que requieren eventos en cliente y validación en servidor