Preguntas de entrevista para Desarrollador Full Stack

Respuesta modelo

Para mí significa poder llevar una funcionalidad desde el refinamiento con producto hasta la monitorización en producción sin necesitar a otras tres personas por el camino. Ahora bien, amplitud no es uniformidad: mi profundidad está en el backend y en la capa de datos, sobre todo en modelado y rendimiento de PostgreSQL, donde soy la persona de referencia de mi equipo. En front soy plenamente autónomo con React y Next.js (monto la interfaz, la pruebo y la optimizo), pero si hay que discutir accesibilidad avanzada o un sistema de diseño desde cero, prefiero que lidere alguien especialista y aportar yo desde la integración. Esa distinción la hago explícita desde el primer día porque evita expectativas equivocadas dentro del equipo.

Respuesta modelo

Rediseñé el flujo de pago de una plataforma de reservas. Empecé por el contrato de la API con el equipo de producto porque el punto crítico era la idempotencia: había cobros duplicados cuando el usuario reintentaba. Decidí guardar el intento de pago como entidad propia con una clave de idempotencia en lugar de resolverlo en el cliente, que era la propuesta inicial y más rápida, porque no protegía frente a reintentos desde otro dispositivo. Después implementé el servicio en Node.js, el checkout en React, la migración en PostgreSQL con estrategia de ampliar y contraer para no cortar servicio, y dejé alertas en Grafana sobre la tasa de pagos fallidos. Pasamos del 4,1 % al 1,3 % de fallos en dos meses y el abandono en el último paso bajó un 18 %.

Respuesta modelo

Con una regla que me funciona: profundizo de forma deliberada en un solo frente cada trimestre y en el otro me limito a seguir las novedades sin perseguirlas. Este año he dedicado el esfuerzo serio a rendimiento de bases de datos, leyendo planes de ejecución en producción y midiendo, mientras que en front me he quedado con lo estable y he adoptado los componentes de servidor solo cuando ya tenía un caso de uso claro. Además, apoyarme en el equipo forma parte del método: en las revisiones de código de front pido explícitamente la opinión de nuestra especialista, y a cambio yo reviso todo lo que toca modelo de datos. No intento saberlo todo a la vez, intento no acumular puntos ciegos peligrosos.

Respuesta modelo

Sigo tres criterios en este orden. Primero, la confianza: cualquier regla que afecte a dinero, permisos o integridad va al servidor o a la base de datos, aunque la duplique en el cliente para dar buena experiencia. Segundo, el coste de cambiarla: si es una regla de negocio que producto va a tocar cada mes, la quiero en un único sitio, normalmente en la capa de dominio del backend, y no repartida entre validaciones de formulario. Y tercero, el volumen de datos: si para calcular algo hay que mover miles de filas, lo resuelvo en la base de datos con una consulta bien pensada en vez de traérmelo a memoria. El caso que más me repito: las validaciones de formulario se duplican a propósito, front por experiencia de usuario y back por seguridad, y esa duplicación es deliberada, no un descuido.

Respuesta modelo

Me pongo un límite de tiempo antes de empezar, normalmente dos horas, y en ese rato intento acotar el problema hasta poder describirlo con precisión: qué esperaba, qué ocurre y qué he descartado. Si no lo resuelvo, pido ayuda con ese resumen ya preparado, porque hace que la conversación dure diez minutos en lugar de una hora. En una migración de infraestructura a ECS me pasó con la red: llevaba media mañana con un problema de grupos de seguridad, escribí lo que había probado, se lo llevé a la persona de plataforma y lo cerramos en un cuarto de hora. Lo que intento evitar es el silencio de dos días, que en un equipo pequeño es lo que de verdad hace daño.

Respuesta modelo

Traduzco la petición a opciones con coste, nunca a un no. En la última planificación pidieron un panel con datos en tiempo real para dos semanas después; expliqué que el tiempo real de verdad exigía websockets, cambios en la ingesta y trabajo de infraestructura que no cabía, y ofrecí tres caminos: refresco cada treinta segundos en una semana, tiempo real completo en cinco semanas, o una versión intermedia con actualización al interactuar. Producto eligió la primera para llegar a la feria del sector y planificamos la completa para el trimestre siguiente. Ser full stack ayuda mucho aquí, porque puedo estimar las dos mitades y la infraestructura sin depender de tres estimaciones ajenas.

Respuesta modelo

