Explícame el stack tecnológico que mejor dominas y por qué lo elegiste.

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.

¿Cómo te mantienes al día con los cambios en el desarrollo web?

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.

¿Cómo manejas una situación en la que los requisitos son poco claros o cambian constantemente?

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.

Cuéntame sobre una vez que tuviste que trabajar estrechamente con un diseñador y la colaboración fue difícil.

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.

Describe una vez que tuviste que depurar un problema bajo presión con una fecha límite encima.

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.

Pon un ejemplo de una vez que rechazaste asumir deuda técnica.

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.

¿Cómo abordas la optimización del rendimiento de una página web lenta?

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.

Explica cómo diseñarías un endpoint REST API para una funcionalidad que hayas desarrollado recientemente.

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.

¿Qué pasos sigues para hacer un sitio web accesible?

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.

Desarrollador web

Las entrevistas para desarrollador web ponen a prueba tus bases técnicas junto con tu capacidad para colaborar, tomar decisiones de arquitectura y entregar código funcional en equipos reales. Los entrevistadores quieren ver que entiendes el stack completo, que te preocupas por la experiencia de usuario y que puedes explicar tus decisiones con claridad. Esta guía cubre las preguntas más frecuentes y las respuestas que demuestran profundidad técnica real.

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

Preguntas de entrevista habituales para Desarrollador web

Preguntas conductuales para puestos de Desarrollador web

Preguntas técnicas para candidatos a Desarrollador web

Lo que buscan los reclutadores en las entrevistas para Desarrollador web

Lo que los responsables de selección buscan realmente en los candidatos a desarrollador web:

Historias concretas de depuración. Cualquiera puede decir que es bueno depurando. Los candidatos que recorren un incidente real con las herramientas que usaron, la causa raíz que encontraron y el cambio de proceso que hicieron después destacan inmediatamente.
Opiniones genuinas sobre los compromisos. Los mejores candidatos no solo describen lo que construyeron: explican por qué eligieron un enfoque sobre otro y qué harían diferente la próxima vez.
Conciencia del ciclo de entrega completo. Escribir código es parte del trabajo, no todo. Busca candidatos que piensen en pruebas, despliegue, monitorización y mantenimiento tan naturalmente como piensan en la implementación.
Colaboración con no ingenieros. Los desarrolladores front end especialmente necesitan trabajar con diseñadores y product managers. Escucha cómo un candidato describe esas relaciones: la especificidad y el respeto mutuo son buenas señales.
Conocimiento de navegadores y accesibilidad más allá de lo básico. Muchos candidatos conocen las funcionalidades principales. Pocos saben cómo Safari gestiona propiedades CSS específicas o cómo implementar correctamente la navegación por teclado. Los que lo saben están significativamente más preparados para producción.

Preguntas que puedes hacer al entrevistador

→¿Cómo es el proceso de despliegue y con qué frecuencia el equipo publica en producción?
→¿Cómo se revisa el trabajo de front end aquí: hay un paso de QA de diseño dedicado antes de que el código se publique?
→¿Cuáles son los mayores desafíos técnicos en los que el equipo está trabajando ahora mismo?
→¿Cómo gestiona el equipo la compatibilidad de navegadores y los requisitos de accesibilidad?
→¿Cómo es el proceso de incorporación para un nuevo desarrollador y cuánto tiempo pasa antes de que alguien entregue de forma independiente?

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 durante la beta. Sin compromiso.

Puestos relacionados

Ingeniero de software