Java Vorstellungsgespräch Fragen 2026: Was wirklich gefragt wird

Ich gebe es offen zu: Ich habe eine Lieblingsfrage für Java-Interviews. Sie ist ungefähr so kompliziert wie eine Büroklammer. „Was ist der Unterschied zwischen == und equals()?“

Klingt einfach, oder? Wer ein paar Wochen Java gelernt hat, kennt die Antwort. Die Person mir gegenüber antwortet gut gelaunt: „== vergleicht Referenzen, equals() vergleicht Inhalte.“ Super. Dann zeige ich das hier:

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

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

Und im Raum wird es sehr, sehr still.

Das liegt nicht daran, dass die Person schlecht ist. Sondern daran, dass sie die Antwort auswendig gelernt hat, statt zu verstehen, wie es funktioniert. Java cacht Integer-Objekte von −128 bis 127, also ist 127 ein und dasselbe Objekt, während du bei 128 zwei verschiedene bekommst. Wer es verstanden hat, erklärt das in zehn Sekunden. Wer es auswendig gelernt hat, starrt sehr, sehr lange auf den Bildschirm.

So läuft ein Java-Vorstellungsgespräch 2026. Die Fragen sind fast dieselben wie vor fünf Jahren. Geändert hat sich Folgendes: Heute kommt fast immer ein „Aber warum?“ hinterher – und die zweite Antwort zeigt sofort, ob du etwas auswendig gelernt oder wirklich verstanden hast.

Mit einer gepaukten Liste „Top 100 Java Interview Fragen“ ins Gespräch zu gehen ist, als würdest du mit Mike Tyson in den Ring steigen, weil du dir auf YouTube ein paar seiner Kämpfe angesehen hast. Technisch gesehen stehst du im Ring. Aber die erste Nachfrage trifft dich schneller, als du „Das kam im Tutorial nicht vor“ sagen kannst.

Schauen wir uns an, was Interviewer gerade fragen, wo die meisten stolpern und wie du dich so vorbereitest, dass Nachfragen dich freuen statt erschrecken.

Was sich 2026 bei Java-Vorstellungsgesprächen geändert hat

Kurz gesagt: Die Core-Java-Interviewfragen ändern sich kaum, aber 2026 kommen modernes Java (17, 21 und 25), Spring Boot 4 und ein neues Format dazu – Live Coding, bei dem KI manchmal erlaubt ist.

Die drei größten Veränderungen:

• Java 25 ist die aktuelle LTS-Version. Sie erschien im September 2025 und ist das erste Long-Term-Support-Release seit Java 21. Interviewer fragen immer öfter nicht nur „Was ist neu in Java 8?“, sondern auch nach Records, Sealed Classes, Pattern Matching und Virtual Threads.
• Spring Boot 4. Erschienen im November 2025 zusammen mit Spring Framework 7: Umstieg auf Jackson 3, JSpecify-Annotationen für Null Safety, eingebaute API-Versionierung. Steht Spring in der Stellenanzeige, rechne mit ein, zwei Fragen zur neuen Major-Version.
• KI im Vorstellungsgespräch. Manche Unternehmen erlauben KI in technischen Interviews schon heute, und Canva verlangt sie seit 2025 sogar ausdrücklich von allen, die sich für Backend, Frontend oder Machine Learning bewerben. Viele Firmen verbieten sie aber nach wie vor. Die Regel ist einfach: Frag vorher beim Recruiting nach.

So läuft ein Java-Vorstellungsgespräch ab

Meist ist es kein einzelnes Gespräch, sondern mehrere Runden:

1. Recruiter-Screening – Motivation, Erfahrung, Gehaltsvorstellung. Kein Code, aber es wird geprüft, ob du ein vernünftiger Mensch bist.
2. Technisches Screening – 30–45 Minuten Grundlagen im Schnelldurchlauf, damit die Engineers keine Zeit mit Leuten verschwenden, die noch nicht so weit sind.
3. Technisches Interview – 60–90 Minuten: Core Java, Collections, Multithreading, Spring, Datenbanken und jede Menge „Warum?“.
4. Live Coding oder Testaufgabe für zu Hause – du löst eine Aufgabe, während jemand zuschaut, oder eben daheim.
5. Finale Runde – das Team, die Prozesse, wie du mit Konflikten und Deadlines umgehst. Nach HashMap fragt hier keiner mehr. Hier wird gefragt, was du tust, wenn die Produktion am Freitag um 18 Uhr ausfällt.

