Go-Interviews drehen sich um Goroutines, Channels, Interfaces und Fehlerbehandlung — die Sprache ist klein, deshalb gehen die Fragen eher in die Tiefe als in die Breite. Hier sind die häufigsten mit Musterantworten. Middle: tieferes Verständnis, Optimierung und reale Arbeitssituationen.
Ein ungepufferter Channel synchronisiert: Das Senden blockiert, bis ein Empfänger den Wert abnimmt, beide Seiten treffen sich also. Ein gepufferter Channel nimmt bis zu seiner Kapazität ohne Empfänger auf und blockiert nur, wenn er voll ist. Ungepuffert ist der sicherere Standard, weil er die Übergabe explizit macht; ein Puffer ist eine Entscheidung darüber, wie viel Arbeit sich anstauen darf.
Wenn sie für immer auf einem Channel blockiert, den niemand lesen oder beschreiben wird, oder auf einen Context wartet, der nie abgebrochen wird. Man bemerkt es an einer Goroutine-Zahl, die steigt und nie wieder fällt — runtime.NumGoroutine() oder das pprof-Goroutine-Profil, das genau zeigt, wo sie geparkt sind. Die übliche Ursache ist ein Producer, der zu früh zurückkehrt und einen Consumer wartend zurücklässt.
Um ein Deadline, ein Cancellation-Signal und Werte im Request-Scope über API-Grenzen zu transportieren. Seine eigentliche Aufgabe ist Cancellation: Wird ein Request aufgegeben, soll alles, was er gestartet hat, stoppen, statt für niemanden weiterzuarbeiten. Nützlich bleibt er durch die Regel, dass Context der erste Parameter ist und nie in einem Struct gespeichert wird.
Ohne default blockiert select, bis einer seiner Cases bereit ist. Mit default nimmt es diesen sofort, wenn nichts anderes bereit ist, wodurch die Operation nicht blockierend wird. Ein default innerhalb einer Schleife ohne sonstige Blockierung ist ein Busy-Wait, das einen Core auslastet — genau der Fehler, auf den man achten sollte.
Er findet gleichzeitige Zugriffe auf denselben Speicher, bei denen mindestens einer schreibt, und zwar auf den Codepfaden, die während des Laufs tatsächlich ausgeführt wurden. Was er nicht findet, ist die Race, die du nicht durchlaufen hast — er ist ein Runtime-Tool, kein Beweis. Deshalb gehört er in CI gegen echte Tests statt einmalig von Hand ausgeführt.
Ein Mutex schützt gemeinsamen Zustand, ein Channel überträgt die Eigentümerschaft an Daten. Lesen und schreiben mehrere Goroutinen eine Struktur, ist ein Mutex einfacher und schneller. Wandert die Arbeit von einer Goroutine zur nächsten, drückt ein Channel das direkt aus. Zum Channel zu greifen, um einen Zähler zu schützen, ist eine häufige Überkomplizierung.
Dass Wait zurückkehrt, sobald der Zähler null erreicht, du also weißt, dass jede verfolgte Goroutine fertig ist. Die zwei klassischen Missbräuche sind, Add innerhalb der Goroutine aufzurufen, was mit Wait racet, und die WaitGroup per Wert zu übergeben, wodurch sie kopiert wird und der ursprüngliche Zähler unberührt bleibt. Beides kompiliert, und beides schlägt sporadisch fehl.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Middle Go-Backend-Interview üben →