Preguntas de entrevista Desarrollador web

Mi stack principal es React en el front end con TypeScript, combinado con Node.js y Express en el back end, y PostgreSQL para la base de datos. Me acerqué a React porque el modelo de componentes encaja bien con mi forma de pensar la interfaz: piezas aisladas con entradas y salidas definidas. TypeScript detectó varias categorías de bugs antes de que llegaran a producción, y dejé de ver las anotaciones de tipos como una carga para empezar a verlas como documentación que el compilador verifica. Añadí Node en el back end para reducir el cambio de contexto mental entre capas. PostgreSQL se adapta bien a los datos relacionales con los que trabajo más a menudo, y su soporte JSON gestiona los casos semiestructurados. No soy dogmático con este stack: elijo las herramientas que se ajustan al problema, y he entregado proyectos en Vue y Python/Django cuando el equipo o los requisitos lo pedían.

Sigo un número reducido de fuentes de alta señal en lugar de intentar leerlo todo. El changelog de MDN Web Docs y las notas de versión de React y TypeScript van directamente a mi lector RSS. Estoy suscrito a un par de newsletters (bytes.dev y JavaScript Weekly) que repaso semanalmente. Cuando algo capta mi atención, abro un pequeño proyecto o un CodeSandbox para probarlo en aislamiento antes de usarlo en código de producción. También reviso pull requests de compañeros con especialidades distintas a las mías: la revisión de código es una de las formas más rápidas de absorber patrones que no he encontrado antes. No adopto cada nuevo framework en cuanto sale. Espero a ver si resuelve un problema real que tengo, y leo el rastreador de issues antes de comprometerte con algo nuevo en una base de código de producción.

Trato los requisitos poco claros como un problema de descubrimiento, no como un bloqueo. Mi primer paso es anotar lo que sé, lo que estoy asumiendo y lo que genuinamente no sé, y luego llevar esa lista a quien sea el dueño del requisito. Esa conversación suele resolver el 80% de la ambigüedad en 15 minutos. Para requisitos genuinamente cambiantes, divido el trabajo en las piezas más pequeñas que podrían entregarse de forma independiente y confirmo cada pieza antes de construir la siguiente. También obtengo un acuerdo explícito sobre qué significa "hecho" antes de empezar: un criterio de aceptación claro es mucho más útil que una descripción larga. Si los requisitos cambian a mitad de la construcción, señalo el coste del cambio en tiempo y reproceso necesario, no como una queja sino como información que el equipo necesita para tomar una buena decisión.

En un proyecto, el diseñador y yo teníamos un conflicto recurrente sobre el espaciado de los componentes. Entregaba archivos de Figma con márgenes pixel-perfect que no encajaban con nuestra cuadrícula de 8 puntos, y yo tenía que elegir entre respetar el diseño exactamente o mantener la coherencia del sistema. Después del tercer episodio, pedí una reunión de 30 minutos para mostrarle el sistema de design tokens que usábamos y explicar por qué los valores arbitrarios creaban problemas de mantenimiento. Recorrí un ejemplo concreto: dos botones que para el usuario parecían idénticos pero tenían valores de margen diferentes en el código, lo que significaba dos tickets de actualización en lugar de uno. Esa conversación cambió nuestra forma de trabajar. Acordamos que yo marcaría las desviaciones de la cuadrícula durante la revisión de diseño antes de que cualquier archivo llegara al desarrollo. Los últimos tres meses del proyecto tuvieron casi cero reproceso por inconsistencias de diseño.

Tuvimos un despliegue en producción un viernes por la tarde que rompió el proceso de pago para los usuarios de Safari. Los pedidos fallaban en silencio y solo lo descubrimos porque un cliente llamó. Reproduje el problema en local en 10 minutos usando las herramientas de desarrollo de Safari. La causa raíz era una propiedad CSS Grid que Chrome manejaba bien pero Safari no: una funcionalidad de subgrid que había usado sin comprobar la tabla de compatibilidad de Safari primero. Lo corregí con un diseño flexbox de reserva, escribí un test de regresión y desplegué en 45 minutos. La parte más difícil fue la comunicación: envié una actualización clara al product owner cada 15 minutos con el estado, el tiempo estimado de resolución y cualquier cambio en esa estimación. Eso mantuvo al equipo tranquilo y evitó que me interrumpieran mientras trabajaba. Tras el incidente añadí una verificación de compatibilidad de navegadores a nuestra lista de revisión de código.

