Junior-Entwickler einstellen – Eigeninitiative im KI-Zeitalter

Wie erkennen Sie Eigeninitiative bei Junior-Entwicklern? Prüfen Sie die Problemwahl, hilfreiche Fragen und Belege – und geben Sie allen eine faire Gelegenheit.

Ernest Bursa

Ernest Bursa

Founder · · 11 Min. Lesezeit
A silver-haired Latina woman talks with three colleagues in a Los Angeles startup courtyard, wearing a cream shirt with an indigo startupkit logo.

Wenn Sie bei der Einstellung von Junior-Entwicklerinnen und -Entwicklern auf Eigeninitiative achten, prüfen Sie, wie jemand ein Problem auswählt, eine Annahme hinterfragt und anhand von Belegen über das weitere Vorgehen entscheidet. Geben Sie Kandidatinnen und Kandidaten vergleichbare Gelegenheiten, das zu zeigen. Ein funktionierender Prototyp kann dabei helfen. Eine gut begründete Entscheidung, nichts zu entwickeln, ebenso.

Letzteres wird umso wichtiger, je leichter eine überzeugende Demo entsteht. Was jemand entwickelt hat, kann Sie beeindrucken, ohne dass Sie wissen, ob sich das Problem überhaupt zu bearbeiten lohnte. Die entscheidende Frage stellt sich vor der ersten Zeile Code: Was ist der Person aufgefallen, und warum ist sie der Sache nachgegangen?

Was ändert „Tatendrang schlägt Dienstalter“ an der Einstellung von Junior-Entwicklern?

Felix Riesebergs Essay vom 27. Oktober liefert einen ermutigenden Ausgangspunkt. Er beschreibt, wie er seine eigenen Coding-Interviews verändert hat und wie Neueinsteiger mit KI nützliche Dinge entwickeln. Seine Ratschläge richten sich auch an erfahrene Entwickler, die neu in einer Organisation sind und dort noch keinen Einfluss haben. Ein gezielter Prototyp kann Menschen ohne gefestigte Position im Unternehmen helfen, auf eine Chance aufmerksam zu machen. Rieseberg räumt zugleich ein, dass er noch keinen fertigen Ersatz für sein bisheriges Interview hat.

Als Personalverantwortliche können Sie daraus Fragen ableiten, deren Antworten sich nachvollziehen lassen. Eigeninitiative beginnt bei der Entscheidung, wo sich Aufwand lohnt. Ein Entwickler kann eine vertraute Anforderung hinterfragen, wiederkehrenden Kundenbeschwerden nachgehen oder feststellen, dass hinter einem vermeintlich technischen Hindernis eine ungeklärte interne Vorgabe steckt.

Für keinen dieser Beiträge muss man im Meeting am lautesten auftreten. Eine Kandidatin oder ein Kandidat, der ruhig nach dem Grund für eine Anforderung fragt, zeigt möglicherweise schon das gewünschte Verhalten. Sie müssen hilfreiche Fragen von einer überzeugenden Inszenierung von Selbstvertrauen unterscheiden können.

Der Gedanke ist älter als die heutigen KI-Werkzeuge. In seinem Karriere-Essay von 2011 verbindet Patrick McKenzie technische Arbeit mit wirtschaftlichem Nutzen. Für die Personalauswahl heißt das: Fragen Sie, was sich für Kunden oder Kollegen verbessert. Verlangen Sie nicht von unerfahrenen Bewerbern, von außerhalb Ihres Unternehmens eine Umsatzstrategie zu entwerfen.

Geben Sie ihnen genug Kontext, um einen sinnvollen Beitrag zu erkennen. Sie prüfen, wie sie mit den Informationen umgehen, die ihnen zugänglich sind.

Warum beantwortet eine schnellere Demo noch nicht die entscheidende Frage?

Die Forschung zur Produktivität mit KI zeigt, wie wichtig die jeweiligen Bedingungen sind, bevor Sie Rückschlüsse auf einzelne Personen ziehen. Sie belegt weder eine allgemeine Überlegenheit von Junior-Entwicklern noch das Gegenteil.

An den Unternehmensexperimenten von Cui und Kollegen nahmen 4.867 Entwickler teil. Zusammengenommen ergab sich mit einem KI-Programmierassistenten ein Anstieg der erledigten Aufgaben um etwa 26 %. Der vollständige Entwurf ordnet Unterschiede nach Erfahrung und Betriebszugehörigkeit vorsichtig ein: Die Muster in den Teilgruppen waren Hinweise, meist aber nicht statistisch signifikant. Untersucht wurden frühere Programmierassistenten und die Zahl erledigter Aufgaben, nicht das Urteilsvermögen bei geschäftlichen Entscheidungen mit heutigen Agenten.

