Preguntas de entrevista para Full Stack Developer: respuestas que funcionan

Has pasado la primera criba de CV y te llega el email con la fecha de la entrevista técnica. Ahora empieza el sudor frío: ¿qué preguntas van a hacer? ¿Cómo estructuro las respuestas? ¿Me van a poner a programar en un pizarra virtual? La incertidumbre es normal, pero se puede reducir mucho con la preparación adecuada. Vamos a desglosar las preguntas más comunes, cómo atacarlas y qué errores evitar para que llegues con confianza.

El filtro inicial: no te relajes#

Las primeras preguntas parecen sencillas, pero son un filtro. Buscan descartar rápido a quien no encaja en lo básico. Aquí no se trata de dar respuestas brillantes, sino de ser claro y directo.

• ¿Por qué quieres trabajar en esta empresa/este proyecto?: El entrevistador quiere saber si investigaste. Menciona algo específico: su stack tecnológico, un producto que te guste, su enfoque de ingeniería. Una respuesta genérica tipo "porque sois líderes" no vale.
• ¿Qué es lo que más te gusta de ser Full Stack?: Aquí buscan pasión genuina. Habla de la visión de conjunto, de entender cómo el frontend y el backend se conectan para crear algo útil, de disfrutar resolviendo problemas en ambos lados.
• Háblame de tu entorno de desarrollo habitual.: No es una pregunta trampa. Quieren saber si usas herramientas modernas y si eres productivo. Menciona tu IDE, sistema de control de versiones, gestor de paquetes, y si has trabajado con entornos containerizados.

Preguntas técnicas de frontend#

Aquí empieza el campo de minas. No te van a preguntar definiciones del libro. Te pondrán situaciones reales.

Pregunta: Explícame el ciclo de vida de un componente en React. ¿Cuándo usarías useEffect y qué problema común tiene?

Esta pregunta evalúa si realmente has construido algo con React. No basta con decir "se monta, actualiza y desmonta".

Respuesta modelo: "El ciclo de vida comienza con el montaje, donde el componente se renderiza por primera vez. Luego viene la actualización, cuando cambian sus props o su estado. Finalmente, el desmontaje, cuando se elimina del DOM. Yo uso useEffect para sincronizar con sistemas externos: llamadas a APIs, suscripciones, manipulación del DOM directa. El error más común es olvidar el array de dependencias o ponerlo vacío cuando el efecto realmente depende de algo. Eso causa renders infinitos o datos desactualizados. Siempre pienso: ¿qué datos necesita este efecto para estar al día?"

Pregunta: Un usuario reporta que la web va lenta. ¿Cómo depurarías el rendimiento en el frontend?

Aquí buscan un proceso, no una respuesta mágica.

Respuesta modelo: "Primero, replicaría el problema: preguntaría qué navegador usa, qué dispositivo, y si pasa siempre o solo a veces. Luego abriría las Chrome DevTools. En la pestaña Network vería si hay peticiones que tardan demasiado o que se repiten. En la pestaña Performance grabaría un perfil para ver si hay cuellos de botella en JavaScript, layout thrashing, o repintados excesivos. Revisaría el tamaño del bundle con herramientas como Webpack Bundle Analyzer para ver si estamos cargando librerías que no necesitamos. A veces el problema es algo tonto: una imagen de 4MB sin comprimir o un bucle que recalcula algo en cada render."

Preguntas técnicas de backend y base de datos#

El backend es donde muchos candidatos se pierden. Las preguntas suelen ser más profundas.

Pregunta: ¿Cuál es la diferencia entre una API REST y GraphQL? ¿Cuándo elegirías una u otra?

No buscan que repitas la definición de Wikipedia. Quieren criterio.

Respuesta modelo: "REST es un estándar basado en recursos y verbos HTTP. Es simple, predecible, y funciona bien cuando los recursos están bien definidos. GraphQL es un lenguaje de consulta donde el cliente pide exactamente los datos que necesita. Yo elegiría REST para APIs internas simples o cuando el equipo ya lo domina. GraphQL cuando el frontend necesita flexibilidad, por ejemplo, una app móvil que consume la misma API que la web pero con menos datos. El riesgo de GraphQL es que puedes crear consultas complejas que sobrecarguen el backend si no pones límites."

Pregunta: ¿Cómo manejarías la autenticación en una aplicación web?

Aquí quieren saber si entiendes seguridad básica, no que diseñes un sistema criptográfico.

Respuesta modelo: "Para la mayoría de casos, usaría JWT con refresh tokens. El token de acceso tiene una vida corta, 15 minutos, y se guarda en memoria. El refresh token tiene vida más larga, se guarda en una cookie HttpOnly y Secure para que JavaScript no pueda leerlo. Cuando el token de acceso expira, uso el refresh token para obtener uno nuevo. Si el refresh token también expira o se revoca, el usuario tiene que volver a iniciar sesión. Nunca guardaría tokens sensibles en localStorage, es vulnerable a ataques XSS."

Pregunta: Tienes una tabla con millones de registros. Una consulta está lenta. ¿Qué haces?

