Preguntas de entrevista Java 2026: qué preguntan y cómo superarla

Lo confieso: tengo una pregunta favorita para las entrevistas de Java. Es más o menos igual de complicada que un clip. "¿Qué diferencia hay entre == y equals()?"

Fácil, ¿no? Cualquiera con unas semanas de Java la conoce. La persona candidata responde tan tranquila: "== compara referencias, equals() compara contenido". Perfecto. Y entonces le enseño esto:

Integer small1 = 127;
Integer small2 = 127;
Integer big1 = 128;
Integer big2 = 128;

boolean sameSmall = small1 == small2; // true
boolean sameBig = big1 == big2;       // false

Y en la sala se hace un silencio muy, muy largo.

No es que la persona sea mala. Es que se aprendió la respuesta de memoria en lugar de entender cómo funciona. Java cachea los objetos Integer de −128 a 127, así que 127 es uno y el mismo objeto, mientras que 128 te da dos objetos distintos. Quien lo entiende lo explica en diez segundos. Quien lo memorizó se queda mirando la pantalla un buen rato. Un rato muy largo.

Así funciona una entrevista para desarrollador Java en 2026. Las preguntas son casi las mismas que hace cinco años. Lo que cambió es esto: ahora casi siempre llega el "¿y por qué?", y la segunda respuesta deja ver al instante si lo memorizaste o si de verdad lo entiendes.

Llegar a esa entrevista después de memorizar una lista de "las 100 preguntas de entrevista Java más frecuentes" es como subirte al ring con Mike Tyson porque viste un par de sus peleas en YouTube. Técnicamente estás en el ring. Pero la primera repregunta te va a llegar antes de que puedas decir "esto no venía en el tutorial".

Vamos a ver qué preguntan ahora mismo en las entrevistas, dónde tropieza más la gente y cómo prepararte para que las repreguntas te alegren en vez de asustarte.

Qué ha cambiado en las entrevistas de Java en 2026

La versión corta: las preguntas básicas de entrevista Java apenas cambian, pero en 2026 vienen acompañadas de Java moderno (17, 21 y 25), Spring Boot 4 y un formato nuevo: live coding en el que a veces te dejan usar IA.

Los tres cambios más grandes:

• Java 25 es la LTS actual. Salió en septiembre de 2025 y es la primera versión con soporte a largo plazo desde Java 21. Cada vez se pregunta menos solo "qué hay de nuevo en Java 8" y más sobre records, sealed classes, pattern matching y virtual threads.
• Spring Boot 4. Salió en noviembre de 2025 junto con Spring Framework 7: el paso a Jackson 3, anotaciones JSpecify para null safety y versionado de API integrado. Si la oferta menciona Spring, cuenta con una o dos preguntas sobre la nueva versión mayor.
• IA en la entrevista. Algunas empresas ya dejan usar IA en las entrevistas técnicas, y desde 2025 Canva directamente la exige a candidatos de backend, frontend y machine learning. Pero muchas empresas todavía la prohíben. La regla es sencilla: pregúntale al recruiter con antelación.

Cómo es una entrevista para desarrollador Java

Normalmente no es una sola conversación, sino varias rondas:

1. Filtro con recruiter: motivación, experiencia, expectativas salariales. No hay código, pero comprueban que eres una persona razonable.
2. Filtro técnico: 30–45 minutos de preguntas rápidas sobre fundamentos, para que los ingenieros no pierdan tiempo con quien todavía no está a punto.
3. Entrevista técnica: 60–90 minutos de Core Java, colecciones, multithreading, Spring, bases de datos y muchísimos "¿por qué?".
4. Live coding o prueba técnica para casa: resuelves un problema mientras el entrevistador mira, o desde casa.
5. Ronda final: el equipo, los procesos, cómo gestionas conflictos y deadlines. Aquí ya nadie pregunta por HashMap. Te preguntan qué harás si producción se cae un viernes a las seis de la tarde.

A los juniors les preguntan sobre todo fundamentos. Cuanto más senior es el puesto, menos teoría y más conversación sobre experiencia real: qué construiste, qué decisiones tomaste y dónde salieron mal las cosas.