Die Beobachtungsstudie von Daniotti und Kollegen auf GitHub fand dagegen Vorteile vor allem bei erfahreneren Entwicklern. Erfahrung bezeichnete hier die Zahl der aktiven Jahre auf GitHub, nicht eine überprüfte berufliche Erfahrungsstufe. Die KI-Nutzung wurde aus Daten abgeleitet; Beiträge dienten als Maß für die Arbeitsleistung. Damit untersucht die Studie etwas anderes als die randomisierten Unternehmensexperimente.

Für Ihr Interview folgt daraus etwas Konkretes: Halten Sie fest, welche Werkzeuge Kandidatinnen und Kandidaten genutzt haben, was sie zuvor verstanden hatten und wie sie das Ergebnis überprüft haben. Leiten Sie ihr Potenzial nicht aus pauschalen Bezeichnungen wie Junior, KI-Native oder erfahren ab.

Unterscheiden Sie außerdem zwischen einer Demonstration und der Entscheidung, das Ergebnis dauerhaft zu betreiben. Ein Prototyp kann zeigen, dass eine Interaktion möglich ist. Offen bleibt, ob Kunden sie wollen, ob sie zum bestehenden Produkt passt und wer sie betreut. Im Folgegespräch nach einer bestandenen Programmieraufgabe können Sie Implementierungsentscheidungen prüfen. Davor steht die Frage, ob es sinnvoll war, diese Lösung überhaupt zu versuchen.

Unterscheiden Sie Eigeninitiative von der Gelegenheit, sie zu zeigen

Ein Portfolio zeigt, was Kandidatinnen und Kandidaten Ihnen vorlegen können. Es zeigt weder alle Gelegenheiten, die sie hatten, noch alle nützlichen Beiträge, die sie veröffentlichen durften.

Jemand bringt vielleicht ein großes privates Projekt mit, ein vertrauliches Beispiel aus dem Beruf, einen Beitrag zu einer ehrenamtlichen Gruppe oder kaum fertige Arbeiten. Fragen Sie nach den Entscheidungen im jeweiligen Beispiel, bevor Sie dessen Umfang belohnen. Eine kleine Änderung unter realen Einschränkungen kann ein ergiebigeres Gespräch ermöglichen als eine aufwendige Anwendung mit unklarem Zweck.

Bieten Sie anschließend einen anderen Weg an. Wer frühere Arbeiten nicht teilen kann, sollte ein klar begrenztes Problem untersuchen dürfen, das Sie bereitstellen. Sorgen Sie für denselben grundlegenden Kontext, dieselben erlaubten Werkzeuge, denselben erwarteten Aufwand und dieselbe Definition einer hilfreichen Antwort. Falls der Zugang zu einem KI-Werkzeug wichtig ist, schaffen Sie vergleichbare Bedingungen. Ein privat bezahltes Abonnement sollte keine unausgesprochene Voraussetzung sein.

Der Leitfaden für strukturierte Interviews des US Office of Personnel Management empfiehlt gemeinsame Fragen und einheitliche Maßstäbe für berufsbezogene Kompetenzen. Das ist auch hier ein sinnvoller Grundsatz. Er belegt jedoch weder die Eignung dieser konkreten Aufgabe noch die Vorhersagekraft eines subjektiven Eindrucks.

Sagen Sie ausdrücklich, welches Wissen Sie bei einem Junior bereits voraussetzen. Die Hinweise des OPM zu Arbeitsproben unterscheiden zwischen Fähigkeiten, die beim Einstieg vorhanden sein müssen, und solchen, die nach der Einstellung vermittelt werden. Wenn Sie Kenntnisse Ihres Produktbereichs ohnehin vermitteln wollen, lassen Sie die Aufgabe zeigen, wie jemand sich diese Kenntnisse erarbeitet. Verwechseln Sie fehlendes internes Wissen nicht mit fehlender Eigeninitiative.

Klare Bedingungen helfen auch den Kandidaten zu entscheiden, ob sie teilnehmen möchten. Nennen Sie den maximalen Aufwand, die erlaubte KI-Nutzung, das Abgabeformat und den Weg für Rückfragen. Die Grundlagen beschreibt unser Leitfaden zum Prüfen von Aufgabenbeschreibungen für die Bearbeitung zu Hause.

