Wie zähmt man einen Junior?

Wie gelangt man als Junior in ein großes Unternehmen? Wie stellt man einen würdigen Junior ein, wenn man ein großes Unternehmen ist? Im Folgenden erzähle ich unsere Geschichte über die Einstellung von Anfängern im Frontend: wie wir Testaufgaben ausgearbeitet, uns auf Interviews vorbereitet und ein Mentorenprogramm zur Entwicklung und Einarbeitung neuer Mitarbeiter aufgebaut haben sowie warum Standardfragen für Vorstellungsgespräche nicht funktionieren.

Ich versuche, einen Junior zu trainieren.

Hallo! Mein Name ist Pavel, ich mache Frontend in einem Team bei Wrike. Wir entwickeln ein System für Projektmanagement und Zusammenarbeit. Ich beschäftige mich seit 2010 mit dem Web, habe 3 Jahre im internationalen Remote-Bereich gearbeitet, an mehreren Startups teilgenommen und einen Kurs über Web-Technologien an der Universität gehalten. In der Firma engagiere ich mich in der Entwicklung technischer Kurse und des Mentorenprogramms von Wrike für Juniors sowie in deren Rekrutierung.

Warum wir überhaupt über die Einstellung von Juniors nachgedacht haben.

Bis vor kurzem haben wir Frontend-Entwickler auf mittlerem oder seniorem Niveau eingestellt — also solche, die selbstständig genug sind, um nach der Einarbeitung produktive Aufgaben zu übernehmen. Anfang dieses Jahres haben wir erkannt, dass wir diese Politik ändern möchten: Innerhalb eines Jahres hat sich die Anzahl unserer Produktteams fast verdoppelt, die Zahl der Frontend-Entwickler war fast bei hundert, und in naher Zukunft wird sich das noch einmal verdoppeln müssen. Es gibt viel zu tun, wenig freie Hände, und auf dem Markt sind es noch weniger, also haben wir beschlossen, uns an diejenigen zu wenden, die gerade erst ihren Weg im Frontend beginnen, und haben verstanden, dass wir bereit sind, in ihre Entwicklung zu investieren.

Was 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:

Einem Junior muss erklärt werden, welche Funktionalität und wie sie umgesetzt werden soll. Einem Mid-Level-Entwickler muss erklärt werden, welche Funktionalität benötigt wird, und er kann selbst herausfinden, wie es umgesetzt wird. Ein Senior wird dir selbst erklären, warum diese Funktionalität nicht umgesetzt werden sollte.

So oder so ist ein Junior der Entwickler, der Beratung benötigt, wie er eine bestimmte Lösung umsetzen kann. Worauf wir uns gestützt haben:

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

Wir hatten auch mehrere Hypothesen:

1. Auf die Junior-Stelle wird es einen Sturm an Bewerbungen geben. Man muss zufällige Bewerbungen bereits beim Versand von Lebensläufen filtern;
2. Der erste Filter wird nicht helfen — es werden noch Testaufgaben benötigt;
3. Testaufgaben werden alle abschrecken — sie sind nicht notwendig.

Nun, natürlich hatten wir ein Ziel: 4 Junioren in 3 Wochen.

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

Wir veröffentlichen die Stellenanzeige

Für das Unternehmen: Es wird Hunderte von Bewerbungen geben! Denken Sie an den Filter.

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

Am ersten Tag erhielten wir etwa 70 Lebensläufe von Kandidaten mit 'JavaScript-Kenntnissen'. Und dann noch mehr. Wir konnten physisch nicht alle zum Interview ins Büro einladen und wählten aus ihnen die besten mit den coolsten Pet-Projekten, einem aktiven GitHub oder zumindest etwas Erfahrung.

Aber die wichtigste Erkenntnis, die wir am ersten Tag gewannen – der Sturm hatte begonnen. Es war an der Zeit, ein Formular für den Fragebogen vor dem Versand des Lebenslaufs hinzuzufügen. Seine Aufgabe war es, Kandidaten auszusondern, die nicht bereit waren, minimalen Aufwand für den Versand des Lebenslaufs zu betreiben, und jene, die über kein Wissen und keinen Kontext verfügten, um wenigstens so viele Informationen zu haben, dass sie die richtigen Antworten googeln konnten.