Im Junior-Bereich geht es vor allem um Grundlagen. Je höher die Position, desto weniger Theorie und desto mehr Gespräch über echte Erfahrung: was du gebaut hast, welche Entscheidungen du getroffen hast und wo etwas schiefging.

Als Nächstes: Java Interview Fragen nach Themen. Das ist keine vollständige Liste – nur die häufigsten Fragen, mit kurzen Antworten und den Fallen, in die viele tappen. Eine ausführliche Analyse von Hunderten Fragen findest du in unserer CodeGym-Serie Fragen und Antworten aus Vorstellungsgesprächen für Java-Entwickler – darauf kommen wir später noch zurück.

Core Java Interview Fragen: Grundlagen, an denen du nicht vorbeikommst

Was ist der Unterschied zwischen primitiven Typen und Referenztypen? Eine primitive Variable enthält die eigentliche Zahl oder das Zeichen, eine Referenzvariable dagegen die Adresse eines Objekts, das im Heap liegt. Und damit sind wir direkt wieder bei der Integer-Fangfrage vom Anfang.

Warum ist String immutable? Er ist so unveränderlich wie die Meinung eines Teamleads zu Tabs vs. Spaces. Aber im Ernst: wegen Sicherheit, Hashcode-Caching und dem String-Pool – viele Teile eines Programms können sich gefahrlos gleichzeitig denselben String teilen. Wenn du in einer Schleife immer wieder Strings zusammenklebst, nimm StringBuilder, sonst erzeugst du bei jeder Iteration ein brandneues Objekt.

Wie hängen equals() und hashCode() zusammen? Eine Regel: Objekte, die laut equals() gleich sind, müssen denselben hashCode() liefern. Dass unterschiedliche Objekte denselben hashCode() haben, ist dagegen völlig in Ordnung – das ist eine ganz normale Kollision. Überschreibst du equals() und vergisst hashCode(), hast du eine todsichere Methode, Objekte zu erzeugen, die HashMap „nicht findet“, obwohl sie direkt vor ihr liegen.

Übergibt Java Objekte per Referenz oder per Wert? Ein Publikumsliebling, über den selbst selbstbewusste Mid-Level-Devs stolpern. Wenn du glänzen willst, sag: „Java übergibt immer per Wert – manchmal ist dieser Wert eben eine Referenz.“ Klingt wie aus einem Glückskeks, funktioniert aber jedes Mal. Deshalb kann eine Methode die Felder eines übergebenen Objekts ändern, aber nicht austauschen, auf welches Objekt deine Variable draußen zeigt.

Was gibt diese Methode zurück?

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

Die Antwort ist "finally". Ein finally-Block läuft immer, und sein return überschreibt das return aus try. finally ist wie der letzte Kommentar im Code Review: Er hat immer das letzte Wort. Interviewer zeigen diesen Code nicht, weil man ihn so schreiben sollte – sie wollen sehen, ob du die Ausführungsreihenfolge verstehst. Und die richtige Antwort auf „Sollte man das jemals so schreiben?“ lautet: Nein. Niemals.

Exceptions: Was kaputtgeht und wer dafür geradesteht

Fragen zu Exceptions wirken langweilig – bis die Produktion wegen eines verschluckten catch ausfällt.

• Checked vs. unchecked: Was ist der Unterschied? Bei checked Exceptions zwingt dich der Compiler, sie entweder zu behandeln oder in throws zu deklarieren – zum Beispiel IOException, wenn du mit einer Datei arbeitest. Unchecked Exceptions, also Unterklassen von RuntimeException, sind meist Bugs im Code selbst, etwa NullPointerException oder IllegalArgumentException, und der Compiler zwingt dich nicht, sie zu behandeln. Eine starke Antwort im Interview ergänzt: Checked ist für Situationen, von denen sich das Programm sinnvoll erholen kann, unchecked für Bugs, die man fixen und nicht fangen sollte.
• Was macht try-with-resources? Alles, was in den Klammern nach try deklariert wird und AutoCloseable implementiert, wird automatisch geschlossen, auch wenn darin eine Exception fliegt:

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

