Preguntas y respuestas de entrevista para desarrollador Java: la guía 2026

Las entrevistas de Java tienen fama de trivia, y parte de esa fama es merecida. Las buenas han evolucionado. Lo que mide hoy un panel competente es si entiendes qué está haciendo el runtime por debajo de tu código: dónde se fue la memoria, por qué hubo esa pausa, qué generó el framework por ti y qué se rompe cuando dos hilos llegan a la misma línea a la vez. Estas son las preguntas que salen una y otra vez, qué mide cada una y cómo se construye una buena respuesta.

Estos son los patrones del puesto en general; si quieres la lista corta para una entrevista concreta, pega el anuncio real de la vacante en el Question Predictor gratuito y obtén las veinte preguntas con más probabilidad de salir en ese proceso concreto.

¿Qué miden de verdad las entrevistas para desarrollador Java?

Cinco áreas, de forma fiable: JVM y comportamiento de la memoria, recolección de basura, el framework de colecciones con detalle real, concurrencia, y el framework en el que viva el equipo, que casi siempre es Spring. Debajo hay una pregunta que nadie dice en voz alta: cuando este servicio se porte mal en producción a las 2 de la mañana, ¿vas a saber averiguar por qué?

La profundidad escala mucho con la seniority. Un junior necesita mecánica correcta; alguien de nivel medio necesita compromisos y diagnóstico; a un senior se le espera razonar sobre el dimensionado del heap, la elección de recolector y la configuración de los pools de hilos con historias de producción pegadas. Una cosa ha cambiado de verdad: el código repetitivo ahora es gratis, así que los paneles dedican menos tiempo a pedirte que escribas un builder y más a preguntarte por qué una transacción no hizo rollback.

¿Cómo es el proceso de entrevistas de Java?

Un proceso típico tiene de cuatro a seis fases: un filtro con el reclutador, un filtro técnico que mezcla código con fundamentos, una ronda de programación más larga, una ronda de diseño y una conversación con el responsable de contratación. Las grandes empresas y las consultoras se apoyan en fundamentos y Spring; las empresas de producto dan más peso al diseño y a la concurrencia. Los ejercicios para casa son habituales en empresas medianas y suelen consistir en un pequeño servicio con Spring.

1. Filtro con el reclutador (20 a 30 minutos). Versión, framework, escala, banda salarial. Ten claro a qué versión de Java apunta tu base de código, porque decir "la última" y luego no saber qué es un record sale mal.
2. Filtro técnico (45 a 60 minutos). Programar en un editor compartido más fundamentos rápidos: colecciones, excepciones, inmutabilidad, streams.
3. Ronda de programación (60 minutos). Un problema práctico más que un acertijo: parsear y agregar un fichero, implementar una caché pequeña, escribir un contador seguro para hilos.
4. Ronda de diseño (60 minutos). Diseño de servicios o un ejercicio orientado a objetos, con capacidad y modos de fallo añadidos en los procesos senior.
5. Ronda de framework y profundidad. Comportamiento de Spring, transacciones, testing, y a veces un ejercicio de revisión en el que criticas una clase deliberadamente defectuosa.
6. Responsable de contratación o ronda conductual. Incidencias, desacuerdos, mentoría, y si el nivel que dices tener aguanta el detalle.

Si conoces la empresa, los bancos de preguntas por empresa son una lectura más rápida del estilo de la casa que rastrear foros, porque las grandes consultoras en particular siguen un guion consistente.

¿Qué preguntas de JVM y memoria puedes esperar?

Espera explicar el camino del código fuente al programa en ejecución, y las regiones de memoria en las que viven tus objetos. El panel comprueba si la JVM es una caja negra para ti. Cubre la compilación a bytecode, la carga de clases, la interpretación seguida de la compilación just-in-time de las rutas calientes, y la separación entre heap, pilas de hilos y metaspace, sin que se convierta en un recitado.

Cuéntame qué pasa entre que escribes una clase y que se ejecuta. Qué mide: si entiendes el runtime sobre el que despliegas. Ve en orden: javac produce bytecode, el class loader lo carga y lo enlaza (merece la pena nombrar la delegación al padre), el intérprete empieza a ejecutar y el compilador JIT optimiza los métodos cuando se calientan, con el inlining y la desoptimización como comportamientos reales.