Es gab Standardfragen zu JS, Layout, Web, Informatik – sie kennt jeder, der weiß, was bei einem Vorstellungsgespräch im Frontend gefragt wird. Was ist der Unterschied zwischen let/var/const? Wie wendet man Styles nur für Bildschirme mit einer Breite von weniger als 600px an? Wir wollten diese Fragen nicht im technischen Interview stellen – die Praxis hat gezeigt, dass man darauf nach 2-3 Interviews antworten kann, ohne wirklich mit der Entwicklung vertraut zu sein. Aber sie konnten uns zunächst zeigen, ob der Kandidat grundsätzlich den Kontext versteht.

Für jede Kategorie hatten wir 3-5 Fragen vorbereitet und änderten Tag für Tag die Auswahl im Antwortformular, bis wir die einfachsten und die schwierigsten ausgeschlossen hatten. Das ermöglichte es uns, den Strom zu reduzieren – in 3 Wochen haben wir 122 Kandidaten erhalten, mit denen man weiterarbeiten konnte. Es waren Studenten aus dem IT-Bereich; Jungs, die von Backend auf Frontend umsteigen wollten; Arbeiter oder Ingenieure im Alter von 25-35 Jahren, die ihren Beruf radikal ändern und unterschiedlich viel Mühe in Selbstbildung, Kurse und Praktika gesteckt haben.

Lernen wir uns besser kennen

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

Für Junioren: Kopiert keine Testaufgaben – das ist deutlich zu erkennen. Und haltet euren GitHub in Ordnung!

Wenn wir alle zu technischen Interviews eingeladen hätten, müssten wir ungefähr 40 Interviews pro Woche nur für Junioren und nur im Frontend führen. Daher haben wir uns entschieden, die zweite Hypothese über die Testaufgabe zu prüfen.

Was uns bei der Testaufgabe wichtig war:

1. Eine gute, skalierbare Architektur zu schaffen, aber ohne Überengineering;
2. Es ist besser, es länger zu machen, aber gut zu machen, als über Nacht eine schnelle Lösung zusammenzuwerfen und mit dem Kommentar "Ich werde es auf jeden Fall zu Ende bringen" zu senden;
3. Die Entwicklungsgeschichte in Git – Ingenieurkultur, iterative Entwicklung und dass die Lösung nicht plump kopiert wurde.

Wir sind zu dem Schluss gekommen, dass wir eine algorithmische Aufgabe und eine kleine Webanwendung sehen wollen. Die Algorithmen waren auf dem Niveau von Laborarbeiten für Grundkurse – 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 erste Testoption entschieden. Die Webanwendung sollte ein Tic-Tac-Toe sein, unter Verwendung irgendeines Frameworks (oder ohne).

Die Testaufgabe wurde von fast der Hälfte der verbleibenden Kandidaten absolviert – uns wurden Lösungen eingereicht 54 Kandidaten. Unglaubliche Einsicht – wie viele umsetzbare Varianten von Tic-Tac-Toe denkt ihr, gibt es im Internet?

Wie viele?Tatsächlich scheinen es nur 3 zu sein. Und in den überwiegenden Mehrzahl der Lösungen waren genau diese 3 Varianten zu finden.
Was uns nicht gefallen hat:

• Kopieren von Code oder Entwicklung nach demselben Tutorial ohne eigene Architektur;
• Beide Aufgaben im selben Repository in verschiedenen Ordnern, wobei es natürlich keine Commit-Historie gibt;
• Schmutziger Code, Verletzung des DRY-Prinzips, Mangel an Formatierung;
• Mischung aus Model, View und Controller in einer Klasse mit hunderten von Codezeilen;
• Mangelndes Verständnis für Unit-Tests;
• Die Lösung „eindimensional“ – ein Hardcodieren der Gewinnkombinationen für 3x3, was ziemlich schwer auf 10x10, zum Beispiel, zu erweitern sein wird.

Und wir haben auch auf benachbarte Repositories geachtet – coole Pet-Projekte liefen im Plus, während eine ganze Reihe von Testaufgaben anderer Unternehmen eher ein Alarmsignal war: Warum konnte der Kandidat dort nicht bestehen?

Letztendlich fanden wir großartige Optionen in React, Angular, Vanilla JS – es gab insgesamt 29. Und einen anderen Kandidaten luden wir ohne Test aufgrund seiner wirklich großartigen Pet-Projekte ein. Unsere Hypothese über den Nutzen von Testaufgaben wurde bestätigt.