Keine finally-Blöcke mehr mit manuellem close() und verschachteltem try im finally – so lief das vor Java 7.

• Kann man OutOfMemoryError fangen? Technisch ja: Er ist eine Unterklasse von Throwable. Aber OutOfMemoryError ist ein Error, keine Exception – ein Signal für ein Problem, mit dem das Programm in der Regel nicht vernünftig umgehen kann. Ihn zu fangen, um „einfach weiterzumachen“, ist, als würdest du auf der Titanic die Liegestühle umstellen. Der einzig sinnvolle Schritt: loggen und sauber herunterfahren.

OOP: Beispiele statt Definitionen

Der häufigste Fehler hier: mit Lehrbuchdefinitionen antworten. „Kapselung ist das Verbergen von Daten.“ Danke – aber wo hat dir das in deinem Code je geholfen?

• Abstrakte Klasse oder Interface? Ein Interface beschreibt, was ein Objekt kann, und eine Klasse kann viele Interfaces implementieren. Eine abstrakte Klasse ist ein gemeinsames Fundament mit Zustand und teilweiser Implementierung, und du kannst nur von einer erben. Seit Java 8 haben Interfaces default-Methoden, die Grenze ist also verschwommener geworden – und genau danach fragen Interviewer gern.
• Overloading vs. Overriding. Overloading heißt: Methoden mit gleichem Namen und unterschiedlichen Parametern, aufgelöst zur Compile-Zeit. Overriding heißt: Eine Unterklasse liefert eine neue Implementierung einer Methode der Elternklasse, aufgelöst zur Laufzeit.
• Wie macht man eine Klasse immutable? Felder private final, keine Setter, die Klasse ist final oder hat einen privaten Konstruktor, und veränderliche Objekte darin werden beim Rein- und beim Rausgeben kopiert. Oder du nimmst einfach einen Record – mehr dazu weiter unten.

Java Collections: Eine HashMap-Frage kommt garantiert

Wenn du nur eine Frage zu Collections bekommst, geht es um HashMap. Wenn du zwei bekommst, geht es in der zweiten auch um HashMap.

Wie funktioniert HashMap unter der Haube? Intern gibt es ein Array aus „Buckets“. Der hashCode() des Schlüssels bestimmt den Bucket, und innerhalb eines Buckets werden die Einträge als Liste gespeichert. Landen in einem Bucket mehr als acht Einträge (und hat das Array schon mindestens 64 Buckets), wird die Liste zu einem Rot-Schwarz-Baum, damit die Suche nicht langsamer wird. Ist das Array zu 75 % gefüllt – das ist der Standard-Load-Factor –, verdoppelt es seine Größe und alle Einträge werden neu verteilt.

Und jetzt die Falle:

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

Wir haben den Schlüssel geändert, nachdem er in der Map lag. Sein hashCode() hat sich geändert, also sucht HashMap in einem anderen Bucket und findet nichts. Der Eintrag ist noch in der Map – du kommst mit diesem Schlüssel nur nicht mehr an ihn heran. Daher die goldene Regel: HashMap-Schlüssel sollten immutable sein.

Weitere häufige Fragen:

• ArrayList oder LinkedList? Im echten Code fast immer ArrayList: Der Indexzugriff geht sofort, und die Daten liegen kompakt im Speicher. LinkedList gewinnt nur in seltenen Szenarien mit häufigem Einfügen in der Mitte über einen Iterator. Alle kennen sie aus dem Lehrbuch, aber kaum jemand hat sie je in Produktion gesehen – ein bisschen wie das Ungeheuer von Loch Ness.
• ConcurrentHashMap oder Collections.synchronizedMap()? Beide sind thread-safe, aber synchronizedMap sperrt die gesamte Map, während ConcurrentHashMap viele Threads parallel damit arbeiten lässt.
• Woher kommt ConcurrentModificationException? Daher, dass du eine Collection änderst, während du mit for-each über sie iterierst. Um Elemente während der Iteration zu entfernen, nimm einen Iterator oder removeIf().

Stream API: Eine Zeile Code, drei Zeilen Fragen

