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. Senior: Architektur, Trade-offs, Mentoring und Entscheidungsfindung.
Mit einem Worker Pool: eine feste Anzahl Goroutinen liest von einem Channel, sodass die Parallelität eine Zahl ist, die du gewählt hast, nicht eine, die der Input bestimmt hat. Für feinere Kontrolle funktioniert auch ein Semaphore-Channel. Zu vermeiden ist, pro Element eine Goroutine zu erzeugen — das wirkt elegant und reißt alles nieder, was stromabwärts liegt, meist ein Connection Pool zur Datenbank.
Eine Referenz, die erreichbar bleibt: eine wachsende Map, die als Cache ohne Eviction dient, eine Goroutine, die für immer geparkt ist und ihren Stack hält, ein Slice eines riesigen Arrays, das den gesamten Backing Store am Leben hält. Letzteres überrascht: Ein großer Buffer, auf drei Byte reduziert, hält ihn komplett fest, bis du kopierst.
pprof über den laufenden Prozess statt Rätselraten: CPU-Profil dafür, wo die Zeit hingeht, Heap-Profil für Allokationen, und das Goroutine-Profil, wenn es nach Blockierung riecht. Allokationen sind in Go der häufige Übeltäter — weniger Garbage zu erzeugen schlägt oft die Optimierung des Algorithmus, weil die Arbeit des Collectors proportional zu dem ist, was du erzeugst.
SIGTERM abfangen, keine neuen Verbindungen mehr annehmen, den Root-Context abbrechen, damit Worker herunterfahren, mit Timeout auf eine WaitGroup warten und dann beenden. Das Timeout ist entscheidend: Ein Shutdown, der ewig auf einen hängenden Request wartet, ist selbst ein Ausfall. Der Readiness-Check muss fehlschlagen, bevor irgendetwas davon beginnt, damit der Load Balancer zuerst aufhört, Traffic zu schicken.
Sie rechtfertigen sich, wenn dieselbe Logik tatsächlich über mehrere Typen hinweg wiederholt wird — ein Container, ein map oder filter über Slices, eine Constraint auf numerische Typen. Sie sind das falsche Werkzeug, wenn ein Interface die Anforderung schon ausdrückt, weil ein Interface einfacher zu lesen und zu ändern ist. Go kam ein Jahrzehnt lang nicht zufällig ohne sie aus, und der Großteil des Codes braucht sie bis heute nicht.
Nach dem, was der Code tut, nicht danach, was er ist: ein Package pro fachlichem Bereich, nicht ein Package namens models, in dem alles landet. Die Abhängigkeitsrichtung nach innen halten, alles, was nicht zum Importieren gedacht ist, unter internal/ ablegen, und einem utils-Package widerstehen — dort stirbt Kohäsion. Die Standardbibliothek ist der Style Guide, den es sich zu kopieren lohnt.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Senior Go-Backend-Interview üben →