A continuación: preguntas de entrevista Java por temas. No es una lista exhaustiva, solo las más habituales, con respuestas cortas y las trampas en las que cae la gente. Si quieres el análisis detallado de cientos de preguntas, echa un vistazo a nuestra serie de CodeGym Exploración de preguntas y respuestas de una entrevista de trabajo para un puesto de desarrollador Java; más adelante volvemos a ella.

Preguntas de Core Java: la base que no te puedes saltar

¿Qué diferencia hay entre tipos primitivos y tipos de referencia? Una variable primitiva guarda el número o el carácter en sí, mientras que una variable de referencia guarda la dirección de un objeto que vive en el heap. Lo cual nos devuelve directamente a la pregunta trampa del Integer con la que empezamos.

¿Por qué String es inmutable? Es tan inmutable como la opinión de un team lead sobre tabs vs. espacios. Ahora en serio: por seguridad, por el cacheo del hash code y por el string pool, gracias al cual muchas partes del programa pueden compartir la misma cadena a la vez sin riesgo. Si necesitas concatenar cadenas una y otra vez dentro de un bucle, usa StringBuilder, o crearás un objeto nuevo en cada iteración.

¿Qué relación hay entre equals() y hashCode()? Una sola regla: los objetos que son iguales según equals() deben devolver el mismo hashCode(). Pero que objetos distintos compartan el mismo hashCode() es perfectamente normal: es una colisión de toda la vida. Sobrescribe equals(), olvídate de hashCode() y tendrás una forma garantizada de crear objetos que HashMap "no encuentra" aunque estén justo ahí.

¿Java pasa los objetos por referencia o por valor? Un clásico que hace tropezar incluso a perfiles mid con mucha seguridad en sí mismos. Si quieres lucirte, di esto: "Java siempre pasa por valor; a veces ese valor resulta ser una referencia". Suena a galleta de la fortuna, funciona siempre. Por eso un método puede cambiar los campos del objeto que le pasas, pero no puede cambiar a qué objeto apunta tu variable de fuera.

¿Qué devuelve este método?

static String pick() {
    try {
        return "try";
    } finally {
        return "finally";
    }
}

La respuesta es "finally". Un bloque finally siempre se ejecuta, y su return anula el return del try. finally es como el último comentario en un code review: siempre tiene la última palabra. Los entrevistadores no enseñan este código porque alguien deba escribirlo, sino para ver si entiendes el orden de ejecución. Y la respuesta correcta a "¿deberías escribir esto alguna vez?" es no. Nunca.

Excepciones: qué se rompe y a quién le toca arreglarlo

Las preguntas sobre excepciones parecen aburridas justo hasta que producción se cae por un catch que se tragó el error.

• Checked vs. unchecked: ¿cuál es la diferencia? Con las checked, el compilador te obliga a manejarlas o a declararlas en throws; por ejemplo, IOException cuando trabajas con un archivo. Las unchecked, las subclases de RuntimeException, suelen ser bugs del propio código, como NullPointerException o IllegalArgumentException, y el compilador no te obliga a manejarlas. Una respuesta fuerte en la entrevista añade: las checked son para situaciones de las que el programa puede recuperarse razonablemente; las unchecked son bugs que hay que corregir, no capturar.
• ¿Qué hace try-with-resources? Todo lo que declares entre los paréntesis después de try y que implemente AutoCloseable se cierra automáticamente, aunque se lance una excepción dentro:

try (var reader = Files.newBufferedReader(Path.of("orders.csv"))) {
    return reader.readLine();
}

Se acabaron los bloques finally con close() manual y un try anidado dentro del finally, que era como se hacía antes de Java 7.

• ¿Se puede capturar OutOfMemoryError? Técnicamente sí: es una subclase de Throwable. Pero OutOfMemoryError es un Error, no una Exception, es decir, la señal de un problema que el programa normalmente no puede manejar con elegancia. Capturarlo para "seguir adelante" es como reacomodar las sillas en la cubierta del Titanic. Lo único sensato es registrarlo en el log y cerrar de forma ordenada.

POO: ejemplos, no definiciones

El error número uno aquí es responder con definiciones de manual. "La encapsulación es la ocultación de datos". Gracias, pero ¿cuándo te sirvió eso en tu código?

