Wie man einen Junior reizt?

Wie findet man einen Einstieg in ein großes Unternehmen, wenn man ein Junior ist? Wie stellt man einen qualifizierten Junior ein, wenn man ein großes Unternehmen ist? Im Folgenden teile ich unsere Erfahrungen bei der Einstellung von Neueinsteigern im Frontend: Wie wir Testaufgaben erarbeitet, uns auf Interviews vorbereitet und ein Mentorenprogramm für die Entwicklung und Einarbeitung von Neueinsteigern aufgebaut haben und warum Standardfragen für Vorstellungsgespräche nicht funktionieren.

Ich versuche, einen Junior zu reizen

Hallo! Ich heiße Pavel, ich arbeite im Frontend-Team von Wrike. Wir entwickeln ein Projektmanagement- und Kollaborationstool. Ich beschäftige mich seit 2010 mit Webtechnologien, habe 3 Jahre im internationalen Remote-Bereich gearbeitet, an mehreren Startups teilgenommen und einen Kurs über Webtechnologien an der Universität gehalten. In unserem Unternehmen bin ich an der Entwicklung technischer Schulungen und des Mentorenprogramms für Junioren beteiligt und kümmere mich direkt um deren Rekrutierung.

Warum haben wir überhaupt über die Einstellung von Junioren nachgedacht?

Bis vor kurzem haben wir Frontend-Entwickler auf dem Niveau Middle oder Senior eingestellt – also solche, die nach der Einarbeitungszeit eigenständig Produktaufgaben übernehmen können. Zu Beginn dieses Jahres haben wir erkannt, dass wir diese Strategie ändern möchten: Im Laufe eines Jahres hat sich die Zahl unserer Produktteams fast verdoppelt, die Anzahl der Frontend-Entwickler nähert sich der hundert und wird sich voraussichtlich bald erneut verdoppeln. Die Aufgaben sind vielfältig, die verfügbaren Hände sind jedoch gering, und auf dem Markt gibt es sogar noch weniger. Daher haben wir beschlossen, uns an diejenigen zu wenden, die am Anfang ihrer Frontend-Karriere stehen und erkannt haben, dass wir bereit sind, in ihre Entwicklung zu investieren.

Wer ist ein Junior?

Das ist die erste Frage, die wir uns gestellt haben. Es gibt verschiedene Kriterien, aber das einfachste und verständlichste Prinzip lautet:

Ein Junior benötigt eine Erklärung, welche Funktion und wie sie umgesetzt werden soll. Ein Middle-Entwickler muss lediglich wissen, welche Funktion benötigt wird, und er wird selbständig die Implementierung übernehmen. Ein Senior hingegen erklärt dir selbst, warum diese Funktion überhaupt nicht notwendig ist.

So oder so ist ein Junior ein Entwickler, der Rat benötigt, wie eine bestimmte Lösung umgesetzt werden soll. Darauf haben wir uns gestützt:

1. Ein Junior ist jemand, der sich entwickeln möchte und bereit ist, dafür hart zu arbeiten;
2. Er weiß nicht immer, in welche Richtung er sich entwickeln möchte;
3. Braucht Rat und sucht Hilfe von außen – sei es bei seinem Teamleiter, Mentor oder in der Community.

Wir hatten außerdem einige Hypothesen:

1. Auf die Junior-Position wird ein Sturm von Bewerbungen eintreffen. Man muss zufällige Bewerbungen bereits beim Versand des Lebenslaufs filtern;
2. Der erste Filter wird nicht helfen – es sind auch zusätzliche Tests erforderlich;
3. Tests schrecken alle ab – sie sind nicht nötig.

Und natürlich hatten wir das Ziel: 4 Juniors in 3 Wochen.

Mit diesem Bewusstsein begannen wir zu experimentieren. Der Plan war einfach: mit einem möglichst breiten Funnel zu starten und ihn schrittweise so zu verengen, dass wir den Strom von Bewerbungen verarbeiten konnten, ohne ihn auf 1 Kandidaten pro Woche zu reduzieren.

Wir schalten die Stelle

Für das Unternehmen: Es werden Hunderte von Bewerbungen kommen! Denken Sie an die Filter.

Für den Junior: Haben Sie keine Angst vor einem Fragebogen vor dem Versand des Lebenslaufs und der Testaufgaben – das ist ein Zeichen dafür, dass sich das Unternehmen um Sie kümmert und den Prozess gut gestaltet hat.

Am ersten Tag erhielten wir etwa 70 Lebensläufe von Kandidaten mit "JavaScript-Kenntnissen". Und es kamen immer mehr. Wir konnten physisch nicht alle zu einem Interview ins Büro einladen und wählten die Kandidaten mit den besten persönlichen Projekten, einem aktiven GitHub-Profil oder zumindest etwas Erfahrung aus.

