Entwickler einstellen, um KI-generierten Code zu reparieren: Interviewfragen

Was bei KI-generiertem Code in echten Projekten schiefgeht

KI-generierte Apps sehen in Demos oft gut aus, weil der Happy Path funktioniert. Die Probleme beginnen, wenn echte Nutzer echte Dinge tun: sich zweimal anmelden, ein Passwort zurücksetzen, merkwürdige Eingaben einfügen, die App über ein langsames Netzwerk öffnen oder ein anderes Gerät verwenden. Viele AI-erstellte Prototypen sind schnell zusammengefügt, sodass der erste Edge Case einen wichtigen Ablauf brechen kann.

Häufige Fehler sind leicht zu erkennen, wenn man weiß, wo man suchen muss. Authentifizierung ist ein großes Thema: Login funktioniert lokal, bricht aber nach Deployment, oder Rollen und Sessions verhalten sich inkonsistent. Ein klassisches Problem sind exponierte Secrets, etwa API-Keys im Client-Code oder im Repository. Auch die Logik ist oft fragil: eine Checkout-Summe wird an zwei Stellen berechnet, ein Webhook läuft doppelt, oder Fehler werden geschluckt, sodass statt eines klaren Fehlers stille Datenkorruption entsteht.

Symptome, die normalerweise bedeuten, dass der Code echte Reparatur (nicht nur kleine Anpassungen) braucht:

• Auth und Berechtigungen wirken zufällig (Nutzer sehen Dinge, die sie nicht sehen sollten)
• Secrets sind hardcodiert oder über Umgebungen hinweg geteilt
• Änderungen in einem Bereich brechen unzusammenhängende Features
• Datenverarbeitung ist inkonsistent (Duplikate, fehlende Updates, partielle Writes)
• Die App funktioniert lokal, aber scheitert nach dem Deployment

Wen Sie eigentlich einstellen wollen, ist nicht „jemanden, der Features hinzufügt“. Sie brauchen jemanden, der schnell diagno stiziert, erklärt, was passiert, und sichere Fixes anwendet, ohne neue Probleme zu schaffen. Das bedeutet: unbekannten Code lesen, Requests End-to-End nachverfolgen, ein paar gezielte Tests oder Checks schreiben und die Struktur verbessern, damit die nächste Änderung leichter ist.

Geschwindigkeit ist wichtig, aber Geschwindigkeit ohne Korrektheit verwandelt Prototypen in endlose Nacharbeiten. Setzen Sie früh Erwartungen: bitten Sie zuerst um eine Erstdiagnose, dann um einen Reparaturplan mit Prioritäten. Ein guter Entwickler trennt "Blutstillung"-Fixes (Sicherheitslücken, kaputte Auth, Datenverlust) von "schöner machen"-Arbeiten (Refactorings, Cleanup). Wenn Sie schnelle Ergebnisse wollen, seien Sie klar, wo rauhe Kanten akzeptabel sind und wo nicht (Security, Zahlungen, Nutzerdaten).

Vor dem Interview: definieren Sie tatsächlich, was Sie brauchen

Wenn Sie jemanden einstellen wollen, um KI-generierten Code zu reparieren, starten Sie nicht mit einer generischen Stellenausschreibung. Schreiben Sie zuerst auf, was "fertig" für Ihr Projekt bedeutet. Ohne das werden Interviews zu Meinungsstreitigkeiten statt zu klaren Ja/Nein-Entscheidungen.

Definieren Sie "fertig" als Ergebnis, nicht als Gefühl. Bei einem unordentlichen Repo bedeutet "fertig" meist, dass die Kernabläufe funktionieren, grundlegende Sicherheitschecks vorhanden sind und Sie ohne Überraschungen deployen können.

Ein einfacher Zielkatalog listet, was am Ende wahr sein muss. Bleiben Sie praktisch: wichtige Nutzerreisen funktionieren End-to-End, die risikoreichsten Pfade haben zumindest ein kleines Test-Sicherheitsnetz, Secrets sind nicht exponiert, Deployment-Schritte sind reproduzierbar (kein "läuft nur auf meinem Rechner") und der Code ist lesbar genug, dass ein anderer Entwickler weitermachen kann.

Bestätigen Sie als Nächstes, ob die Aufgabe wirklich "reparieren" ist und nicht "neu bauen". KI-erstellte Apps können vollständig aussehen, aber tiefe Probleme verbergen (verflochtene Struktur, fragile Zustände, kaputte Auth). Entscheiden Sie, was Sie akzeptieren: ein Patch, der den aktuellen Code stabilisiert, oder ein partieller Rewrite der riskantesten Teile.

