Was Sie im ersten Gespräch mit einem Freelance-Entwickler für Ihr Legacy-System fragen sollten

Die meisten Unternehmen, die einen Freelance-Entwickler für ein Legacy-System einstellen, führen dasselbe erste Gespräch: ein kurzer Rundgang durch den Stack, eine Frage zur Verfügbarkeit, vielleicht ein Check der Rate. Dann entscheiden sie danach, wie selbstbewusst die Person geklungen hat. Dieser Ansatz funktioniert gut bei einem Greenfield-Projekt, bei dem sich jeder kompetente Entwickler einarbeiten kann. Er funktioniert schlecht bei Legacy-Arbeit, wo die Lücke zwischen jemandem, der tatsächlich alte Systeme am Leben gehalten hat, und jemandem, der nur neuen Code schreibt, Sie Monate kosten kann.

Die Fragen, die Sie einem Freelance-Entwickler zu Legacy-Arbeit stellen, unterscheiden sich von den Fragen, die bei einer normalen Einstellung funktionieren, weil der Job selbst ein anderer ist. Eine Legacy-Codebasis hat bereits Nutzer, Daten und Fehlermodi, die in jahrelange Entscheidungen eingebacken sind, an die sich niemand mehr vollständig erinnert. Der Entwickler, den Sie wollen, ist jemand, der echte Zeit in diesem Chaos verbracht hat und eine Meinung dazu hat, wie man es überlebt – nicht nur Theorien darüber, wie Software gebaut werden sollte.

Im Folgenden finden Sie zwölf Fragen, die sich für dieses erste Gespräch lohnen, geordnet danach, was sie eigentlich testen. Keine davon erfordert, dass Sie Code verstehen. Was sie erfordern, ist, auf die Form der Antwort zu hören, nicht nur auf ihr Selbstbewusstsein.

Fragen zur Codebasis selbst

1. Was ist das älteste System, an dem Sie gearbeitet haben, und was war daran falsch?

Ein Entwickler mit echter Legacy-Erfahrung antwortet konkret: eine PHP-5-Anwendung, die niemand dokumentiert hatte, eine Rails-App drei Major-Versionen zurück, eine Datenbank ohne Foreign Keys mit drei verschiedenen Datumsformaten in derselben Spalte. Ein Generalist antwortet allgemein und nennt alles „technische Schulden", ohne zu benennen, worin die Schulden eigentlich bestanden. Konkretheit ist hier das gesamte Signal.

2. Wie fangen Sie normalerweise an, bevor Sie überhaupt Code berühren?

Eine gute Antwort beinhaltet, das System zu lesen, bevor man es ändert: prüfen, welche Tests existieren, die Deployment-Historie ansehen, herausfinden, welche Teile der Anwendung tatsächlich Traffic bekommen und welche totes Gewicht sind. Eine schwache Antwort springt direkt zu Meinungen über den Stack, oder beginnt über einen Rewrite zu sprechen, bevor sie überhaupt Ihr Repository gesehen hat.

3. Wie gehen Sie vor, um einen Teil des Systems zu verstehen, den Ihnen niemand erklären kann?

Jedes Legacy-System hat Code, der die Personen überlebt hat, die ihn geschrieben haben. Die ehrliche Antwort beschreibt das Nachverfolgen: Git-Historie, Commit-Nachrichten, alte Tickets, manchmal einfach das Ausführen in einer isolierten Kopie und beobachten, was kaputtgeht. Wer behauptet, es jedes Mal schnell herauszufinden, ist entweder unerfahren oder nicht ehrlich zu Ihnen.

Fragen zu Risiko und Sicherheit

4. Was ist der schlimmste Produktionsvorfall, den Sie verursacht haben, und was haben Sie danach geändert?

Das ist eine der nützlicheren Fragen an einen Freelance-Entwickler, gerade weil sie unangenehm ist. Wer echte Produktionsarbeit gemacht hat, hat irgendwann einmal etwas in Produktion kaputt gemacht. Die Antwort, auf die es ankommt, ist nicht der Fehler selbst, sondern was sich dadurch an ihrem Prozess geändert hat – eine neue Routine bei Backups, ein anderer Umgang mit Feature Flags, ein strengerer Review-Schritt vor Deployments.

5. Wie entscheiden Sie, was sicher zu ändern ist, ohne eine vollständige Testsuite?

Legacy-Systeme kommen selten mit der Testabdeckung, die man sich wünschen würde. Ein Entwickler, der diese Arbeit tatsächlich gemacht hat, spricht darüber, Characterization Tests um den Teil zu schreiben, den er gleich berührt, in kleinen, umkehrbaren Schritten zu deployen, und einen Rollback-Plan bereitzuhalten, bevor er etwas Tragendes ändert. Wer sagt, Testen spiele für ein Projekt wie Ihres keine große Rolle, sollte ein klares Warnsignal sein.

6. Was würde Sie veranlassen, zu einer Änderungsanfrage Nein zu sagen?

Gute Legacy-Entwickler widersprechen manchmal. Sie könnten sich weigern, eine ungeprüfte Änderung direkt in der Produktion vorzunehmen, oder darauf hinweisen, dass eine gewünschte Lösung ein tieferes Problem überdecken würde, das in drei Monaten wieder auftaucht. Wenn jemand sagt, er werde alles tun, was Sie verlangen, ohne Einschränkung, klingt das in einem Verkaufsgespräch angenehm und wird zum Problem, sobald ihn die erste schlechte Idee erreicht.

Fragen zu Kommunikation und Reporting

