Empieza por el contexto del producto

Empieza explicando qué hace la aplicación, quién la utiliza y qué problema empresarial resuelve. Una introducción sólida podría ser: «Construí un marketplace donde los clientes podían buscar productos, comparar precios y completar el proceso de pago». Esto le da al entrevistador un motivo para interesarse por las decisiones técnicas que explicarás a continuación.

Mantén breve esta introducción, normalmente entre 30 y 60 segundos, y después relaciona el producto con tus responsabilidades. Explica si trabajaste en toda la aplicación o si te encargaste de funcionalidades específicas, como la autenticación, la búsqueda de productos, los pagos o el panel de administración. Menciona el tamaño del equipo y la duración del proyecto solo cuando ayuden a aclarar tu nivel de responsabilidad.

Describe la arquitectura de Next.js

Explica las capas principales del proyecto en un orden lógico: interfaz de usuario, aplicación de Next.js, servicios externos y almacenamiento de datos. Por ejemplo, el navegador puede solicitar una página de producto a Next.js, el servidor puede obtener los datos del producto desde una API y la página puede mostrar el resultado mediante componentes reutilizables de React. Describir este flujo de solicitudes es más útil que limitarse a decir que el proyecto utilizaba Next.js.

Después, describe cómo estaba organizado el código. Puedes mencionar un directorio app que contenga segmentos de rutas, componentes compartidos para la navegación y los formularios, utilidades del lado del servidor para acceder a los datos y esquemas de validación para la entrada del usuario. Evita enumerar todas las carpetas; céntrate en la estructura que ayudaba al equipo a separar la presentación, la lógica de negocio y la infraestructura.

Explica las decisiones de renderizado

La estrategia de renderizado es una de las partes más importantes de una conversación técnica sobre Next.js. Explica por qué algunas páginas utilizaban renderizado en el servidor o generación estática, mientras que los controles interactivos seguían siendo componentes del cliente. Una página de detalles de producto que cambia con poca frecuencia podría generarse o renderizarse en el servidor, mientras que un filtro en tiempo real, un carrito de compras o un editor de arrastrar y soltar necesitan mantener su estado en el navegador.

Relaciona cada decisión con un comportamiento medible o con las necesidades del usuario, en lugar de repetir terminología del framework. El renderizado en el servidor puede reducir la cantidad de JavaScript necesaria antes de que aparezca el contenido, mientras que el renderizado del lado del cliente es adecuado para interacciones que dependen de eventos, del estado local o de las API del navegador. Explica también el compromiso: los datos renderizados en el servidor pueden quedar obsoletos si no se revalidan, y un exceso de componentes del cliente puede aumentar el tamaño del payload de JavaScript.

Explica el proceso de obtención de datos paso a paso

Elige un recorrido de usuario importante y sigue el trayecto de sus datos desde la solicitud hasta la pantalla. Para una página de búsqueda, describe cómo se lee y valida el parámetro de consulta de la URL, como “?q=keyboard&page=2”, cómo se envía a una API y cómo se transforma en la lista que renderiza la página. Esto demuestra que comprendes tanto el framework como el comportamiento real de la aplicación.

Incluye los estados de carga, vacío y error como parte de la misma explicación. Un ejemplo útil es mostrar un skeleton mientras una solicitud está pendiente, presentar un mensaje claro cuando no hay productos que coincidan y ofrecer una acción para reintentar después de un fallo temporal de la API. Menciona la configuración de caché o revalidación cuando sea relevante, especialmente si el proyecto tenía requisitos como datos de inventario actualizados o una navegación repetida rápida.

Muestra mejoras de rendimiento

Prepara un caso concreto de rendimiento con una comparación entre el antes y el después. Puedes explicar que una imagen hero grande y sin optimizar retrasaba el Largest Contentful Paint, por lo que el equipo redimensionó la imagen de origen, utilizó el componente de imagen de Next.js y cargó de forma diferida los recursos multimedia situados por debajo del pliegue. Si tienes mediciones reales, indica el cambio exacto, como una reducción de 3,8 a 2,4 segundos en una página de prueba definida.

El rendimiento también incluye el tamaño del bundle, la latencia de la base de datos y los renderizados innecesarios. Explica cómo identificaste el cuello de botella utilizando las herramientas de rendimiento del navegador, el análisis del bundle, los registros del servidor o Web Vitals, en lugar de hacer suposiciones. Sé preciso sobre la limitación: una optimización que ayuda a una landing page estática puede no ayudar a un dashboard cuyo retraso se debe a solicitudes lentas a una API autenticada.

Habla sobre las pruebas y la fiabilidad

Explica la estrategia de pruebas en tres niveles cuando el proyecto requería fiabilidad. Las pruebas unitarias pueden cubrir funciones de formato o reglas de validación; las pruebas de componentes pueden verificar el comportamiento de los formularios; y las pruebas end-to-end pueden confirmar un flujo completo, como iniciar sesión, añadir un artículo y completar el checkout. Un ejemplo concreto demuestra una comprensión mayor que afirmar que el proyecto tenía una buena cobertura de pruebas.

Incluye los fallos y casos límite que consideraste. Por ejemplo, una página autenticada debe gestionar una sesión caducada, una solicitud de pago debe impedir los envíos duplicados y un formulario debe mostrar los errores de validación del servidor sin perder los datos introducidos por el usuario. Menciona cómo se ejecutaban las pruebas en CI y si utilizaste respuestas simuladas, una base de datos de pruebas o un entorno de staging.

Explica las decisiones y las lecciones aprendidas

Las entrevistas técnicas suelen ser más sólidas cuando explicas una decisión que no fue perfecta. Podrías decir que el equipo eligió un proveedor de autenticación gestionado para publicar rápidamente, aceptando tener menos control sobre la experiencia de inicio de sesión, o que seleccionó una biblioteca de datos del lado del cliente porque las actualizaciones frecuentes del dashboard compensaban la complejidad adicional. Indica las alternativas que consideraste y la restricción que influyó en la decisión final.

Termina explicando qué mejorarías en una segunda versión. Entre las posibles mejoras se incluyen límites más claros entre el servidor y el cliente, contratos de API más sólidos, una mejor monitorización de las solicitudes lentas o pruebas de accesibilidad más tempranas. Mantén la respuesta centrada en el proyecto: describe una lección, las evidencias que la respaldan y cómo cambiaría tu implementación, en lugar de afirmar que habría que reescribir toda la arquitectura.

Artículos relacionados

Lecturas adicionales

Next.js

React

Renderizado del lado del servidor