Geben Sie Kandidaten ein Problem, dessen Untersuchung sich lohnt

Wählen Sie eine Aufgabe, bei der mehrere nächste Schritte sinnvoll sein können. Wenn nur die von Ihnen bevorzugte Funktion als Ergebnis zählt, prüfen Sie die Übereinstimmung mit einer Antwort, die Sie vorher nicht genannt haben.

Stellen Sie sich ein Startup vor, bei dem neue Kunden das Produkt häufig verlassen, bevor sie ein Teammitglied einladen. Das Team vermutet, dass der Einladungsablauf überarbeitet werden muss. Sie suchen einen Junior-Entwickler für die Produktentwicklung und stellen deshalb fiktive Unterlagen zusammen: eine einfache Übersicht des Nutzungsablaufs, beispielhafte Supportnotizen, einige Beispielsitzungen und die aktuelle Einladungsansicht.

Bitten Sie Kandidatinnen und Kandidaten, einen nächsten Schritt vorzuschlagen, mit dem Sie die Einstiegshürde besser verstehen oder verringern könnten. Erklären Sie das Produktziel, die Grenzen der Unterlagen und welche Fragen im Gespräch erlaubt sind. Eine kurze schriftliche Erklärung, eine Skizze oder ein kleiner Prototyp sind zulässig. Die Qualität der Untersuchung zählt mehr als der Umfang des Ergebnisses.

Ein Kandidat entwickelt sofort einen flüssigeren Einladungsdialog. Das kann gute Arbeit sein. Fragen Sie, aufgrund welcher Hinweise gerade dieser Dialog der beste Ansatzpunkt war. Kann die Person zwischen Schwierigkeiten beim Versenden einer Einladung und Nutzern unterscheiden, die noch keinen Anlass haben, jemanden einzuladen?

Ein anderer Kandidat bemerkt, dass mehrere der Beispielnutzer das Produkt zunächst allein prüfen, bevor sie eine Freigabe einholen. Er fragt, ob sie überhaupt ein Teammitglied einladen müssen, um den Nutzen zu erleben. Im Gespräch erfährt er: Das alleinige Ausprobieren ist erlaubt, doch die Texte beim Einstieg lassen Einladungen verpflichtend erscheinen.

Damit stehen mehrere sinnvolle Wege offen. Der Kandidat könnte einen Prototyp entwickeln, der den Einstieg beim alleinigen Ausprobieren verständlicher macht. Er könnte vorschlagen, überarbeitete Anweisungen zu testen, bevor die Oberfläche verändert wird. Oder er könnte empfehlen, zuerst herauszufinden, warum Menschen das Produkt verlassen, statt schon Entwicklungszeit einzusetzen.

Angenommen, er entscheidet sich für die letzte Möglichkeit. In seiner Erklärung benennt er die unsichere Annahme: Wer ohne Einladung geht, ist nicht zwangsläufig am Einladungsablauf gescheitert. Er schlägt eine kurze Nachfrage bei Personen vor, die einer Teilnahme zustimmen, und erklärt, welche Antworten eine Produktänderung rechtfertigen würden. Außerdem benennt er eine Grenze der Unterlagen: Die Beispielsitzungen zeigen nicht, ob jemand später zurückkehrt.

Diese Antwort enthält womöglich keinen Code. Sie kann trotzdem Eigeninitiative erkennen lassen: eine relevante Frage, eine plausible andere Erklärung und einen Test, dessen Ergebnis die Entscheidung verändern könnte. Prüfen Sie, ob der vorgeschlagene Test tatsächlich zwischen den Erklärungen unterscheiden würde. Der bloße Wunsch nach weiterer Recherche sollte ebenfalls nicht automatisch als gute Antwort gelten.

Machen Sie die Grenzen der Aufgabe deutlich. Dies ist ein hypothetischer Vorschlag, um Verhalten zu beobachten, kein validiertes Auswahlverfahren. Verwenden Sie fiktives oder entsprechend aufbereitetes Material und setzen Sie Bewerber nicht als unbezahltes Team zur Erkundung neuer Produktideen ein. Wird daraus ein umfangreicher kommerzieller Auftrag, vereinbaren und vergüten Sie diesen gesondert.

Fragen Sie nach der Überlegung, die das weitere Vorgehen verändert hat