Respuesta modelo: "Primero usaría EXPLAIN en la consulta para ver el plan de ejecución. Probablemente faltaría un índice en la columna del WHERE o del JOIN. Si ya hay índices, revisaría si son los correctos: un índice en una columna con baja selectividad no ayuda mucho. También vería si puedo evitar SELECT * y solo traer las columnas que necesito. En casos extremos, consideraría particionar la tabla o usar una tabla de resumen para consultas agregadas."

Preguntas de comportamiento y situación#

Estas preguntas pesan tanto como las técnicas. Muchos candidatos las subestiman.

Pregunta: Cuéntame un desacuerdo técnico que tuviste con un compañero. ¿Cómo lo resolviste?

Buscan madurez profesional, no que fueras el que tenía razón.

Respuesta modelo: "En mi proyecto anterior, un compañero quería usar microservicios para una aplicación que era básicamente un CRUD con algo de lógica de negocio. Yo pensaba que era overengineering. En vez de discutir en abstracto, preparé una comparación: tiempo de desarrollo estimado, complejidad operativa, coste de infraestructura. Presentamos ambas opciones al equipo con pros y contras reales. El equipo votó por el monolito modular. Mi compañero no se lo tomó mal porque el proceso fue transparente. Aprendí que los datos ganan a las opiniones."

Pregunta: ¿Cómo priorizas cuando tienes más trabajo del que puedes terminar?

Respuesta modelo: "Primero hablo con mi manager para que me ayude a priorizar. No todas las tareas son urgentes aunque parezcan. Suelo clasificar: lo que bloquea a otros va primero, luego lo que tiene fecha de entrega cercana, luego lo demás. Si hay demasiado, prefiero avisar antes que entregar algo a medias. La comunicación temprana evita sorpresas."

Qué evalúa realmente el entrevistador#

No es solo si sabes la respuesta. Evalúan cómo piensas.

• Proceso de resolución: ¿descompones el problema o das un salto a la solución?
• Comunicación: ¿explicas con claridad o divagas?
• Honestidad: ¿dices "no sé" cuando no sabes, o inventas?
• Curiosidad: ¿haces preguntas para entender mejor el problema?
• Pragmatismo: ¿propones soluciones realistas o arquitecturas para un problema que no existe?

Errores comunes que te descartan#

• Decir "no sé" y quedarse en silencio. Mejor: "No lo he usado en producción, pero entiendo que funciona de X forma. Me encantaría aprender más."
• Mentir sobre tecnologías que no dominas. Te van a pillar en la prueba técnica.
• No hacer preguntas al final. Si no preguntas nada, pareces desinteresado.
• Hablar mal de empresas o compañeros anteriores. Siempre.
• Memorizar respuestas de internet sin entenderlas. Se nota.

Checklist de preparación#

• Investiga la empresa: qué producto tienen, qué stack usan, tamaño del equipo.
• Repasa los fundamentos del lenguaje que piden, no solo los frameworks.
• Practica al menos 3 problemas de estructuras de datos y algoritmos en LeetCode o similar.
• Prepara 3 historias concretas de proyectos: problema, solución, resultado.
• Revisa tu propio CV: te van a preguntar por todo lo que ponga ahí.
• Ten preparadas 5 preguntas para hacer al final de la entrevista.
• Haz una simulación en voz alta, solo o con alguien. Pensar la respuesta y decirla son cosas muy distintas.

Antes de la entrevista, usa nuestro analizador de ofertas gratuito para entender exactamente qué buscan. Y si quieres ver qué piden las empresas ahora mismo, echa un vistazo a las ofertas para desarrolladores. Para afinar tu currículum, prueba la herramienta de revisión para sistemas automáticos. También tienes más consejos sobre cómo preparar entrevistas técnicas en nuestro blog.

Preguntas frecuentes#

¿Cuánto gana un Full Stack Developer en España?

Los rangos varían mucho según experiencia, ciudad y tecnología. Un junior puede empezar entre 22.000 y 28.000 euros brutos anuales, un intermedio entre 30.000 y 45.000, y un senior puede superar los 55.000. Estas cifras son orientativas: consulta fuentes actualizadas como el INE o portales de empleo para datos recientes.

¿Necesito saber DevOps para una entrevista de Full Stack?

No es obligatorio, pero suma. Saber lo básico de Docker, CI/CD y despliegue en la nube te da ventaja. Muchas empresas pequeñas esperan que el full stack pueda poner en producción su propio código sin depender de otro equipo.

¿Es mejor especializarme en frontend o backend antes de ir a full stack?

Tener una base sólida en uno de los dos lados te hace más fuerte. Si domina el backend, aprender frontend es más fácil porque entiendes los datos. Al revés, si vienes del frontend, entiendes la experiencia de usuario y eso te ayuda a diseñar mejores APIs.

¿Qué lenguaje tiene más salida para full stack?

JavaScript y TypeScript dominan el mercado de full stack porque sirven para frontend y backend. Python con Django o Flask también tiene mucha demanda. Java y .NET siguen siendo fuertes en empresas grandes y sectores regulados.

¿Cuánto dura típicamente un proceso de selección para full stack?

Entre 2 y 4 semanas es lo normal. Suele haber una llamada de recursos humanos, una entrevista técnica, a veces una prueba práctica para casa, y una última ronda con el equipo. En startups puede ser más rápido, en grandes empresas más lento.