Preguntas de entrevista para Desarrollador Web

Un informe de HackerRank de 2024 reveló que el 68 % de los responsables de contratación de ingeniería valoran la capacidad de resolución de problemas por encima del conocimiento tecnológico específico al evaluar candidatos a desarrollador web [1]. Sin embargo, la mayoría de los candidatos se preparan en exceso para preguntas de algoritmos y se quedan cortos en las preguntas que realmente determinan las decisiones de contratación: explicar compromisos arquitectónicos, depurar problemas de producción y comunicar decisiones técnicas a partes interesadas no técnicas. Aquí están las preguntas que realmente enfrentarás, organizadas por categoría, con marcos para responderlas de manera convincente.

Puntos clave

• Las preguntas conductuales tienen el mismo peso que las preguntas técnicas en la mayoría de las empresas — prepara 5-7 historias STAR
• Las preguntas técnicas evalúan razonamiento y análisis de compromisos, no definiciones memorizadas
• El ejercicio de programación (para casa o en vivo) es la señal de evaluación más importante — practica construyendo pequeñas funcionalidades bajo presión de tiempo
• Haz 3-4 preguntas específicas sobre el stack tecnológico, el proceso de despliegue y la estructura del equipo de la empresa
• Los candidatos más fuertes explican no solo qué construyeron sino por qué tomaron decisiones técnicas específicas

Preguntas conductuales (formato STAR)

1. Cuéntame sobre una funcionalidad que hayas entregado y de la que estés más orgulloso. ¿Qué la hizo desafiante?

Lo que evalúan: Profundidad técnica, resolución de problemas, capacidad de articular complejidad Marco de respuesta fuerte: Describe el impacto de la funcionalidad en el usuario (no solo la tecnología). Explica el desafío técnico: ¿fue una restricción de rendimiento, un requisito ambiguo, una limitación de código legacy o una integración con una API de terceros poco confiable? Detalla tu enfoque y decisiones específicas. Cuantifica el resultado. Ejemplo: "Reconstruí la funcionalidad de búsqueda de nuestra plataforma de e-commerce, migrando de una consulta SQL LIKE a Elasticsearch. El desafío fue mantener la disponibilidad de búsqueda durante la migración — nuestro sitio procesaba 4.000 búsquedas por hora. Implementé un patrón de lectura dual donde el nuevo índice de Elasticsearch corría en modo shadow durante 2 semanas, comparando resultados contra la búsqueda SQL existente. Cuando la paridad de resultados alcanzó el 98 %, hicimos el cambio con un feature flag. La latencia de búsqueda bajó de 1,8 segundos a 120 milisegundos, y las vistas de páginas de producto desde la búsqueda aumentaron un 34 %."

2. Describe una vez que estuviste en desacuerdo con una decisión técnica en tu equipo. ¿Cómo lo manejaste?

Lo que evalúan: Colaboración, comunicación, capacidad de disentir productivamente Marco de respuesta fuerte: Explica la decisión y tu preocupación. Describe cómo planteaste el tema — ¿escribiste un ADR (Architecture Decision Record), presentaste datos, construiste un proof of concept? Muestra respeto por el decisor. Describe el resultado: ¿tenías razón tú, tenían razón ellos, o encontraron una tercera opción?

3. Cuéntame sobre un bug en producción que tuviste que depurar bajo presión de tiempo.

Lo que evalúan: Metodología de depuración, compostura bajo presión, pensamiento sistemático Marco de respuesta fuerte: Describe los síntomas y el impacto. Recorre tu proceso de depuración: ¿dónde miraste primero, qué herramientas usaste (DevTools del navegador, logs del servidor, Sentry, consultas a la base de datos), cómo aislaste la causa raíz? Explica la corrección y qué hiciste para prevenir recurrencia (tests, alertas de monitoreo, documentación).

4. Describe una vez que tuviste que aprender una nueva tecnología rápidamente para entregar un proyecto.

Lo que evalúan: Capacidad de aprendizaje, ingenio, humildad intelectual

5. Cuéntame sobre una vez que mejoraste la experiencia de desarrollo de tu equipo.

Lo que evalúan: Iniciativa, empatía con los compañeros, pensamiento de infraestructura