A mitad de un proyecto, el equipo propuso copiar un gran bloque de código legacy espagueti en la nueva base de código para cumplir una fecha límite de sprint. Argumenté en contra no por principio sino con datos concretos: ese bloque tenía tres bugs abiertos en el backlog, ningún test, y tocaría seis componentes que planeábamos refactorizar el trimestre siguiente. Estimé el coste de reproceso en unos dos días de sprint, más que el tiempo que ahorraríamos copiándolo ahora. Propuse una alternativa: una implementación más ligera, limpia y testeable, que estimé en día y medio. El tech lead estuvo de acuerdo. Entregamos a tiempo con la versión limpia y no pagamos el coste de reproceso después. También he estado en situaciones donde acepté contraer deuda deliberadamente: la clave es hacer el compromiso explícito y registrarlo en el backlog con un ticket de remediación para que no desaparezca.

Empiezo midiendo, no adivinando. Paso la página por Lighthouse y la pestaña de Rendimiento de Chrome para obtener una línea base. Lo primero que reviso es el waterfall de red: las imágenes sobredimensionadas y los assets sin comprimir son responsables de la mayoría de los problemas de tiempo de carga en mi experiencia. Después busco scripts que bloqueen el renderizado, y luego el tamaño del bundle de JavaScript usando una herramienta como webpack-bundle-analyzer o el plugin de análisis de bundle de Next.js. En el lado del renderizado verifico los desplazamientos de diseño (CLS) y las tareas largas (TTI). Si la página está en React, busco re-renderizados innecesarios con el perfilador de React DevTools. Las correcciones habituales: carga diferida de imágenes y componentes fuera de pantalla, code-splitting a nivel de ruta, cargar scripts de terceros como async o defer, y cachear respuestas de API. Siempre mido de nuevo después de cada cambio para confirmar que la mejora es real.

Para una reciente funcionalidad de notificaciones de usuario diseñé un endpoint GET /users/:id/notifications. Elegí REST sobre GraphQL porque la estructura de datos era sencilla y el equipo ya conocía las convenciones REST. Versioné la API en /v1/ desde el principio para evitar cambios que rompieran compatibilidad más adelante. El endpoint devuelve una lista paginada usando paginación basada en cursor en lugar de offset, porque el feed de notificaciones se actualiza con frecuencia y la paginación por offset produce duplicados o elementos omitidos en esos casos. Incluí filtrado por estado de lectura como parámetro de consulta (?unread=true) y mantuve el envelope de respuesta consistente con nuestros otros endpoints: un array data, un objeto meta con cursores de paginación y una estructura de error estándar. Escribí una spec OpenAPI antes de la implementación para que los equipos de front y back pudieran trabajar en paralelo.

Trato la accesibilidad como un requisito de desarrollo, no como una auditoría que hago al final. En la práctica eso significa: escribir HTML semántico primero y solo usar div y span cuando no existe ningún elemento apropiado; añadir texto alternativo a todas las imágenes significativas; asegurar que cada elemento interactivo es alcanzable y operable con teclado; usar atributos ARIA solo cuando la semántica nativa es insuficiente, porque un ARIA incorrecto es peor que ninguno. Ejecuto axe-core en el entorno de desarrollo como linter para que los problemas aparezcan antes de la revisión de código. También pruebo periódicamente con un lector de pantalla: VoiceOver en macOS cubre muchos casos reales. En CSS verifico los ratios de contraste de color respecto a los mínimos WCAG AA (4,5:1 para texto normal). Para la validación de formularios me aseguro de que los mensajes de error estén asociados programáticamente a sus campos mediante aria-describedby.