Explica las áreas de memoria de la JVM. Qué mide: si sabes localizar un problema de memoria. El heap guarda los objetos y es donde ocurre la recolección; cada hilo tiene una pila para marcos y variables locales; el metaspace guarda los metadatos de clases fuera del heap. La memoria nativa que usan los buffers queda fuera de todo eso, y por eso a un contenedor lo pueden matar mientras el heap parece sano.

¿Cómo diagnosticarías un OutOfMemoryError en producción? Qué mide: experiencia operativa real. Pregunta primero de qué OutOfMemoryError se trata, porque el heap, el metaspace y los fallos al crear hilos tienen causas distintas. Después captura un volcado de heap al producirse el error, inspecciona el árbol de dominadores para ver qué retiene el conjunto, y mira los logs de GC para distinguir un crecimiento sostenido de un pico.

¿Qué preguntas de recolección de basura salen?

Las preguntas de GC miden si sabes razonar sobre tiempo de pausa frente a rendimiento. Empieza por la hipótesis generacional (la mayoría de los objetos mueren jóvenes), explica que las recolecciones de la generación joven son baratas y las completas no, y trata la elección de recolector como una decisión de requisitos y no como un favorito. Nunca digas que un flag de tuning arregla un problema que no has medido.

¿Cómo funciona en realidad la recolección de basura? Qué mide: mecánica, no vocabulario. Describe la alcanzabilidad desde las raíces del GC en lugar del conteo de referencias, la división entre generación joven y vieja, las recolecciones menores promocionando supervivientes, y las pausas stop-the-world como lo que de verdad duele.

¿Cómo eliges entre los recolectores disponibles? Qué mide: si ajustas la herramienta a un objetivo de latencia. G1 es el valor por defecto sensato para la mayoría de las cargas de servidor y apunta a un objetivo de pausa. ZGC y Shenandoah cambian rendimiento por pausas muy bajas en heaps grandes, cosa que importa cuando 300 ms te revientan el presupuesto.

Tu servicio muestra pausas de 400 ms en el percentil 99. ¿Cómo lo atacas? Qué mide: disciplina de medición. Activa el logging de GC y confirma que las pausas son de verdad GC antes de tocar nada, porque la contención de locks y las llamadas lentas a servicios de abajo producen colas parecidas. Si es GC, mira primero la tasa de asignación, porque casi todos los problemas de pausa son problemas de asignación.

¿Qué preguntas de colecciones de Java se hacen?

Las colecciones son el filtro más fiable del proceso, porque todo el mundo dice conocerlas y pocos saben explicar sus interioridades. Prepárate para describir cómo está implementado HashMap, por qué el contrato entre equals y hashCode no es opcional, cuándo una LinkedList es de verdad la elección correcta (pocas veces) y en qué se diferencian las colecciones concurrentes de un envoltorio sincronizado.

¿Cómo funciona HashMap por dentro? Qué mide: profundidad. Cubre el hasheo de la clave, la dispersión de los bits, el indexado en un array de buckets, el encadenamiento de colisiones en una lista que se convierte en árbol balanceado cuando un bucket crece mucho, y el redimensionado al llegar al factor de carga rehasheando en un array mayor.

¿Cuál es el contrato entre equals y hashCode, y qué se rompe si lo violas? Qué mide: si alguna vez has depurado esto. Los objetos iguales deben devolver hash codes iguales; los objetos distintos pueden colisionar. Rómpelo y un objeto metido en un HashSet se vuelve imposible de encontrar, porque la búsqueda va al bucket equivocado.

ArrayList o LinkedList: ¿cuándo tirarías de verdad de LinkedList? Qué mide: si repites la complejidad del libro de texto o piensas en el hardware. La notación O favorece a LinkedList en las inserciones, pero ArrayList gana en la práctica para casi cualquier carga porque la memoria contigua es amiga de la caché y perseguir punteros no lo es. LinkedList se defiende sobre todo como deque, y ahí ArrayDeque suele ganarle.

ConcurrentHashMap o un mapa sincronizado: ¿cuál es la diferencia? Qué mide: entender la contención. Un envoltorio sincronizado serializa cada operación sobre un único lock; ConcurrentHashMap permite lecturas concurrentes y escrituras con locks segmentados, lo que da mucho mejor rendimiento bajo carga.

¿Qué preguntas de concurrencia hacen los entrevistadores de Java?