6. ¿Cómo has mentoreado a un desarrollador junior o ayudado a un compañero a crecer?

Lo que evalúan: Liderazgo, capacidad de enseñanza, paciencia

Preguntas técnicas

1. Explica la diferencia entre Server-Side Rendering (SSR), Static Site Generation (SSG) y Client-Side Rendering (CSR). ¿Cuándo usarías cada uno?

Lo que evalúan: Comprensión arquitectónica, razonamiento sobre compromisos Estructura de respuesta fuerte: CSR: el navegador descarga un shell HTML mínimo y JavaScript renderiza la página. Más rápido para aplicaciones altamente interactivas (dashboards, SPAs) pero malo para SEO y carga inicial. SSR: el servidor genera HTML para cada solicitud. Mejor para páginas críticas de SEO con contenido dinámico (páginas de producto de e-commerce, artículos de noticias). Compromiso: mayor costo de servidor, TTFB más lento que estático. SSG: HTML se genera en tiempo de build. Cargas de página más rápidas y menor costo de servidor, pero datos obsoletos requieren rebuilds o ISR (Incremental Static Regeneration). Mejor para contenido que cambia con poca frecuencia (blogs, documentación, páginas de marketing). Menciona que el App Router de Next.js permite mezclar estas estrategias por ruta.

2. ¿Cómo optimizarías una página web con un tiempo de carga de 6 segundos?

Lo que evalúan: Habilidades de diagnóstico y optimización de rendimiento Estructura de respuesta fuerte: Comienza con la medición: Lighthouse, WebPageTest, pestaña de rendimiento de Chrome DevTools. Diagnostica por categoría: (1) Imágenes — comprimir a WebP/AVIF, usar srcset responsivo, implementar lazy loading. (2) JavaScript — code split, tree-shake, diferir scripts no críticos, verificar tamaño del bundle con webpack-bundle-analyzer. (3) CSS — eliminar estilos sin usar, incrustar CSS crítico inline, diferir hojas de estilo no críticas. (4) Servidor — activar compresión (gzip/Brotli), agregar CDN caching (CloudFront, Cloudflare), optimizar consultas de base de datos que bloquean el renderizado. (5) Fuentes — usar font-display: swap, hacer subset de fuentes, precargar fuentes críticas. Objetivo: LCP bajo 2,5 s, INP bajo 200 ms, CLS bajo 0,1.

3. Explica cómo HTTPS, CORS y la protección CSRF trabajan juntos para asegurar una aplicación web.

Lo que evalúan: Fundamentos de seguridad Estructura de respuesta fuerte: HTTPS encripta datos en tránsito (TLS), previniendo ataques man-in-the-middle y asegurando la integridad de las solicitudes. CORS (Cross-Origin Resource Sharing) restringe qué dominios pueden hacer solicitudes a tu API — el navegador verifica los headers Access-Control-Allow-Origin antes de permitir solicitudes de origen cruzado. La protección CSRF (Cross-Site Request Forgery) previene que sitios maliciosos activen acciones autenticadas — comúnmente implementada con cookies SameSite y tokens CSRF que validan que la solicitud se originó en tu propio sitio. Juntos: HTTPS asegura el transporte, CORS asegura orígenes autorizados, CSRF asegura intención auténtica del usuario.

4. Explícame cómo diseñarías un sistema de notificaciones en tiempo real para una aplicación web.

Lo que evalúan: Diseño de sistemas, selección de tecnología, pensamiento de escalabilidad Estructura de respuesta fuerte: Capa de transporte: conexión WebSocket para comunicación bidireccional de baja latencia (Socket.io o WebSocket nativo). Para casos de uso más simples, Server-Sent Events (SSE) con EventSource API. Backend: servicio de notificaciones que publica eventos en una cola de mensajes (Redis Pub/Sub para simple, Kafka para alto volumen). Los clientes se suscriben a canales basados en ID de usuario. Persistencia: almacenar notificaciones en base de datos (PostgreSQL) con estado leído/no leído. Frontend: React context o Zustand store para el estado de notificaciones, componente toast para visualización en tiempo real, panel de notificaciones para historial. Escalabilidad: las conexiones WebSocket son con estado — necesitan sticky sessions o una capa de estado compartido (Redis) para escalado horizontal. Menciona degradación elegante: fallback a polling si WebSocket falla.