Technisches Interview

Für das Unternehmen: Bei Ihnen sind keine Mid-Levels/Senioren gekommen! Es ist ein individuellerer Ansatz nötig.

Für Junioren: Denken Sie daran, dass dies keine Prüfung ist – versuchen Sie nicht, bei einer Drei zu schweigen oder den Professor mit dem ganzen Wissen, das Sie haben, zu überfluten, sodass er verwirrt ist und eine „eins“ gibt.

Was wollen wir im technischen Interview verstehen? Eine einfache Sache – wie der Kandidat denkt. Wahrscheinlich hat er einige Hard Skills, wenn er die ersten Auswahlphasen bestanden hat – es bleibt zu klären, ob er in der Lage ist, sie anzuwenden. Wir einigten uns auf 3 Aufgaben.

Die erste – über Algorithmen und Datenstrukturen. Mit Stift, auf Blatt Papier, in einer Pseudoprogrammiersprache und mit Hilfe von Zeichnungen diskutierten wir, wie man einen Baum kopiert oder ein Element aus einer einfach verketteten Liste entfernt. Eine unangenehme Entdeckung war, dass nicht alle Rekursion und die Funktionsweise von Verweisen verstehen.

Die zweite – Live-Coding. Wir gingen auf codewars.com, wählten einfache Aufgaben wie das Sortieren eines Arrays von Wörtern nach dem letzten Buchstaben aus und versuchten zusammen mit dem Kandidaten, alle Tests in 30-40 Minuten zu bestehen. Es schien, als sollte es keine Überraschungen von den Leuten geben, die Tic Tac Toe bewältigt hatten – aber in der Praxis konnten nicht alle verstehen, dass der Wert in einer Variablen gespeichert werden musste und die Funktion etwas über return zurückgeben sollte. Obwohl ich aufrichtig hoffe, dass es nur ein Nervenkitzel war und die Leute in einer entspannteren Umgebung diese Aufgaben bewältigen konnten.

Schließlich die dritte – ein wenig über Architektur. Wir diskutierten, wie man eine Suchleiste machen kann, wie dabei Debouncing funktioniert, wie man verschiedene Widgets in den Suchhinweisen rendert und wie das Frontend mit dem Backend interagieren kann. Es gab einige interessante Lösungen, auch über Server-Side-Rendering und Web-Sockets.

Wir haben 21 Interviews nach diesem Schema durchgeführt. Das Publikum war völlig gemischt – lassen Sie uns das an Comics verdeutlichen:

1. „Raketa“. Sie beruhigt sich nie, mischt sich überall ein und bei Interviews wird sie Sie mit einem Gedankenstrom überschütten, der direkt nicht mit der gestellten Frage zusammenhängt. Wenn es sich um eine Universität handeln würde, wäre das für viele eine bekannte Versuch, all ihr Wissen zu demonstrieren, wenn man sich nur daran erinnert, dass man das Ticket, das man bekommen hat, gestern Abend nicht lernen wollte – es ist so oder so nicht mehr zu retten.
2. „Groot“. Es ist ziemlich schwierig, mit ihm in Kontakt zu treten, weil er Groot ist. Man muss bei den Interviews lange auf ihn einreden und die Antworten Wort für Wort hervorholen. Es ist gut, wenn es nur ein Stocken ist – sonst wird es später in der täglichen Arbeit sehr schwer für Sie.
3. „Drax“. Früher war er im Gütertransport tätig und hat nur JS über Stackoverflow gelernt, deshalb versteht er nicht immer, worüber beim Interview gesprochen wird. Dabei ist er ein guter Mensch, hat die besten Absichten und möchte ein großartiger Frontend-Entwickler werden.
4. Und wahrscheinlich, „Star-Lord“. Insgesamt ein ordentlicher Kandidat, mit dem man verhandeln und einen Dialog aufbauen kann.

Am Ende unserer Recherchen 7 Kandidaten haben es ins Finale geschafft, indem sie ihre Hard Skills mit einer großartigen Testaufgabe und guten Antworten im Interview unter Beweis stellten.

Cultural Fit

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

Für Junioren: Sie werden mit ihnen arbeiten! Ist das Unternehmen wirklich bereit, in das Wachstum von Juniors zu investieren, oder wird es Ihnen nur die gesamte Drecksarbeit für ein niedriges Gehalt aufhelfen?