Vengo de tres años en consultoría, que me dieron variedad y mucha soltura para entrar en código ajeno, y tres años en producto, donde he visto lo que aporta sostener el mismo servicio durante mucho tiempo. Quiero seguir en producto, en un equipo donde la persona que desarrolla también despliega y responde de lo que hay en producción, porque es donde mejor rindo. Concretamente busco un producto con carga real, un equipo pequeño con propiedad clara y espacio para profundizar en datos y rendimiento sin dejar de tocar el front. De su empresa me interesa justo eso, y por eso quería preguntarle cómo está repartida hoy la responsabilidad de las guardias.

Empiezo por el caso de uso de la pantalla, no por las tablas: si el detalle de reserva necesita seis datos, el endpoint devuelve esos seis y no el modelo entero. Documento el contrato en OpenAPI y genero los tipos de TypeScript a partir del esquema, de forma que un cambio incompatible rompe la compilación del front antes de llegar a producción. Para evolucionar aplico la regla de solo añadir: campos nuevos opcionales, nada de renombrar ni de cambiar el tipo de un campo existente. Cuando el cambio es inevitable, versiono la ruta, mantengo las dos versiones durante un tiempo acordado y mido el uso de la antigua para saber cuándo puedo retirarla. Si hay varios consumidores muy distintos, valoro un BFF antes que llenar la API general de parámetros condicionales.

Mido antes de tocar nada, capa por capa, porque en full stack la causa puede estar en cualquiera. Empiezo por la pestaña de red y las trazas de usuario real: si el retardo está en el primer byte, el problema es de servidor y bajo a las trazas del backend y al plan de ejecución de las consultas, donde lo más frecuente es un N+1 o un índice ausente. Si el primer byte llega rápido y lo lento es el renderizado, miro el tamaño del paquete de JavaScript, las fuentes bloqueantes y las imágenes sin dimensionar. Un caso real: 1.900 ms de percentil 95 que eran cuatro consultas N+1 en la búsqueda de disponibilidad; con índices parciales, la consulta reescrita y caché en Redis bajó a 240 ms. La regla que aplico es no optimizar nada sin una medición previa que demuestre dónde está el coste.

Depende de a qué necesite responder el sistema. Con sesiones en servidor tengo revocación inmediata y control total, a cambio de un almacén compartido (normalmente Redis) y de pensar la escalabilidad horizontal. Con JWT gano ausencia de estado y validación barata en varios servicios, pero pierdo la revocación instantánea, lo que obliga a tokens de vida corta con tokens de refresco y a una lista de revocación que, en la práctica, vuelve a introducir el estado que quería evitar. Para una aplicación web con un solo backend elijo sesiones en cookie HttpOnly con SameSite estricto, porque es más simple y más segura frente a XSS. Reservo el JWT para comunicación entre servicios o para clientes móviles con varios backends. Lo que nunca hago es guardar un token de acceso en localStorage.

Con la estrategia de ampliar y contraer, en tres despliegues. Primero amplío: añado la columna nueva como opcional, sin tocar nada más, y despliego. Segundo, escribo en ambos sitios y relleno los datos históricos en lotes pequeños, vigilando la carga y con posibilidad de pausar; solo cuando la nueva columna está completa y validada cambio la lectura. Tercero, contraigo: elimino la escritura antigua y por último la columna, ya sin código que dependa de ella. Los cambios que bloquean tablas grandes los ejecuto con las variantes concurrentes cuando el motor lo permite (por ejemplo, creación de índices sin bloqueo en PostgreSQL) y siempre fuera de la hora punta. Cada paso tiene su vuelta atrás definida antes de lanzarlo; si un despliegue no se puede revertir, no sale.

Prácticamente siempre que el equipo sea pequeño y el dominio no esté asentado. Con menos de diez o quince personas, los microservicios añaden coste de despliegue, de observabilidad, de consistencia de datos y de depuración distribuida que no se compensa con ninguna ventaja real. Mi opción por defecto es un monolito modular con fronteras internas claras, un módulo por dominio, comunicación explícita entre ellos y prohibición de acceder a las tablas de otro módulo; así, cuando de verdad haga falta extraer uno, el corte ya está hecho. Partiría solo si hay una razón concreta: un componente con un perfil de escalado muy distinto, un requisito de aislamiento por normativa, o dos equipos que se estorban de forma sistemática en el mismo despliegue. En mi último proyecto extraje tres servicios de un monolito PHP en nueve meses, pero solo esos tres y con la métrica de dolor identificada antes de empezar.

