21 October 20258 Min. Lesezeit
Der übliche Rat an eine nicht-technische Gründerin lautet, jemanden Technischen für das Interview zu finden, und der ist richtig und nutzlos, denn hätten Sie diese Person, würden Sie das hier nicht lesen. Die brauchbarere Fassung ist enger: Es gibt Teile dieser Beurteilung, die Sie besser können als die meisten Entwickler, Teile, die Sie gar nicht können, und einen billigen Weg, die zweiten für etwa eine Stunde einzukaufen.
Vorweg gesagt: Sie versuchen nicht festzustellen, ob jemand abstrakt eine starke Entwicklerin ist. Sie versuchen festzustellen, ob sie genau die Arbeit erledigen kann, die Sie haben, und ob sie Ihnen dabei die Wahrheit darüber sagt. Das sind weitgehend nicht-technische Fragen.
Was Sie selbst beurteilen können
Vier Dinge, und sie sagen mehr über das Ergebnis voraus, als die meisten erwarten.
- Ob sie Ihnen ihre eigene Arbeit erklären können. Nicht vereinfacht bis zur Bedeutungslosigkeit, sondern erklärt: was das Problem war, wofür sie sich entschieden haben, was es gekostet hat.
- Was sie Sie fragen. Gute Entwickler hinterfragen die Anforderung, bevor sie sie schätzen. Wer ein Briefing aus zwei Sätzen annimmt und eine Zahl nennt, hat Ihnen etwas gesagt.
- Wie sie mit Nichtwissen umgehen. Fragen Sie nach etwas außerhalb ihres Bereichs und beobachten Sie, ob sie das schlicht sagen oder anfangen, Nebel zu erzeugen.
- Was sie bereuen. Jeder mit echter Erfahrung hat eine Entscheidung, die schlecht ausging. Wer keine solche Geschichte hat, hat entweder wenig geliefert oder führt Sie.
Nichts davon erfordert, Code zu lesen, und alles davon lässt sich über vierzig Minuten schwer vortäuschen.
Der Erklärungstest, richtig durchgeführt
Nehmen Sie einen Punkt aus dem Lebenslauf und lassen Sie ihn sich erklären, als wären Sie neu auf der Geschäftsseite. Stellen Sie dann eine Rückfrage, die sich nicht einüben lässt: Was würden Sie heute anders machen, und welcher Teil hat aus Gründen, die niemand erwartet hätte, am längsten gedauert?
Sie hören auf Struktur. Eine starke Antwort geht von Problem zu Randbedingung zu Entscheidung zu Folge und enthält mindestens eine Sache, die schiefging. Eine schwache Antwort ist eine Liste von Technologien. Wenn Sie die Geschichte danach nicht in drei Sätzen zusammenfassen können, ist das ein echter Befund und kein Versagen Ihres eigenen Verständnisses.
Das Gespräch über die Schätzung
Beschreiben Sie ein Arbeitspaket, das Sie tatsächlich brauchen. Fragen Sie, wie sie es angehen würden und was es doppelt so lange dauern lassen würde. Die zweite Hälfte ist die eigentliche Frage.
Erfahrene Menschen benennen konkrete Risiken: Die Daten sind vermutlich unordentlicher als beschrieben, die fremde API unterstützt womöglich nicht, was das Feature voraussetzt, der bestehende Code in diesem Bereich hat vielleicht keine Tests. Unerfahrene oder unachtsame Menschen geben Ihnen eine Dauer und eine Beruhigung. Sie müssen die fachliche Richtigkeit der Risiken nicht beurteilen können, um zu bemerken, ob überhaupt welche benannt wurden.
Was Sie nicht beurteilen können und nicht länger vorgeben sollten
Sie können nicht beurteilen, ob der Code gut ist, ob die architektonischen Instinkte solide sind oder ob der beschriebene Ansatz der naheliegende oder ein schrulliger ist. Persönlicher Charme, flüssiges Englisch und Selbstbewusstsein ersetzen das nicht, und genau diese Eigenschaften führen Sie in die Irre, wenn Sie es versuchen.
Das ist eine echte Lücke, und sie muss von jemand anderem gefüllt werden. Die gute Nachricht: Es kostet eine Stunde, einmal, pro Person auf der Shortlist.
Wen Sie sich ausleihen und wie Sie diese Person briefen
Ungefähr danach geordnet, wie sehr Sie dem Ergebnis trauen sollten: eine Entwicklerin, die Sie privat kennen und die kein Interesse am Ausgang hat; eine Interims- oder Teilzeit-Entwicklungsleitung, für ein paar Stunden bezahlt; eine Entwicklerin in einem befreundeten Unternehmen, der Sie denselben Gefallen im Gegenzug anbieten; eine Auftragnehmerin, die eigens für technische Interviews engagiert wird.
Briefen Sie sie schriftlich und kurz. Sagen Sie ihnen, welche Arbeit die Person tatsächlich machen wird, wie Ihr bestehendes System aussieht und welche eine Frage Sie am dringendsten beantwortet haben wollen. Bitten Sie dann um eine Rückmeldung in einer festen Form: Würden Sie diese Person für diese Arbeit einstellen, worin ist sie schwach, und worauf würden Sie im ersten Monat achten? Ohne diese Form bekommen Sie eine Note von eins bis zehn, und die ist nicht brauchbar.
Der erfahrene Entwickler des Anbieters kann sich dazuschalten und ist oft wirklich hilfreich, gerade bei Details zum jeweiligen Stack. Behalten Sie nur das Naheliegende im Kopf: Er ist nicht neutral, und seine Einschätzung sollte als ein Beitrag gelten, nicht als das Urteil.
Eine Arbeitsprobe lesen, ohne Code zu lesen
Wenn Sie ein Repository oder eine Aufgabe erhalten, gibt es Dinge, die Sie sehen können. Gibt es eine README, die erklärt, wie man es startet und warum es so gebaut ist? Gibt es überhaupt Tests? Ist die Commit-Historie eine Folge nachvollziehbarer Schritte oder ein einziger Commit namens final? Haben sie aufgeschrieben, was sie mit mehr Zeit gemacht hätten?
Nichts davon beweist, dass der Code gut ist. Alles davon zeigt, ob die Person schriftlich über ihre Arbeit kommuniziert, ungefragt, wenn niemand hinsieht. Über eine Remote-Zusammenarbeit hinweg zählt diese Gewohnheit ungefähr so viel wie der Code.
Der Fehlermodus, vor dem Sie sich hüten sollten
Nicht-technische Beurteiler belohnen Redegewandtheit systematisch zu stark. Wer gut spricht, bereitwillig zustimmt und nie ein entmutigendes Wort sagt, macht sich im Interview wunderbar und ist oft die schwächere Einstellung, denn genau die Eigenschaften, die Ihnen im Interview gefielen, werden später Probleme vor Ihnen verbergen.
Eine schroffe Gegenprobe: Behaupten Sie im Gespräch mindestens einmal etwas leicht Falsches über Ihr eigenes Produkt oder Ihren Plan und sehen Sie, ob Widerspruch kommt. Wer der Person, die ihn gleich einstellen will, höflich widerspricht, zeigt Ihnen das wertvollste Verhalten, das Sie aus der Ferne einkaufen können.
Behandeln Sie dann den ersten Monat als das eigentliche Interview
Kein Interviewprozess ersetzt vollständig die gemeinsame Arbeit, und Ihrer ist dünner als die meisten, planen Sie den Nachlauf also bewusst ein. Vereinbaren Sie für die ersten zwei Wochen ein kleines, echtes, abschließbares Arbeitspaket mit klarer Definition of Done und eine schriftliche Zwischenbetrachtung am Ende des ersten Monats darüber, was ausgeliefert wurde und was im Weg stand.
Gestalten Sie das als faire, bezahlte Probe mit symmetrischen Ausstiegsbedingungen statt als unbezahltes Vorsprechen, und beide Seiten bekommen früh eine ehrliche Antwort. Stellen Sie über einen Anbieter ein, gilt dasselbe mit einer Ergänzung: Vereinbaren Sie vorab, wie ein Ersatz aussieht, damit eine Fehlbesetzung ein Terminproblem ist und keine Verhandlung.