Interviewer lieben Streams, echter Code auch. Mit ihnen schreibt man aber auch sehr leicht etwas, das schön aussieht und trotzdem falsch ist.

• Warum „tut“ mein Stream nichts? Operationen wie filter, map und sorted sind intermediär: Sie geben einen neuen Stream zurück und stoßen von sich aus nichts an. Streams sind lazy: Die Arbeit beginnt erst bei einer terminalen Operation – collect, count, forEach. Bis dahin wird kein einziges Element angefasst. Daher die Falle: Schreibst du einen Stream mit map und vergisst die terminale Operation, läuft der Code in map nie. Ein Stream ohne terminale Operation ist wie die To-do-Liste am Montag: wunderschön geschrieben, und es passiert nichts.
• map() oder flatMap()? map heißt: ein Element rein, ein Element raus. flatMap macht aus jedem Element einen ganzen Stream und führt dann alle zu einem einzigen Fluss zusammen. Das klassische Beispiel ist das „Flachklopfen“ einer Liste von Listen:

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]

• Kann man einen Stream zweimal nutzen? Nein. Nach einer terminalen Operation ist der Stream geschlossen, und ein erneuter Aufruf wirft IllegalStateException. Brauchst du ihn noch mal? Erzeug einen neuen.
• Optional: Wie macht man es kaputt? Optional sagt dir ehrlich: Der Wert ist vielleicht nicht da. Am einfachsten ruinierst du das, indem du blind get() aufrufst – das ist dieselbe alte NullPointerException, nur mit Brille und falschem Schnurrbart. Der zweite Weg: Optional als Klassenfeld oder Methodenparameter verwenden, obwohl es als Rückgabetyp gedacht war. Die richtigen Werkzeuge sind orElse, orElseThrow, map und ifPresent.
• Was ist ein Functional Interface? Ein Interface mit genau einer abstrakten Methode, etwa Runnable, Comparator oder Function. Genau diese Interfaces kannst du mit einem Lambda implementieren. Die Annotation @FunctionalInterface ist nicht Pflicht, aber sie bittet den Compiler zu prüfen, dass es wirklich nur eine Methode gibt.

Java Multithreading Interview Fragen: Wo Mid-Level am häufigsten scheitert

Genau hier wird der Großteil der Mid-Level-Bewerbungen aussortiert. Denn Multithreading kann man nicht vom Spickzettel auswendig lernen – man muss es verstehen. Und ein bisschen Respekt davor haben: Das ist ein gesunder Instinkt.

• Was garantiert volatile? Sichtbarkeit von Änderungen zwischen Threads: Schreibt ein Thread in eine volatile-Variable, sehen die anderen das sofort. Atomarität gibt dir volatile aber nicht: count++ ist Lesen, Addieren und Schreiben, und zwei Threads können trotzdem das Update des jeweils anderen verlieren.
• Was ist happens-before? Eine Regel, die garantiert, dass die Ergebnisse einer Aktion für eine andere sichtbar sind. Zum Beispiel sieht der Thread, der einen Monitor als Nächstes bekommt, alles, was ein anderer Thread vor dem Freigeben dieses Monitors getan hat.
• Wie entsteht ein Deadlock? Zwei Threads holen sich dieselben Locks in unterschiedlicher Reihenfolge und warten ewig aufeinander. Wie zwei extrem höfliche Menschen in einem engen Flur: „Nein, bitte nach Ihnen“ – bis zum Feierabend. Die Lösung ist eine einheitliche Reihenfolge beim Holen der Locks, und aufspüren kannst du den Deadlock mit einem Thread-Dump.
• Runnable oder Callable? Callable kann ein Ergebnis zurückgeben und checked Exceptions werfen. Gestartet werden beide meist über einen ExecutorService, nicht von Hand über new Thread().

Multithreading ist ein großes Thema für sich – mehr dazu im Multithreading-Abschnitt unserer 50 wichtigsten Interviewfragen und Antworten zu Java Core, Teil 2.

Modernes Java: Was 2026 im Interview gefragt wird

Diesen Teil gab es vor fünf Jahren in Interviews noch nicht – und genau deshalb erkennt man daran, wer mit der Sprache Schritt hält.

