Wie zähmt man einen Junior?

Wie kommt man als Junior in ein großes Unternehmen? Wie stellt man einen anständigen Junior ein, wenn man ein großes Unternehmen ist? Unterhalb des Schnitts erzähle ich Ihnen unsere Geschichte der Einstellung von Einsteigern im Front-End: wie wir Testaufgaben durchgearbeitet, uns auf die Durchführung von Vorstellungsgesprächen vorbereitet und ein Mentoring-Programm für die Entwicklung und das Onboarding von Neulingen aufgebaut haben, und auch, warum Standardfragen im Vorstellungsgespräch scheitern Funktioniert nicht.

Wie zähmt man einen Junior?
Ich versuche, Junior zu zähmen

Hallo! Mein Name ist Pavel, ich mache Frontend-Arbeit im Wrike-Team. Wir schaffen ein System für Projektmanagement und Zusammenarbeit. Ich arbeite seit 2010 im Web, habe 3 Jahre im Ausland gearbeitet, an mehreren Startups teilgenommen und an der Universität einen Kurs über Webtechnologien unterrichtet. Im Unternehmen bin ich an der Entwicklung technischer Kurse und des Wrike-Mentoring-Programms für Nachwuchskräfte beteiligt und rekrutiere diese auch direkt.

Warum haben wir überhaupt darüber nachgedacht, Nachwuchskräfte einzustellen?

Bis vor Kurzem rekrutierten wir Entwickler mittlerer oder höherer Ebene für das Frontend – unabhängig genug, um nach dem Onboarding Produktaufgaben zu erledigen. Zu Beginn dieses Jahres wurde uns klar, dass wir diese Politik ändern wollten: Im Laufe des Jahres hat sich die Anzahl unserer Produktteams fast verdoppelt, die Anzahl der Front-End-Entwickler hat sich der Hundert angenähert, und in naher Zukunft wird das alles so sein muss nochmal verdoppeln. Es gibt viel Arbeit, wenige freie Hände und es gibt noch weniger davon auf dem Markt. Deshalb haben wir uns entschieden, uns an die Leute zu wenden, die gerade erst ihre Reise im Frontend beginnen, und erkannten, dass wir bereit sind, in sie zu investieren Entwicklung.

Wer ist ein Junior?

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

Junior muss erklärt werden, welche Funktion und wie sie ausgeführt wird. Dem Mittleren muss erklärt werden, welche Funktion benötigt wird, und er wird die Implementierung selbst herausfinden. Der Unterzeichner selbst wird Ihnen erklären, warum diese Funktion überhaupt nicht ausgeführt werden muss.

Auf die eine oder andere Weise ist ein Junior ein Entwickler, der Ratschläge zur Implementierung dieser oder jener Lösung benötigt. Worauf wir aufbauen wollten:

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

Wir hatten auch mehrere Hypothesen:

  1. Auf die Position von June wird es einen Sturm der Reaktionen geben. Sie müssen zufällige Antworten beim Versenden Ihres Lebenslaufs filtern;
  2. Ein Primärfilter hilft nicht. — Es sind mehr Testaufgaben erforderlich.
  3. Testaufgaben werden jeden abschrecken - Sie werden nicht benötigt.

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

Mit dieser Erkenntnis begannen wir zu experimentieren. Der Plan war einfach: Beginnen Sie mit einem möglichst breiten Trichter und versuchen Sie, ihn schrittweise einzugrenzen, damit Sie den Flow verarbeiten können, aber reduzieren Sie ihn nicht auf einen Kandidaten pro Woche.

Wir veröffentlichen eine Stelle

Für die Firma: Es wird Hunderte von Antworten geben! Denken Sie an einen Filter.

Für Junioren: Haben Sie keine Angst vor dem Fragebogen, bevor Sie Ihren Lebenslauf und Ihre Testaufgabe absenden – das ist ein Zeichen dafür, dass sich das Unternehmen um Sie gekümmert und den Prozess gut eingerichtet hat.

Am ersten Tag erhielten wir etwa 70 Lebensläufe von Kandidaten „mit JavaScript-Kenntnissen“. Und dann noch einmal. Und weiter. Wir konnten nicht jeden zu einem Vorstellungsgespräch ins Büro einladen und wählten aus ihnen die Jungs mit den coolsten Lieblingsprojekten, Live-Github oder zumindest Erfahrung aus.

Aber die wichtigste Schlussfolgerung, die wir gleich am ersten Tag gezogen haben, war, dass der Sturm begonnen hatte. Jetzt ist es an der Zeit, ein Fragebogenformular hinzuzufügen, bevor Sie Ihren Lebenslauf einreichen. Ihr Ziel war es, Kandidaten auszusortieren, die nicht bereit waren, den geringsten Aufwand zu betreiben, um einen Lebenslauf einzureichen, und diejenigen, die nicht über das Wissen und den Kontext verfügten, um zumindest die richtigen Antworten bei Google zu finden.