• ¿Clase abstracta o interfaz? Una interfaz describe lo que un objeto puede hacer, y una clase puede implementar muchas interfaces. Una clase abstracta es una base común con estado e implementación parcial, y solo puedes heredar de una. Desde Java 8 las interfaces tienen métodos default, así que la frontera se ha difuminado, y a los entrevistadores les encanta preguntar por eso.
• Sobrecarga vs. sobrescritura. Sobrecarga (overloading): métodos con el mismo nombre y parámetros distintos, se resuelve en tiempo de compilación. Sobrescritura (overriding): una subclase aporta una nueva implementación de un método del padre, se resuelve en tiempo de ejecución.
• ¿Cómo haces una clase inmutable? Campos private final, sin setters, la clase final o con constructor privado, y cualquier objeto mutable de dentro se copia al entrar y al salir. O usa directamente un record; más sobre eso abajo.

Colecciones en Java: cuenta con una pregunta sobre HashMap

Si te hacen una sola pregunta sobre colecciones, será sobre HashMap. Si te hacen dos, la segunda también será sobre HashMap.

¿Cómo funciona HashMap por dentro? Dentro hay un array de "buckets". El hashCode() de la clave elige el bucket, y dentro de un bucket las entradas se guardan como una lista. Si un bucket acaba con más de ocho entradas (y el array ya tiene al menos 64 buckets), la lista se convierte en un árbol rojo-negro para que las búsquedas no se degraden. Cuando el array está lleno al 75% (el load factor por defecto), dobla su tamaño y todas las entradas se redistribuyen.

Y ahora, la trampa:

Map<List<Integer>, String> map = new HashMap<>();
List<Integer> key = new ArrayList<>(List.of(1));
map.put(key, "value");

key.add(2);
String found = map.get(key); // null

Hemos cambiado la clave después de meterla en el mapa. Su hashCode() cambió, así que HashMap la busca en otro bucket y no encuentra nada. La entrada sigue en el mapa; simplemente ya no puedes recuperarla con esa clave. De ahí la regla de oro: las claves de un HashMap deben ser inmutables.

Otras preguntas habituales:

• ¿ArrayList o LinkedList? En código real, casi siempre ArrayList: el acceso por índice es instantáneo y los datos están compactos en memoria. LinkedList solo gana en escenarios raros con inserciones frecuentes en el medio mediante un iterador. Todo el mundo la conoce por los libros, pero casi nadie la ha visto en producción. Como a Pie Grande.
• ¿ConcurrentHashMap o Collections.synchronizedMap()? Las dos son thread-safe, pero synchronizedMap bloquea el mapa entero, mientras que ConcurrentHashMap deja que muchos hilos trabajen con él en paralelo.
• ¿De dónde sale ConcurrentModificationException? De modificar una colección mientras la recorres con un for-each. Para eliminar elementos durante la iteración, usa un iterador o removeIf().

Stream API: una línea de código, tres líneas de preguntas

A los entrevistadores les encantan los streams, y al código real también. Y además hacen facilísimo escribir algo precioso e incorrecto.

• ¿Por qué mi stream "no hace nada"? Operaciones como filter, map y sorted son intermedias: devuelven un stream nuevo y por sí solas no ponen nada en marcha. Los streams son perezosos (lazy): el trabajo empieza solo con una operación terminal: collect, count, forEach. Hasta entonces no se toca ni un solo elemento. De ahí la trampa: escribes un stream con map, olvidas la operación terminal y el código dentro de map nunca se ejecuta. Un stream sin operación terminal es como la lista de tareas del lunes: preciosa, bien escrita, y no pasa nada.
• ¿map() o flatMap()? map es un elemento de entrada, un elemento de salida. flatMap convierte cada elemento en un stream entero y luego los junta todos en un único flujo. El ejemplo clásico es "aplanar" una lista de listas:

List<List<String>> teams = List.of(
        List.of("Anna", "Ben"),
        List.of("Vicky"));

List<String> people = teams.stream()
        .flatMap(List::stream)
        .toList(); // [Anna, Ben, Vicky]