Was ist ein Record? Eine kompakte Klasse für unveränderliche Daten:

record Point(int x, int y) {}

Eine Zeile, und du hast schon einen Konstruktor, die Getter x() und y(), equals(), hashCode() und toString(). Alle Felder sind final. Irgendwo packt Lombok leise seine Koffer. Perfekt für DTOs und für genau diese HashMap-Schlüssel – es sei denn, dein Record enthält eine veränderliche ArrayList: final schützt die Referenz, nicht den Inhalt der Liste.

Wozu braucht man Sealed Classes? Sie legen explizit fest, wer von ihnen erben darf. Zusammen mit Pattern Matching in switch kennt der Compiler alle möglichen Varianten und warnt dich, wenn eine davon nicht behandelt wird.

Was sind Virtual Threads? Leichtgewichtige Threads, die von der JVM verwaltet werden, nicht vom Betriebssystem. Zehntausend davon sind kein Problem, es dürfen auch Hunderttausende sein:

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

Eine gute Interviewfrage klingt so: Wann helfen Virtual Threads nicht? Antwort: wenn die Aufgabe CPU-lastig ist, statt ihre Zeit mit Warten zu verbringen. Virtual Threads glänzen dort, wo Code viel wartet – auf Netzwerk, Datenbank, externe Services. Eine rechenintensive Aufgabe machen sie aber kein bisschen schneller, genauso wenig wie ein neuer Bürostuhl dich schneller coden lässt.

Bonus für Mid-Level: Früher wurde ein Virtual Thread an seinen Plattform-Thread „gepinnt“, wenn er innerhalb von synchronized blockierte, und der ganze Vorteil war dahin. Java 24 hat das behoben, aber die Falle solltest du kennen – Java-21-Projekte verschwinden so schnell nicht.

Was ist neu in Java 25? Du musst nicht jede Änderung aufzählen, aber ein paar solltest du kennen. Zum Beispiel kannst du jetzt ein Programm schreiben, ohne eine Klasse zu deklarieren, und mit einer vereinfachten main-Methode – gedacht für alle, die gerade erst mit der Sprache anfangen. Und Konstruktoren können jetzt Code ausführen, bevor sie super() aufrufen, zum Beispiel um Argumente zu validieren.

JVM und Speicher

• Aus welchen Bereichen besteht der JVM-Speicher? Aus dem Heap, in dem die Objekte leben; dem Stack jedes Threads mit lokalen Variablen und Methodenaufrufen; und dem Metaspace, in dem die Metadaten der Klassen liegen.
• Wie funktioniert der Garbage Collector? Er entfernt Objekte, auf die aus den „lebenden“ Teilen des Programms nichts mehr verweist. Stell ihn dir als Reinigungsteam im Büro vor: Weggeworfen wird nur, was niemand für sich beansprucht. Eine Tasse mit dem Klebezettel „NICHT ANFASSEN“ bleibt stehen, auch wenn sie seit drei Jahren dort steht. Die meisten Objekte leben nur sehr kurz, deshalb ist der Heap in Generationen aufgeteilt: Junge Objekte werden oft und schnell eingesammelt, alte seltener.
• Kann es in Java Memory Leaks geben? Ja. Der Garbage Collector entfernt kein Objekt, auf das noch etwas verweist. Das klassische Beispiel ist eine statische Collection, in die immer nur hinzugefügt und nie aufgeräumt wird. Dieselbe Tasse mit Klebezettel, nur ein Gigabyte groß. Oder die HashMap mit dem veränderten Schlüssel: Die Einträge bleiben, aber du kommst nicht mehr an sie heran.

Spring Boot und Datenbanken: Fragen im Vorstellungsgespräch

Wenn Spring in der Stellenanzeige steht – und das tut es fast immer (manchmal hat man das Gefühl, sogar in Anzeigen für Baristas) –, bereite diesen Block separat vor.