Es enthielt Standardfragen zu JS, Layout, Web und Informatik – jeder, der sich vorstellt, was er in einem Front-End-Interview stellt, kennt sie. Was ist der Unterschied zwischen let/var/const? Wie kann ich Stile nur auf Bildschirme anwenden, die kleiner als 600 Pixel breit sind? Wir wollten diese Fragen nicht bei einem technischen Interview stellen – die Praxis hat gezeigt, dass sie nach 2-3 Interviews beantwortet werden können, ohne dass man die Entwicklung überhaupt versteht. Sie konnten uns aber zunächst zeigen, ob der Kandidat den Kontext grundsätzlich versteht.

In jeder Kategorie haben wir 3-5 Fragen vorbereitet und Tag für Tag deren Satz im Antwortformular geändert, bis wir die passabelsten und schwierigsten Fragen eliminiert haben. Dadurch konnten wir den Durchfluss reduzieren – in 3 Wochen erhielten wir 122 Kandidaten, mit dem wir weiterarbeiten könnten. Das waren IT-Studenten; Leute, die vom Backend nach vorne wechseln wollten; Arbeiter oder Ingenieure im Alter von 25 bis 35 Jahren, die ihren Beruf radikal wechseln wollten und unterschiedlich viel Aufwand in Selbstbildung, Kurse und Praktika steckten.

Sich besser kennenlernen

Für die Firma: Die Testaufgabe schreckt Kandidaten nicht ab, sondern hilft, den Trichter zu verkürzen.

Für Junioren: Kopieren Sie keine Testversionen und fügen Sie sie nicht ein – das fällt auf. Und halten Sie Ihren Github in Ordnung!

Wenn wir alle zu einem technischen Vorstellungsgespräch einladen würden, müssten wir etwa 40 Vorstellungsgespräche pro Woche nur für Junioren und nur im Frontend führen. Daher haben wir uns entschieden, die zweite Hypothese zu testen – über die Testaufgabe.

Was uns im Test wichtig war:

  1. Erstellen Sie eine gute skalierbare Architektur, aber ohne Overengineering;
  2. Es ist besser, sich länger Zeit zu nehmen, es aber gut zu machen, als über Nacht ein Handwerk zusammenzustellen und es mit dem Kommentar „Ich werde es auf jeden Fall fertigstellen“ zu verschicken;
  3. Die Entwicklungsgeschichte von Git ist die Ingenieurskultur, die iterative Entwicklung und die Tatsache, dass die Lösung nicht offensichtlich kopiert wurde.

Wir waren uns einig, dass wir uns ein algorithmisches Problem und eine kleine Webanwendung ansehen wollten. Algorithmen wurden auf der Ebene von Laboratorien der Grundstufe vorbereitet – binäre Suche, Sortieren, Prüfen auf Anagramme, Arbeiten mit Listen und Bäumen. Am Ende haben wir uns für die binäre Suche als erste Testoption entschieden. Die Webanwendung musste mit einem beliebigen Framework (oder ohne) kompatibel sein.

Fast die Hälfte der verbleibenden Jungs hat die Testaufgabe abgeschlossen – sie haben uns die Lösungen geschickt 54 Kandidaten. Unglaubliche Einsicht – wie viele Implementierungen von Tic-Tac-Toe, bereit zum Kopieren und Einfügen, gibt es Ihrer Meinung nach im Internet?

Сколько?Tatsächlich scheint es nur 3 zu geben. Und in den allermeisten Entscheidungen gab es genau diese 3 Optionen.
Was hat nicht gefallen:

  • Kopieren und Einfügen oder Entwicklung basierend auf demselben Tutorial ohne Ihre eigene Architektur;
  • beide Aufgaben befinden sich im selben Repository in unterschiedlichen Ordnern, natürlich gibt es keinen Commit-Verlauf;
  • schmutziger Code, DRY-Verstoß, fehlende Formatierung;
  • eine Mischung aus Modell, Ansicht und Controller in einer Klasse mit einer Länge von Hunderten von Codezeilen;
  • mangelndes Verständnis für Unit-Tests;
  • Eine „frontale“ Lösung ist ein Hardcode einer 3x3-Matrix von Gewinnkombinationen, die sich beispielsweise nur sehr schwer auf 10x10 erweitern lässt.

Wir haben auch auf benachbarte Repositories geachtet – coole Lieblingsprojekte waren ein Plus und eine Reihe von Testaufgaben anderer Unternehmen waren eher ein Weckruf: Warum konnte der Kandidat nicht dorthin gelangen?