• ¿Se puede usar un stream dos veces? No. Después de una operación terminal el stream queda cerrado, y volver a usarlo lanza IllegalStateException. ¿Lo necesitas otra vez? Crea uno nuevo.
• Optional: ¿cómo se suele estropear? Optional va de frente contigo: puede que el valor no esté. La forma más fácil de arruinarlo es llamar a get() a ciegas: es el NullPointerException de siempre con gafas y bigote postizo. La segunda es usar Optional como campo de una clase o como parámetro de un método: se diseñó como tipo de retorno. Las herramientas correctas son orElse, orElseThrow, map e ifPresent.
• ¿Qué es una interfaz funcional? Una interfaz con exactamente un método abstracto, como Runnable, Comparator o Function. Son las interfaces que puedes implementar con una lambda. La anotación @FunctionalInterface no es obligatoria, pero le pide al compilador que verifique que de verdad hay un solo método.

Preguntas de entrevista sobre multithreading en Java: donde caen los perfiles mid

Aquí es donde se filtra a la mayoría de candidatos de nivel mid. Porque el multithreading no se memoriza con un resumen: hay que entenderlo. Y tenerle un poco de miedo, que es un instinto muy sano.

• ¿Qué garantiza volatile? La visibilidad de los cambios entre hilos: una escritura en una variable volatile hecha por un hilo es visible de inmediato para los demás. Pero volatile no te da atomicidad: count++ es una lectura, una suma y una escritura, y dos hilos aún pueden perder la actualización de alguno.
• ¿Qué es happens-before? Una regla que garantiza que los resultados de una acción son visibles para otra. Por ejemplo, todo lo que hizo un hilo antes de liberar un monitor lo verá el hilo que adquiera ese monitor después.
• ¿Cómo se produce un deadlock? Dos hilos toman los mismos locks en distinto orden y se esperan mutuamente para siempre. Como dos personas extremadamente educadas en un pasillo estrecho: "No, pasa tú", hasta el final de la jornada. La solución es un orden consistente de adquisición de locks, y puedes localizarlo con un thread dump.
• ¿Runnable o Callable? Callable puede devolver un resultado y lanzar excepciones checked. Normalmente se ejecutan a través de un ExecutorService, no a mano con new Thread().

El multithreading es un tema enorme por sí solo; para profundizar, mira la sección de multithreading en nuestro artículo Las 50 mejores preguntas y respuestas de entrevistas de trabajo para Java Core, parte 2.

Java moderno: qué preguntan los entrevistadores en 2026

Esta es la parte que hace cinco años no existía en las entrevistas, y precisamente por eso distingue a quien sigue la evolución del lenguaje.

¿Qué es un record? Una clase compacta para datos inmutables:

record Point(int x, int y) {}

Una línea y ya tienes constructor, los getters x() e y(), equals(), hashCode() y toString(). Todos los campos son final. En algún lugar, Lombok está haciendo las maletas en silencio. Perfecto para DTOs y para esas claves de HashMap, salvo, claro, que tu record contenga un ArrayList mutable: final protege la referencia, no el contenido de la lista.

¿Para qué sirven las sealed classes? Enumeran explícitamente quién puede heredar de ellas. Combinadas con pattern matching en switch, el compilador conoce todas las variantes posibles y te avisará si alguna no está cubierta.

¿Qué son los virtual threads? Hilos ligeros gestionados por la JVM, no por el sistema operativo. Diez mil no son ningún problema; puedes llegar a cientos de miles:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 10_000; i++) {
        executor.submit(() -> callSlowService());
    }
}

Una buena pregunta de entrevista suena así: ¿cuándo no te ayudan los virtual threads? Respuesta: cuando la tarea es CPU-bound y no se pasa el tiempo esperando. Los virtual threads brillan donde el código espera mucho: red, base de datos, servicios externos. Pero no harán más rápida una tarea de cálculo pesado, igual que una silla de oficina nueva no te hace programar más rápido.

Bonus para perfiles mid: antes, un virtual thread quedaba "anclado" (pinned) a su hilo de plataforma si se bloqueaba dentro de synchronized, y toda la ventaja se iba por la ventana. Java 24 lo arregló, pero conviene conocer la trampa: los proyectos en Java 21 no van a desaparecer.

¿Qué hay de nuevo en Java 25? No hace falta enumerar todos los cambios, pero un par merece la pena conocerlos. Por ejemplo, ahora puedes escribir un programa sin declarar una clase y con un método main simplificado, pensado para quien empieza a aprender el lenguaje. Y los constructores ya pueden ejecutar código antes de llamar a super(), por ejemplo para validar argumentos.