Entscheiden Sie auch, welche Art Entwickler Sie brauchen: jemanden, der sich mit fremdem Code wohlfühlt. Screenen Sie das vor dem Interview, indem Sie sie beschreiben lassen, wie sie ihre ersten 48 Stunden in einem chaotischen Repo angehen würden. Suchen Sie nach einem Plan, der mit Diagnose beginnt (projekt starten, Bugs reproduzieren, Logs lesen) und dann Sicherheit schafft (Tests, Backups, kleine Änderungen), nicht mit großen Refactors am ersten Tag.

Setzen Sie zuletzt Erwartungen an die Kommunikation von Risiko. Sie wollen jemanden, der sagen kann: "Ich bin mir noch nicht sicher. Das werde ich als Nächstes prüfen, und das könnte die Schätzung ändern."

Interviewfragen, die ihren Debugging-Ansatz offenbaren

Sie stellen nicht auf Cleverness ab. Sie suchen nach einer wiederholbaren Methode, die wahre Ursache zu finden, auch wenn der Code chaotisch ist.

Fragen Sie nach ihren ersten fünf Schritten nach einem kritischen Bug-Report. Achten Sie auf einen ruhigen, geordneten Plan (Fakten sammeln, reproduzieren, Umfang eingrenzen) und nicht auf "Ich würde anfangen, Dinge zu ändern." Starke Kandidaten nennen das Bestätigen der Auswirkung, exakte Fehlermeldungen erfassen und zuletzt vorgenommene Änderungen prüfen.

Einstiege, die zeigen, wie sie arbeiten:

• „Ein Nutzer sagt, der Checkout schlägt fehl. Was sind deine ersten 5 Schritte, in der Reihenfolge?“
• „Wie reproduzierst du einen Bug, wenn der Report vage ist? Welche Details fragst du nach?“
• „Wie isolierst du den kleinsten fehlschlagenden Fall, und warum ist das wichtig?“
• „Worauf greifst du zuerst zu: Logs, Breakpoints, Tests, Tracing? Wann wechselst du?“

Nachdem sie antworten, lassen Sie sie ein echtes Beispiel durchgehen. Zum Beispiel: die App funktioniert lokal, aber in Produktion werden Nutzer zufällig ausgeloggt. Ein guter Debugger spricht darüber, Umgebungen zu vergleichen, Cookies und Sessions zu prüfen, nach Timeouts zu suchen und gezieltes Logging mit einer klaren Hypothese hinzuzufügen.

Die aufschlussreichste Frage ist, was sie tun, wenn sie den Bug nicht reproduzieren können. Suchen Sie nach Antworten wie: Observability verbessern (bessere Logs, Traces), einen minimalen Test erstellen, das Risiko mit einem Guard oder Feature-Flag reduzieren und eine kurze Hypothesenliste aufbauen. Wenn sie sagen „Ich würde einfach weiter probieren“, ist das ein Warnsignal bei fragilen, KI-erstellten Codebasen, in denen ein "kleiner Fix" drei andere Abläufe brechen kann.

Wenn Sie einen schnellen Reality-Check wollen, bitten Sie sie, ihren Ansatz in einfacher Sprache zu erklären, als würden sie am Ende des Tages einem nicht-technischen Gründer ein Update geben. Klare Updates passen meist zu diszipliniertem Debugging.

Fragen, die zeigen, wie sie mit Unsicherheit und Fehlern umgehen

KI-generierter Code ist oft selbstbewusst falsch. Sie brauchen jemanden, der eingestehen kann, dass eine Vermutung falsch war, schnell umschaltet und das System sicherer hinterlässt, als er es vorgefunden hat.

Dieser Teil des Interviews ist nicht auf perfekte Antworten ausgelegt. Es geht darum, wie sie reagieren, wenn die Realität nicht zur ersten Theorie passt.

Bitten Sie um eine echte Fehlersgeschichte (und machen Sie sie konkret)

Fordern Sie Details, keine polierten Erfolgsgeschichten:

• „Erzähl von einem Bug, den du zuerst falsch diagnostiziert hast. Was dachtest du zuerst, und was war es tatsächlich?“
• „Welches Signal hat dich umdenken lassen?“
• „Was hast du zuerst getan, um das Risiko zu verringern, als du noch unsicher warst?“
• „Wie hast du die Lösung bestätigt und sichergestellt, dass sie nicht in der Nähe etwas kaputt macht?“

Wenn sie vage bleiben, haken Sie nach: „Was war das kleinste Experiment, das du durchgeführt hast, um deine Theorie zu beweisen oder zu widerlegen?“