• IoC und DI: Was ist das, und warum ist Constructor Injection besser? Spring erzeugt die Objekte selbst und übergibt ihnen ihre Abhängigkeiten. Constructor Injection ist besser, weil die Abhängigkeiten sofort sichtbar sind, Felder final sein können und sich die Klasse leicht ohne Spring testen lässt.
• Warum funktioniert @Transactional nicht? Der Klassiker: Eine mit @Transactional annotierte Methode wird aus einer anderen Methode derselben Klasse aufgerufen. Transaktionen werden über einen Proxy gesteuert, und ein Aufruf innerhalb der Klasse geht direkt an ihm vorbei – wie jemand aus dem Team, der durch die Hintertür reinschlüpft und den Ausweis nie an den Scanner hält. Das ist eine der häufigsten Mid-Level-Fragen.
• Was ist das N+1-Problem? Du lädst mit einer Abfrage eine Liste von 100 Bestellungen und holst dann für jede Bestellung den Kunden mit einer separaten Abfrage. Das sind 101 Abfragen statt einer oder zwei. Die Datenbank weint derweil leise vor sich hin. Die Lösung ist JOIN FETCH oder ein EntityGraph.
• Welche Isolationsstufen für Transaktionen gibt es? Von READ UNCOMMITTED bis SERIALIZABLE. Aufzählen reicht nicht – du musst erklären, gegen welche Anomalien jede Stufe schützt: Dirty Reads, Non-Repeatable Reads, Phantom Reads.
• INNER JOIN oder LEFT JOIN? Stell dir zwei Tabellen vor: Kunden und Bestellungen. INNER JOIN behält nur die Kunden, die mindestens eine Bestellung haben – alle anderen verschwinden einfach aus dem Ergebnis. LEFT JOIN behält alle Kunden, und die „leeren“ bekommen NULL in den Bestellspalten. Eine klassische Verständnisfrage: Wie findest du Kunden, die gar keine Bestellungen haben? Antwort: LEFT JOIN plus die Bedingung, dass eine Spalte aus der Bestelltabelle IS NULL ist.
• Wozu Indizes, und warum kann man nicht einfach alles indizieren? Ein Index beschleunigt die Suche wie das Inhaltsverzeichnis eines Buchs: Die Datenbank muss nicht die ganze Tabelle lesen. Aber jeder Index bremst Einfügen und Aktualisieren, weil er mitgepflegt werden muss, und er braucht Platz. Deshalb legt man Indizes für echte Abfragen an, nicht auf Verdacht. Alles zu indizieren ist, als würdest du ein komplettes Lehrbuch mit Textmarker anstreichen: Wenn alles markiert ist, ist nichts markiert.

Wenn Datenbanken deine Schwachstelle sind, kannst du im SQL-Kurs von CodeGym Abfragen praktisch üben, bis JOINs dir keine Angst mehr machen.

Java Coding Interview: Live Coding und KI

Live Coding ist der gruseligste Teil. Eine Aufgabe zu lösen, während jemand zuschaut, ist Stress: Selbst eine simple for-Schleife sieht plötzlich verdächtig aus. Aber hier ist das Geheimnis: Den Interviewer interessiert fast immer mehr, wie du denkst, als ob deine Antwort am Ende stimmt.

Was Interviewer beim Live Coding schätzen:

• Denk laut. Wer schweigt, ist eine Blackbox. Wer laut überlegt, zeigt den eigenen Denkprozess, selbst wenn es mal hakt.
• Kläre die Anforderungen. „Kann die Eingabe null enthalten?“, „Wie groß ist das Array?“ – das ist keine Ahnungslosigkeit, das ist Professionalität.
• Fang mit einer einfachen Lösung an. Erst muss es funktionieren, dann wird optimiert. Eine funktionierende Brute-Force-Lösung schlägt eine geniale Idee, die du nicht mehr fertig bekommen hast.

Beispiel: So sieht eine Live-Coding-Aufgabe aus

Nehmen wir eine typische Live-Coding-Aufgabe: Finde das erste Zeichen in einem String, das genau einmal vorkommt. Für den String "swiss" lautet die Antwort "w".

Schritt 1. Anforderungen klären. Bevor du Code schreibst, stell ein paar Fragen. Was soll zurückkommen, wenn es kein solches Zeichen gibt? Sind Groß- und Kleinbuchstaben unterschiedlich? Kann der String leer sein? Der Interviewer antwortet – und sieht, dass du an Edge Cases denkst.