La concurrencia separa el nivel medio del senior más rápido que cualquier otro tema. Espera visibilidad frente a atomicidad, configuración de pools de hilos, deadlocks y, cada vez más, hilos virtuales. Las mejores respuestas evitan la abstracción: describe el fallo real, una lectura obsoleta, una actualización perdida o un pool agotado por tareas bloqueadas, en lugar de recitar definiciones de palabras clave.

¿Qué garantiza volatile y qué no? Qué mide: el modelo de memoria. Volatile garantiza visibilidad y orden: una escritura la ven los demás hilos y se restringe la reordenación a través de ella. No garantiza atomicidad, así que incrementar un contador volatile sigue siendo un bug de actualización perdida, porque leer, sumar y escribir son tres operaciones.

¿Cómo dimensionas un pool de hilos y qué tienen de malo los métodos de fábrica de conveniencia? Qué mide: si has visto fallar un pool. Un pool fijo creado con la fábrica de conveniencia usa una cola sin límite, así que en sobrecarga acumula tareas hasta que el heap muere en lugar de hacer contrapresión. Constrúyelo explícitamente con una cola acotada y una política de rechazo, dimensionado según el tipo de carga.

¿Qué causa un deadlock y cómo lo evitas? Qué mide: precisión y sentido práctico. Un deadlock necesita exclusión mutua, retención y espera, ausencia de expropiación y espera circular, y lo rompes eliminando una de esas condiciones, normalmente con un orden global de locks.

¿Para qué sirven los hilos virtuales y cuándo no ayudan? Qué mide: si estás al día. Hacen que la entrada/salida bloqueante sea barata, así que puedes escribir código bloqueante y directo con mucha concurrencia en lugar de retorcerlo en cadenas asíncronas. No aceleran el trabajo limitado por CPU, y agruparlos en un pool destruye la idea.

¿Qué preguntas de Spring y Spring Boot salen?

Las preguntas de Spring miden si entiendes lo que el framework genera por ti. Espera fundamentos de inyección de dependencias, cómo decide la autoconfiguración qué cablear, el comportamiento de las transacciones y el manejo de errores en una capa REST. La pregunta de las transacciones es el filtro senior clásico, porque las formas en las que una anotación no hace nada en silencio son exactamente las formas en las que los bugs reales llegan a producción.

Explica la inyección de dependencias y por qué se prefiere la inyección por constructor. Qué mide: si entiendes la inversión de control o solo anotas cosas. La inyección por constructor hace las dependencias explícitas y obligatorias, permite campos final y hace la clase testeable sin contenedor. La inyección por campo esconde las dependencias, deja que las referencias circulares sobrevivan sin que se noten, y necesita reflexión para testear.

¿Cómo funciona de verdad @Transactional y cuándo deja de aplicarse en silencio? Qué mide: los proxies. Spring envuelve el bean en un proxy que abre y confirma una transacción alrededor de la llamada, lo que significa que la autoinvocación (un método que llama a otro método anotado de la misma clase) se salta el proxy por completo y se ejecuta sin ninguna transacción.

¿Qué está haciendo la autoconfiguración? Qué mide: si la magia se entiende o se teme. Spring Boot evalúa configuración condicional contra lo que hay en el classpath y lo que ya has definido tú, así que añadir una dependencia cablea valores por defecto sensatos y declarar tu propio bean desactiva ese valor por defecto. El informe de condiciones muestra exactamente qué encajó, que es la vía más rápida para explicar un bean sorprendente.

¿Cómo manejas los errores en una API REST con Spring? Qué mide: consistencia. Centraliza con un controller advice que mapee tipos de excepción a códigos de estado y a un cuerpo de error estable, mantén las trazas de pila fuera de las respuestas y separa bien los errores de cliente de los de servidor.

¿Qué preguntas de lenguaje y diseño se siguen haciendo?

Espera un puñado de preguntas de lenguaje que se usan para calibrar: excepciones, inmutabilidad y las incorporaciones recientes. Mantén las respuestas cortas y prácticas. El panel comprueba que tus opiniones vienen del uso y no de un recitado, así que ata cada una a una decisión que hayas tomado de verdad en una base de código.

Excepciones comprobadas o no comprobadas: ¿cuál es tu postura? Qué mide: gusto por el diseño de APIs. Las excepciones comprobadas obligan a quien llama a manejar una condición recuperable, pero contaminan las firmas y en la práctica acaban tragadas, y por eso la mayoría de las bases de código modernas prefieren excepciones no comprobadas con una frontera clara que las traduzca.