Als Ergebnis fanden wir coole Optionen in React, Angular, Vanilla JS – es waren 29. Und wir beschlossen, einen weiteren Kandidaten ohne Test für seine sehr coolen Lieblingsprojekte einzuladen. Unsere Hypothese zum Nutzen von Testaufgaben wurde bestätigt.

Technisches Interview

Für die Firma: Es sind nicht die Mittel-/Senioren, die zu Ihnen gekommen sind! Wir brauchen einen individuelleren Ansatz.

Für Junioren: Denken Sie daran, dass es sich hierbei nicht um eine Prüfung handelt – versuchen Sie nicht, für eine Drei zu schweigen oder den Professor mit einem Strom all Ihres möglichen Wissens zu bombardieren, sodass er verwirrt ist und ein „sehr gut“ gibt.

Was wollen wir in einem technischen Interview verstehen? Eine einfache Sache – wie der Kandidat denkt. Er verfügt wahrscheinlich über einige Hard Skills, wenn er die ersten Stufen der Auswahl bestanden hat – es bleibt abzuwarten, ob er diese einzusetzen weiß. Wir haben uns auf 3 Aufgaben geeinigt.

Im ersten geht es um Algorithmen und Datenstrukturen. Mit einem Stift, auf einem Blatt Papier, in Pseudosprache und mithilfe von Zeichnungen haben wir herausgefunden, wie man einen Baum kopiert oder ein Element aus einer einfach verknüpften Liste entfernt. Die unangenehme Entdeckung war, dass nicht jeder Rekursion und die Funktionsweise von Referenzen versteht.

Die zweite ist Live-Codierung. Wir gingen nach codewars.com, wählte einfache Dinge wie das Sortieren einer Reihe von Wörtern nach dem letzten Buchstaben und versuchte 30-40 Minuten lang zusammen mit dem Kandidaten, alle Tests zu bestehen. Es schien, dass es keine Überraschungen seitens der Jungs geben sollte, die Tic-Tac-Toe beherrschten – aber in der Praxis war nicht jedem klar, dass der Wert in einer Variablen gespeichert werden sollte und die Funktion per Return etwas zurückgeben sollte. Obwohl ich aufrichtig hoffe, dass es eine Nervosität war und die Jungs diese Aufgaben unter leichteren Bedingungen bewältigen konnten.

Im dritten Teil schließlich geht es ein wenig um Architektur. Wir haben besprochen, wie man eine Suchleiste erstellt, wie Debounce funktioniert, wie man verschiedene Widgets in Suchtipps rendert und wie das Frontend mit dem Backend interagieren kann. Es gab viele interessante Lösungen, darunter serverseitiges Rendering und Web-Sockets.

Wir haben 21 Interviews mit diesem Design durchgeführt. Das Publikum war völlig vielfältig – schauen wir uns Comics an:

  1. "Rakete". Er lässt sich nie beruhigen, lässt sich auf alles ein und wird Sie während eines Vorstellungsgesprächs mit einem Gedankenstrom überwältigen, der nicht einmal direkt mit der gestellten Frage zusammenhängt. Wenn es an einer Universität wäre, wäre dies ein vertrauter Versuch, Ihr gesamtes Wissen zu demonstrieren, wenn Sie sich von dem Ticket, das Sie gefunden haben, nur daran erinnern, dass Sie sich gestern Abend entschieden haben, es nicht zu studieren – Sie können es immer noch nicht bekommen es raus.
  2. „Groot“. Es ist ziemlich schwierig, mit ihm in Kontakt zu treten, weil er Groot ist. Während eines Vorstellungsgesprächs muss man lange versuchen, Wort für Wort Antworten zu finden. Es ist gut, wenn es nur eine Benommenheit ist – sonst wird es für Sie im Arbeitsalltag sehr schwierig.
  3. „Drax“. Ich habe früher im Gütertransport gearbeitet und in Bezug auf die Programmierung habe ich JS nur auf Stackoverflow gelernt, daher verstehe ich nicht immer, was in einem Vorstellungsgespräch besprochen wird. Gleichzeitig ist er ein guter Mensch, hat die besten Absichten und möchte ein großartiger Front-End-Entwickler werden.
  4. Wir werden wahrscheinlich „Sternenlord“. Insgesamt ein guter Kandidat, mit dem Sie verhandeln und einen Dialog aufbauen können.

Am Ende unserer Recherche 7 Kandidaten erreichten das Finale und bestätigten ihre harten Fähigkeiten mit einer tollen Testaufgabe und guten Antworten auf das Interview.

Kulturelle Passform

Für die Firma: Du arbeitest mit ihm! Ist der Kandidat bereit, extrem hart für seine Entwicklung zu arbeiten? Wird er wirklich ins Team passen?