Eine hilfreiche Bewertung macht nachvollziehbar, wie Kandidatinnen und Kandidaten aus den verfügbaren Informationen zu ihrem Vorschlag gekommen sind. Andere Prüfer sollten verstehen können, weshalb Sie die Arbeit vielversprechend oder bedenklich fanden.

Halten Sie im Beispiel fest, dass der Kandidat die Aussagekraft der Einladungskennzahl hinterfragt und sie mit dem Ziel der testenden Person verknüpft hat. Dokumentieren Sie, welche Informationen Sie im Gespräch ergänzt haben. Beschreiben Sie dann, wie der Kandidat diese genutzt hat. Denn auf einen Hinweis klug zu reagieren, ist ein anderer Nachweis, als das Problem selbst zu erkennen.

Einige gemeinsame Fragen halten das Gespräch bei der Sache:

  • Warum lohnte es sich, dieses Problem vor den anderen Auffälligkeiten zu untersuchen?
  • Welche Einschränkung haben Sie überprüft, und wie hat die Antwort Ihr Vorgehen beeinflusst?
  • Bei welchem Ergebnis würden Sie den vorgeschlagenen nächsten Schritt verwerfen?
  • Was ist noch unklar, und wer müsste beteiligt werden, bevor es weitergeht?

Achten Sie darauf, ob eine Antwort einer begründeten Rückfrage standhält. Schlägt der Kandidat neue Einstiegstexte vor, fragen Sie, was geschieht, wenn die Nutzer trotzdem gehen. Empfiehlt er eine Untersuchung, fragen Sie, weshalb sich der Aufwand für diese Informationen lohnt. Die Fähigkeit, eine Position zu überdenken, sagt mehr aus als eine sofortige Verteidigung gegen jeden Einwand.

Machen Sie nicht aus jeder Beobachtung ein Urteil über die Persönlichkeit. „Hat gefragt, ob das alleinige Ausprobieren vorgesehen ist“ ist konkret. „Hat Gründermentalität“ hilft dem nächsten Prüfer kaum weiter. Dahinter kann sich auch Uneinigkeit darüber verbergen, für welche Arbeit Sie die Person eigentlich einstellen.

Sie können einen Ansatz bevorzugen und dennoch durchdachte Arbeit bei einem anderen anerkennen. Einigen Sie sich auf die berufsbezogenen Verhaltensweisen, bevor Sie besprechen, wer Sie am meisten beeindruckt hat. Halten Sie Beobachtungen, deren Grenzen und Ihre Empfehlung so auseinander, dass Kollegen Ihre Überlegungen hinterfragen können.

Was können Bewerber ohne umfangreiches Portfolio zeigen?

Wählen Sie ein Beispiel, bei dem Sie eine Entscheidung erklären können. Das Projekt muss weder groß noch öffentlich noch kommerziell erfolgreich sein. Sie müssen lediglich darüber sprechen dürfen.

Beschreiben Sie etwa einen wiederkehrenden manuellen Arbeitsschritt, den Sie untersucht haben, eine unklare Anleitung, die Sie mit Nutzern getestet haben, oder eine Funktion, deren Entwicklung Sie nach neuen Erkenntnissen eingestellt haben. Erklären Sie Ihre ursprüngliche Annahme, Ihre Prüfung und das weitere Geschehen. Können Sie ein Ergebnis nicht belegen, beschreiben Sie Ihre Beobachtungen, statt einen wirtschaftlichen Erfolg zu erfinden.

Falls KI geholfen hat, erklären Sie die Arbeitsteilung konkret. Vielleicht hat sie Alternativen erzeugt, eine erste Implementierung geschrieben oder bei der Fehleranalyse geholfen. Zeigen Sie, wo Sie zwischen Vorschlägen ausgewählt, eine Aussage geprüft oder eine Antwort verworfen haben. Mit einer Werkzeugliste kann Ihr Gesprächspartner weniger anfangen als mit einer Entscheidung, die Sie begründen können.

Erklären Sie auch, was Sie mit besserem Zugang tun würden. Nennen Sie die Kundenfrage, die Sie nicht beantworten konnten, oder die Erlaubnis, die Sie für einen Test bräuchten. Damit zeigen Sie, dass Sie die Grenzen Ihrer Belege kennen. Geben Sie keine vertraulichen Unterlagen eines Arbeitgebers preis, nur um Ihre Geschichte eindrucksvoller zu machen.