Jeder Junior kommt – neben dem Produktteam, dessen Leiter zustimmen muss, ihn aufzunehmen – zu einem Mentor. Die Aufgabe des Mentors ist es, ihn durch einen dreimonatigen Onboarding- und Hard-Skill-Entwicklungsprozess zu führen. Daher kamen wir zu jedem Cultural Fit als Mentoren und stellten uns die Frage: „Werde ich die Verantwortung übernehmen, den Kandidaten in 3 Monaten nach unserem Plan zu entwickeln?“

Dieser Schritt verlief ohne Besonderheiten und brachte uns schließlich 4 Angebote, von denen 3 angenommen wurden, und die Jungs traten den Teams bei.

Leben nach dem Angebot

Für das Unternehmen: Kümmere dich um deine Juniors oder es werden es andere tun!

Für Junioren: AAAAAAAAAAAAAAA!!!

Wenn ein neuer Mitarbeiter eingestellt wird, muss er onboarding — in die Prozesse eingewiesen werden, erklärt bekommen, wie alles im Unternehmen und im Team funktioniert und wie er allgemein arbeiten soll. Wenn ein Junior eintritt, muss man verstehen, wie man ihn weiterentwickeln kann.

Als wir darüber nachdachten, haben wir eine Liste von 26 Fähigkeiten erstellt, die, unserer Meinung nach, ein Junior bis zum Ende der dreimonatigen Onboarding-Phase besitzen sollte. Darunter fallen Hard-Skills (basierend auf unserem Stack), Kenntnisse über unsere Prozesse, Scrum, Infrastruktur und Projektarchitektur. Wir haben sie in einem Zeitplan zusammengefasst, der sich über 3 Monate erstreckt.

Hier ist zum Beispiel der Zeitplan meines Juniors.

Jeden Junior weisen wir einen Mentor zu, der individuell mit ihm arbeitet. Abhängig vom Mentor und dem aktuellen Niveau des Kandidaten können die Treffen 1 bis 5 Mal pro Woche je 1 Stunde stattfinden. Mentoren sind freiwillige, engagierte Frontend-Entwickler, die mehr machen wollen, als nur Code zu schreiben.

Ein Teil der Last wird von den Kursen zu unserem Stack — Dart, Angular — von den Mentoren genommen. Die Kurse finden regelmäßig für kleine Gruppen von 4-6 Personen statt, wo die Teilnehmer ohne Unterbrechung von der Arbeit lernen.

Über die 3 Monate hinweg sammeln wir regelmäßig Feedback von den Juniors, deren Mentoren und den Leads und passen den Prozess individuell an. 1-2 Mal während des gesamten Zeitraums findet eine Überprüfung der erworbenen Fähigkeiten statt, die am Ende ebenfalls durchgeführt wird — auf deren Basis werden Empfehlungen erstellt, welche Bereiche verbessert werden sollten.

Fazit

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

Für Junioren: Suchen Sie Unternehmen, die sorgfältig Kandidaten auswählen und wissen, wie man sie entwickelt.

In 3 Monaten haben wir 122 Umfragen, 54 Testaufgaben durchgesehen und 21 technische Interviews durchgeführt. Das führte uns zu 3 großartigen Juniors, die mittlerweile die Hälfte ihrer Onboarding- und Beschleunigungspläne erfolgreich bewältigt haben. Sie lösen bereits echte Produktaufgaben in unserem Projekt, wo allein im Frontend mehr als 2.000.000 Codezeilen und über 400 Repositories vorhanden sind.

Wir haben festgestellt, dass der Auswahlprozess für Juniors durchaus anspruchsvoll sein kann und sollte, aber letztendlich sind es nur die Kandidaten, die wirklich bereit sind, sehr hart zu arbeiten und in ihre Entwicklung zu investieren.

Derzeit besteht unsere Hauptaufgabe darin, die dreimonatigen Roadmaps zur Entwicklung für jeden Junior in individueller Zusammenarbeit mit einem Mentor und gemeinsamen Kursen abzuschließen, Metriken zu sammeln, Feedback von Teamleitern, Mentoren und den Teilnehmern selbst einzuholen. Damit kann das erste Experiment als abgeschlossen betrachtet werden, um daraus Schlüsse zu ziehen, den Prozess zu verbessern und ihn erneut zu starten, um neue Kandidaten auszuwählen.

Quelle: habr.com