Prüfen Sie Laravel-Tiefe, nicht nur PHP
Viele „PHP-Entwickler“ kennen ein bisschen Laravel; weniger kennen es gründlich. Der Unterschied zeigt sich im Detail. Fragen Sie, wie sie N+1-Query-Probleme mit Eloquent vermeiden würden (die Antwort lautet Eager Loading), wann sie Arbeit in eine Queue auslagern würden, statt sie direkt auszuführen, und wie sie Tests mit Pest oder PHPUnit strukturieren. Ein starker Kandidat spricht ungefragt und flüssig über Migrations, Form Requests, Service-Klassen und Middleware. Bei Agenturen signalisiert der Status als Official Laravel Partner geprüfte Tiefe, die ein allgemeiner Dienstleister nicht vorweisen kann.
Konkrete Signale, auf die Sie achten sollten
Über das Gespräch hinaus trennen einige Dinge solide Einstellungen von riskanten. Ausgelieferte, live laufende Laravel-Apps, die Sie tatsächlich öffnen können – nicht nur private Repos, von denen man Ihnen erzählt. Eine GitHub-Historie mit echten Commits, idealerweise mit ein oder zwei selbst gepflegten Paketen. Tests und Versionskontrolle als Standard, nicht als Nachgedanke. Und klare, verständliche Antworten, wenn Sie fragen, warum eine technische Entscheidung so getroffen wurde – wer eine Entscheidung nicht einfach erklären kann, hat vermutlich nicht gründlich darüber nachgedacht. Vage Antworten wie „Ich bin Full-Stack, ich mache alles“ sind ein gelbes Warnsignal.
Häufige Fehler bei der Einstellung
Drei Fehler kosten am meisten. Nur nach dem Stundensatz einstellen – der billigste Entwickler, der drei Neuschreibungen braucht, ist der teure. Die Prüfung von Referenzen und Portfolio auslassen, weil jemand im Gespräch gut war. Und den kompletten Build übergeben, bevor die Zusammenarbeit getestet ist, und dann festsitzen, wenn sich die Kommunikation als das eigentliche Problem herausstellt. Die Lösung für alle drei ist dieselbe: klein anfangen und für einen Nachweis bezahlen, bevor Sie sich festlegen.
Freelancer, Agentur oder intern?
Jedes Modell passt zu einer anderen Phase. Ein Freelancer eignet sich für eine kleine, klar umrissene Funktion oder eine kurze Korrektur, und den Managementaufwand tragen Sie selbst. Eine Agentur bietet Ihnen ein Team, einen Prozess und Kontinuität für einen kompletten Build, meist mit Staff Augmentation (Sie mieten Entwickler pro Monat) oder Projekten mit festem Umfang – fester Umfang schützt Ihr Budget, Staff Augmentation gibt Ihnen Flexibilität, wenn sich Anforderungen ändern. Ein internes Team passt, wenn die App zum Kern des Geschäfts gehört und laufende Weiterentwicklung braucht, die ein externer Dienstleister nicht dauerhaft leisten kann. Wählen Sie das Modell nach der Phase, nicht nur nach den Kosten am ersten Tag.
Prüfen Sie mit einer echten Aufgabe
Codebeispiele und Lebensläufe sagen nur begrenzt etwas aus. Eine kleine, bezahlte Probeaufgabe – eine echte Funktion oder ein gezieltes Code-Review – verrät in wenigen Tagen mehr über Qualität und Kommunikation als jedes Gespräch. Achten Sie darauf, wie Fragen gestellt, Unklarheiten gehandhabt und Commit-Messages geschrieben werden, nicht nur darauf, ob der Code läuft. Und halten Sie das Eigentum am Code und die Übertragung der IP-Rechte schriftlich fest, bevor der Haupt-Build beginnt, nicht danach. Behandeln Sie die Probeaufgabe also als das Gespräch, das wirklich zählt.