7. Wie halten Sie mich auf dem Laufenden, wenn ich den Code selbst nicht lesen kann?

Die meisten fachfremden Entscheider, die einen Freelance-Entwickler beauftragen, werden keine Diffs überprüfen. Die richtige Antwort beschreibt einen Reporting-Rhythmus, dem Sie tatsächlich folgen können: kurze schriftliche Updates, eine laufende Liste, was sich geändert hat und warum, eine Zusammenfassung in einfacher Sprache, bevor etwas Riskantes live geht. Hier erfahren Sie auch, ob der Entwickler technische Arbeit in Begriffe übersetzen kann, die Ihnen erlauben, den Zustand des Systems Ihrem eigenen Management zu erklären, statt Sie raten zu lassen.

8. Was passiert, wenn Sie auf etwas Unerwartetes stoßen?

Legacy-Arbeit ist voller Überraschungen – eine Abhängigkeit, die sich als unwartet herausstellt, eine Geschäftsregel, die drei Ebenen tief vergraben ist und die niemand dokumentiert hat. Die entscheidende Antwort betrifft die Geschwindigkeit der Offenlegung. Sie wollen jemanden, der eine Überraschung am Tag ihres Auftretens meldet, mit Optionen, statt jemanden, der die zusätzliche Zeit still aufnimmt und es Ihnen erst am Ende erzählt.

9. Können Sie mir erklären, wie Sie dokumentieren, was Sie geändert haben?

Ein Entwickler, der keine Spur hinterlässt, bereitet der nächsten Person – möglicherweise Ihnen selbst – genau die Verwirrung vor, die dieses Projekt überhaupt erst teuer gemacht hat. Fragen Sie, was er tatsächlich hinterlässt: aktualisierte Kommentare, ein Changelog, eine kurze Notiz im Repository, die erklärt, warum eine knifflige Entscheidung so getroffen wurde, wie sie getroffen wurde.

Fragen zu Umfang, kommerziellen Bedingungen und Passung

10. Wie schätzen Sie Arbeit an einem System, das Sie noch nicht vollständig gesehen haben?

Niemand kann Ihnen ein ehrliches Festpreisangebot für Legacy-Arbeit geben, bevor er den Code gesehen hat. Eine glaubwürdige Antwort beschreibt eine kurze, bezahlte Discovery-Phase, nach der die Schätzung belastbarer wird, statt einer selbstbewussten Zahl, die im ersten Gespräch aus der Luft gegriffen wird. Wenn Sie ein Rahmenwerk dafür wollen, was die Recherche- und Discovery-Phase vor der vollen Beauftragung abdecken sollte, behandelt unser Leitfaden zur Beauftragung eines Freelance-Symfony-Entwicklers für Legacy-Arbeit das ausführlicher für einen verbreiteten Stack, und dieselbe Logik gilt unabhängig von der Sprache.

11. Wie sieht eine typische Woche aus, wenn Sie neben meinem aktuellen Team oder allein arbeiten?

Diese Frage zeigt Ihnen, ob der Entwickler tatsächlich schon einmal innerhalb des Prozesses eines anderen gearbeitet hat – an Standups teilgenommen, Ihr Ticketsystem genutzt, eine bestehende Code-Review-Kultur respektiert hat –, oder ob er erwartet, dass Sie sich an ihn anpassen. Keine der beiden Antworten ist automatisch falsch, aber Sie wollen wissen, welche davon Sie bekommen, bevor der Vertrag beginnt.

12. Was würde dies für Sie zu einer schlechten Passung machen?

Das ist die Frage, die in den meisten Einstellungsgesprächen übersprungen wird, und oft die aufschlussreichste. Ein erfahrener Freelance-Entwickler hat schon einmal Projekte abgelehnt, meist weil der Zeitplan unrealistisch war, der Umfang sich ständig änderte, ohne dass über Budget gesprochen wurde, oder der Kunde einen Rewrite wollte, den die Daten nicht rechtfertigten. Wer bereit ist, seine eigenen Grenzen im ersten Gespräch zu benennen, ist später eher ehrlich zu Ihnen, wenn Ehrlichkeit schwerer zu hören ist.

Die Antworten nutzen, nicht nur die Fragen

Keine dieser zwölf Fragen hat eine einzige richtige Antwort, die Sie gegen ein Skript abhaken können. Worauf Sie bei allen zusammen achten, ist eine durchgängige Textur: konkrete Beispiele statt allgemeiner Behauptungen, die Fähigkeit, vergangene Fehler ohne Unbehagen einzugestehen, und ein Kommunikationsstil, der davon ausgeht, dass Sie den Code nicht lesen können, und das einplant, statt es zu ignorieren.

Wenn sich mehrere Antworten in Folge vage, generisch oder seltsam einstudiert anfühlen, sollten Sie das genauso schwer gewichten wie ein technisches Warnsignal. Entwickler, die tatsächlich Legacy-Systeme am Laufen gehalten haben, haben eher Geschichten als Slogans, und das erste Gespräch reicht meist aus, um den Unterschied zu erkennen.

Wenn Sie lieber jemand anderen dieses Gespräch und das anschließende technische Screening führen lassen möchten, hilft Wolf-Tech fachfremden Teams, Freelance-Entwickler und Agenturen für Legacy- und individuelle Softwareentwicklung zu bewerten, einschließlich der Scoping-Phase und des Code-Qualitäts-Reviews, das vor jeder Vertragsunterschrift stattfinden sollte. Melden Sie sich unter hello@wolf-tech.io, wenn Sie vor Ihrer Entscheidung eine zweite Meinung möchten.