Junior-Entwickler: Was im ersten Job wirklich zählt

Wer programmieren lernt, löst meist Übungsaufgaben: eine Funktion, ein Algorithmus, ein klar abgegrenztes Problem. Die erste Aufgabe im Job sieht anders aus. Sie bekommen ein Ticket, arbeiten in einer bestehenden Codebasis, müssen Tests bestehen und Ihr Code wird von Kollegen geprüft. Diese Fähigkeiten lassen sich üben, wenn man weiß, worauf es ankommt.

Wie eine typische Aufgabe abläuft

1. Ein Ticket beschreibt, was gebraucht wird, meist mit Akzeptanzkriterien.
2. Sie klären offene Fragen, bevor Sie anfangen.
3. Sie planen kurz, wie Sie es umsetzen, bei größeren Aufgaben schriftlich.
4. Sie arbeiten in einem eigenen Branch und schreiben Tests.
5. Sie öffnen einen Pull Request, jemand anderes prüft den Code.
6. Nach dem Review wird der Code zusammengeführt und ausgeliefert.

Tickets lesen und Akzeptanzkriterien ernst nehmen

Akzeptanzkriterien sagen, wann eine Aufgabe fertig ist, zum Beispiel: „Codes enthalten nur Buchstaben und Ziffern“, „Dieselbe URL ergibt denselben Code“, „Alles außer http(s) wird abgelehnt“. Lesen Sie sie wie eine Testliste. Was nicht drinsteht, ist eine Frage an die Person, die das Ticket geschrieben hat, keine Einladung zum Raten.

Erst planen: die Design-Notiz

Vor größeren Änderungen schreiben viele Teams eine kurze Design-Notiz. Sie hilft, Fehler zu finden, bevor sie im Code stecken, und macht das Review leichter. Eine halbe Seite reicht: das Problem, Ihr Ansatz, verworfene Alternativen, Risiken und wie Sie testen.

Ticket HOP-101: Short links for campaign URLs

Problem:   Marketing needs short links for printed flyers.
Approach:  Base62 code from a counter; store code → URL in a table
           with a unique index on the URL, so the same URL gets the same code.
Rejected:  Random codes: need collision checks, no benefit here.
Risks:     Invalid input → accept only http(s) URLs.
Tests:     same URL twice → same code; ftp:// → rejected;
           code uses only letters and digits.

Tests als Arbeitsgrundlage

Im Job laufen Tests bei jeder Änderung. Gewöhnen Sie sich an, zuerst die vorhandenen Tests auszuführen, dann für jedes Akzeptanzkriterium einen Test zu schreiben und erst danach die Lösung zu bauen. Ein roter Test, der grün wird, ist der klarste Beweis, dass ein Ticket erledigt ist.

Code-Reviews geben und annehmen

Im Review prüft jemand Ihren Code, bevor er zusammengeführt wird. Kommentare sind kein Urteil über Sie, sondern Teil der Arbeit. Prüfen Sie Ihren eigenen Code vorher mit denselben Fragen, die ein erfahrener Kollege stellen würde:

• Versteht jemand ohne Kontext, was der Code tut? Sind Namen eindeutig?
• Sind Randfälle abgedeckt: leere Eingaben, Fehler, sehr große Werte?
• Werden Fehler sinnvoll behandelt statt verschluckt?
• Gibt es Tests für die Akzeptanzkriterien?
• Enthält der Pull Request nur, was zum Ticket gehört?
• Ist er klein genug, um ihn in einer Sitzung zu prüfen?

Werkzeuge, die vorausgesetzt werden

• Git: Branches, saubere Commits, Konflikte lösen, Pull Requests
• Das Build-System Ihrer Sprache, etwa CMake für C++ oder npm für JavaScript
• Ein Debugger statt nur Ausgaben in der Konsole
• Das Terminal für Builds, Tests und Logs

So üben Sie das gezielt

• Bauen Sie Projekte von Anfang bis Ende und schreiben Sie sich selbst Tickets mit Akzeptanzkriterien.
• Schreiben Sie vor jedem Feature eine kurze Design-Notiz und vergleichen Sie sie hinterher mit dem Ergebnis.
• Prüfen Sie Ihren eigenen Code am nächsten Tag mit der Review-Checkliste.
• Tragen Sie zu Open-Source-Projekten bei, die Einsteiger-Issues markieren: Dort lernen Sie echte Reviews kennen.

Algorithmus-Aufgaben oder Projekte?

Algorithmus-Aufgaben trainieren Problemlösen und kommen in manchen Bewerbungsgesprächen vor. Projekte zeigen dagegen, dass Sie so arbeiten können wie im Team: mit Tickets, Tests und Reviews. Für den ersten Job lohnt sich beides, aber der Arbeitsalltag besteht fast nur aus dem Zweiten.