In einem früheren Artikel
über die Implementierung der Agile-Methodik in unserem Startup habe ich mich teilweise mit dem Thema Personalmanagement befasst. In diesem Artikel werde ich Ihnen erklären, wie wir diese Mitarbeiter einstellen, welche Klassifizierung wir verwenden, welche Tests und Methoden wir auf ihre Professionalität und Angemessenheit überprüfen.
Rekrutierungsmodell
Wie in jedem jungen Unternehmen begann unsere Arbeit im Bereich der Personalauswahl mit der Entwicklung eines Rekrutierungsmodells. Die Situation war wie folgt: Wir hatten bereits ein Team von „indigenen“ Mitarbeitern, die alle hochqualifiziert waren und in leitenden Positionen arbeiteten. Diese Leute mussten irgendwie entladen werden, das heißt, es bestand keine Notwendigkeit für Marktspezialisten, Kompetenz zu erlangen, daher war während der Zeit der aktiven Erweiterung des Personals die überwältigende Anzahl von freien Plätzen Positionen im Juni. Bevor wir offene Stellen auf Rekrutierungsseiten platzieren, haben wir uns entschlossen, unsere interne Klassifizierung nach dem Qualifikationsniveau und den Anforderungen für verschiedene Kategorien von Entwicklern zu erstellen.
Die folgende Klassifizierung wurde abgeleitet:
Level 0 - Fullzero-Entwickler, eine Person hat ein paar Kurse durchlaufen, die grundlegenden Konstruktionen und die Semantik einer bestimmten Sprache gelernt, mehrere Artikel über den Haber zu Hype-Themen gelesen, daher gibt es vom Programmierer einen maximalen Aufkleber auf dem Laptop.
Stufe 1 - Ein Junior-Entwickler, eine Person, die Code gut schreibt, Stapel gut kennt, aktuelle Trends kennt, weiß, wie man ein Problem zerlegt und es selbst löst.
Stufe 2 - Mittlerer Entwickler, eine Person besitzt alle oben aufgeführten Juniorqualitäten und kann auf der Grundlage einer Ressourcenanalyse ihre kompetente Meinung zu dem zu lösenden Problem äußern und den Verlauf seiner Implementierung im Rahmen der von ihr gewählten Toolchain beeinflussen.
Level 3 - ein leitender Entwickler, er ist auch ein Anführer, er ist ein Vater, ein Vater, eine Person, die Aufgaben von einer Business-Ebene in eine Entwicklungsebene umwandelt und projiziert, diese Aufgaben auf Mitte und Juni verteilt, kontrolliert und bei deren Implementierung hilft.
Zu dieser Klassifizierung wurden folgende Kriterien hinzugefügt: Kenntnis unserer Toolchain, Angemessenheit, Berufserfahrung von ca. 1-2 Jahren und mindestens ein erfolgreich umgesetztes Projekt, die Fähigkeit, Gedanken klar auszudrücken, das Vorhandensein von Kommunikationsfähigkeiten, die Fähigkeit, Fehler und Mängel zuzugeben (gesunde Selbstkritik - es ist ein mächtiges Werkzeug). Die Priorität für das Set wurde, wie oben erwähnt, den Nachwuchsentwicklern eingeräumt, da unsere Erfahrung im Umgang mit Mitten gezeigt hat, dass diese Leute in der Regel bereits durch eine Art Technologie-Stack und „einzigartige“ Ansätze anderer Unternehmen verwöhnt werden. Darüber hinaus hat die Praxis gezeigt, dass es eine große Anzahl von Menschen auf dem Markt gibt, die es gewohnt sind, in einer starren vertikalen Struktur zu leben, wo sie ein Material aus gekauten Aufgaben auf den Tisch bringen, das nur noch in Form eines Codes ausgefüllt werden muss, und die Aufgabe der Senioren ist es, die Pfosten mit einem Stock auf den Kopf zu schlagen . Aber die Sache ist, dass, wenn die Aktion in einem jungen Startup stattfindet und das Team nur etwa dreißig Personen hat, von denen jede unter einen vollen Tank geladen ist, keine Zeit für eine persönliche Zersetzung für jeden Mitarbeiter bleibt, da dies gleichbedeutend mit der Erfüllung dieser Aufgabe ist. Unter solchen Bedingungen müssen beim Schreiben von Code etwa zehn Prozent der gesamten Ausführungszeit der Aufgabe nicht nur die Finger, sondern auch der Kopf einbezogen werden. Genau das steht in der "Bibel" aller Programmierer - Stephen McConnell "Ideal Code" alias Redbook (nicht zu verwechseln mit dem amerikanischen Frauenmagazin).
Und dann bedeckte uns eine Welle ...
Wer auch immer uns nicht betreten hat, angefangen bei Charakteren, die glauben, dass sie in der Mitte sind, weil sie eine komplette Anwendung auf Android geschrieben haben, die bis zu 37 Downloads bei Google Play hat Einige Studios, obwohl ihre Arbeit im Großen und Ganzen auf die Übertragung von Aufgaben von der Designabteilung auf die Entwicklungsabteilung beschränkt war, das heißt, sie hatten keine Erfahrung im Entwerfen oder Verwalten der Entwicklung, aber es gab nur viel Ehrgeiz und viel Ehrgeiz . Es gab auch diejenigen, die sich mit sieben Monaten Programmiererfahrung als Senioren betrachteten und ein Gehalt von 240.000 verlangten, während sie nicht einmal elementare Aufgaben für Junioren lösten. Aus unserer Sicht waren diese Leute nicht einmal Joons. Der Ansatz ist einfach: Wenn eine Person direkt aus dem Herzen programmiert, ist sie nur ein Programmierer, aber wenn eine Person schlecht programmiert oder überhaupt nicht zieht, ist sie kein Junior, sie ist einfach kein Programmierer. Hier hat uns ein wunderbarer Live-Hack geholfen, solche Kandidaten auszuschalten. Er heißt „Sanitärgesetz“ und lautet: „Jeder neue Klempner, der an einem neuen Arbeitsplatz ankommt, schüttet Schlamm auf einen anderen Klempner und sagt, dass er einen Kolbenarm hat und dass jetzt alles getan werden muss Null. " In der Praxis funktioniert das ungefähr so: Der Bewerber kommt in die Junior-Position, gibt ihm einen vorgefertigten Code, zum Beispiel ein Fragment des Linux-Kernels, und fragt, was er von dieser Entscheidung hält. Wenn er anfängt zu spucken und etwas sagt wie: „Was für ein Handschreiber hat das geschrieben? Hier muss alles erneuert werden! Geben Sie mir Zeit, und ich schreibe alles noch einmal “, so dass der Klempner vor Ihnen steht und seine erste Priorität darin besteht, den vorherigen Klempner zu schelten.
Michelangelo sagte bei dieser Gelegenheit: "Ich nehme einen Stein, schneide alles Unnötige ab." Der große Meister schrieb keine Skripte, aber er verstand gut, dass sich eine kompetente Person dem Arbeitsgegenstand mit dem Wunsch nähert, es zu verstehen und gegebenenfalls umzuwandeln, aber nicht zu zerstören und in Staub umzuwandeln. Das heißt, wenn eine Person solche Fragen beantwortet: "Wenn der Code in der Produktion funktioniert und seine Funktionen ausführt, ist das gut. Ich denke, Sie können diesen Code an einigen Stellen verbessern, wenn nötig, ich kann ihn zeigen." Dann können und sollten Sie mit einer solchen Person den Dialog fortsetzen .
Eine andere Technik zum Definieren von Jones mit geringen Fähigkeiten besteht darin, sich auf Hype und Hype-Stacks zu konzentrieren. Wenn eine Person zu einem Interview kommt und anfängt, Trendansätze zu gießen, und zu der berechtigten Frage: „Wie sind Sie zu diesem Schluss gekommen und haben Sie diese Tools analysiert?“ - Er verzieht das Gesicht angesichts der Grimasse, die die Erleuchtung des Senioren erreicht hat, und antwortet: „Sie können alles darauf schreiben, die Zukunft steckt dahinter!“ Dann steht Ihnen bestenfalls ein schwacher Junior gegenüber, der keine Analyse von Ressourcen, Stapeln und anderen Werkzeugketten hat, sondern nur oberflächliche Informationen Hype-Tools und Ansätze.
Ein bisschen mehr über das Interview
Darüber hinaus ist es bei der Einstellung eines Programmierers sehr wichtig, von ihm eine offene Position zu seinem Wissen in einem bestimmten Stapel zu erhalten. Sie entscheiden sich für den Stapel und er wählt die Sprache, in der er "wai wai wai wie stark" ist. Nehmen wir an, er ist ein Highlander von JavaScript. Es gibt eine vorgefertigte Reihe von Aufgaben, zum Beispiel:
setTimeout(()=>{console.log('Hello World!')}, 1000); while (true) { let a = false; };
Wenn die Frage zu dieser Aufgabe lautet: "Wann wird Hello World!" Angezeigt ? ", Stottert er im Stil der Antwort:" Nun ... ähm ... schau ... nachdem er die while-wahre Schleife abgeschlossen hat oder nach einer Sekunde "- das bedeutet, dass er den Stapel absolut nicht kennt, über seine Fähigkeiten lügt, die höchstwahrscheinlich nahe sind auf Null. Tatsache ist, dass das while-Konstrukt den Präprozessor lädt, und da JS Single-Threaded ist, gibt die Hauptschleife niemals ein Ereignis von einem Timer aus. Das heißt, Die richtige Antwort ist nie.
Wenn eine Person nicht bereit ist, ihr Wissen angemessen und ehrlich zu bewerten, den Code einer anderen Person nicht lesen kann, kann über die Art der Arbeit in einem Team gesprochen werden. Wenn sich eine Person nicht als „Klempner“ erweist und die Aufgaben bewältigt, ihr Wissen über den Stapel bestätigt oder die Aufgabe, ihre Fehler und teilweise Inkompetenz konstruktiv beurteilt, besteht die Möglichkeit, dass sie Ihr neuer Mitarbeiter wird und in Zukunft wachsen kann Seite höherer Klassifikationsstufen.
Es gibt Zeiten, in denen eine Person mit der internen Klassifizierung des Unternehmens nicht einverstanden ist und negativ auf die Aussage reagiert, dass sie nicht in der Mitte oder sogar im Juni zieht und dass ihre Entscheidung nicht funktioniert. In diesem Fall können Sie, wenn er weiterhin darauf besteht, das Prinzip anwenden und seine Lösung in der Umgebung ausführen. Natürlich stellt sich heraus, dass dieses Design nicht funktionsfähig ist, dh, die Person hat es vermasselt. Dann kann er beginnen, die Autorität seiner früheren Arbeit zu zerstören. Zum Beispiel gab es Fälle, in denen eine Person nach einem solchen Versagen angab, ein sehr wertvoller Mitarbeiter einer großen Bank zu sein und dort sehr geschätzt zu werden. In Wirklichkeit stellte sich heraus, dass weitere zwölftausend Menschen wie er in dieser Bank arbeiteten und die Personalabteilung seine Inkompetenz einfach übersah. Nachdem er etwa ein Jahr dort verbracht hatte, erklärte er nun seinen Status als Spezialist. Und hier, wo es ein Team von ungefähr zwanzig Programmierern gibt, von denen jeder mit seinem eigenen Geschäft vertraut ist, geht er einfach verloren und kann nicht mehr nach dem alten Schema arbeiten. Unser CEO, Ilya Bykonya, sagt dazu: "Für mich wie für den derzeitigen Entwickler und Gründer des Unternehmens ist eine Autorität die Fähigkeit der Person, und wo sie gearbeitet hat und welche Position sie hatte, ist von untergeordneter Bedeutung."
Zusammenfassend
Möglicherweise liegt ein Fehler in unserem Ansatz zur Bewertung von Bewerbern vor. Und die Tatsache, dass wir ihn „im Rang senken“ und sagen, dass er nicht in der Mitte ist, sondern im Juni oder noch schlimmer, spielt einen grausamen Witz mit uns. Vielleicht verlieren wir die zukünftigen Napoleons wie das russische Reich auf einmal? Wer weiß ... Aber aus unserer Sicht ist eine solche Strategie durch ihre Wirksamkeit völlig gerechtfertigt, und am Ende verlor Napoleon immer noch den Krieg des russischen Reiches.