Das war aber nicht immer so. 2015 bekam ich einen Job als erstklassiger Softwareentwickler. Und vergebens. Ich war ein echter Betrüger. Aber meine mageren technischen Fähigkeiten haben mich nicht davon abgehalten, am Ende auf den zweiten Rang befördert zu werden. Ich möchte meine Geschichte teilen, um anderen Betrügern zu helfen, in FAANG-Unternehmen erfolgreich zu sein - na ja, oder in anderen.
Wie ich mich in Amazon eingeschlichen habe
Ich bewundere die Menschen, die es geschafft haben, den gesamten Auswahlzyklus bei einem der FAANG-Unternehmen zu durchlaufen. Dies ist eine Reihe von Interviews von morgens bis abends, bei denen der Kandidat von fünf verschiedenen Mitarbeitern des Unternehmens nach technischem Wissen und persönlichen Qualitäten befragt wird. Um diese Prüfung zu bestehen, müssen Sie Hunderte von Stunden damit verbringen, komplexe Datenstrukturen und Algorithmen vorzubereiten, gründlich zu studieren und Probleme monatelang zu lösen. All dies erfordert ebenso viel Geduld, Entschlossenheit und Beharrlichkeit wie die Veröffentlichung eines Buches.
Mein Weg ging um all diese Schwierigkeiten herum. 2014 führte Amazon auf dem Campus Vorstellungsgespräche für Sommerpraktikanten durch. Einige meiner Kommilitonen gingen vor mir dorthin. Sie alle kamen mit Geschichten über rätselhafte Programmierfragen zurück, die ihnen gestellt worden waren.
Ich hatte vier Prüfungen in dieser Woche und schlief durchschnittlich vier Stunden am Tag. Ich habe es geschafft, drei Stunden für die Vorbereitung herauszuarbeiten. Es gab zwei Interviews. Die Programmierfragen, die ich bekam, sind unglaublich einfach. Bei einem ging es um Bitmanipulation, bei dem anderen um die Verwendung verknüpfter Listen, und ich musste auch über Hash-Tabellen sprechen. Das ist alles. Ich hatte einfach Glück.
Praktikanten bei Amazon erhalten, wenn sie gut abschneiden, ein Angebot, zu einem Vollzeitentwickler mit dem ersten Einstiegsrang zu wechseln. Sie müssen keine Interviews wiederholen. Ich habe mein Praktikum in Seattle gemacht und eine Ruby on Rails-Site von Grund auf neu gestaltet. Erhielt ein Angebot und begann 2015 als Softwareentwickler in Virginia.
Über die Knappheit meines Wissens
Entwickler mit Rang 1 sollten mit fortgeschrittenen Datenstrukturen vertraut sein: Heaps, Diagramme, Präfixbäume. Ich wusste nicht einmal die Bedeutung dieser Wörter. Entwickler mit Rang 1 sollten in der Lage sein, die zeitliche und räumliche Komplexität von Algorithmen zum Sortieren, Suchen, Einfügen und Aufteilen abzuschätzen. Ich würde Ihnen nicht die zeitliche Komplexität einer banalen Tiefensuche in einem Binärbaum sagen.
Warum hatte ich so viele Wissenslücken? Es gab zwei Gründe.
Zunächst habe ich Informatik studiert, nicht Informatik. Der Schwerpunkt lag eher auf der Integration von Software und Hardware als auf der Entwicklung großer Systeme. Diese Orientierung lehrte mich, komplexe Probleme unter zweifelhaften Bedingungen zu lösen, aber das Programm bot überhaupt keine detaillierte Analyse von Datenstrukturen und Algorithmen. Zweitens habe ich keinen vollständigen Vorbereitungsprozess durchlaufen, ich habe nicht Hunderte von Stunden mit Lernen verbracht - deshalb habe ich nicht gelernt.
Mir selbst wurde klar, dass ich nicht mithalten konnte. Das Betrugssyndrom quälte mich zunächst mit schrecklicher Gewalt.
Erste Pfannkuchen
Jede Code-Inspektion war eine Katastrophe. Ich habe ein Snippet zur Überprüfung eingereicht (z. B. in Form einer Änderungsanforderung), das mir mit achtzig Kommentaren zurückgesandt wurde. Das geht nicht. Ich habe korrigiert und eine neue Version eingereicht. Noch fünfzig Kommentare. Das geht nicht. Und so weiter und so fort.
Bei einigen Fragmenten waren die Dinge so schlecht, dass Kollegen einfach nicht wussten, wie sie das Wesentliche des Problems erklären sollten, damit ich es verstehen konnte. Sie mussten den Code herunterladen und neu schreiben. Sie wollten mir helfen und waren sehr freundlich, aber ich brannte buchstäblich vor Scham aus. Ich lebte in der Angst, dass die Leute verstehen würden: Ich gehöre nicht hierher. Kein einziger Arbeitstag verging ohne den Gedanken, dass ich heute entlassen würde.
Den Betrüger bloßstellen
Nach und nach zog ich mich hoch. Schließlich fing ich an, die Fristen einzuhalten und den Code konsequent an die Produktion weiterzugeben. Ungefähr neun Monate später entwickelte ich Selbstvertrauen. Ich entschied, dass es Zeit war, das Betrugssyndrom ein für alle Mal loszuwerden. Ich wandte mich Problemen mit LeetCode zu, um mir selbst zu beweisen, dass ich an meiner Stelle war. Ich erinnere mich, dass ich gedacht habe: „Ich bin jetzt ein vollwertiger Entwickler bei Amazon. Ich habe Verpflichtungen in der Produktion. Warum kann ich diese einfachen Aufgaben nicht bewältigen? "
Ich habe mich für eine der einfachen Optionen in LeetCode entschieden - und konnte sie nicht lösen. Ich habe mich für einen anderen entschieden - und ich konnte es auch nicht. Und der dritte und der vierte. Dann wurde mir klar, dass ich an keinem Syndrom litt. Ich bin ein Betrüger.
Sei, scheine nicht zu sein
Nach zweieinhalb Jahren wurde ich zu einem Entwickler der zweiten Stufe befördert. Ein Entwickler des zweiten Ranges kann mit minimaler Unterstützung von außen selbst ein großes System erstellen und warten. Wie habe ich das gemacht? Wie habe ich es geschafft, die Spielregeln zu meinen Gunsten neu zu interpretieren?
Nun ... auf keinen Fall. Bei Amazon funktionieren Shenanigans nicht. Das System kann nicht wiedergegeben werden. "Gib vor, ein Spezialist zu sein, bis du Erfolg hast" ist ein sehr häufiger und sehr schlechter Rat. Das funktioniert nicht. Die einzige Möglichkeit, sich zum Tier 2-Entwickler zu ernennen, besteht darin, Tier 2-Entwickler zu werden.
Beförderung ist ein anstrengender Prozess. Sie müssen Ihre Verdienste und Erfolge auf mehr als zwanzig Seiten Dokumentation beschreiben, so dass Kollegen und Chefs glauben. Sie müssen ständig Kennzahlen sammeln und nachweisen, dass Ihr Erfolg auf einem höheren Niveau liegt. Sie können nur dann mit einer Erhöhung rechnen, wenn Sie die Messlatte der nächsten Stufe sechs Monate oder sogar ein ganzes Jahr lang konstant halten.
Sie haben wahrscheinlich den Satz gehört: "Unsere Persönlichkeit besteht aus dem, was wir regelmäßig tun." Im Folgenden werde ich Ihnen sagen, welche Maßnahmen ich ergriffen habe, um nicht länger Betrüger zu sein und mich als übergeordneter Entwickler zu etablieren.
Was habe ich getan
Um die Akzeptanz von Rückmeldungen zu maximieren , haben FAANG-Neulinge häufig ihr Ego aufgeblasen. Dies beraubt sie der Fähigkeit, konstruktive Kritik von Kollegen zu akzeptieren und zu berücksichtigen. Aber diese Kollegen sind kluge Leute, von denen jeder seine eigene Erfahrung im Bereich der IT hinter sich hat.
Ich hatte keine Probleme mit dem Selbstwertgefühl. Auf freundschaftliche Weise hatte ich nichts mit der Firma zu tun. Als ich Feedback erhielt, hörte ich zu und hörte nachdenklich zu.
Die Äußerungen der Kollegen waren wahr, kontrovers oder falsch. Wenn die Bemerkung richtig war, folgte ich dem Rat ohne Vorbehalt. Wenn es um etwas Kontroverses ging, versuchte ich zuerst, den Standpunkt eines anderen Entwicklers zu verstehen und erst dann - meinen eigenen zu vermitteln. Und plötzlich hörte ich sogar die falschen Bemerkungen.
In diesem Fall lautete der Gedankengang: "Warum bin ich sicher, dass ich Recht habe? Was hat eine Person zu einer solchen Idee geführt? Kann ich irgendwie klarstellen, dass eine solche Reaktion nicht auftritt? " Das nenne ich maximale Offenheit. Kluge Leute gehen, selbst wenn sie sich irren, in ihren Schlussfolgerungen von etwas aus. Ich habe herausgefunden, woraus es besteht, und meinen Code unter Berücksichtigung dieser Informationen verbessert.
Dumme Fragen gestellt
Neulinge in FAANG-Unternehmen versuchen oft, keine Fragen zu stellen - sie haben Angst, dass sie schlecht gedacht werden. Dieses Element des Betrüger-Syndroms besteht paradoxerweise neben einer aufgeblasenen Einbildung. Nun, ich als wahrer Betrüger habe vollkommen verstanden, dass meine Fragen dumm waren. Es hat mich nicht gestört.
Zum Beispiel:
« , . , ?»
« , ?»
« , . - ?»
Sehr bald bekam ich Hunderte von Lesezeichen, sammelte Tonnen zusätzlicher Informationen und wurde sehr erfolgreich bei der Teilnahme an Meetings.
Den Restless Code Inspector gefunden
Zunächst ist es sehr wichtig, dass möglichst viele andere Entwickler Ihren Code überprüfen. Jeder Mitarbeiter, der eine Inspektion durchführt, hat seine eigenen Vorlieben, nörgelnde, tierische Ärmel. Umso wichtiger ist es, den unruhigen Inspektor herauszufinden.
In jedem Team gibt es einen. Sein Job ist nie zufrieden. Es klammert sich an den Namen jeder Variablen, jedes Protokolls, jedes ausgewählten API-Parameters. Ich habe mich besonders bemüht, diese Person zu finden und ihnen meinen Code so oft wie möglich zuzuwerfen. Warum? Weil ich verstanden habe: Je konstruktiver Kommentare ich erhalte, desto schneller wird das Training.
Verwendete vorhandene Designs, um Fehler zu vermeiden
Junioren versuchen oft, das Rad neu zu erfinden. Die meisten Entwicklungsaufgaben sind nichts Neues. Bevor ich anfing, den angeforderten Code zu schreiben, suchte ich nach ähnlichen Lösungen für interne Ressourcen. Ich habe verschiedene Beispiele durchgesehen und untersucht, wie der Code darin strukturiert ist. Dann wandte ich mich dem Code meines Teams zu und fand heraus, wie ich das neue Fragment am besten an das Gesamtsystem binden kann.
Ich habe den gleichen Ansatz gewählt, als ich Konstruktionsdokumentation und Obduktionsberichte geschrieben habe. Zuerst Proben, dann Aktionen.
Konzentriert auf Korrektheit und Angemessenheit
Ich habe die versunkene Kostenfalle vermieden. Wenn ich etwas falsch mache, spielt es keine Rolle, dass ich bereits vier Stunden damit verbracht habe. Ich wusste, dass ich das, was ich entwickelt hatte, beiseite schieben und es auf die richtige Weise wiederholen musste.
Für hundert Codezeilen, die zur Inspektion geschickt wurden, gab es 250 Zeilen Müll, die ich geschrieben und weggeworfen habe. Ich habe versucht sicherzustellen, dass jede dieser hundert Zeilen verständlich, zielgerichtet geschrieben und für etwas benötigt wird. Jetzt erhält mein Code normalerweise nach ein oder zwei Überarbeitungen grünes Licht.
Sich in die Hitze stürzen
Sie werden sich nie "bereit" fühlen, an Schlüsselfunktionen zu arbeiten, Projekte für die Produktion bereitzustellen, Interviews durchzuführen und Notfälle zu beseitigen. Der beste Weg, sich auf all das vorzubereiten, ist es, es zu nehmen und es zu tun.
Bei der ersten Gelegenheit sagte ich einfach zu meinem Chef: Ich bin bereit. Auch wenn ich vorher nicht die Gelegenheit hatte, die Handlungen anderer im Detail zu beobachten, wie es normalerweise empfohlen wird. Manchmal musste ich um Hilfe bitten oder jemanden von meinen Kollegen, um meiner Arbeit zu folgen. Aber letztendlich konnte ich meine Komfortzone erweitern und mein Wachstum beschleunigen. Ich
ergriff die Initiative in den kleinen Dingen und
bemerkte Möglichkeiten, die operative Exzellenz des Teams, die Arbeitsprozesse und die Entwicklungserfahrung zu verbessern. Mehr als ein- oder zweimal habe ich freiwillig langweilige Aufgaben übernommen: Ich habe manuell durchgeführte Vorgänge automatisiert, die Dokumentation fertiggestellt, die CI / CD-Pipeline verbessert und den Legacy-Code überarbeitet.
Ich habe versucht, professionell zu sein
Programmieren ist eine Art von Kreativität, die auf Logik basiert. Jede Aufgabe, jede neue Funktion habe ich als leeres Blatt wahrgenommen, auf dem Sie Ihre Fähigkeiten unter Beweis stellen und die Schöpfung verlassen können.
Der Entwickler der zweiten Stufe muss laut Stephen Pressfield, Autor von The War of Art, ein Softwareentwickler oder ein Fachmann sein. Ich habe alle meine Anstrengungen darauf verwendet, sauberen Code zu schreiben (Sie sollten auf jeden Fall das gleichnamige Buch lesen) und schöne, elegante Lösungen zu schaffen.
Er hat deutlich seinen Wunsch nach einer Erhöhung
bekundet. In FAANG-Unternehmen bietet niemand eine Erhöhung an - Sie fragen sie selbst und mehr als einmal. Wenn dies nicht getan wird, wird der Prozess viele Monate dauern.
In privaten Gesprächen mit dem Chef machte ich deutlich, dass ich befördert werden wollte. Ich bat um Feedback, um zu verstehen, welche Bereiche durchhängen. Ich habe die Ergebnisse der abgeschlossenen Arbeit objektiv bewertet und Kritik akzeptiert, wenn es um mich ging. Ich suchte nach Möglichkeiten, meine Fähigkeiten zu verbessern und die Lücken zu schließen. Wenn ich einige Fähigkeiten unter Beweis stellen konnte, habe ich versucht, das Feedback schriftlich zu halten. Schließlich können Sie nicht vorhersagen, wann die nächste Umstrukturierung stattfinden wird und Ihr Chef sich ändern wird.
Den Job für die Beförderung vor den anderen stellen
Ich habe verstanden: Sie können nicht nur und ausschließlich für die Werbung arbeiten. Wenn jeder dies tut, wird die Teamatmosphäre definitiv für das Leben ungeeignet. Gleichzeitig habe ich buchstäblich die Aufgaben gestellt, die ich für die Beförderung brauchte.
Das heißt, wenn ich mich auf eine wichtige Funktion konzentrieren musste, deren Fristen eng waren, übernahm ich sie vom ersten Morgen an. Auf diese Weise konnte ich sicher sein, dass ich genug Zeit hatte, um die Arbeit gut zu machen. Wenn ich eine aktivere Code-Inspektion durchführen musste, wurden die Morgenstunden dafür aufgewendet. Wenn ich öfter an Interviews teilnehmen musste, begann ich meinen Arbeitstag mit der Anmeldung für die kommenden.
Ständig Beweise für meinen Erfolg sammeln
Auf die Fähigkeit, seine Leistungen durch eine Kombination von quantitativen und qualitativen Indikatoren darzustellen, kann man nicht verzichten.
Bevor ich die Aufgabe zur Arbeit nahm, suchte ich nach Metriken, die den aktuellen Status des Systems darstellten. Nach Abschluss der Arbeiten habe ich mir die neuen Indikatoren angesehen und Berechnungen durchgeführt, um zu verstehen, inwieweit meine Handlungen die Situation beeinflusst haben. Und schließlich habe ich alles, was mit der Aufgabe zu tun hat, in der Dokumentation festgehalten, die als Rechtfertigung für die Erhöhung dienen sollte: STAR-Analyse, quantitative Indikatoren, Links zu Code-Inspektionsergebnissen, Grafiken und andere Relikte der Arbeit.
Mir wurde klar, was von mir abhängt und was nicht
Ich habe verstanden, dass alles passieren kann. Manchmal fehlen einem Team wichtige Funktionen. Manchmal werden Projekte geschlossen. Manchmal ändert sich das Management aufgrund von Umstrukturierungen. Manchmal ist die CI / CD-Pipeline bereits perfekt und es gibt einfach nichts zu verbessern.
Gleichzeitig wurde mir klar, dass ich, wenn ich mich darauf konzentriere, an die Grenzen der Möglichkeiten zu arbeiten und Aufgaben professionell anzugehen, für den Moment bereit bin, in dem sich die Gelegenheit bietet, mich zu zeigen. Die Gelegenheit ergab sich - er zeigte sich als Profi. Dies brachte ein paar weitere Möglichkeiten mit sich - wieder habe ich alles auf dem Level gemacht. Usw.
Reflexionen
Schädigt die im Einstellungsprozess entwickelte „Leetcode-Kultur“ das Geschäft?
Ich habe es geschafft, erfolgreich bei Amazon Fuß zu fassen, obwohl mir Aufgaben mit Leetcode bei meiner Ankunft zu schwer fielen. Als ich dann selbst anfing, Interviews zu führen, zerlegte ich natürlich gezielt alle notwendigen Algorithmen und Datenstrukturen, um die Antworten der Kandidaten bewerten zu können.
Ich denke, der aktuelle Ansatz zahlt sich aus. Unternehmen interessieren sich für Menschen, die die Ausdauer und Motivation haben, neue Dinge zu lernen und diese Informationen in Verbindung mit vorhandenen Fähigkeiten zu nutzen. Die etablierten Prozesse leisten gute Arbeit bei der Auswahl solcher Personen.
Es ist also einfacher, durch ein Praktikum in die Rang 1 der Entwickler einzusteigen?
Das würde ich nicht sagen. Diese beiden Interviews sind für Praktikanten normalerweise nicht einfacher als fünf Interviews für Vollzeitbeschäftigte. Als ich 2014 ein Interview führte, hatte ich kein Glück. Wenn jemand entscheidet, dass er definitiv die gleichen einfachen Fragen wie ich bekommt, sabotiert er sich selbst.
Im Unternehmen gelten für Praktikanten dieselben Anforderungen wie für Entwickler ersten Ranges. Jeder Aspekt der Arbeit wird fast unter dem Mikroskop untersucht. Ich kannte viele Programmierer, die ihr Praktikum abgeschlossen hatten, aber nie ein Stellenangebot bekamen.
Während dieser fünf Jahre habe ich selbst mehrere Praktikanten unterrichtet und jetzt, wenn ich den Prozess von der anderen Seite betrachte, verstehe ich, wie hoch die Messlatte für sie ist. Wenn ich jetzt zurückblicke und meine Praktikumsarbeit bewerte, stelle ich fest, dass ich in diesem Sommer gute Arbeit geleistet habe und es wirklich verdient habe, zum Entwickler befördert zu werden.
Also hätte Amazon dich nicht einstellen sollen?
Bis vor kurzem war ich geneigt, zu bejahen. Es besteht kein Zweifel, dass meine Programmierkenntnisse zu diesem Zeitpunkt nicht den Anforderungen entsprachen. Aber nach und nach kam ich zu dem Schluss, dass das Unternehmen langfristig die richtige Entscheidung getroffen hat, mich einzustellen. Ich habe Amazon definitiv greifbare Vorteile gebracht.
Ich habe AWS sicherer gemacht, war an Bildungs- und Verkaufsprogrammen beteiligt. Ich habe Lösungen für eine große Anzahl interner und externer Kunden bereitgestellt. Ich habe Einführungskurse für ein Publikum von mehreren hundert Personen gegeben. Ich wurde ein Mentor für viele Programmierer, die danach strebten, in Entwickler der zweiten Ebene einzusteigen. Bevor ich zu Amazon kam, hatte ich die Möglichkeit, die Fußball- und Basketballmannschaften zu leiten, die beide das Viertelfinale in Virginia erreichten. Im Laufe der Jahre habe ich meine Fähigkeiten in der Arbeit mit Menschen und führenden Menschen verbessert - diese Fähigkeiten haben sich bei Amazon als nützlich erwiesen. Ich hoffe, dass ich der Entwickler-Community in Zukunft noch mehr bieten kann, weil ich weiß, wie es ist, ein Betrüger zu sein.