Mais ce ne fut pas toujours ainsi. En 2015, j'ai obtenu un emploi de développeur de logiciels de premier rang. Et en vain. J'étais un vrai imposteur. Mais mes maigres compétences en ingénierie ne m'ont pas empêché finalement d'être promu au deuxième rang. Je veux partager mon histoire pour aider d'autres imposteurs à réussir dans les entreprises FAANG - enfin, ou dans d'autres.
Comment je me suis faufilé dans Amazon
J'admire les gens qui ont réussi à passer par le cycle de sélection complet dans l'une des entreprises FAANG. Il s'agit d'une série d'entretiens du matin au soir, au cours desquels le candidat est interrogé sur ses connaissances techniques et ses qualités personnelles par cinq collaborateurs différents de l'entreprise. Pour réussir cet examen, vous devez passer des centaines d'heures à vous préparer, étudier en profondeur des structures de données et des algorithmes complexes, résoudre des problèmes pendant des mois. Tout cela demande autant de patience, de détermination et de persévérance que le processus de publication d'un livre.
Mon chemin a contourné toutes ces difficultés. En 2014, Amazon faisait des entretiens d'embauche sur le campus pour les stagiaires d'été. Certains de mes camarades y sont allés avant moi. Ils sont tous revenus avec des histoires de questions de programmation déroutantes qui leur avaient été posées.
J'ai passé quatre examens cette semaine-là et j'ai dormi en moyenne quatre heures par jour. J'ai réussi à prévoir trois heures de préparation. Il y a eu deux entretiens. Les questions de programmation que j'ai reçues sont incroyablement simples. L'un concernait la manipulation de bits, l'autre l'utilisation de listes chaînées, et je devais également parler des tables de hachage. C'est tout. J'étais juste chanceux.
Les stagiaires d'Amazon, s'ils réussissent bien, reçoivent une offre de passer à un développeur à temps plein du premier rang d'entrée. Ils n'ont pas à répéter les interviews. Je faisais mon stage à Seattle - sculptant minutieusement un site Ruby on Rails à partir de zéro. J'ai reçu une offre et j'ai commencé en tant que développeur de logiciels en 2015 en Virginie.
À propos de la rareté de mes connaissances
Les développeurs de rang 1 doivent bien connaître les structures de données avancées: tas, graphiques, arborescences de préfixes. Je ne connaissais même pas le sens de ces mots. Les développeurs de rang 1 devraient être capables d'estimer la complexité temporelle et spatiale des algorithmes de tri, de recherche, d'insertion et de division. Je ne vous dirais pas la complexité temporelle d'une recherche banale en profondeur d'abord dans un arbre binaire.
Pourquoi ai-je tant de lacunes dans les connaissances? Il y avait deux raisons.
Tout d'abord, j'ai étudié l'ingénierie informatique, pas l'informatique. L'accent était mis sur l'intégration des logiciels et du matériel plutôt que sur le développement de grands systèmes. Cette orientation m'a appris à résoudre des problèmes complexes dans des conditions douteuses, mais le programme ne prévoyait pas du tout une analyse détaillée des structures de données et des algorithmes. Deuxièmement, je n’ai pas suivi un processus de préparation à part entière, je n’ai pas passé des centaines d’heures à étudier - je n’ai donc pas appris.
J'ai moi-même réalisé que je ne suivais pas le rythme. Au début, le syndrome de l'imposteur me tourmentait avec une force terrible.
Premières crêpes
Chaque inspection de code était un désastre. J'ai soumis un extrait de code pour examen (sous la forme d'une demande d'acceptation de modifications, par exemple), il m'a été retourné avec quatre-vingts commentaires. Ça ne va pas. J'ai corrigé et soumis une nouvelle version. Cinquante autres commentaires. Ça ne va pas. Et ainsi de suite.
Avec certains fragments, les choses allaient si mal que les collègues ne savaient tout simplement pas comment expliquer l'essence du problème pour que je la comprenne. Ils ont dû télécharger le code et le réécrire. Ils voulaient m'aider et étaient plutôt sympathiques, mais je me suis littéralement épuisé de honte. J'ai vécu dans la peur que les gens comprennent: je n'ai pas ma place ici. Pas un seul jour ouvrable ne s'est passé sans penser qu'aujourd'hui je serais licencié.
Exposer l'imposteur
Petit à petit, je me suis redressé. Enfin, j'ai commencé à respecter les délais et à donner systématiquement le code à la production. Environ neuf mois plus tard, j'ai développé une confiance en moi. J'ai décidé qu'il était temps de se débarrasser une fois pour toutes du syndrome de l'imposteur. Je me suis tourné vers les problèmes sur LeetCode, juste pour me prouver que j'étais à ma place. Je me souviens avoir pensé: «Je suis maintenant un développeur à part entière chez Amazon. J'ai des commits en production. Pourquoi, je ne peux pas faire face à ces tâches simples? "
J'ai choisi l'un des plus faciles sur LeetCode - et je n'ai pas pu le résoudre. J'en ai choisi un autre - et je ne pouvais pas non plus. Et le troisième et le quatrième. Ensuite, il est devenu clair pour moi que je ne souffrais d'aucun syndrome. Je suis un imposteur.
Sois, ne semble pas être
Après deux ans et demi, j'ai été promu développeur de niveau 2. Un développeur de deuxième rang est capable de créer et de maintenir seul un grand système avec une assistance minimale de l'extérieur. Alors, comment ai-je fait? Comment ai-je réussi à réinterpréter les règles du jeu en ma faveur?
Eh bien ... pas moyen. Chez Amazon, les manigances ne fonctionnent pas. Le système ne peut pas être rejoué. «Faire semblant d'être un spécialiste jusqu'à ce que vous réussissiez» est un conseil très courant et très mauvais. Cela ne fonctionne pas. La seule façon de vous faire nommer développeur de niveau 2 est de devenir développeur de niveau 2.
La promotion est un processus exténuant. Vous devez décrire vos mérites et vos réalisations sur plus de vingt pages de documentation, à tel point que vos collègues et patrons le croient. Vous devez constamment collecter des métriques et des preuves que vos progrès sont à un niveau supérieur. Vous ne pouvez compter sur une augmentation que si vous maintenez systématiquement la barre du niveau suivant pendant six mois, voire une année entière.
Vous avez probablement entendu la phrase: «Notre personnalité est constituée de ce que nous faisons régulièrement». Ci-dessous, je décrirai les mesures que j'ai prises pour cesser d'être un imposteur et me développer en tant que développeur de niveau supérieur.
Qu'est-ce que j'ai fait
S'accorder pour maximiser l'acceptation des commentaires Les
nouveaux arrivants à FAANG ont souvent un ego gonflé. Cela les prive de la capacité d'accepter et de prendre en compte les critiques constructives de leurs collègues. Mais ces collègues sont des gens intelligents, chacun ayant sa propre expérience unique dans le domaine de l'informatique.
Je n'ai eu aucun problème d'estime de soi. A l'amiable, je n'avais rien à voir avec l'entreprise. Par conséquent, lorsque j'ai reçu des commentaires, j'ai écouté et écouté attentivement.
Les commentaires des collègues étaient vrais, controversés ou incorrects. Si la remarque était correcte, j'ai suivi les conseils sans réserve. S'il s'agissait de quelque chose de controversé, j'ai d'abord essayé de comprendre le point de vue d'un autre développeur, et alors seulement - de transmettre le mien. Et, tout d'un coup, j'écoutais même les mauvaises remarques.
Dans ce cas, le fil de la pensée était: «Pourquoi suis-je sûr d'avoir raison? Qu'est-ce qui a conduit une personne à une telle idée? Puis-je en quelque sorte clarifier pour qu'une telle réaction ne se produise pas? " C'est ce que j'appelle une ouverture maximale. Les gens intelligents, même lorsqu'ils se trompent, partent de quelque chose dans leurs conclusions. J'ai compris quoi exactement et j'ai amélioré mon code en gardant ces informations à l'esprit. Poser des
questions stupides Les
nouveaux arrivants dans les entreprises FAANG essaient souvent de ne pas poser de questions - ils ont peur d'être mal pensés. Cet élément du syndrome de l'imposteur coexiste paradoxalement avec une vanité exagérée. Eh bien, moi, en vrai imposteur, j'ai parfaitement compris que mes questions étaient stupides. Cela ne m'a pas dérangé.
Par exemple:
« , . , ?»
« , ?»
« , . - ?»
Très vite, j'ai obtenu des centaines de signets, collecté des tonnes d'informations supplémentaires et j'ai eu beaucoup de succès en participant à des réunions.
Trouver l'inspecteur de code sans repos
Au début, il est très important que le plus grand nombre possible de développeurs examinent votre code. Chaque employé effectuant une inspection aura ses propres préférences, harcelantes, bêtes noires. Mais il est encore plus important de découvrir l'inspecteur agité.
Il y en a un dans chaque équipe. Son travail n'est jamais satisfait. Il s'accroche au nom de chaque variable, de chaque journal, de chaque paramètre d'API sélectionné. J'ai fait un effort particulier pour retrouver cette personne et lui envoyer mon code le plus souvent possible. Pourquoi? Parce que j'ai compris: plus je reçois des commentaires constructifs, plus la formation ira vite.
Utilisé des modèles existants pour éviter les erreurs Les
juniors essaient souvent de réinventer la roue. La plupart des tâches de développement ne sont pas nouvelles. Avant de commencer à écrire le code demandé, je cherchais des solutions similaires sur les ressources internes. J'ai parcouru plusieurs exemples différents, en explorant la manière dont le code y est structuré. Ensuite, je me suis tourné vers le code de mon équipe et j'ai trouvé la meilleure façon de lier le nouveau fragment au système général.
J'ai adopté la même approche lors de la rédaction de la documentation de conception et des rapports post mortem. Échantillons d'abord, puis actions.
Axé sur l'exactitude et la pertinence
J'ai évité le piège des coûts irrécupérables. Si je fais quelque chose de mal, peu importe que j'y ai déjà passé quatre heures. Je savais que je devrais écarter ce que j'avais développé et le refaire de la bonne manière.
Pour cent lignes de code envoyées pour inspection, il y avait deux cent cinquante lignes d'ordures que j'ai écrites et jetées. J'ai essayé de m'assurer que chacune de ces cent lignes était compréhensible, écrite à dessein et était nécessaire pour quelque chose. Maintenant, mon code obtient généralement le feu vert après une ou deux révisions.
Se jeter dans la chaleur
Vous ne vous sentirez jamais «prêt» à travailler sur des fonctions clés, à déployer des projets en production, à mener des interviews et à éliminer les urgences. La meilleure façon de se préparer à tout cela est de le prendre et de le faire.
À la première occasion, j'ai simplement dit à mon patron: je suis prêt. Même si avant cela je n'avais pas l'occasion d'observer en détail les actions des autres, comme cela est généralement conseillé. Parfois, je devais demander de l'aide ou demander à quelqu'un de mes collègues de suivre mon travail. Mais au final, cela m'a permis d'élargir ma zone de confort et d'accélérer ma croissance.
Prenant l'initiative dans les petites choses,
j'ai remarqué des opportunités d'améliorer l'excellence opérationnelle de l'équipe, les processus de travail, l'expérience de développement. Plus d'une ou deux fois, j'ai volontairement assumé des tâches ennuyeuses: j'ai automatisé les procédures exécutées manuellement, finalisé la documentation, amélioré le pipeline CI / CD, refactorisation du code hérité.
J'ai essayé d'être professionnel
La programmation est un type de créativité basé sur la logique. Chaque tâche, chaque nouvelle fonction, je l'ai perçue comme une feuille vierge sur laquelle vous pouvez montrer votre compétence et quitter la création.
Le développeur de deuxième niveau doit être un ingénieur logiciel ou un professionnel, selon Stephen Pressfield, auteur de The War of Art. J'ai déployé tous mes efforts pour écrire du code propre (vous devriez certainement lire le livre du même nom) et créer de belles solutions élégantes.
Il a clairement indiqué son désir d'augmentation
Dans les entreprises FAANG, personne n'offre d'augmentation - vous leur demandez vous-même, et plus d'une fois. Si cela n'est pas fait, le processus s'éternisera pendant plusieurs mois.
Lors de conversations privées avec mon patron, j'ai clairement indiqué que je voulais être promu. J'ai demandé des commentaires pour comprendre quels domaines s'affaissaient. J'ai évalué objectivement les résultats des travaux terminés et j'ai accepté les critiques quand elles me venaient. J'ai cherché des opportunités pour parfaire mes compétences et combler les lacunes. Si je pouvais montrer certaines compétences, j'essayais de garder les commentaires par écrit. Après tout, vous ne pouvez pas prédire quand la prochaine restructuration aura lieu et votre patron changera.
Faire passer le travail pour la promotion avant les autres
J'ai compris: vous ne pouvez pas travailler uniquement et exclusivement pour la promotion. Si tout le monde fait cela, l'ambiance d'équipe deviendra définitivement impropre à la vie. Mais en même temps, j'ai littéralement mis les tâches dont j'avais besoin pour la promotion en premier lieu.
Autrement dit, si j'avais besoin de me concentrer sur une fonction importante, dont les délais étaient serrés, je l'ai assumée le matin. Je pouvais donc être sûr que j'avais assez de temps pour bien faire le travail. Si j'avais besoin de mener plus activement l'inspection du code, alors les heures du matin y étaient consacrées. Si je devais assister plus souvent aux entretiens, j'ai commencé ma journée de travail en m'inscrivant aux prochains.
Collecter constamment des preuves de mon succès
On ne peut se passer de la capacité de présenter ses réalisations à travers une combinaison d'indicateurs quantitatifs et qualitatifs.
Avant de commencer la tâche, j'ai recherché des métriques décrivant l'état actuel du système. À la fin des travaux, j'ai regardé les nouveaux indicateurs et effectué des calculs pour comprendre dans quelle mesure mes actions ont influencé la situation. Et enfin, j'ai enregistré tout ce qui concernait la tâche dans la documentation qui devait servir de justification à l'augmentation: analyse STAR, indicateurs quantitatifs, liens vers les résultats de l'inspection du code, graphiques et autres reliques de travail.
J'ai réalisé ce qui dépend de moi et ce qui ne dépend pas de moi
J'en suis venu à comprendre que tout peut arriver. Parfois, une équipe manque de fonctions importantes. Parfois, les projets sont fermés. Parfois, en raison de restructurations, la direction change. Parfois, le pipeline CI / CD est déjà parfait et il n'y a tout simplement rien à améliorer.
Et en même temps, je me suis rendu compte que si je me concentre sur le travail à la limite et sur l'approche professionnelle des tâches, je serai prêt pour le moment où l'opportunité de me montrer apparaîtra. L'opportunité s'est présentée - il s'est montré professionnel. Cela a apporté quelques opportunités supplémentaires - encore une fois, j'ai tout fait au niveau. Etc.
Réflexions
La «culture Leetcode» qui s'est développée au cours du processus de recrutement nuit-elle à l'entreprise?
J'ai réussi à prendre pied sur Amazon, même si à mon arrivée, les tâches avec Leetcode étaient trop difficiles pour moi. Puis, lorsque j'ai moi-même commencé à mener des entretiens, j'ai bien entendu désassemblé délibérément tous les algorithmes et structures de données nécessaires pour pouvoir évaluer les réponses des candidats.
Je pense que l'approche actuelle est payante. Les entreprises s'intéressent aux personnes qui ont la persévérance et la motivation nécessaires pour apprendre de nouvelles choses et utiliser ces informations en conjonction avec les compétences existantes. Les processus établis font un bon travail de sélection de ces personnes.
Il est donc plus facile d'entrer dans les développeurs de rang 1 grâce à un stage?
Je ne dirais pas ça. Ces deux entretiens ne sont généralement pas plus faciles pour les stagiaires que cinq entretiens pour les employés à temps plein. Quand j'ai interviewé en 2014, je n'ai pas eu de chance. Si quelqu'un décide qu'il aura certainement les mêmes questions simples que moi, alors il se sabote.
Dans l'entreprise, les mêmes exigences sont imposées aux stagiaires qu'aux développeurs de premier rang. Chaque aspect du travail est examiné presque au microscope. Je connaissais de nombreux programmeurs qui avaient terminé leur stage, mais ils n'ont jamais eu d'offre d'emploi.
Au cours de ces cinq années, j'ai moi-même enseigné à plusieurs stagiaires et maintenant, en regardant le processus de l'autre côté, je comprends à quel point la barre est haute pour eux. Maintenant, en regardant en arrière et en évaluant mon travail de stage, je me rends compte que j'ai fait du bon travail cet été et méritait vraiment d'être promu développeur.
Alors Amazon n'aurait pas dû vous embaucher?
Jusqu'à récemment, j'étais enclin à répondre par l'affirmative. Il ne fait aucun doute que mes connaissances en programmation à l'époque ne répondaient pas aux exigences. Mais petit à petit, je suis arrivé à la conclusion qu'à long terme, l'entreprise avait pris la bonne décision de m'embaucher. J'ai certainement apporté des avantages tangibles à Amazon.
J'ai rendu AWS plus sûr, j'ai participé à des programmes de formation et de vente. J'ai fourni des solutions à un grand nombre de clients internes et externes. J'ai donné des cours d'introduction à un public de plusieurs centaines de personnes. Je suis devenu le mentor de nombreux programmeurs qui aspiraient à devenir des développeurs de deuxième niveau. Avant de rejoindre Amazon, j'étais capitaine des équipes de football et de basket-ball, qui ont toutes deux atteint les quarts de finale en Virginie. Au fil des ans, j'ai perfectionné mes compétences en travaillant avec les gens et en dirigeant les gens - ces compétences m'ont été utiles chez Amazon. Dans le futur, j'espère donner encore plus à la communauté des développeurs car je sais ce que c'est que d'être un imposteur.