¿Qué problema resuelven los records y los tipos sellados? Qué mide: estar al día con el lenguaje. Los records dan portadores de datos inmutables y concisos con equals, hashCode y toString generados, lo que elimina toda una clase de bugs escritos a mano. Los tipos sellados restringen las implementaciones permitidas, lo que hace que el pattern matching en un switch sea exhaustivo y comprobado en tiempo de compilación.

¿Qué errores hunden a los candidatos de Java?

Casi todos son fallos de profundidad. Los paneles de Java sondean dos o tres niveles por debajo de la definición, así que a quien ha memorizado vocabulario pero nunca ha leído un volcado de heap ni un volcado de hilos lo pillan en la repregunta, no en la primera respuesta. Estos son los patrones que se repiten.

• Recitar definiciones sin mecánica. "Volatile lo hace seguro para hilos" no cuela. Di qué garantiza y qué no.
• Ignorar el runtime. Quien no sabe describir adónde va la memoria ni qué provoca una pausa no puede depurar producción, por muy limpio que tenga el código.
• Tratar Spring como magia. No saber que las transacciones funcionan mediante proxies es la carencia más común a nivel senior.
• Complejidad de libro de texto por encima del comportamiento real. La respuesta sobre LinkedList sacada directamente de un libro señala a alguien que no ha medido nada nunca.
• Silencio mientras programas. Los paneles están comprando tu razonamiento. Narra el enfoque, los casos límite y el compromiso mientras tecleas.
• Conocimiento caducado. Si el equipo está en una LTS actual y tú nunca has oído hablar de records ni de hilos virtuales, se lee como alguien que dejó de aprender.

¿Cómo deberías preparar una entrevista de Java?

Elige las tres áreas que el panel va a sondear seguro (interioridades de las colecciones, concurrencia y el framework que nombre la descripción del puesto) y llévalas hasta el punto de poder explicarlas sin notas. Lee una vez los logs de GC de tu propio servicio y un volcado de hilos, para que esas respuestas salgan de la experiencia y no de una lectura. Después ensaya dos historias de producción, una sobre memoria o latencia y otra sobre un desacuerdo.

Antes del proceso en sí, pega la oferta de empleo real en el Question Predictor gratuito y trabájate las veinte preguntas que marca para ese puesto concreto, porque un equipo de trading de baja latencia y una consultora de Spring comparten un lenguaje y casi nada más.

Para las rondas en vivo, GhostPilot es un copiloto de entrevistas en tiempo real: un panel lateral de extensión de Chrome y una app de escritorio opcional para Windows que transcriben la llamada, pillan la pregunta en cuanto cae y tienen una respuesta estructurada lista unos dos segundos después. Ayuda sobre todo en las preguntas con trampa, como la de las transacciones. Es un apunte, no un guion, y el detalle de producción tiene que salir de ti. El plan gratuito te da 10 minutos de entrevista en vivo a la semana, sin tarjeta.

FAQ de entrevistas de Java

¿Cuánto debería prepararme para una entrevista de desarrollador Java? De dos a tres semanas para un puesto de nivel medio si escribes Java a diario: una semana de fundamentos y colecciones, una de concurrencia y comportamiento del framework, y unos días de historias.

¿Qué versión de Java debería saber para las entrevistas en 2026? Conoce la LTS que usa la empresa a la que apuntas y qué añadieron las versiones recientes, en particular records, tipos sellados, pattern matching en switch e hilos virtuales. Muchas grandes empresas siguen en una LTS más antigua, así que sé honesto sobre lo que has usado de verdad.

¿Cuánto Spring necesito? Si el puesto menciona Spring, trátalo como un tema de primer nivel y no como una nota al pie. Inyección de dependencias, autoconfiguración, transacciones y testing salen en casi todos los procesos con Spring, y la pregunta de las transacciones es donde más candidatos pierden la ronda.

¿Debería admitir cuando no sé algo? Sí. "No he ajustado ese recolector en producción, pero así es como lo abordaría y esto es lo primero que mediría" le gana a una respuesta equivocada dicha con seguridad. Los paneles de Java sondean dos o tres niveles en las repreguntas, así que el farol se derrumba rápido.