Trabajo con cuatro niveles y decido en cada uno qué tolerancia a datos obsoletos acepta el negocio. En el navegador y en la CDN, todo lo estático con huella en el nombre y caducidad larga; el HTML, con revalidación. En la aplicación, caché de datos que se consultan mucho y cambian poco, típicamente catálogo y configuración, en Redis. Y en la base de datos, vistas materializadas solo para agregados caros. Para invalidar prefiero la caducidad corta más la invalidación por evento cuando el dato es sensible: al guardar una reserva emito un evento que borra las claves afectadas, en lugar de fiarlo todo al vencimiento. Nombro las claves con el identificador de entidad y su versión para poder invalidar por prefijo, y evito el patrón de caché sin límite de memoria: siempre política de expulsión y tamaño máximo definido.

Separo lo que es negociable de lo que no. Lo innegociable es que no se rompa lo que ya funciona y que la solución rápida no cierre puertas. Con esa base, propongo la vía corta acotada: la implemento sin tocar la parte que exigiría refactorizar, la aíslo detrás de una interfaz y dejo un indicador de funcionalidad para poder desactivarla. Después escribo la deuda en el backlog con su coste estimado y su riesgo concreto, no como una etiqueta genérica de refactorización, y pido comprometer ese trabajo en el siguiente sprint. Lo que sí digo con claridad es cuál es el precio de la vía corta, porque si nadie lo expresa en la reunión, dentro de seis meses parecerá que el código simplemente se estropeó solo.

Primero restablecer el servicio, después entender la causa: son dos fases distintas y mezclarlas alarga las incidencias. Miro qué se ha desplegado en las últimas horas y, si hay un candidato claro, revierto sin discutirlo; una reversión cuesta minutos y una investigación a medianoche cuesta horas. Si no hay despliegue reciente, sigo el camino de la petición con las trazas: navegador, balanceador, aplicación, base de datos y servicios externos, mirando errores y latencias para localizar en qué salto se rompe. Voy comunicando por el canal de incidencias cada quince minutos aunque no tenga novedades, porque negocio y soporte necesitan saber si pueden dar una estimación al cliente. Al día siguiente escribo el análisis sin buscar culpables, con acciones concretas: en la última incidencia salieron una alerta que faltaba y un límite de reintentos mal configurado.

Asumo que en su terreno probablemente tenga razón y empiezo preguntando qué problema ve, no defendiendo mi propuesta. En un caso reciente yo quería una librería de estado global y ella defendía que la mayor parte era estado de servidor y que bastaba con una capa de consultas y caché; tenía razón y lo comprobamos con un prototipo pequeño sobre la pantalla más compleja. Cuando el desacuerdo persiste, lo llevamos a criterios explícitos (coste de mantenimiento, curva de entrada para quien llegue nuevo, tamaño del paquete) y decidimos con datos. Si aun así no hay acuerdo, decide quien tiene la propiedad de esa área y lo documentamos en un ADR con las alternativas descartadas, para que dentro de un año se entienda por qué. Ser full stack me da opinión en su terreno, pero no la última palabra.

Lo tomo como una oportunidad, pero la negocio para que salga bien. Digo con claridad que mi ritmo al principio será más lento y pido dos cosas concretas: revisiones de código algo más exigentes de la persona especialista durante las primeras semanas y una tarea inicial de tamaño medio, ni trivial ni crítica, para coger contexto. Me fijo además un objetivo de aprendizaje explícito para el trimestre para que no sea un aprendizaje difuso. Me pasó con un proyecto en Java y Spring Boot después de dos años centrado en Node.js: las tres primeras semanas fueron lentas, a partir de la cuarta iba a ritmo normal, y esa etapa es hoy una de las cosas que más me diferencia frente a candidatos de un solo lenguaje.

No toco la lógica hasta tener una red de seguridad. Empiezo por caracterizarlo: escribo tests que capturan el comportamiento actual, incluidas las rarezas, aunque parezcan errores, porque puede haber clientes que dependan de ellas. Después busco las fronteras del módulo (qué entra, qué sale, con qué habla) y aíslo la parte que necesito cambiar detrás de una interfaz, sin reescribir lo que no me hace falta. Si encuentro algo que parece un error, no lo arreglo por mi cuenta: lo consulto con producto o con soporte, porque en aplicaciones con años de vida ese comportamiento raro suele ser un requisito no escrito. Y dejo el módulo un poco mejor de lo que estaba, no reescrito entero: la reescritura completa de un componente heredado es la forma más eficaz que conozco de perder un trimestre.