JVM y memoria

• ¿Qué áreas forman la memoria de la JVM? El heap, donde viven los objetos; la pila (stack) de cada hilo, con variables locales y llamadas a métodos; y el metaspace, donde se guardan los metadatos de las clases.
• ¿Cómo funciona el garbage collector? Elimina los objetos a los que ya no llega ninguna referencia desde las partes "vivas" del programa. Piensa en el equipo de limpieza de la oficina: solo tira lo que nadie reclama. Una taza con un post-it de "NO TOCAR" se queda donde está, aunque lleve tres años ahí. La mayoría de los objetos viven muy poco, así que el heap se divide en generaciones: los objetos jóvenes se recogen a menudo y rápido; los viejos, con menos frecuencia.
• ¿Puede haber memory leaks en Java? Sí. El garbage collector no eliminará un objeto al que algo sigue haciendo referencia. El ejemplo clásico es una colección static a la que solo se le añaden cosas y nunca se limpia. La misma taza con el post-it, solo que de un gigabyte. O aquel HashMap con la clave mutada: las entradas siguen ahí, pero no las puedes recuperar.

Preguntas de entrevista sobre Spring Boot y bases de datos

Si la oferta incluye Spring (y casi siempre lo incluye; a veces parece que hasta las ofertas de barista lo piden), prepara este bloque aparte.

• IoC y DI: ¿qué son y por qué es mejor la inyección por constructor? Spring crea los objetos por su cuenta y les entrega sus dependencias. La inyección por constructor es mejor porque las dependencias se ven a primera vista, los campos pueden ser final y la clase se prueba fácilmente sin Spring.
• ¿Por qué no funciona @Transactional? El clásico: un método anotado con @Transactional se llama desde otro método de la misma clase. Las transacciones las gestiona un proxy, y una llamada desde dentro de la clase lo rodea por completo, como alguien de la plantilla que entra por la puerta de atrás y nunca pasa la tarjeta. Es una de las preguntas más comunes para perfiles mid.
• ¿Qué es el problema N+1? Cargas una lista de 100 pedidos con una consulta y luego traes el cliente de cada pedido con una consulta aparte. Son 101 consultas en lugar de una o dos. Mientras tanto, la base de datos llora en silencio. La solución es JOIN FETCH o un EntityGraph.
• ¿Qué niveles de aislamiento de transacciones existen? De READ UNCOMMITTED a SERIALIZABLE. No basta con enumerarlos: hay que explicar de qué anomalías protege cada uno: lecturas sucias, lecturas no repetibles, lecturas fantasma.
• ¿INNER JOIN o LEFT JOIN? Imagina dos tablas: clientes y pedidos. INNER JOIN se queda solo con los clientes que tienen al menos un pedido; el resto desaparece del resultado. LEFT JOIN conserva a todos los clientes, y los "vacíos" reciben NULL en las columnas de pedidos. Una pregunta clásica para comprobar si lo entiendes: ¿cómo encuentras a los clientes que no tienen ningún pedido? Respuesta: LEFT JOIN más la condición de que una columna de la tabla de pedidos IS NULL.
• ¿Para qué sirven los índices y por qué no se puede indexar todo? Un índice acelera las búsquedas como el índice de un libro: la base de datos no tiene que leer la tabla entera. Pero cada índice ralentiza las inserciones y actualizaciones, porque también hay que mantenerlo, y ocupa espacio. Por eso los índices se crean para consultas reales, no por si acaso. Indexarlo todo es como subrayar un libro de texto entero: si todo está subrayado, no hay nada subrayado.

Si las bases de datos son tu punto débil, el curso de SQL de CodeGym te permite practicar consultas con tus propias manos hasta que los JOIN dejen de dar miedo.

Entrevista técnica de Java: live coding e IA

El live coding es la parte que más asusta. Resolver un problema mientras alguien mira es estresante: hasta un simple bucle for empieza a parecer sospechoso. Pero aquí va el secreto: al entrevistador casi siempre le importa más cómo piensas que si la respuesta te salió bien.

Lo que valoran los entrevistadores en el live coding:

• Piensa en voz alta. Quien calla es una caja negra. Quien razona en voz alta muestra su proceso de pensamiento, aunque se atasque.
• Aclara los requisitos. "¿La entrada puede contener null?", "¿De qué tamaño es el array?": eso no es despiste, es profesionalidad.
• Empieza por una solución simple. Primero que funcione, luego que sea óptima. Una solución de fuerza bruta que funciona gana a una idea brillante que no te dio tiempo a terminar.

Ejemplo práctico: cómo es un problema de live coding

Tomemos un problema típico de live coding: encontrar el primer carácter de una cadena que aparece exactamente una vez. Para la cadena "swiss", la respuesta es "w".

Paso 1. Aclara los requisitos. Antes de escribir código, haz un par de preguntas. ¿Qué devuelves si no existe ese carácter? ¿Mayúsculas y minúsculas cuentan como distintas? ¿La cadena puede estar vacía? El entrevistador responderá y verá que piensas en los casos límite.

Paso 2. Solución simple. Para cada carácter, recorres toda la cadena y cuentas cuántas veces aparece. Funciona, pero es O(n²): con una cadena de un millón de caracteres va a tardar muchísimo. Dilo en voz alta: el entrevistador quiere ver que entiendes el coste de tu solución.

Paso 3. Optimiza. Bastan dos pasadas: primero cuentas todos los caracteres y luego buscas el primero con recuento uno. Para mantener el orden de los caracteres, LinkedHashMap cumple. Y como puede que el carácter no exista, devolvemos Optional, tal como quedamos en la sección de streams:

static Optional<Character> firstUnique(String text) {
    Map<Character, Integer> counts = new LinkedHashMap<>();
    for (char c : text.toCharArray()) {
        counts.merge(c, 1, Integer::sum);
    }
    for (Map.Entry<Character, Integer> entry : counts.entrySet()) {
        if (entry.getValue() == 1) {
            return Optional.of(entry.getKey());
        }
    }
    return Optional.empty();
}

Ahora es O(n): cada carácter se procesa un número constante de veces.

Paso 4. Ponte a prueba. Ejecuta un par de ejemplos mentalmente: "swiss" devuelve "w", "aabb" devuelve un Optional vacío, y una cadena vacía también devuelve un Optional vacío. Si el entrevistador pregunta por qué LinkedHashMap y no HashMap, ya tienes la respuesta: un HashMap normal no recuerda el orden de inserción, así que el "primer" carácter podría ser cualquiera.

Y ahora un bonus que sorprenderá gratamente a tu entrevistador: puedes arreglártelas con un HashMap normal si la segunda pasada recorre la propia cadena en lugar del mapa. Entonces es la cadena la que marca el orden, y el mapa solo guarda los recuentos. Dos opciones que funcionan y una elección clara entre ellas: justo lo que los entrevistadores quieren ver en un live coding.

Ese es todo el secreto del live coding. No una solución brillante a la primera, sino un camino claro: aclarar los requisitos, resolverlo de forma simple, estimar la complejidad, mejorarlo y probarlo.

Entonces, ¿se puede usar IA? Depende de la empresa y, a veces, de la ronda de la entrevista. Si está permitida, el entrevistador normalmente no se fija en lo que generó la IA, sino en cómo la usas: qué le pides, cómo compruebas el resultado, si detectas los errores. En Canva, por ejemplo, lo dicen sin rodeos: lo que importa no es lo que la IA escribió por ti, sino la capacidad de leer el código generado, entenderlo y mejorarlo, y de explicar cada decisión técnica. Si no sabes explicar qué hace el código, la IA no te ayudó: te dejó vendido. Es como presentarte a un examen con apuntes escritos en un idioma que no hablas.

Sinceramente, es el argumento más fuerte a favor de unos fundamentos sólidos que conozco. Una IA te escribe un HashMap con una clave mutable en un segundo. Solo tú puedes darte cuenta de que no debería.

Resumen: qué evalúan de verdad las preguntas de entrevista Java

Cada pregunta de entrevista tiene una capa oculta. Esto es lo que hay detrás de las más habituales:

Cómo preparar una entrevista de Java en tres semanas