Schritt 2. Einfache Lösung. Geh für jedes Zeichen den ganzen String durch und zähl, wie oft es vorkommt. Das funktioniert, ist aber O(n²): Bei einem String mit einer Million Zeichen dauert das sehr lange. Sag das laut – der Interviewer will sehen, dass du die Kosten deiner Lösung verstehst.

Schritt 3. Optimieren. Zwei Durchläufe reichen: zuerst alle Zeichen zählen, dann das erste mit der Anzahl eins finden. Damit die Reihenfolge der Zeichen erhalten bleibt, erledigt LinkedHashMap den Job. Und weil es das Zeichen vielleicht gar nicht gibt, geben wir Optional zurück – genau wie im Abschnitt zu Streams besprochen:

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();
}

Jetzt ist es O(n): Jedes Zeichen wird eine konstante Anzahl von Malen verarbeitet.

Schritt 4. Selbst testen. Spiel im Kopf ein paar Beispiele durch: "swiss" liefert "w", "aabb" liefert ein leeres Optional, ein leerer String ebenfalls ein leeres Optional. Fragt der Interviewer, warum LinkedHashMap und nicht HashMap, hast du die Antwort schon parat: Eine normale HashMap merkt sich die Einfügereihenfolge nicht, das „erste“ Zeichen könnte also irgendeins sein.

Und jetzt ein Bonus, der deinen Interviewer angenehm überraschen wird: Du kommst auch mit einer normalen HashMap aus, wenn dein zweiter Durchlauf über den String selbst geht statt über die Map. Dann bestimmt der String die Reihenfolge, und die Map speichert nur die Zählerstände. Zwei funktionierende Varianten und eine begründete Wahl zwischen ihnen – genau das wollen Interviewer beim Live Coding sehen.

Das ist das ganze Geheimnis von Live Coding. Keine geniale Lösung im ersten Anlauf, sondern ein klarer Weg: Anforderungen klären, einfach lösen, Komplexität abschätzen, verbessern, testen.

Darfst du also KI nutzen? Das hängt vom Unternehmen ab, manchmal sogar von der Interviewrunde. Wenn es erlaubt ist, achtet der Interviewer meist nicht darauf, was die KI generiert hat, sondern darauf, wie du sie einsetzt: worum du sie bittest, wie du das Ergebnis prüfst, ob du Fehler bemerkst. Bei Canva zum Beispiel sagt man es ganz offen: Entscheidend ist nicht, was die KI für dich geschrieben hat, sondern die Fähigkeit, den generierten Code zu lesen, zu verstehen und zu verbessern – und jede technische Entscheidung zu erklären. Wenn du nicht erklären kannst, was der Code tut, hat die KI dir nicht geholfen, sondern dich ins offene Messer laufen lassen. Das ist, als würdest du mit einem Spickzettel in eine Prüfung gehen, der in einer Sprache geschrieben ist, die du nicht sprichst.

Ehrlich gesagt ist das das stärkste Argument für solide Grundlagen, das ich kenne. Eine KI schreibt dir in einer Sekunde eine HashMap mit veränderlichem Schlüssel. Dass das keine gute Idee ist, merkst nur du.

Spickzettel: Was Java Interview Fragen wirklich prüfen

Jede Interviewfrage hat eine versteckte Ebene. Das steckt hinter den häufigsten:

So bereitest du dich in drei Wochen auf ein Java-Vorstellungsgespräch vor

Woche 1 – Grundlagen. Core Java, OOP, Exceptions, Collections und die Stream API. Lies nicht nur Antworten – schreib Code. Steck einen veränderlichen Schlüssel in eine HashMap und schau, was passiert. Mach equals() und hashCode() kaputt und finde heraus, wo es knallt.

Woche 2 – Multithreading und modernes Java. Schreib ein Programm mit Deadlock und finde ihn per Thread-Dump. Bau ein paar Klassen in Records um. Starte zehntausend Virtual Threads und schau dir an, wie das funktioniert.

Woche 3 – Spring, Datenbanken und Praxis. Bau eine kleine Spring-Boot-App mit Datenbank, spür in deinem eigenen Code ein N+1-Problem auf und behebe es. Und mach unbedingt ein paar Probe-Interviews – mit Freunden, im Mentoring oder zur Not laut vor dem Spiegel.