Die wichtigste Erkenntnis, die wir am ersten Tag gewonnen haben, ist, dass der Sturm begonnen hat. Es war an der Zeit, ein Formular für die Bewerbung vor dem Einreichen des Lebenslaufs einzuführen. Ziel war es, Kandidaten auszusondern, die nicht bereit sind, minimale Anstrengungen für die Einreichung ihres Lebenslaufs zu unternehmen, sowie diejenigen, die nicht über das Wissen und den Kontext verfügen, um zumindest die richtigen Antworten zu googeln.

Das Formular enthielt Standardfragen zu JS, Webentwicklung und Computerwissenschaften – das kennt jeder, der weiß, was in einem Frontend-Interview gefragt wird. Was ist der Unterschied zwischen let/var/const? Wie wendet man Styles nur für Bildschirmbreiten unter 600px an? Wir wollten diese Fragen nicht im technischen Interview stellen – die Erfahrung hat gezeigt, dass man darauf nach 2-3 Interviews ohne tiefere Kenntnisse der Entwicklung antworten kann. Aber dennoch konnten sie uns zunächst zeigen, ob der Kandidat überhaupt das grundlegende Verständnis hat.

In jeder Kategorie haben wir 3-5 Fragen vorbereitet und täglich die Auswahl in unserem Feedback-Formular angepasst, bis wir die einfachsten und die kompliziertesten ausgeschlossen haben. Dadurch konnten wir den Zulauf reduzieren – in 3 Wochen haben wir erhalten 122 Kandidaten, mit denen wir weiterarbeiten konnten. Es handelte sich um Informatikstudierende; junge Leute, die vom Backend in den Frontend-Bereich wechseln wollten; Arbeiter oder Ingenieure zwischen 25 und 35 Jahren, die ihren Beruf grundlegend ändern wollten und unterschiedlich viel Energie in Selbstbildung, Kurse und Praktika investierten.

Lernen Sie uns näher kennen

Für das Unternehmen: Die Testaufgabe schreckt die Kandidaten nicht ab, sondern hilft, den Auswahlprozess zu verkürzen.

Für den Junior: Kopieren Sie keine Testaufgaben – das fällt auf. Und halten Sie Ihr GitHub aufgeräumt!

Wenn wir alle zu technischen Interviews eingeladen hätten, müssten wir etwa 40 Interviews pro Woche nur für Junioren und nur für den Frontend-Bereich führen. Deshalb haben wir beschlossen, die zweite Hypothese – hinsichtlich der Testaufgabe – zu überprüfen.

Was uns bei der Testaufgabe wichtig war:

1. Eine gute, skalierbare Architektur aufzubauen, aber ohne Overengineering;
2. Es ist besser, sich Zeit zu nehmen und alles gut zu machen, als in der Nacht etwas zusammenzubasteln und mit dem Kommentar zu verschicken, "Ich werde es auf jeden Fall fertigstellen".
3. Die Geschichte der Entwicklung in Git ist eine Ingenieurskultur, iterative Entwicklung und die Tatsache, dass die Lösung nicht völlig dreist kopiert wurde.

Wir haben uns darauf geeinigt, eine algorithmische Aufgabe und eine kleine Webanwendung zu betrachten. Die Algorithmen waren auf dem Niveau von Laborarbeiten der ersten Studiengänge vorbereitet – binäre Suche, Sortierung, Überprüfung auf Anagramme, Arbeiten mit Listen und Bäumen. Letztendlich haben wir uns für die binäre Suche als ersten Testfall entschieden. Die Webanwendung sollte ein Spiel von X und O mit der Verwendung eines beliebigen Frameworks (oder ohne) sein.

Fast die Hälfte der verbleibenden Kandidaten hat die Testaufgabe erfolgreich bestanden – uns wurden Lösungen zugeschickt. 54 Kandidaten. Eine unglaubliche Erkenntnis – wie viele Implementierungen von X und O, die zum Kopieren bereit sind, gibt es wohl im Internet?

Wie viele?Tatsächlich scheint es nur 3 zu geben. Und in der überwiegenden Mehrheit der Lösungen gab es genau diese 3 Varianten.
Was nicht gefallen hat:

• Copy-Paste oder die Entwicklung nach dem gleichen Tutorial ohne eigene Architektur;
• beide Aufgaben in einem Repository in verschiedenen Ordnern, wobei es natürlich keine Commit-Historie gibt;
• schmutziger Code, Verstoß gegen DRY, fehlende Formatierung;
• Mischung aus Modell, View und Controller in einer Klasse mit Hunderten von Zeilen Code;
• fehlendes Verständnis für Unit-Tests;
• Lösung "von der Stange" — Hardcodierung einer 3x3-Matrix gewinnender Kombinationen, die schwer auf 10x10 erweitert werden kann, zum Beispiel.