5. ¿Qué es el Virtual DOM y por qué lo usan los frameworks? ¿Cuáles son las alternativas?

Lo que evalúan: Comprensión de los mecanismos internos del framework Estructura de respuesta fuerte: El Virtual DOM (usado por React) es una representación en memoria del DOM real. Cuando el estado cambia, React crea un nuevo árbol de Virtual DOM, lo compara con el anterior (reconciliación) y aplica solo el conjunto mínimo de mutaciones DOM reales. Esto es rápido porque la manipulación del DOM es el cuello de botella — leer y escribir en el DOM activa recalculación de layout, paint y operaciones de composición. Alternativas: Svelte compila componentes a actualizaciones quirúrgicas del DOM en tiempo de build (sin Virtual DOM en runtime — menos bytes de runtime). SolidJS usa reactividad de grano fino que actualiza nodos DOM específicos directamente. Vue usa Virtual DOM pero con optimizaciones de compilación de templates que reducen el costo del diff. Compromisos: el Virtual DOM es flexible pero tiene overhead; los enfoques basados en compilación son más rápidos pero más opinados.

6. ¿Cómo manejas la gestión de estado en una aplicación React compleja?

Lo que evalúan: Habilidades prácticas de arquitectura Estructura de respuesta fuerte: Distingue entre estado del servidor y estado del cliente. Estado del servidor (datos de APIs): React Query o TanStack Query maneja caching, refetching en segundo plano, actualizaciones optimistas y estados de carga/error. Estado del cliente (estado de UI como modales, inputs de formulario, filtros): Zustand para estado global del cliente (API más simple que Redux), React context para tema/auth, useState local para estado específico del componente. Anti-patrones a mencionar: poner todo en estado global (penalización de rendimiento por re-renders innecesarios), hacer fetch en useEffect sin una capa de caching, prop drilling más de 2-3 niveles.

7. Explica la indexación de bases de datos y cuándo crearías un índice.

Lo que evalúan: Comprensión de bases de datos más allá del CRUD básico Estructura de respuesta fuerte: Un índice es una estructura de datos (típicamente B-tree en PostgreSQL) que acelera la recuperación de datos a costa de escrituras más lentas y almacenamiento adicional. Crea índices en columnas usadas frecuentemente en cláusulas WHERE, condiciones JOIN y ORDER BY. Índices compuestos para consultas que filtran por múltiples columnas. Índices parciales para tablas grandes donde solo consultas un subconjunto de filas. Usa EXPLAIN ANALYZE para verificar el uso del índice. Anti-patrones: indexar cada columna (ralentiza inserciones), no indexar claves foráneas (JOINs lentos), crear índices redundantes que son subconjuntos de índices compuestos existentes.

Preguntas situacionales

1. Un product manager no técnico te pide estimar cuánto tardará una funcionalidad. Tienes incertidumbre. ¿Cómo respondes?

Enfoque fuerte: Descompón la funcionalidad en tareas específicas. Identifica incógnitas (integración de API, dependencias de terceros, ambigüedad de diseño). Proporciona un rango con confianza: "Estimo 3-5 días. El límite inferior asume que la integración de la API de pagos funciona como está documentada. El límite superior contempla comportamiento inesperado de la API y pruebas de casos límite. Actualizaré la estimación después de completar la integración en el día 2."

2. Notas que una funcionalidad recientemente desplegada está causando un aumento del 15 % en el tiempo de carga de la página. El equipo de producto no quiere revertir porque la funcionalidad está impulsando conversiones.

Enfoque fuerte: Cuantifica ambos lados: ¿cuánto vale el aumento en conversiones, y cuál es el costo en rendimiento en tasa de rebote e impacto SEO? Propón optimización: ¿puede la funcionalidad cargarse de forma asíncrona, renderizarse en el servidor o diferirse hasta después de la carga inicial? Presenta compromisos basados en datos al equipo de producto. Implementa la optimización antes de presionar por una reversión.