Und die wichtigste Regel: Lern keine Antworten auswendig. Jede Frage aus diesem Artikel lässt sich in fünf Minuten mit Code überprüfen. Was du mit eigenen Händen überprüft hast, bleibt für immer; was du auswendig gelernt hast, hält bis zum ersten „Aber warum?“.

Und dann wird es im Raum wieder still. Nur diesmal, weil der Interviewer nichts mehr hinzuzufügen hat.

Wo du üben kannst

Im Java-Kurs von CodeGym wird fast jedes Thema aus diesem Artikel – von Collections und Exceptions bis Multithreading – mit Aufgaben trainiert, die sofort automatisch geprüft werden. Ein Fehler in equals() und hashCode() fällt direkt auf, nicht erst im Vorstellungsgespräch.

Und falls du dir den Weg bis zum ersten Jobangebot lieber mit Mentoring, Code Reviews und Portfolio-Projekten wünschst: Unser betreutes Programm Java University läuft auf Englisch und hat ein Career Center, das bei Lebenslauf und Interviewvorbereitung hilft.

Noch mehr Fragen mit ausführlichen Antworten? Schau in unsere CodeGym-Serie Fragen und Antworten aus Vorstellungsgesprächen für Java-Entwickler und in die 150 am häufigsten gestellten Fragen in Java-Vorstellungsgesprächen. Das reicht für viele Abende.

FAQ

Welche Java Interview Fragen werden 2026 gestellt? Das Fundament bleibt gleich: Core Java, OOP, Exceptions, Collections, die Stream API, Multithreading, die JVM, Spring und Datenbanken. 2026 kommen Fragen zu modernem Java dazu – Records, Sealed Classes, Pattern Matching, Virtual Threads und die Änderungen in Java 25 – plus Spring Boot 4.

Was wird im Java-Vorstellungsgespräch für Junior Developer gefragt? Vor allem Grundlagen: der Unterschied zwischen == und equals(), wie equals() und hashCode() zusammenhängen, warum String immutable ist, wie HashMap funktioniert, ArrayList vs. LinkedList, checked vs. unchecked Exceptions, try-with-resources sowie map() vs. flatMap() in der Stream API. Die Antwort zu kennen reicht nicht – du musst erklären, warum es so funktioniert.

Welche Java Interview Fragen bekommen Mid-Level-Developer? Multithreading (volatile, happens-before, Deadlock, ExecutorService), wie JVM und Garbage Collector funktionieren, Spring (DI, @Transactional und seine Fallen), Hibernate (das N+1-Problem, Lazy Loading) und die Isolationsstufen von Transaktionen. Dazu viele Fragen zu echter Praxiserfahrung.

Darf man im Java-Vorstellungsgespräch KI nutzen? Das hängt vom Unternehmen ab und sogar von der Interviewrunde. Manche Firmen erlauben oder verlangen KI in technischen Interviews, viele verbieten sie weiterhin. Kläre das vorher mit dem Recruiting. Ist KI erlaubt, wird geprüft, ob du den generierten Code erklären und überprüfen kannst.

Welche Java-Version ist für Vorstellungsgespräche gerade wichtig? Die aktuelle LTS-Version ist Java 25, erschienen im September 2025. Viele Unternehmen setzen allerdings noch auf Java 17 und 21, deshalb lohnt es sich zu wissen, was jede dieser Versionen eingeführt hat.

Welche Aufgaben kommen im Java Coding Interview dran? Meist kleine Algorithmus-Aufgaben zu Strings, Arrays und Collections: das erste nicht wiederholte Zeichen finden, Duplikate in einem Array finden, auf ein Palindrom prüfen, Daten mit einer HashMap gruppieren. Der Interviewer schaut nicht nur aufs Ergebnis, sondern auch darauf, wie du Anforderungen klärst, die Komplexität abschätzt und Edge Cases prüfst.

Wie bereite ich mich schnell auf ein Java-Vorstellungsgespräch vor? Drei Wochen reichen, um deine Grundlagen gründlich aufzufrischen: Woche eins – Core Java und Collections, Woche zwei – Multithreading und modernes Java, Woche drei – Spring, Datenbanken und Probe-Interviews. Entscheidend ist, jede Antwort mit Code zu überprüfen, statt sie auswendig zu lernen.