Verlangt das Unternehmen eine neue Aufgabe, fragen Sie nach dem erwarteten Aufwand und den Bewertungskriterien. Sie sollten wissen, ob ein Prototyp nötig ist und ob eine begründete Empfehlung ausreicht. Wenn Sie die Grenzen der Aufgabe kennen, können Sie sich auf die Frage konzentrieren, die tatsächlich beantwortet werden soll.

Was schulden Führungskräfte Entwicklern mit einem frischen Blick?

Geben Sie Neueinsteigern die Möglichkeit, Annahmen zu hinterfragen, solange ihnen diese noch auffallen. Menschen wegen ihrer Eigeninitiative einzustellen, ergibt wenig Sinn, wenn anschließend jede Frage Einfluss voraussetzt, den sie noch nicht haben.

James Marchs Arbeit zum organisationalen Lernen von 1991 liefert eine hilfreiche Erklärung. Seine Modelle untersuchen, wie die Vielfalt von Überzeugungen abnehmen kann, wenn Mitglieder einer Organisation deren etablierte Praktiken übernehmen. Der Beitrag neuer Mitglieder entsteht aus anderen Perspektiven, nicht aus durchschnittlich überlegenem Wissen. Das ist Organisationstheorie, kein Beleg dafür, dass Unerfahrenheit einen Entwickler besser im Umgang mit KI macht.

Übertragen Sie diesen Gedanken auf Ihren Führungsalltag. Erklären Sie das Kundenziel, benennen Sie einen Ansprechpartner für Fragen und geben Sie Entwicklern während der Arbeitszeit Raum, eine klar begrenzte Möglichkeit zu untersuchen. Helfen Sie ihnen, echte technische Einschränkungen von Entscheidungen zu unterscheiden, die niemand mehr überprüft hat.

Wenn Sie einen Vorschlag ablehnen, erklären Sie, was Ihre Meinung ändern würde. Wenn ein Test scheitert, würdigen Sie, was der Test klären konnte. Sonst lernen die Menschen, Ihnen geschliffene Erfolgsgeschichten vorzulegen und ihre Zweifel für sich zu behalten. Ihr Lernplan für Junior-Entwickler kann die Lernbegleitung bieten, die ein Interview nicht leisten kann.

Außerdem muss jemand für die Entscheidung über das Vorhaben verantwortlich sein. Eine Person muss das Ergebnis lesen, über die Fortsetzung entscheiden und bei der nächsten Abhängigkeit helfen. Ein Prototyp, mit dem sich niemand auseinandersetzt, ist eine schlechte Lektion in Eigeninitiative.

Halten Sie die Nachweise in Kit für die Bewertung bereit

Bewahren Sie die eingereichte Arbeit, die Aufgabenbedingungen und die Begründungen Ihrer Prüfer zusammen auf. So können Sie über die tatsächlichen Nachweise sprechen, wenn die Erinnerungen an ein beeindruckendes Gespräch allmählich auseinandergehen.

In Kit können Sie mit der Portfoliobewertung frühere Arbeiten sammeln, die Kandidatinnen und Kandidaten teilen dürfen. Die Arbeitsprobe ermöglicht eine vom Unternehmen gestellte Aufgabe mit einer privaten Aufgabenbeschreibung, einem sichtbaren erwarteten Aufwand und einer Frist, die mit dem Start durch den Kandidaten beginnt. Menschliche Prüfer können über den Ablauf für Bewertungen und Feedback Punktwerte, Kommentare und Empfehlungen festhalten.

Diese Aufzeichnungen geben Ihrem Team eine Grundlage, um Eigeninitiative zu beurteilen. Sie müssen weiterhin eine sinnvolle Gelegenheit schaffen und entscheiden, was die Nachweise tatsächlich hergeben. Beginnen Sie mit einem Problem, das sich in überschaubarem Rahmen untersuchen lässt, machen Sie die Bedingungen klar und lassen Sie Raum dafür, dass ein Bewerber als nächsten sinnvollen Schritt eine bessere Frage vorschlägt.

Verwandte Artikel

Testen Sie Kit 30 Tage lang.

Recruiting, Sicherheitsmeldungen und Schulungen in einem Konto, für Teams, in denen nichts davon ein Vollzeitjob ist. 30 Tage kostenlos, Kreditkarte erforderlich. Kündigen Sie vor Ablauf, zahlen Sie nichts.

Kostenlos starten