Ein realistisches Beispiel: Der Login einer App schlägt „zufällig“ fehl. Eine schwache Antwort schiebt es auf „Auth ist flaky“ und probiert neue Bibliotheken. Eine starke Antwort erklärt, wie sie es reproduzierten, Token-Ablauf oder Uhrzeit-Drift entdeckten und das mit ein oder zwei gezielten Checks bewiesen.

Wie gute Antworten klingen

Achten Sie auf Gewohnheiten, auf die Sie sich verlassen können. Gute Kandidaten beschreiben eine Timeline (Hypothese, Test, Ergebnis, nächster Schritt), nennen das Beweisstück, das sie umdenken ließ, und sprechen über Containment (Rollback-Pläne, temporäre Guards). Sie verhindern Wiederholungen mit einem kleinen Test, einer kurzen Root-Cause-Notiz oder einem Monitoring-Alert.

Wenn sie einen Fehler nicht ohne Schuldzuweisung erklären können oder behaupten, sie würden „nie falsch liegen“, ist das ein Warnzeichen. Debugging in chaotischem Code bedeutet Unsicherheit, und die Besten bleiben ruhig und methodisch.

Sicherheitsgewohnheiten: Fragen, die reale Praktiken offenlegen

Security ist oft der Punkt, an dem „es läuft auf meinem Rechner“ zu echtem Risiko wird. Sie wollen wiederholbare Gewohnheiten, keine Versprechungen.

Beginnen Sie mit Auth und Sessions. AI-erstellte Apps mischen oft Muster (Cookies, JWTs, localStorage) und lassen Lücken.

Fragen, die schnell echte Praxis zeigen:

• „Wenn du ein neues Codebase öffnest, was prüfst du zuerst bei Auth und Session-Handling?“ Hören Sie nach konkreten Punkten: Cookie-Flags (HttpOnly, Secure, SameSite), Session-Expiry, Refresh-Flows und wo Tokens gespeichert werden.
• „Zeig mir, wie du exponierte Secrets und unsichere Konfiguration findest.“ Gute Antworten beinhalten Scans nach .env-Dateien und Schlüsseln im Repo sowie einen Plan zur Rotation und zur Verhinderung eines Re-Commits.
• „Wie verhinderst du SQL-Injection hier?“ Sie sollten parametrisierte Queries, sichere ORM-Muster und Input-Validierung nennen. Wenn sie nur „ich säubere Eingaben“ sagen, fragen Sie nach dem Wie.
• „Wie pflegst du Abhängigkeitsupdates in einem chaotischen Projekt?“ Starke Antworten erwähnen Lockfiles, Audit-Tools und einen Testplan nach Updates.

Eine nützliche Nachfrage: „Erklär das Abwägen zwischen Geschwindigkeit und Sicherheit bei diesem Fix.“ Beispiel: Wenn ein Prototyp JWTs in localStorage speichert, sollte ein solider Entwickler erklären, warum HttpOnly-Cookies das XSS-Risiko verringern und was das für das Frontend ändert.

Warnsignale sind selbstbewusste, aber vage Antworten: keine konkreten Checks für Sessions und Token-Speicherung; Input-Validierung als gesamte SQL-Injection-Lösung; Abhängigkeitsschwierigkeiten abtun, weil „es nur ein Prototyp ist“; oder Geheimnis-Rotation nach einem Leak vermeiden.

Wie sie Trade-offs in einfacher Sprache erklären

Sie stellen nicht nur Coding-Fähigkeit ein. Sie stellen Urteilskraft ein. Die besten Kandidaten können erklären, was sie tun, warum sie es tun und was man dafür gewinnt (und verliert).

Ein einfacher Test: Lassen Sie sie dieselbe Entscheidung zweimal erklären, einmal an einen Entwickler und einmal an einen vielbeschäftigten Gründer, der nur Risiko und Kosten wissen will. Wenn sie nicht zwischen den Zielgruppen wechseln können, wird die Zusammenarbeit schwer.

Schneller Patch vs. gründlicher Refactor

Geben Sie ihnen einen echten Bugtyp (kaputte Auth, zufällige Crashes, fehlgeschlagene Zahlungen) und bitten Sie um den Vergleich: schneller Patch vs. tiefere Lösung. Achten Sie darauf, ob sie Risiken beschreiben und Sicherheitsmaßnahmen wie Tests, Logging oder Rollback-Pläne einschließen.

Nützliche Fragen:

• „Wenn wir heute einen schnellen Patch ausliefern, was kann nächste Woche brechen?“
• „Was würde dich stoppen und sagen lassen: das braucht einen Refactor, keinen Patch?“
• „Wie würdest du beweisen, dass der Fix funktioniert, ohne auf Hoffnung zu setzen?"

Rewrite vs. Repair und wie sie Entscheidungen dokumentieren

KI-erstellter Code funktioniert oft, bis er echten Traffic sieht. Fragen Sie, wie sie entscheiden, ob ein Modul neu geschrieben oder repariert werden sollte. Gute Kandidaten nutzen Signale wie unklare Grenzen, verfilzte Abhängigkeiten, wiederholtes Copy-Paste oder Sicherheitsrisiken, die sich schwer einkapseln lassen.

Bitten Sie um ein konkretes Beispiel: „Wenn das Nutzerprofil-Modul Spaghetti ist, was würdest du in den ersten 48 Stunden tun?“ Ein guter Plan isoliert das Modul, fügt ein paar Tests hinzu, refactort in kleinen Schritten und beobachtet die Performance, damit keine langsamen Seiten oder Skalierungsprobleme entstehen.

Fragen Sie zuletzt, wie sie Entscheidungen so aufschreiben, dass Nicht-Techniker sie verstehen. Achten Sie auf kurze Entscheidungsnotizen: was geändert wurde, was noch nicht, Risiken und nächste Schritte.

Ein realistisches Szenario für das Interview

Nutzen Sie eine kleine, konkrete Story und lassen Sie sie laut denken.

Szenario: Nach einem Update eines AI-Tools können sich Nutzer nicht mehr einloggen. Die App zeigt „Ungültige Sitzung“, obwohl das Passwort korrekt ist. Gestern funktionierte es noch. Jetzt häufen sich Support-Tickets.

Hören Sie zuerst auf die Fragen, die sie stellen, bevor sie den Code anfassen. Starke Kandidaten wollen Grundlagen wissen: Was hat sich geändert (Deploy, env vars, Dependency-Bump), betrifft es alle Nutzer oder nur eine Untermenge, gibt es Logs oder Traces, welche Auth-Methode verwenden Sie (Cookies, JWT, OAuth) und wurden Secrets oder Keys rotiert? Bonus, wenn sie nach Risiko fragen: „Sind die Nutzer nur ausgesperrt, oder werden Sessions fälschlicherweise akzeptiert?“

Dann lassen Sie sie ihren Ansatz zeitlich begrenzen. Der Plan sollte wie eine Checkliste klingen, nicht wie Raten:

• Erste Stunde: Bug reproduzieren, eine fehlgeschlagene Request/Response erfassen, jüngste Diffs scannen, Config prüfen (Cookie-Domain, CORS, Callback-URL, Session-Store).
• Erster Tag: Den kompletten Login-Fluss nachverfolgen, temporäres Logging rund um Session-Erstellung und -Validierung hinzufügen, einen kleinen Test schreiben, der das Versagen reproduziert.
• Sobald stabil: die fragilen Teile refactoren, versteckte Kopplungen entfernen, Monitoring hinzufügen und dokumentieren, was passiert ist, damit es nicht wieder vorkommt.

Fragen Sie dann, wie sie den Fix bestätigen. Gute Antworten umfassen einen reproduzierbaren Repro-Step, Tests für Erfolgs- und Fehlerfälle und einen Rollback-Plan. Sie sollten auch Maßnahmen nennen, um Wiederholungen zu verhindern (Versionen pinnen, sichere Config-Checks, grundlegende Code-Review-Regeln).

Zum Schluss drücken Sie auf Trade-offs: Was würden sie jetzt ausliefern vs. aufschieben? Sie wollen jemanden, der die Nutzer heute schützt, ohne Sie in zukünftige Schulden zu stürzen.

Übliche Fallen beim Interview für chaotische Code-Reparatur

Die größten Fehler passieren, wenn das Gespräch abstrakt bleibt. Sie wollen Details: worauf sie zuerst schauen, was sie messen und was sie tun, wenn sie falschliegen.

Eine Falle ist, Fragen zu stellen, die Selbstsicherheit belohnen, nicht Klarheit. Wenn Sie fragen: „Kannst du das aufräumen?“, bekommen Sie von fast jedem ein „Ja“. Drücken Sie stattdessen auf Spezifika: Welche Signale sagen, dass der Bug in Daten, Auth oder State liegt, und welche Belege würden sie sammeln, bevor sie Code anfassen?

