{"id":36985,"date":"2019-10-31T22:15:09","date_gmt":"2019-10-31T19:15:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-priruchit-dzhuniora\/"},"modified":"2019-10-31T22:15:09","modified_gmt":"2019-10-31T19:15:09","slug":"kak-priruchit-dzhuniora","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/kak-priruchit-dzhuniora","title":{"rendered":"Wie man einen Junior reizt?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wie findet man einen Einstieg in ein gro\u00dfes Unternehmen, wenn man ein Junior ist? Wie stellt man einen qualifizierten Junior ein, wenn man ein gro\u00dfes 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\u00fcr die Entwicklung und Einarbeitung von Neueinsteigern aufgebaut haben und warum Standardfragen f\u00fcr Vorstellungsgespr\u00e4che nicht funktionieren.<\/p>\n

\"Wie
\nIch versuche, einen Junior zu reizen<\/i>
\n<\/a><\/noindex>
\nHallo! Ich hei\u00dfe Pavel, ich arbeite im Frontend-Team von Wrike. Wir entwickeln ein Projektmanagement- und Kollaborationstool. Ich besch\u00e4ftige mich seit 2010 mit Webtechnologien, habe 3 Jahre im internationalen Remote-Bereich gearbeitet, an mehreren Startups teilgenommen und einen Kurs \u00fcber Webtechnologien an der Universit\u00e4t gehalten. In unserem Unternehmen bin ich an der Entwicklung technischer Schulungen und des Mentorenprogramms f\u00fcr Junioren beteiligt und k\u00fcmmere mich direkt um deren Rekrutierung.<\/p>\n

Warum haben wir \u00fcberhaupt \u00fcber die Einstellung von Junioren nachgedacht?<\/h3>\n

\nBis vor kurzem haben wir Frontend-Entwickler auf dem Niveau Middle oder Senior eingestellt \u2013 also solche, die nach der Einarbeitungszeit eigenst\u00e4ndig Produktaufgaben \u00fcbernehmen k\u00f6nnen. Zu Beginn dieses Jahres haben wir erkannt, dass wir diese Strategie \u00e4ndern m\u00f6chten: Im Laufe eines Jahres hat sich die Zahl unserer Produktteams fast verdoppelt, die Anzahl der Frontend-Entwickler n\u00e4hert sich der hundert und wird sich voraussichtlich bald erneut verdoppeln. Die Aufgaben sind vielf\u00e4ltig, die verf\u00fcgbaren H\u00e4nde 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.<\/p>\n

Wer ist ein Junior?<\/h3>\n

\nDas ist die erste Frage, die wir uns gestellt haben. Es gibt verschiedene Kriterien, aber das einfachste und verst\u00e4ndlichste Prinzip lautet:<\/p>\n

Ein Junior ben\u00f6tigt eine Erkl\u00e4rung, welche Funktion und wie sie umgesetzt werden soll. Ein Middle-Entwickler muss lediglich wissen, welche Funktion ben\u00f6tigt wird, und er wird selbst\u00e4ndig die Implementierung \u00fcbernehmen. Ein Senior hingegen erkl\u00e4rt dir selbst, warum diese Funktion \u00fcberhaupt nicht notwendig ist.<\/p><\/blockquote>\n

So oder so ist ein Junior ein Entwickler, der Rat ben\u00f6tigt, wie eine bestimmte L\u00f6sung umgesetzt werden soll. Darauf haben wir uns gest\u00fctzt:<\/p>\n

    \n
  1. Ein Junior ist jemand, der sich entwickeln m\u00f6chte und bereit ist, daf\u00fcr hart zu arbeiten;<\/li>\n
  2. Er wei\u00df nicht immer, in welche Richtung er sich entwickeln m\u00f6chte;<\/li>\n
  3. Braucht Rat und sucht Hilfe von au\u00dfen \u2013 sei es bei seinem Teamleiter, Mentor oder in der Community.<\/li>\n<\/ol>\n

    \nWir hatten au\u00dferdem einige Hypothesen:<\/p>\n

      \n
    1. Auf die Junior-Position wird ein Sturm von Bewerbungen eintreffen<\/i>. Man muss zuf\u00e4llige Bewerbungen bereits beim Versand des Lebenslaufs filtern;<\/li>\n
    2. Der erste Filter wird nicht helfen<\/i> \u2013 es sind auch zus\u00e4tzliche Tests erforderlich;<\/li>\n
    3. Tests schrecken alle ab<\/i> \u2013 sie sind nicht n\u00f6tig.<\/li>\n<\/ol>\n

      \nUnd nat\u00fcrlich hatten wir das Ziel: 4 Juniors in 3 Wochen<\/b>.<\/p>\n

      Mit diesem Bewusstsein begannen wir zu experimentieren. Der Plan war einfach: mit einem m\u00f6glichst 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.<\/p>\n

      Wir schalten die Stelle<\/h3>\n

      <\/p>\n

      F\u00fcr das Unternehmen<\/b>: Es werden Hunderte von Bewerbungen kommen! Denken Sie an die Filter.<\/p>\n

      F\u00fcr den Junior<\/b>: Haben Sie keine Angst vor einem Fragebogen vor dem Versand des Lebenslaufs und der Testaufgaben \u2013 das ist ein Zeichen daf\u00fcr, dass sich das Unternehmen um Sie k\u00fcmmert und den Prozess gut gestaltet hat.\n<\/p><\/blockquote>\n

      \nAm ersten Tag erhielten wir etwa 70 Lebensl\u00e4ufe von Kandidaten mit \"JavaScript-Kenntnissen\". Und es kamen immer mehr. Wir konnten physisch nicht alle zu einem Interview ins B\u00fcro einladen und w\u00e4hlten die Kandidaten mit den besten pers\u00f6nlichen Projekten, einem aktiven GitHub-Profil oder zumindest etwas Erfahrung aus. <\/p>\n

      Die wichtigste Erkenntnis, die wir am ersten Tag gewonnen haben, ist, dass der Sturm begonnen hat. Es war an der Zeit, ein Formular f\u00fcr die Bewerbung vor dem Einreichen des Lebenslaufs einzuf\u00fchren. Ziel war es, Kandidaten auszusondern, die nicht bereit sind, minimale Anstrengungen f\u00fcr die Einreichung ihres Lebenslaufs zu unternehmen, sowie diejenigen, die nicht \u00fcber das Wissen und den Kontext verf\u00fcgen, um zumindest die richtigen Antworten zu googeln. <\/p>\n

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

      In jeder Kategorie haben wir 3-5 Fragen vorbereitet und t\u00e4glich die Auswahl in unserem Feedback-Formular angepasst, bis wir die einfachsten und die kompliziertesten ausgeschlossen haben. Dadurch konnten wir den Zulauf reduzieren \u2013 in 3 Wochen haben wir erhalten 122 Kandidaten<\/b>, 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 \u00e4ndern wollten und unterschiedlich viel Energie in Selbstbildung, Kurse und Praktika investierten.<\/p>\n

      Lernen Sie uns n\u00e4her kennen<\/h3>\n

      <\/p>\n

      F\u00fcr das Unternehmen<\/b>: Die Testaufgabe schreckt die Kandidaten nicht ab, sondern hilft, den Auswahlprozess zu verk\u00fcrzen.<\/p>\n

      F\u00fcr den Junior<\/b>: Kopieren Sie keine Testaufgaben \u2013 das f\u00e4llt auf. Und halten Sie Ihr GitHub aufger\u00e4umt!\n<\/p><\/blockquote>\n

      Wenn wir alle zu technischen Interviews eingeladen h\u00e4tten, m\u00fcssten wir etwa 40 Interviews pro Woche nur f\u00fcr Junioren und nur f\u00fcr den Frontend-Bereich f\u00fchren. Deshalb haben wir beschlossen, die zweite Hypothese \u2013 hinsichtlich der Testaufgabe \u2013 zu \u00fcberpr\u00fcfen.<\/p>\n

      Was uns bei der Testaufgabe wichtig war:<\/p>\n

        \n
      1. Eine gute, skalierbare Architektur aufzubauen, aber ohne Overengineering;<\/li>\n
      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\".<\/li>\n
      3. Die Geschichte der Entwicklung in Git ist eine Ingenieurskultur, iterative Entwicklung und die Tatsache, dass die L\u00f6sung nicht v\u00f6llig dreist kopiert wurde.<\/li>\n<\/ol>\n

        \nWir haben uns darauf geeinigt, eine algorithmische Aufgabe und eine kleine Webanwendung zu betrachten. Die Algorithmen waren auf dem Niveau von Laborarbeiten der ersten Studieng\u00e4nge vorbereitet \u2013 bin\u00e4re Suche, Sortierung, \u00dcberpr\u00fcfung auf Anagramme, Arbeiten mit Listen und B\u00e4umen. Letztendlich haben wir uns f\u00fcr die bin\u00e4re Suche als ersten Testfall entschieden. Die Webanwendung sollte ein Spiel von X und O mit der Verwendung eines beliebigen Frameworks (oder ohne) sein.<\/p>\n

        Fast die H\u00e4lfte der verbleibenden Kandidaten hat die Testaufgabe erfolgreich bestanden \u2013 uns wurden L\u00f6sungen zugeschickt. 54 Kandidaten<\/b>. Eine unglaubliche Erkenntnis \u2013 wie viele Implementierungen von X und O, die zum Kopieren bereit sind, gibt es wohl im Internet? <\/p>\n

        Wie viele?<\/b>Tats\u00e4chlich scheint es nur 3 zu geben. Und in der \u00fcberwiegenden Mehrheit der L\u00f6sungen gab es genau diese 3 Varianten.
        \nWas nicht gefallen hat:<\/p>\n