Semana 1: fundamentos. Core Java, POO, excepciones, colecciones y Stream API. No te limites a leer respuestas: escribe código. Mete una clave mutable en un HashMap y mira qué pasa. Rompe equals() y hashCode() y encuentra dónde explota.

Semana 2: multithreading y Java moderno. Escribe un programa con un deadlock y encuéntralo con un thread dump. Reescribe un par de clases como records. Lanza diez mil virtual threads y observa cómo funciona.

Semana 3: Spring, bases de datos y práctica. Monta una pequeña app de Spring Boot con base de datos, detecta un problema N+1 en tu propio código y arréglalo. Y haz sí o sí un par de entrevistas de prueba: con una amistad, con un mentor o, como mínimo, en voz alta delante del espejo.

Y la regla principal: no memorices respuestas. Cada pregunta de este artículo se puede comprobar con código en cinco minutos. Lo que verificas con tus propias manos se queda para siempre; lo que memorizas dura hasta el primer "¿y por qué?".

Y entonces en la sala volverá a hacerse el silencio. Solo que esta vez será porque el entrevistador ya no tiene nada que añadir.

Dónde practicar

En el curso de Java de CodeGym, casi todos los temas de este artículo, desde colecciones y excepciones hasta multithreading, se trabajan con tareas que se verifican al instante. Un error en equals() y hashCode() salta en el momento, no en la entrevista.

Y si buscas un programa con mentor, code review y proyectos para el portfolio, existe Java University, pero ten en cuenta que se imparte en inglés.

¿Quieres todavía más preguntas con respuestas detalladas? Abre nuestra serie de CodeGym Exploración de preguntas y respuestas de una entrevista de trabajo para un puesto de desarrollador Java y Las 150 preguntas de entrevista de trabajo más frecuentes para desarrolladores de Java. Hay material para muchas tardes.

Preguntas frecuentes

¿Qué preguntas de entrevista Java se hacen en 2026? La base sigue siendo la misma: Core Java, POO, excepciones, colecciones, Stream API, multithreading, la JVM, Spring y bases de datos. En 2026 se suman preguntas sobre Java moderno (records, sealed classes, pattern matching, virtual threads y los cambios de Java 25) y sobre Spring Boot 4.

¿Qué preguntan en una entrevista para desarrollador Java junior? Sobre todo fundamentos: la diferencia entre == y equals(), la relación entre equals() y hashCode(), por qué String es inmutable, cómo funciona HashMap, ArrayList vs. LinkedList, excepciones checked vs. unchecked, try-with-resources y map() vs. flatMap() en la Stream API. No basta con saber la respuesta: hay que explicar por qué funciona así.

¿Qué preguntas de entrevista Java le hacen a un perfil mid? Multithreading (volatile, happens-before, deadlock, ExecutorService), cómo funcionan la JVM y el garbage collector, Spring (DI, @Transactional y sus trampas), Hibernate (el problema N+1, lazy loading) y los niveles de aislamiento de transacciones. Además de muchas preguntas sobre experiencia real.

¿Se puede usar IA en una entrevista de Java? Depende de la empresa e incluso de la ronda de la entrevista. Algunas empresas permiten o exigen IA en las entrevistas técnicas; muchas todavía la prohíben. Consúltalo con el recruiter con antelación. Si la IA está permitida, comprobarán si sabes explicar y verificar el código generado.

¿Qué versión de Java importa ahora mismo para las entrevistas? La versión LTS actual es Java 25, publicada en septiembre de 2025. Aun así, muchas empresas siguen con Java 17 y 21, así que conviene saber qué introdujo cada una de esas versiones.

¿Qué problemas salen en una entrevista técnica de Java con código? Normalmente pequeños problemas algorítmicos con cadenas, arrays y colecciones: encontrar el primer carácter que no se repite, encontrar duplicados en un array, comprobar si algo es un palíndromo, agrupar datos con un HashMap. El entrevistador no solo mira el resultado, sino cómo aclaras los requisitos, estimas la complejidad y compruebas los casos límite.

¿Cómo preparar una entrevista de Java rápido? Tres semanas bastan para refrescar a fondo los fundamentos: la primera, Core Java y colecciones; la segunda, multithreading y Java moderno; la tercera, Spring, bases de datos y entrevistas de prueba. La clave es comprobar cada respuesta con código en lugar de memorizarla.