Für Junioren: Du arbeitest mit ihnen! Ist das Unternehmen wirklich bereit, in die Entwicklung von Nachwuchskräften zu investieren, oder wird es Ihnen einfach die ganze Drecksarbeit für ein niedriges Gehalt abwälzen?

Jeder Junior erhält zusätzlich zum Produktteam, dessen Leiter seiner Einstellung zustimmen muss, einen Mentor. Die Aufgabe des Mentors besteht darin, ihn durch einen dreimonatigen Prozess der Einarbeitung und Verbesserung seiner Hard Skills zu begleiten. Deshalb kamen wir als Mentoren zu jedem Cultural Fit und beantworteten die Frage: „Übernehme ich die Verantwortung für die Entwicklung eines Kandidaten in 3 Monaten gemäß unserem Plan?“

Diese Etappe verlief ohne Besonderheiten und brachte uns letztendlich 4 Angebote, 3 davon wurden angenommen und die Jungs traten in die Teams ein.

Leben nach dem Angebot

Für die Firma: Kümmere dich um deine Junioren, sonst tun es andere!

Für Junioren: AAAAAAAAAAA!!!

Wenn ein neuer Mitarbeiter herauskommt, muss er eingearbeitet werden – er muss mit den Prozessen auf den neuesten Stand gebracht werden, ihm wird erklärt, wie alles im Unternehmen und im Team funktioniert und wie er im Allgemeinen arbeiten soll. Wenn ein Junior herauskommt, müssen Sie verstehen, wie Sie ihn weiterentwickeln können.

Als wir darüber nachdachten, kamen wir auf eine Liste mit 26 Fähigkeiten, über die ein Junior unserer Meinung nach bis zum Ende der dreimonatigen Einarbeitungsphase verfügen sollte. Dazu gehörten Hard Skills (gemäß unserem Stack), Kenntnisse unserer Prozesse, Scrum, Infrastruktur und Projektarchitektur. Wir haben sie zu einer Roadmap zusammengefasst, verteilt auf 3 Monate.

Wie zähmt man einen Junior?

Hier ist zum Beispiel die Roadmap meines Juniors

Wir stellen jedem Junior einen Mentor zur Seite, der ihn individuell betreut. Abhängig vom Mentor und dem aktuellen Niveau des Kandidaten können die Treffen 1 bis 5 Mal pro Woche für 1 Stunde stattfinden. Mentoren sind ehrenamtliche Frontend-Entwickler, die mehr als nur Code schreiben möchten.

Ein Teil der Belastung für Mentoren wird durch die Kurse auf unserem Stack – Dart, Angular – verringert. Regelmäßig finden Kurse für Kleingruppen von 4-6 Personen statt, bei denen die Studierenden ohne Arbeitsunterbrechung lernen.

Über einen Zeitraum von 3 Monaten sammeln wir regelmäßig Feedback von Juniors, ihren Mentoren und Leads und passen den Prozess individuell an. Die aufgepumpten Fähigkeiten werden über den gesamten Zeitraum 1-2 Mal überprüft, derselbe Check erfolgt am Ende – darauf aufbauend werden Empfehlungen gebildet, was genau verbessert werden muss.

Abschluss

Für die Firma: Lohnt es sich, in Junioren zu investieren? Ja!

Für Junioren: Suchen Sie nach Unternehmen, die Kandidaten sorgfältig auswählen und wissen, wie man sie fördert

Innerhalb von drei Monaten haben wir 3 Fragebögen und 122 Testaufgaben überprüft und 54 technische Interviews durchgeführt. Dies brachte uns drei großartige Junioren, die nun die Hälfte ihrer Onboarding- und Beschleunigungs-Roadmaps abgeschlossen haben. Sie erledigen bereits echte Produktaufgaben in unserem Projekt, bei dem es allein im Frontend mehr als 21 Zeilen Code und mehr als 3 Repositories gibt.

Wir haben herausgefunden, dass der Trichter für Junioren ziemlich komplex sein kann und sollte, aber am Ende passieren ihn nur diejenigen Leute, die wirklich bereit sind, sehr hart zu arbeiten und in ihre Entwicklung zu investieren.

Jetzt besteht unsere Hauptaufgabe darin, dreimonatige Entwicklungs-Roadmaps für jeden Junior im Modus der individuellen Arbeit mit einem Mentor und allgemeinen Kursen zu erstellen und Metriken, Feedback von Leads, Mentoren und den Jungs selbst zu sammeln. An diesem Punkt kann das erste Experiment als abgeschlossen betrachtet werden, Schlussfolgerungen gezogen werden, der Prozess kann verbessert werden und es kann erneut mit der Auswahl neuer Kandidaten begonnen werden.

Source: habr.com

Kommentar hinzufügen