Ein weiterer Fehler ist, sich zu sehr auf Frameworks zu konzentrieren. Ein Kandidat, der nur davon spricht, in den neuesten Stack umzuschreiben, könnte die echte Arbeit vermeiden: fremden Code lesen, Requests nachverfolgen und Risiken reduzieren.

Warnsignale:

• Ihr Debugging-Plan besteht im Wesentlichen aus „console logs hinzufügen“ (keine Erwähnung von Repro, Eingrenzen der Inputs, Logs und Traces).
• Tests werden als „später“ abgetan und es gibt kein Sicherheitsnetz vor Refactors.
• Sie geben feste Zeitpläne ohne Einsicht in Repo, Configs und Deployment-Setup.
• Sie weigern sich, Entscheidungen in einfacher Sprache zu erklären oder reagieren genervt auf „Warum“-Fragen.

Zeitpläne sind eine besondere Falle. Starke Entwickler geben Bereiche und einen Plan, keine Versprechungen. „Tag 1: reproduzieren und Request-Flow mappen. Tag 2: Top-Root-Causes fixen und Tests hinzufügen. Dann neu bewerten“ ist glaubwürdiger als eine garantierte Fertigstellung ohne Code-Review.

Kurze Checkliste: Anzeichen, dass Sie die richtige Person gefunden haben

Nach einer kurzen Durchsicht kann ein starker Kandidat sagen, worauf er schaut und warum es fehlschlägt. Sie brauchen keine perfekte Sicherheit, aber sie sollten die Codebase in einfachen Worten zusammenfassen können: was die App macht, wo die Hauptflüsse sind (Login, Zahlungen, Uploads, Admin) und was auffällt (fehlende env vars, verwirrtes Datenmodell, duplizierte Logik).

Sie werden auch nicht sofort zu Rewrites springen. Das beste Muster ist: „Erst ein kurzer Audit, dann eine priorisierte Fix-Liste.“ Diese Liste sollte nach Impact und Risiko sortiert sein, nicht danach, was technisch spannend ist.

Achten Sie auf Produktionsgewohnheiten, nicht vage Versprechen. Erwarten Sie Erwähnungen von Tests für kaputte Pfade, einer Staging-Umgebung, einem Rollback-Plan und einfachem Monitoring (Logs, Alerts). Hören Sie darauf, wie sie beweisen, dass ein Fix funktioniert, nicht nur, wie sie ihn implementieren.

Security ist ein schneller Indikator. Ein guter Kandidat findet Risiken ohne Hinweise: exponierte Secrets, schwache Auth-Checks, unsicher zusammengesetzte SQL-Queries, fehlende Input-Validierung oder zu offene CORS-Einstellungen.

Fragen Sie auch, wie sie die Arbeit Woche für Woche abwickeln. Sie wollen klare Check-ins und nachvollziehbare Deliverables, z. B. eine kurze Liste der Top-Issues mit Schweregrad, was geliefert wurde, was als Nächstes kommt und was blockiert.

Nächste Schritte: Führen Sie einen kleinen Testauftrag aus und vereinbaren Sie einen klaren Reparaturplan

Springen Sie nicht sofort in einen großen Rewrite. Bei chaotischem, KI-generiertem Code lernt man mehr aus einem kleinen bezahlten Trial als aus einer weiteren Gesprächsrunde. Ziel ist zu sehen, wie sie denken, wie sie kommunizieren und ob sie den Code sicherer hinterlassen.

Halten Sie den Trial klein, aber real: ein nutzersichtbarer Bug, ein Sicherheitsfix und ein einfacher Test, der die Änderung sichert. Beispiel: „Login funktioniert manchmal nicht“, „entferne ein exponiertes Secret aus dem Repo und rotiere es“ und „füge einen Basistest für den Login-Fluss hinzu“. Enger Umfang erlaubt Bewertung in ein bis zwei Tagen.

Vereinbaren Sie vor Beginn, was „fertig" bedeutet und was Sie zurückbekommen. Sie sollten eine kurze Erklärung dessen sehen, was geändert wurde und warum, Hinweise zu Config- oder Umgebungsänderungen und einen einfachen Deploy-Plan mit Verifikation und Rollback-Anweisungen.

Wenn Sie nicht viel Zeit für Kandidatenbewertung haben, kann ein Audit-first-Ansatz dennoch helfen. FixMyMess (fixmymess.ai) konzentriert sich auf Diagnose und Reparatur von KI-generierten Apps aus Tools wie Lovable, Bolt, v0, Cursor und Replit und beginnt mit einer kostenlosen Code-Audit, damit Sie vor einer größeren Entscheidung konkrete Probleme und Prioritäten sehen.