3. La suite de tests de tu equipo tarda 25 minutos en ejecutarse en CI. ¿Cómo la reduces?

Enfoque fuerte: Analiza la suite de tests: ¿cuáles son los más lentos? ¿Los tests E2E están probando cosas que los tests unitarios deberían cubrir? Paraleliza: divide archivos de test entre múltiples runners de CI. Optimiza: mockea APIs externas, usa bases de datos en memoria para tests de integración, reduce setup/teardown redundante. Selectivo: ejecuta solo tests afectados por archivos cambiados (Jest --changedSince, Playwright --grep). Objetivo: menos de 10 minutos para la mayoría de los PRs.

Criterios de evaluación

Preguntas para tu entrevistador

1. "¿Cómo es tu proceso de despliegue — con qué frecuencia despliegan a producción, y qué salvaguardas tienen?"
2. "¿Cuál es tu estrategia de deuda técnica — asignan tiempo dedicado para refactorización y mejoras de infraestructura?"
3. "¿Puedes describir el proceso de code review del equipo y cómo es un PR típico?"
4. "¿Cuál es el mayor desafío técnico que enfrenta el equipo actualmente?"
5. "¿Cómo está estructurado el equipo de ingeniería — equipos de producto, equipos de plataforma, o un modelo diferente?"

Conclusiones finales

Las entrevistas para desarrolladores web evalúan tres capacidades: ¿puedes construir software de calidad de producción (técnica), puedes razonar sobre compromisos (arquitectura), y puedes comunicarte efectivamente con tu equipo (colaboración)? Prepara historias STAR para preguntas conductuales, practica explicando decisiones técnicas en voz alta, y estudia el producto y stack tecnológico de la empresa antes de la entrevista. Los candidatos que reciben ofertas demuestran pensamiento claro, autoevaluación honesta y la capacidad de conectar el trabajo técnico con resultados de usuario y negocio.

Preguntas frecuentes

¿Cómo debo prepararme para un ejercicio de programación para casa?

Trátalo como un PR real: escribe código limpio, incluye un README con instrucciones de configuración y decisiones de diseño, escribe tests para caminos críticos, y haz commits con mensajes claros. La mayoría de los ejercicios para casa evalúan tu capacidad de producir código entregable más que brillantez algorítmica. Limita tu tiempo de trabajo (la mayoría están diseñados para 3-4 horas) y documenta compromisos: "Con más tiempo, habría añadido manejo de errores para X y optimizado la consulta de base de datos para Y."

¿Debería practicar LeetCode para entrevistas de desarrollador web?

Para empresas FAANG, sí — las preguntas de estructuras de datos y algoritmos siguen siendo parte de su proceso. Para la mayoría de las demás empresas (startups, mercado medio, agencias), tu tiempo está mejor invertido practicando diseño de sistemas, construyendo proyectos y preparando historias conductuales. Pregunta al reclutador sobre el formato de la entrevista antes de invertir más de 100 horas en práctica algorítmica.

¿Qué tan técnicas deberían ser mis respuestas si el entrevistador es un responsable de contratación no técnico?

Adáptate a su nivel. Si el responsable hace preguntas conductuales, enfócate en el impacto y la colaboración. Si un entrevistador técnico pregunta sobre React, profundiza. En caso de duda, comienza con una explicación de alto nivel y ofrece profundizar: "A nivel general, mejoramos la velocidad de búsqueda 10 veces. Puedo explicar el enfoque técnico si es útil."

¿Qué pasa si no sé la respuesta a una pregunta técnica?

Dilo directamente y explica tu enfoque para encontrar la respuesta: "No he trabajado con ese patrón específico, pero mi enfoque sería consultar la documentación oficial, buscar referencias previas en nuestra base de código y construir un pequeño proof of concept para validar el enfoque antes de implementarlo en producción." La honestidad más un enfoque de aprendizaje sistemático impresiona más que un bluff vago.

Fuentes: [1] HackerRank, "Developer Skills and Hiring Report," hackerrank.com, 2024. [2] Stack Overflow, "2024 Developer Survey," stackoverflow.com/survey/2024. [3] Hired, "State of Software Engineers Report," hired.com, 2024.