Außerdem haben wir auf benachbarte Repositories geachtet — coole Pet-Projects waren erfolgreich, während viele Testaufgaben von anderen Unternehmen eher ein Alarmzeichen waren: warum konnte der Kandidat dort nicht bestehen?

Letztendlich fanden wir großartige Optionen in React, Angular, Vanilla JS — insgesamt waren es 29. Und einen weiteren Kandidaten haben wir ohne Test eingeladen wegen seiner großartigen Pet-Projects. Unsere Hypothese über den Nutzen von Testaufgaben hat sich bestätigt.

Technisches Interview

Für das Unternehmen: Sie haben es mit keinen Mid-Level/Senior-Kandidaten zu tun! Es ist mehr individueller Ansatz erforderlich.

Für den Junior: Denken Sie daran, das ist kein Test — versuchen Sie nicht, einfach nur das Nötigste zu sagen oder den Professor mit all Ihrem Wissen zu überfluten, um ihn zu verwirren und eine „sehr gut“ zu bekommen.

Was möchten wir im technischen Interview verstehen? Eine einfache Sache — wie der Kandidat denkt. Wahrscheinlich hat er einige Hard Skills, wenn er die ersten Auswahlstufen bestanden hat — jetzt gilt es herauszufinden, ob er sie auch anwenden kann. Wir haben uns auf 3 Aufgaben geeinigt.

Die erste betrifft Algorithmen und Datenstrukturen. Mit Stift und Blatt, in Pseudocode und mithilfe von Zeichnungen haben wir erörtert, wie man einen Baum kopiert oder ein Element aus einer einfach verketteten Liste entfernt. Eine unangenehme Entdeckung war, dass nicht jeder Rekursion und das Funktionieren von Verweisen versteht.

Die zweite ist Live-Coding. Wir haben uns auf codewars.com, wir haben uns mit einfachen Themen wie der Sortierung eines Wörterarrays nach dem letzten Buchstaben beschäftigt und zusammen mit dem Kandidaten versucht, alle Tests in 30-40 Minuten zu bestehen. Es schien, als sollte es keine Überraschungen von den Leuten geben, die schon Tic-Tac-Toe gemeistert hatten — doch in der Praxis konnten nicht alle erkennen, dass der Wert in einer Variable gespeichert werden muss und die Funktion etwas über return zurückgeben sollte. Ich hoffe aufrichtig, dass dies nur eine Nervosität war und die Leute diese Aufgaben unter leichteren Bedingungen lösen konnten.

Schließlich ging es im dritten Teil ein wenig um Architektur. Wir haben besprochen, wie man eine Suchleiste erstellt, wie debounce dabei funktioniert, wie verschiedene Widgets in den Suchvorschlägen gerendert werden und wie das Frontend mit dem Backend interagieren kann. Es gab viele interessante Lösungen, darunter serverseitiges Rendering und WebSockets.

Wir haben 21 Interviews nach diesem Schema durchgeführt. Das Publikum war äußerst vielfältig – um es mit Comics zu vergleichen:

1. „Rakete“. Nie gibt er Ruhe, drängt sich überall ein, und im Vorstellungsgespräch überrollt er Sie mit einem Gedankenstrom, der nicht einmal direkt mit der gestellten Frage verbunden ist. Wäre es an der Universität, dann würde das vielen bekannt vorkommen – der Versuch, all sein Wissen zu zeigen, während man sich nur daran erinnert, dass man das Thema, auf das man gestoßen ist, gestern Abend nicht lernen wollte – es wird sowieso nicht klappen.
2. „Groot“. Es ist ziemlich schwierig, mit ihm in Kontakt zu treten, weil er Groot ist. Im Interview muss man lange ausholen und Antworten Wort für Wort herauskitzeln. Gut, wenn es sich nur um einen Stau handelt – sonst wird die tägliche Arbeit sehr schwierig werden.
3. „Drax“. Früher hat er im Transportwesen gearbeitet und hat Programmierung nur durch JS-Tutorials auf Stackoverflow gelernt, weshalb er nicht immer versteht, worum es im Vorstellungsgespräch geht. Trotzdem ist er ein netter Mensch, hat die besten Absichten und möchte ein großartiger Frontend-Developer werden.
4. Na ja, wahrscheinlich „Star-Lord“. Insgesamt ein solider Kandidat, mit dem man verhandeln und einen Dialog aufbauen kann.

Am Ende unserer Recherchen 7 Kandidaten Sie haben das Finale erreicht, indem sie ihre Hard Skills mit einer großartigen Testaufgabe und überzeugenden Antworten im Interview bestätigt haben.

Kulturelle Passung

Für das Unternehmen: Sie werden mit ihm arbeiten! Ist der Kandidat bereit, extrem viel für seine Entwicklung zu investieren? Passt er wirklich ins Team?

Für den Junior: Sie werden mit ihnen arbeiten! Ist das Unternehmen bereit, in das Wachstum von Junioren zu investieren, oder wird es einfach die ganze Drecksarbeit zu einem niedrigen Gehalt auf Sie abwälzen?

Jeder Junior wird zusätzlich zum Produktteam, dessen Leiter zustimmen muss, ihn aufzunehmen, einem Mentor zugewiesen. Die Aufgabe des Mentors besteht darin, den Junior durch einen dreimonatigen Onboarding-Prozess und die Entwicklung von Hard Skills zu begleiten. Daher kamen wir zu jedem Cultural Fit als Mentoren und stellten uns die Frage: "Werde ich die Verantwortung übernehmen, den Kandidaten in 3 Monaten gemäß unserem Plan weiterzubilden?"

Diese Phase verlief ohne besondere Vorkommnisse und brachte uns letztendlich 4 Angebote, von denen 3 angenommen wurden und die Leute in die Teams eingetreten sind.

Das Leben nach dem Angebot

Für das Unternehmen: Kümmern Sie sich um Ihre Junioren, oder werden es andere tun!

Für den Junior: AAAAAAAAAAAAA!!!

Wenn ein neuer Mitarbeiter eintritt, muss er onboarded werden – in die Abläufe eingeführt, darüber informiert werden, wie alles im Unternehmen und im Team funktioniert und wie er überhaupt arbeiten soll. Wenn ein Junior eintrittt, muss man verstehen, wie man ihn fördern kann.

Nachdem wir darüber nachgedacht haben, haben wir eine Liste mit 26 Fähigkeiten erstellt, die unserer Meinung nach ein Junior bis zum Ende der dreimonatigen Einarbeitungszeit besitzen sollte. Dazu gehören Hard Skills (in Bezug auf unseren Tech-Stack), Kenntnisse über unsere Prozesse, Scrum, Infrastruktur und Projektarchitektur. Wir haben sie in einen Roadmap integriert, die über einen Zeitraum von 3 Monaten verteilt ist.

Hier ist beispielsweise der Roadmap für meinen Junior.

Jeden Junior weisen wir einen Mentor zu, der in einem individuellen Modus mit ihm arbeitet. Je nach Mentor und aktuellem Status des Kandidaten können die Treffen zwischen 1 und 5 Mal pro Woche für 1 Stunde stattfinden. Mentoren sind freiwillig initiierte Frontend-Entwickler, die mehr tun möchten, als nur Code zu schreiben.

Ein Teil der Last wird von den Mentorenschulungen in unserem Tech-Stack – Dart, Angular – genommen. Diese Kurse finden regelmäßig in kleinen Gruppen von 4-6 Personen statt, in denen die Teilnehmer ohne Unterbrechung ihrer Arbeit lernen.

Über einen Zeitraum von 3 Monaten sammeln wir regelmäßig Feedback von Junioren, deren Mentoren und Führungskräften und passen den Prozess individuell an. 1-2 Mal während dieses Zeitraums führen wir eine Überprüfung der verbesserten Fähigkeiten durch; eine ähnliche Überprüfung erfolgt am Ende. Basierend darauf werden Empfehlungen erstellt, was verbessert werden sollte.

Fazit

Für das Unternehmen: Sollte man in Junioren investieren? Ja!

Für den Junior: Suchen Sie nach Unternehmen, die sorgfältig Kandidaten auswählen und wissen, wie sie sich weiterentwickeln können.

In 3 Monaten haben wir 122 Fragebögen, 54 Testaufgaben und 21 technische Interviews durchgesehen. Dies hat uns 3 großartige Junioren gebracht, die inzwischen die Hälfte ihrer Roadmaps für Onboarding und Beschleunigung durchlaufen haben. Sie lösen bereits reale Produktaufgaben in unserem Projekt, wo alleine im Frontend über 2.000.000 Codezeilen und mehr als 400 Repositories vorhanden sind.

Wir haben herausgefunden, dass der Auswahlprozess für Junioren komplex sein kann und sollte, aber letztendlich bestehen nur die Kandidaten, die wirklich bereit sind, sehr hart zu arbeiten und in ihre Entwicklung zu investieren.

Aktuell liegt unser Hauptaugenmerk darauf, die dreimonatigen Entwicklungs-Roadmaps für jeden Junior hinzubekommen, indem wir individuelle Mentorenarbeit und gemeinsame Schulungen bieten. Wir sammeln Metriken, Feedback von Teamleitern, Mentoren und den Teilnehmern selbst. Nach diesem ersten Experiment können wir die Ergebnisse auswerten, den Prozess verbessern und ihn erneut starten, um neue Kandidaten auszuwählen.

Quelle: habr.com