Article original : Coding Interview Prep for Big Tech (FAANG) – And How I Became A Google Engineer
Lorsque j'ai changé de carrière, passant d'avocat à ingénieur logiciel chez Google, j'ai publié 10 grandes idées qui m'ont aidé à effectuer cette transition massive. Depuis, j'ai reçu de nombreuses questions de personnes me demandant :
Comment je m'ai auto-appris de nouvelles compétences
Comment j'ai su que apprendre à coder à 37 ans n'était pas "trop tard"
Comment je me suis préparé pour les entretiens de codage des grandes entreprises technologiques
Comment j'ai analysé et minimisé le risque de changement de carrière
Comment j'ai déterminé que l'ingénierie logicielle était "faite pour moi"
Quelles langues j'ai ciblées
Si être ingénieur logiciel chez FANG/FAMGA est fait pour tout le monde (indice : il est tentant de le penser, mais j'ai vu beaucoup de preuves que ce n'était pas le cas pour les objectifs de certaines personnes)
Note : Je pense que "FAANG/FAMGA" est limitant, et je préfère me référer aux "grandes entreprises technologiques" puisque il y a de nombreuses entreprises très prestigieuses autres que les 4-5 habituelles sur lesquelles tout le monde se concentre.
Pourquoi j'ai écrit cet article
Chacune de ces questions que j'ai listées ci-dessus mérite son propre article, même si je sais que notre culture contemporaine préfère les "conseils de la taille d'un tweet". Cependant, les compétences significatives ne peuvent pas être internalisées à partir de quelques centaines de caractères.
Aujourd'hui, je vais donc partager avec vous ma réponse à l'une de ces questions – l'approche que j'ai adoptée lorsque :
J'ai fait ce premier saut de carrière, passant d'avocat à codeur à 38 ans, et
Comment je me suis préparé pour les entretiens des grandes entreprises technologiques à l'âge mûr de 39 ans, avec moins de 2 ans de codage derrière moi.
Si vous voulez que j'écrive sur l'une des autres questions que l'on me pose toujours, faites-le moi savoir ! Je vais mettre mes coordonnées quelque part dans cet article, et la seule façon de les trouver sera de lire attentivement l'article. 😊 Cela est aussi pour vous encourager à lire attentivement cet article plutôt que de le parcourir pour un "conseil rapide".
Découvrir le vrai objectif
Je tiens les opinions suivantes : obtenir des entretiens de codage est plus difficile que d'apprendre à coder. Bien performer lors des entretiens est souvent aussi difficile que d'obtenir les entretiens. Les entretiens comportementaux sont difficiles si vous n'avez pas d'expérience solide – mais vos concurrents en ont.
Lorsque j'ai fait la transition, je n'avais aucune expérience en codage. Plus tard, lorsque j'ai visé les grandes entreprises technologiques, je savais que je serais en compétition avec des docteurs, des personnes qui codaient depuis leur adolescence (souvent 20+ ans), et des gens qui avaient accompli beaucoup plus techniquement que moi en une seule année d'expérience en tant que développeur.
Et j'avais le défi supplémentaire de postuler pour les grandes entreprises technologiques depuis l'extérieur des États-Unis.
Je devais donc développer un plan qui allait bien au-delà du simple "apprendre à coder".
D'abord, laissez-moi expliquer pourquoi j'ai conclu que "apprendre à coder" est la partie facile, même si j'avais essayé et échoué à apprendre à coder 4 fois, entre 2012 et 2018.
Cette prise de conscience m'est venue fin 2018, lorsque ma startup avait du mal. J'avais perdu des dizaines de milliers de dollars en construisant ma startup. Je n'avais aucun revenu depuis plus de 2 ans.
Et j'ai décidé de retirer plus de 40 000 $ de mon hypothèque. Pourquoi ? Je suis entré dans un bootcamp très bien noté à San Francisco.
J'ai laissé ma famille derrière moi et j'ai déménagé aux États-Unis. J'étais censé y être pendant plus de 14 semaines, mais je me suis retiré de ce bootcamp très bien noté dès la première semaine et je suis retourné en Australie.
J'avais été super excité par l'aventure (et effrayé par toutes les dettes). Mais j'ai développé de graves doutes sur la stratégie du bootcamp. J'ai remarqué que mes instructeurs et le programme étaient conçus pour aider les gens à "apprendre à coder" plutôt que "devenir un codeur".
D'après mon expérience du côté de l'embauche dans 3 autres industries et 4 pays, je savais que c'était une erreur.
Apprendre à coder n'est qu'une forme de "littératie". Et la littératie n'est pas une compétence.
J'en étais la preuve vivante : chacune des 4 fois où je me suis concentré sur "apprendre à coder", j'ai réussi dans un sens étroit. Que ce soit en HTML ou en Java ou en écrivant une simple application Android à partir d'un livre, j'ai toujours réussi à apprendre à lire et à écrire les bases. Mais je n'avais aucune idée de comment construire quelque chose d'utile. J'étais complètement incapable d'appliquer mes connaissances – je n'avais aucune "compétence" réelle.
Dans ce siècle, nous ne sommes pas embauchés pour ce que nous savons. Nous sommes embauchés pour nos compétences.
J'ai rapidement vu plusieurs raisons pour lesquelles un bootcamp de codage était la mauvaise stratégie pour moi.
Ce bootcamp coûteux me donnerait probablement quelques compétences de base, le genre qui pourrait même me permettre de décrocher un emploi "de niveau d'entrée". Mais je pouvais voir que les choses allaient être précipitées, standardisées et axées sur "sortir de l'autre côté".
Je ne voulais pas "cocher une case". Je voulais des compétences. De la compétence. De la confiance.
De plus, les bootcamps semblaient préparer tout le monde pour des emplois "développeur junior" de niveau d'entrée.
J'avais 37 ans et je ne voulais pas me contenter d'un état d'esprit de "travail de niveau d'entrée". De plus, je ne crois pas que quiconque avec 3 + années d'expérience soit "junior" même s'il est un parfait débutant dans le domaine.
Ensuite, j'ai découvert que plusieurs instructeurs et assistants d'enseignement du bootcamp étaient d'anciens étudiants qui n'avaient pas encore trouvé d'emploi. Ils n'avaient jamais changé de carrière – beaucoup n'avaient jamais eu de "carrière" à proprement parler. Les conseillers en recherche d'emploi n'avaient jamais même été du côté de l'entretien dans le domaine de la technologie.
Comment allais-je apprendre à faire quelque chose auprès de personnes qui n'avaient jamais fait ce dont j'avais besoin ?
Et puis il y avait la géographie. Les étudiants basés à San Francisco avaient des avantages, alors que les personnes venant d'autres parties des États-Unis ne trouvaient pas de travail aussi facilement et manquaient d'argent dans les longs mois suivant l'obtention de leur diplôme et avant d'obtenir leur premier emploi. En plus, j'étais basé en Australie... comment cela allait-il fonctionner pour moi ?
J'ai regardé mon objectif explicite. Ce n'était pas "apprendre à coder" – c'était de construire une carrière qui me comble.
De plus, en recherchant des bootcamps, je pouvais voir un chemin pour apprendre "à temps partiel". Cela semblait être une stratégie beaucoup plus durable pour moi car je pouvais trouver un emploi et apprendre le soir et les weekends. Après plus de 2 ans sans revenu, j'avais besoin d'avoir un flux de trésorerie afin de garder la peur à distance et de me concentrer sur le fait de devenir un codeur professionnel.
Comme le disait le légendaire homme d'affaires Harvey Firestone :
"Avoir un surplus est la plus grande aide au jugement commercial que je connaisse."
Avoir un revenu pendant mes études me donnerait la confiance nécessaire pour prendre de meilleures décisions. De meilleures décisions sont importantes pour une carrière épanouissante à long terme.
Je n'avais aucun doute que je "apprendrais à coder" si je faisais 3-4 mois dans le bootcamp.
Mais est-ce que j'apprendrais assez pour qu'une bonne équipe me paie pour mes compétences ? Je ne croyais plus que les bootcamps et les sites de codage en ligne m'aideraient à atteindre cet objectif.
Apprendre à coder ne me mènerait pas loin. Je devais être assez bon pour battre mes concurrents qui avaient des diplômes en informatique, une expérience préalable et des réseaux. Je voulais une carrière dans le codage.
Alors j'ai quitté le bootcamp, j'ai radié environ 9 000 $ et je suis retourné en Australie. Bien sûr, j'avais acquis une littératie de codage rudimentaire pour passer le test d'entrée du bootcamp. Mais j'étais très loin d'être compétent.
Cette analyse peut être difficile à comprendre si vous êtes nouveau sur le marché du travail. Une autre façon de vraiment la comprendre est de remarquer que beaucoup d'entre nous jouent de la musique, mais ne sont pas dans un groupe. Comme l'a dit mon mentor :
"Michael Jordan ne voulait pas apprendre à jouer au basket-ball. Il voulait être dans la NBA. Énorme différence."
Comment utiliser vos avantages et inconvénients
Cette prise de conscience a fait toute la différence. En 8 mois, en 2019, j'ai obtenu les 4 emplois de développeur pour lesquels j'ai postulé. J'ai simplement suivi le programme que j'avais développé avec l'aide de mon coach (non technique !).
Ne vous y trompez pas. J'avais des avantages inattendus. J'ai bénéficié de 2 avantages majeurs qui semblaient initialement être des inconvénients.
Ce n'était pas mon premier changement de carrière, et pendant près d'une décennie, j'avais été du côté de l'embauche dans mes carrières précédentes. Aujourd'hui, j'ai été du côté de l'embauche en ingénierie aussi, et les schémas sont très similaires.
Mon plus grand avantage était que je ne pensais plus au défi du marché de l'emploi en tant que candidat. Je pensais à cela du point de vue du responsable de l'embauche. Cela a eu un impact significatif sur mon plan car j'avais de l'expérience sur la façon dont les responsables de l'embauche pensent – leurs contraintes, priorités, valeurs, besoins commerciaux, aversions, drapeaux rouges...
Mon expérience (mon âge ?) m'a aidé à comprendre quel impact je pouvais apporter à une équipe et une organisation, et à identifier les bonnes personnes auprès desquelles je pouvais apprendre, qui pouvaient m'aider avec des idées, des conseils, des suggestions et des recommandations. Ce qui était un inconvénient était maintenant un avantage – l'avantage d'un changeur de carrière.
Sur le point des avantages, je veux souligner quelque chose d'important.
La chose la plus facile au monde est de rejeter les autres pour avoir des avantages "mortels". Il est facile de hausser les épaules et de dire "Bien sûr – c'est pourquoi ils ont réussi". Il est facile de ne pas remarquer que tout le monde a des inconvénients très convaincants et sérieux.
Pour moi, mes "inconvénients" étaient :
La géographie – Je ne vis pas aux États-Unis ou dans l'un des autres pôles technologiques
Aucune qualification formelle en informatique
Aucun background technique
Une hypothèque et des responsabilités financières
Mon "âge" – apprendre de nouvelles compétences lorsque l'on approche de la quarantaine est plus difficile que lorsque l'on a 25 ans
Les attentes culturelles et sociales, le jugement, la négativité
Les recruteurs et les patrons étaient plus jeunes que moi et incertains sur la façon de me traiter
Comparé à d'autres candidats, les gens voyaient mon changement comme très, très "risqué"
Je allais gagner moins en ingénierie que je ne gagnerais en tant qu'avocat
Chaque jour, j'entends des gens qui laissent l'une de ces choses les arrêter. Bien que je ne puisse pas commenter si ce sont des raisons réelles ou non, je peux dire que si nous plaidons pour nos limitations, nous pouvons les garder.
S'accrocher à nos inconvénients ne nous aide pas à les surmonter.
Avec l'aide de mon coach et une tonne de formation sur l'état d'esprit/la psychologie, j'ai pu creuser mes inconvénients et en convertir quelques-uns (pas beaucoup !) en avantages majeurs. Et c'est à ce moment-là que j'ai réalisé que mon expérience sur la façon dont les entretiens, le recrutement et la gestion des ressources fonctionnent m'aiderait beaucoup à formuler une stratégie.
Priorité numéro un : le changement de carrière
Lorsque j'ai appris à coder et que j'ai intentionnellement fixé l'objectif de devenir un codeur professionnel, j'ai constaté que je passais constamment à une pensée à court terme et que je m'obsédais sur mon premier rôle.
Je voulais que mon premier rôle soit glorieux, pour prouver que tous mes critiques avaient tort, pour me payer des milliards de dollars et me sauver de devoir faire face au doute de soi et à la lutte pour le reste de ma vie.
Mais je devais m'entraîner à voir les choses différemment. Mon premier rôle devait être celui qui me fait apprendre et grandir, et me préparer pour le succès futur quoi qu'il arrive. Il devait payer des taux de marché équitables, mais j'étais heureux de prendre un salaire légèrement inférieur si l'équipe était fantastique et que la croissance/l'apprentissage était solide. Il n'avait pas besoin d'être le travail de mes rêves.
J'étais très explicite sur les compromis que je ferais :
L'équipe compte plus que la marque
L'équipe compte plus que l'argent
La marque compte plus que l'argent (car cela me préparerait pour de futures opportunités)
L'argent compte plus que les actions (c'était pour mon premier rôle de développeur, car cela rendrait mon plan d'apprentissage continu durable, même si les actions pourraient me donner plus de gains financiers)
Mais l'apprentissage comptait plus que la marque ou l'argent – car apprendre plus me ferait gagner du temps, ce qui est mieux que de gagner de l'argent
Je ne ferais pas de compromis entre l'équipe et l'apprentissage. J'avais besoin des deux (mais j'étais plus susceptible d'obtenir des signaux fiables sur l'équipe que sur l'apprentissage/la croissance réelle que j'obtiendrais sur le travail)
"Réussir" ou être à l'aise n'était pas une priorité. Ma priorité était de changer de carrière avec succès.
Accepter un travail de codage médiocre (et il y en a beaucoup...) ne serait pas un changement de carrière "réussi" pour moi. Mais de même, je n'avais pas à entrer dans les grandes entreprises technologiques (jamais) pour que mon changement de carrière soit "réussi". C'était très personnel – le succès pour moi signifiait aimer le travail que je fais et apprendre beaucoup en le faisant. Point.
Comment j'ai fait un plan personnalisé
Après avoir analysé mes avantages et mes "inconvénients convertibles", la prochaine chose dont j'avais besoin était de développer un plan personnalisé. J'avais besoin d'un plan qui soit adapté à moi, en lequel je pouvais croire.
J'avais besoin d'un plan qui prenne en compte mon contexte spécifique, qui inclut mon tempérament, mon expérience, mes croyances, mes valeurs, mes objectifs et mes compétences.
Notez que je n'ai toujours pas parlé des entretiens techniques, des algorithmes et des structures de données, etc. En développant mon plan, je devais me concentrer sur toutes les nombreuses pièces qui n'avaient rien à voir avec mes compétences en codage ou mes capacités techniques.
Il devrait également tenir compte de ma "piste" psychologique – combien de temps étais-je prêt à investir dans ce changement de carrière, avant d'abandonner, de perdre espoir ou de changer d'avis ? Je ne pouvais pas répondre à cela sans comprendre combien de temps il me faudrait pour apprendre les compétences minimales requises.
Pour comprendre cela, je devais rechercher et analyser quel était l'ensemble minimum de compétences en ingénierie que le marché valoriserait.
Et pour comprendre cela, je devais analyser les dizaines de domaines d'ingénierie sur le marché, et lesquels conviendraient à mon tempérament, à mon intérêt/passion et à mes avantages. Et à partir de cette analyse, je devrais choisir les domaines sur lesquels je me concentrerais et exclure tous les autres.
Je devrais trouver le chevauchement entre mes intérêts, mes capacités et ce que le marché valorisait.
Encore une fois, mon expérience du côté de l'embauche sur le marché m'a donné quelques (petits mais importants) avantages. Je savais que la pure compétence technique ne suffirait pas – c'est juste le point de départ. L'"invitation à la danse".
Je savais aussi que les bonnes équipes n'embauchent pas seulement pour la compétence technique brute, elles embauchent aussi pour des attributs non techniques essentiels. Quelles sont ces traits dépend du domaine technique, de la culture de l'équipe, de la composition actuelle de l'équipe, et ainsi de suite.
Oui, vous avez raison. Un plan personnalisé est extrêmement multidimensionnel, et bien faire les choses n'est que modérément utile, alors que mal faire les choses peut entraîner une énorme perte de direction et de temps.
Puisque j'étais presque à mi-chemin de ma carrière, j'étais déterminé à ne pas répéter les erreurs passées. J'allais être :
Très spécifique dans mes objectifs.
Très intentionnel dans mes choix et mes actions.
Concentré sur ce que je voulais, sans prêter attention aux choses que je ne voulais pas.
Prêt à me changer, mes habitudes et mes croyances négatives, afin de pouvoir changer le monde autour de moi.
Prêt à me concentrer sur la construction d'une carrière gratifiante et épanouissante plutôt que simplement "obtenir le prochain emploi".
Prêt à me concentrer sur la création de valeur pour mon future équipe plutôt que sur une mentalité de "qu'est-ce qu'il y a pour moi".
Prêt à jouer le long jeu – penser en horizons de 5-10-25 ans plutôt que les prochaines semaines.
Je dois avouer que faire ces choses de manière cohérente était beaucoup plus difficile que je ne l'avais anticipé. J'ai souvent glissé, surtout sur les trois premières. Mais puisque j'avais mon plan personnalisé écrit, je l'ai laissé être mon guide et la seule source de vérité pour ce que je devais faire.
Mon plan exigeait que je me concentre sur les compétences fondamentales en programmation, puis que je les affine pour le segment que je sentais correspondre à mes objectifs et compétences à long terme. Pour moi, c'était le développement web. Cela signifiait éviter complètement et impitoyablement toutes les "nouvelles choses brillantes" et faire des choses comme Python ou Java.
Et les tutoriels et les vidéos sans fin n'allaient pas me faire battre la concurrence. J'ai calculé que l'ensemble minimum de compétences que je devrais développer pour ma ville nécessiterait 900-1100 heures de codage concentré, en pratiquant les bonnes choses dans la bonne séquence.
La préparation du plan a pris plusieurs semaines. Je l'ai continuellement affiné et renforcé et ne l'ai pas précipité artificiellement. Je suis très inspiré par Abraham Lincoln (un autre avocat qui a changé de carrière !) et il a dit un jour : "Donnez-moi six heures pour abattre un arbre et je passerai les quatre premières à aiguiser la hache".
J'étais tellement tenté de plonger directement dans mon plan et de m'occuper, mais j'avais appris que être occupé n'était pas du tout la même chose qu'être efficace. Une fois que le plan semblait aussi complet que possible avec les informations dont je disposais, je me suis tourné vers l'exécution de ce plan, avec une concentration totale.
Cela signifiait beaucoup de sacrifices, et de nombreux jours de doute de soi, combattant la tentation de changer, et apprenant à gérer mon énergie. J'ai développé quelques habitudes incroyables pendant cette période, mais elles n'étaient évidentes pour moi qu'avec le recul. Pendant ces 6 mois de travail, j'étais constamment assailli par l'incertitude, la peur et la perte occasionnelle d'espoir.
Plus tard, j'ai adapté ce processus de planification pour créer un plan pour les grandes entreprises technologiques et surtout pour Google. Ce plan a pris 500 à 600 heures supplémentaires d'étude intentionnelle qui était complètement différente de mon plan pour devenir développeur. Plus à ce sujet plus tard.
Résultats précoces, et puis... Google SWE
Une autre leçon que j'avais apprise de 4 ans d'essais, d'erreurs et d'échecs était que j'étais très susceptible de changer de plans à mi-chemin, de changer de ressources, de cours ou de concentration.
C'est un problème beaucoup plus sérieux que nous ne le réalisons car chaque fois que nous changeons de concentration ou de plans, nous jetons le travail acharné que nous avons fait, nous retournons à la case départ et... nous recommençons... tout... depuis... le début.
Imaginez si vous conduisiez de A à B et que vous faisiez constamment des demi-tours et que vous retourniez et recommenciez. Vous n'arriveriez jamais nulle part.
Mais je m'étais fait une promesse (il est plus facile de tenir une seule promesse que d'en tenir un tas !) : j'allais terminer mon plan et ensuite décider si je continuerais. Cette fois, je n'allais pas m'arrêter avant d'avoir terminé mon plan.
Je n'avais pas à aimer le faire. Je devais simplement aimer les possibilités qui se trouvaient à la fin.
Mon plan avait un moment spécifique où je commencerais les entretiens même si je ne me sentais pas prêt pour les entretiens. Mais pour en arriver là, je devais devenir bon à générer des opportunités d'entretien.
Encore une fois, mon expérience passée dans d'autres carrières m'a aidé. J'ai appliqué tout ce que j'avais appris en 18 ans et j'ai obtenu 4 entretiens en quelques semaines, et j'ai obtenu les 4 offres même s'il y avait beaucoup de candidats avec plus d'expérience, de compétences et de qualifications que moi.
Ce n'était pas parce que j'étais meilleur en codage. Je ne vois pas comment cela pourrait être, étant donné que je n'étais dans le domaine que depuis quelques mois.
Je crois que j'ai obtenu les 4 offres parce que pendant le processus d'entretien j'ai démontré que j'étais un meilleur candidat pour le responsable de l'embauche. Cette approche était cruciale dans la façon dont je me suis présenté.
Obtenir les offres est génial, mais j'avais un problème inattendu. Puisque mon plan exigeait que je sois très intentionnel sur le type de travail que je poursuivrais, les 4 rôles pour lesquels j'avais postulé étaient ceux que je croyais vraiment être un fantastique début pour ma nouvelle carrière. Comment allais-je choisir ?
Oui, c'est un excellent problème à avoir, mais cela ne rend pas la décision facile !
Pour résoudre ce problème de manière intelligente, j'ai appris à me poser une question très importante :
Est-ce que je sais cela ou est-ce que je pense simplement cela ?
Très souvent, nous prenons des décisions basées sur des hypothèses et des croyances qui n'ont jamais été testées, et nous confondons nos opinions ou nos fantasmes avec la réalité. Ce que nous savons réellement est bien moins que ce que nous croyons sans vraiment savoir.
Être intentionnel exigeait que je me concentre sur ce que je sais plutôt que sur ce que je souhaitais ou pensais simplement. Je devais soit trouver des preuves pour étayer mes pensées, soit écarter les pensées pour ce que je savais.
Ce cadre a développé mes pouvoirs d'analyse et m'a aidé à choisir le bon premier rôle au début de 2019. J'ai eu 39 ans à cette époque.
Jusqu'à aujourd'hui, je continue à utiliser ce cadre savoir vs penser dans ma prise de décision personnelle ainsi que dans ma prise de décision en ingénierie. Je le trouve être un excellent cadre pour analyser les compromis dans les décisions complexes.
En regardant en arrière, j'ai appris énormément sur le fait de rester fidèle à mon plan, de revisiter mes objectifs, de prendre conscience de moi-même et de pratiquer l'intentionnalité.
Quelques mois après avoir commencé mon nouveau rôle, j'ai remarqué que beaucoup d'avocats commençaient à me contacter et à me demander comment j'avais fait cela. Curieusement, beaucoup d'entre eux étaient des personnes qui insistaient sur le fait que je faisais une énorme erreur et que vouloir apprendre à coder à ce stade était immature et téméraire.
Maintenant, ils voulaient "apprendre à coder". Et cela m'a fait réfléchir.
Qu'est-ce que les autres ont dit être "impossible" ? Savent-ils cela ou pensent-ils simplement cela ?
Et mes objectifs n'avaient pas changé. Pour moi, l'apprentissage, la croissance et l'équipe étaient toujours plus importants que la marque ou l'argent. Mais j'avais presque 40 ans et je voulais aussi explorer la vie d'une manière dont je n'avais jamais eu le courage de le faire dans la première moitié de ma carrière.
Alors j'ai décidé de me fixer un objectif ambitieux : j'allais découvrir ce que c'était que d'être ingénieur logiciel dans une grande entreprise technologique. J'avais travaillé dans de grandes entreprises auparavant et je savais que ce n'est pas pour tout le monde – c'est la raison pour laquelle je suis allé dans des startups et des entreprises plus petites en premier lieu.
Mais ne pourrais-je pas apprendre et grandir BEAUCOUP en étant entouré de certaines des "meilleures" personnes dans leur domaine, de l'ingénierie au produit et aux ventes ? Le savais-je ? Ou le pensais-je simplement ?
J'ai fait des recherches et j'ai découvert que, en moyenne, les gens étaient heureux dans les grandes entreprises technologiques. Mais j'ai aussi découvert que la plupart des gens n'étaient pas aussi intentionnels que moi. J'ai donc limité mes recherches aux personnes qui étaient très intentionnelles quant à leur carrière. Et elles (presque universellement) ont dit qu'elles avaient beaucoup grandi grâce aux grandes entreprises technologiques, même si elles décidaient de partir. Quitter les grandes entreprises technologiques était également intentionnel, en poursuite de leurs objectifs finaux.
Alors j'ai décidé de tenter ma chance dans les grandes entreprises technologiques (y compris 3 des entreprises FAMGA) et plusieurs autres, dans la Silicon Valley, à New York et à Seattle. J'étais toujours basé en Australie, donc c'était un énorme défi.
J'ai redessiné mon plan. Plusieurs des étapes étaient les mêmes, mais le programme de codage devait être massivement révisé. Je devais aussi découvrir comment se fait le recrutement dans les grandes entreprises technologiques américaines, et être digne d'une recommandation.
Environ 7 mois plus tard, j'ai commencé à générer des entretiens. J'ai travaillé très dur pour prouver que je méritais des recommandations pendant ces 7 mois, et les gens ont offert de me donner des recommandations en fonction de mes efforts et de mon engagement prouvé.
J'ai été recommandé à Meta (qui s'appelait alors Facebook) mais je n'ai pas obtenu l'entretien car mes compétences n'étaient pas le bon match. Ce fut un énorme apprentissage pour moi car je pensais avoir été prudent en ne postulant que pour des rôles où mes compétences correspondaient – et j'avais tort.
C'est à ce moment-là que j'ai réalisé que parfois la description de poste est écrite de manière à signifier une chose pour l'entreprise qui embauche, mais signifie des choses très différentes en dehors de cette entreprise. Cela est dû au fait que différentes organisations utilisent les mêmes mots pour signifier des choses différentes. Les deux côtés, celui de l'embauche et celui du candidat, peuvent ne pas être conscients de cela !
Tous ces apprentissages se sont accumulés. En 3 mois, j'ai obtenu des offres de 2 grandes entreprises technologiques, et j'ai manqué une troisième à l'entretien final parce que je ne savais tout simplement pas comment écrire un système de fichiers à partir de zéro (je ne comprenais pas grand-chose au monde Linux !).
Et puis j'ai obtenu une offre de Google.
Encore une fois, j'ai été confronté à une décision très difficile. Google est une force culturelle qu'il est très difficile d'aborder de manière objective. Mais je voulais vraiment rester fidèle à mes objectifs, à mon plan et à mes intentions.
Essayer de séparer ce que je savais de ce que je pensais était EXTRÊMEMENT difficile lorsqu'il s'agissait de Google. Mais j'étais absolument sûr d'une chose : l'équipe avec laquelle j'avais passé l'entretien était composée de personnes formidables.
Et c'est là que je crois que la chance compte. Peu importe ce que les gens disent sur les compétences, le cerveau, l'intelligence et tout ça, la chance et la "magie" ont un rôle dans la vie.
Mes intervieweurs de Google étaient amicaux, gentils, joyeux et très concentrés. Ils ne cherchaient pas à prouver que je n'étais pas à la hauteur. Ils voulaient m'aider à prouver que j'étais bon. Ils ont répondu à mes questions avec enthousiasme, et je me suis senti comme un collaborateur dès la première minute.
Est-ce une chose de Google ? Peut-être. Mais plus tard, en me formant pour devenir intervieweur technique chez Google, j'ai été témoin d'une très grande variété de styles et de croyances des intervieweurs/responsables de l'embauche. J'ai vu des candidats avec de grandes compétences perdre leurs moyens, lutter pour communiquer leur processus, et ainsi de suite. Et j'en suis venu à apprécier le rôle du hasard dans tout cela.
Donc oui – j'ai eu de la chance d'avoir le genre d'intervieweurs que j'ai eus, et que le jour de l'entretien, je savais comment travailler à travers le code.
C'est aussi là que ma préparation ultra-concentrée sur le type de travail et les compétences pertinentes a porté ses fruits. Il y a un très grand nombre de rôles d'ingénierie dans les grandes entreprises technologiques pour lesquels je n'aurais jamais été adapté (comme celui chez Meta). Même avec mon expérience précédente dans d'autres carrières, je n'avais aucune idée de la taille du monde de l'ingénierie, du nombre de saveurs et de types qu'il y a, et de la difficulté à les distinguer.
En me forçant à être très intentionnel et en ne postulant pas de manière aléatoire et aveugle pour des rôles d'ingénierie dans les grandes entreprises technologiques, j'ai amélioré mes chances de petites mais importantes manières. J'ai creusé profondément dans chaque rôle et les ai recherchés soigneusement en parlant à des amis dans l'industrie (encore une fois – mon âge et mon expérience étaient un atout car j'avais construit des relations sur 15+ ans sans jamais m'attendre à ce qu'elles soient si utiles plus tard !).
Pour chaque offre que j'ai reçue, j'avais recherché le rôle en profondeur et bien préparé les entretiens techniques. Le jour de l'entretien, les étoiles étaient alignées et les choses ont fonctionné. Bien que je ne pense pas avoir "réussi" mes entretiens, j'ai fait assez bien pour communiquer que j'étais un candidat approprié pour les besoins de l'équipe.
Ce qui m'amène à la question : Comment me suis-je préparé pour les entretiens des grandes entreprises technologiques ?
Comment se préparer aux entretiens des grandes entreprises technologiques
Réponse : En deux phases qui m'ont pris plus de 500 heures à exécuter.
Phase 1 : Comprendre les réalités et le paysage concurrentiel
Si je voulais m'attaquer aux grandes entreprises technologiques, depuis un autre pays, avec moins d'un an d'expérience dans l'industrie, et 15+ ans dans une carrière sans rapport, sans diplôme en informatique, je devais avoir une vision très claire des réalités, en particulier du paysage concurrentiel.
Cela signifie qu'il y avait de la place pour un espoir éclairé, mais pas de place pour des rêves éthérés, des pensées magiques et des souhaits irréalistes.
Des vérités difficiles (voir mes premières vidéos YouTube sur ce sujet ici). Des réalités difficiles. Du travail acharné.
Je devais pleinement intérioriser et apprécier ce qui suit :
Le codage n'est que le point de départ. Pas le point final. Apprendre à coder était la première étape de nombreuses, une petite pièce d'un puzzle beaucoup plus grand. En d'autres termes, c'est nécessaire, mais pas suffisant pour obtenir un emploi en codage (et surtout dans les grandes entreprises technologiques).
Mon plus grand ennemi serait mon propre esprit. Il laisserait soit la négativité des autres me décourager, soit il se retournerait contre moi et sapperait ma propre confiance. Je devais développer les habitudes qui m'aideraient à avoir un état d'esprit résilient. Je me suis concentré sur le rétablissement après les revers plutôt que sur leur évitement.
Mes concurrents ne seraient probablement pas des changeurs de carrière. Ou s'ils l'étaient, ils viendraient de domaines connexes comme le génie informatique, le génie mécanique ou le génie électronique. La grande majorité aurait des qualifications techniques, peut-être même des doctorats (ce qui s'est avéré vrai !), et plusieurs années d'expérience dans l'industrie.
En tant qu'excentrique et "joker", la partie la plus difficile serait d'obtenir les entretiens. Apprendre les algorithmes et les structures de données serait plus facile. Et "réussir l'entretien de codage" (quoi que cela signifie...) serait plus facile aussi. Pourquoi ? Le code est déterministe – un code identique produit généralement des résultats identiques. Mais la vie n'est pas déterministe, et obtenir des entretiens est hautement subjectif. Sur le marché du travail, des actions identiques ne produisent pas des résultats identiques.
Je devais me façonner en tant que type de personne avec laquelle les ingénieurs expérimentés voudraient travailler
J'ai supposé que la plupart de mes concurrents auraient au moins 3 à 5 ans d'expérience. Je ne pouvais pas les rattraper, et encore moins les dépasser. Au lieu de cela, je devais les surpasser sur les compétences non techniques et me comparer favorablement (sinon les surpasser) sur les aspects techniques.
Je devais communiquer mieux que les autres. Si je ne savais pas quelque chose, je devrais le dire et ensuite communiquer comment je le résoudrais si on me donnait le temps et l'opportunité. Je devais aussi communiquer pour montrer aux intervieweurs que je comprenais leurs besoins commerciaux et que je ne me concentrais pas seulement sur mes rêves égoïstes.
Ce qui signifie que je devais vraiment travailler à comprendre ce que l'équipe de recrutement valorisait, recherchait, voulait et avait besoin.
Je ne pouvais pas contrôler mes concurrents (leur compétence, leur performance, ce qu'ils savaient, etc.), ou ce que mon intervieweur pensait, voulait, ce qu'il valorisait, ou s'il aimait les changeurs de carrière ou non. Je ne pouvais pas contrôler la plupart des choses. Je ne pouvais optimiser que mon effort, ma concentration, ma psychologie, et combien d'apprentissage je tirais de chaque expérience, bonne ou mauvaise. Je ne pouvais contrôler que mes choix et mes actions. Me concentrer sur autre chose que cela serait donc une perte d'énergie précieuse.
Je devais accepter le rôle de la chance. Jordan, Tendulkar, Federer – ils ont tous eu de mauvais jours. Moi aussi. Ou peut-être que je ferais bien, mais ce jour-là quelqu'un d'autre ferait mieux. Ou quelqu'un d'autre serait simplement un meilleur choix pour ce dont l'équipe avait besoin. Pas de mal, pas de faute. J'ai pris ces décisions difficiles du côté des entretiens d'innombrables fois moi-même, donc je sais comment ces choses fonctionnent.
Si j'étais performant dans plus d'une offre, je devrais pré-penser et pré-convenir avec moi-même des signaux et facteurs que j'utiliserais pour décider (j'avais appris de mon expérience de choix entre mes quatre premières offres !).
Si vous vous demandez comment je savais faire tout cela... je ne savais pas. Pas tout à la fois. Ce que vous lisez est un résumé a posteriori. Mais j'ai dû travailler la plupart de cela en "temps réel" basé sur la "pensée par premiers principes". Et j'ai travaillé avec mon mentor pour les affiner au fur et à mesure. Cela a pris beaucoup de temps et j'étais si impatient de "commencer à coder". Mais... je savais quel conseil Abraham Lincoln me donnerait...
Phase 2 : Comment j'ai choisi mes ressources d'apprentissage
Je sais que tout le monde pense qu'il existe une "balle magique" secrète quelque part. Un blog, une vidéo, une ressource, un tutoriel, un podcast, une feuille de triche PDF... quelque chose... qui déverrouillera tout le "secret" et nous fera apprendre les choses instantanément.
Non.
Je vais m'acharner sur ce point jusqu'à ma mort – l'information est une marchandise.
Apprendre est difficile, mais c'est rendu beaucoup plus difficile parce qu'il y a trop d'informations gratuites.
Nous tombons tous dans le piège de penser qu'il manque un morceau d'information. Ce n'est pas le cas.
Pourquoi ? Parce que peu importe où vous vivez, quelle langue vous parlez, quelle couleur ont vos yeux, votre peau ou vos cheveux, quel genre vous identifiez – toutes les ressources vont vous enseigner des choses qui "fonctionnent". Elles sont toutes "les mêmes" à un niveau très fondamental.
Elles doivent l'être, car c'est ainsi que fonctionnent les ordinateurs.
Si vous et moi écrivons une fonction identique en JavaScript ou Python ou Java, nous allons obtenir des résultats identiques. C'est ainsi que fonctionnent les ordinateurs – ils sont des algorithmes déterministes.
Mais la vie (et les entretiens) est très certainement non déterministe. Un effort, des notes, des compétences, une intelligence identiques ne produiront pas des résultats identiques.
Encore une fois, j'ai dû m'apprendre à apprendre. J'ai dû m'apprendre à détourner mon attention des ressources/blogs/sites web/cours et à porter mon attention sur la construction de modèles mentaux solides, l'identification des compétences pertinentes, l'approfondissement des concepts plutôt que des implémentations de code, l'application de ce que je savais déjà de nouvelles manières, le raisonnement, la résolution de problèmes, et la communication de mon raisonnement tout en raisonnant.
Maintenant, vous allez être surpris par les ressources que j'ai utilisées pour mes entretiens chez Google et autres grandes entreprises technologiques.
Oui, j'ai utilisé Leetcode, Algoexpert, InterviewCake et Les cours de CS de Jenny et peut-être quelques autres. Mais je n'ai terminé aucun d'entre eux.
Ce n'était pas parce que j'ai changé ou perdu le focus. J'étais intentionnel. J'ai réalisé qu'ils enseignent tous la même chose, mais avec des styles et des contenus légèrement différents. Donc j'ai utilisé ces ressources pour apprendre des concepts et j'ai mélangé et assorti toutes ces ressources en fonction de mes analyses des modèles d'entretien.
Mon raisonnement était simple. Ayant été du côté de l'embauche, je sais que chaque année la qualité des candidats (dans les bonnes entreprises) s'améliore. Je pense personnellement que se concentrer sur l'entreprise est une énorme erreur – nous devrions nous concentrer sur l'équipe, les personnes et le type de travail.
Mais le monde fonctionne d'une certaine manière, et à cause de cela, tout le monde se précipite vers les grandes entreprises. Cela augmente la compétition, ce qui rend plus difficile pour les responsables de l'embauche d'évaluer les candidats.
La seule façon pour les responsables de l'embauche de gérer cela est d'élever la barre, rendant les choses plus difficiles pour les candidats. Le nombre total de candidats continue d'augmenter, mais le "bassin" de candidats qui sont invités à l'entretien reste dans une fourchette étroite – généralement 2 à 10 personnes. Peu importe le nombre de centaines de candidats, c'est environ le nombre qui aura même une chance d'être interviewé.
Par conséquent, le nombre de candidats qui n'ont pas de réponse ou qui sont confrontés à un rejet augmente, surtout dans les marchés haussiers.
Si la compétition augmente et que les ressources sur Internet augmentent également, mais que le nombre de présélectionnés reste plus ou moins constant, alors "apprendre plus" ne peut pas être la solution. Tout le monde "apprend plus", donc par rapport à la compétition, il n'y a pas de changement.
J'ai également réalisé que les grandes entreprises technologiques auraient des listes de questions d'entretien (c'est "efficace" car l'entretien est très chronophage, et il est donc logique de gagner du temps en ayant une banque de questions que les intervieweurs pourraient utiliser). Naturellement, ils n'utiliseraient pas ces questions si elles étaient "fuitées" – cela annulerait le processus d'entretien.
Donc, logiquement, les responsables de l'embauche ne poseront pas de questions qui sont disponibles sur Leetcode ou Algoexpert ou d'autres sites. Cela produit une sorte de "course aux armements" – plus les questions sont rendues publiques, plus les questions de la banque de questions sont modifiées. Cela entraîne plus d'innovation et de variance dans les questions et les stratégies d'embauche.
Cela ne me laissait qu'un seul choix. Je devais apprendre à résoudre des problèmes en utilisant des modèles mentaux et en les classifiant. Il y avait peu de chances que l'on me demande de trier une liste chaînée ou d'implémenter l'algorithme du plus court chemin de Dijkstra. Au lieu de cela, je devrais savoir comment appliquer ces types d'algorithmes à des problèmes "réels", pratiques.
Souvent, les problèmes réels ne ressemblent pas, ne sonnent pas ou ne sentent pas comme les questions d'entraînement que nous étudions. Les questions d'entraînement et les questions de codage compétitif tendent à être "proprement" emballées avec des contraintes claires.
Mais en tant qu'intervieweur, je voulais savoir comment le candidat pense, raisonne, analyse, interprète les informations et collabore. Résoudre le problème est un bonus. Souvent, ils ont la bonne solution mais manquent de temps – mais posent de grandes questions et savent clairement comment aborder le problème. Ces candidats peuvent toujours obtenir l'offre.
Plus tard, en tant qu'ingénieur chez Google, je pouvais toujours dire si quelqu'un savait comment résoudre quelque chose même s'il était incapable de le résoudre à temps. De même, il est immédiatement évident lorsqu'un candidat ne sait pas comment résoudre quelque chose (et c'est OK – nous sommes tous en train d'apprendre).
En adoptant mon approche de compréhension des types de problèmes et des solutions plutôt que des implémentations de code spécifiques, je pouvais me concentrer sur l'apprentissage du raisonnement plutôt que sur l'apprentissage de l'écriture d'algorithmes spécifiques.
Cette approche signifiait que j'ai complété moins de 40 % d'Algoexpert (et à l'époque, il avait la moitié des questions qu'il a maintenant). J'ai également fait peut-être 50 à 60 questions de Leetcode et la plupart d'entre elles n'étaient pas les plus "difficiles".
J'ai pensé que les questions "difficiles" apparaîtraient probablement dans les entretiens de 45 minutes environ 20 % du temps, ce qui signifie que 80 % du temps, ce seraient des questions faciles ou moyennes. Il était donc logique d'optimiser pour les 80 % étant donné que j'étais encore relativement nouveau en ingénierie et que les problèmes difficiles entraveraient la compréhension des faciles et moyens.
J'ai utilisé ces ressources pour reconnaître des motifs plutôt que simplement "compléter" et obtenir une certification. C'est pourquoi je n'ai terminé aucune d'entre elles. Et non, je n'ai pas utilisé "Cracking the coding interview" non plus.
En cours de route, j'ai également commencé un processus systématique de compréhension des questions de conception de systèmes. J'ai documenté la préparation de la conception de systèmes dans un long article de blog sur les concepts essentiels pour les questions d'entretien sur la conception de systèmes.
J'ai également décidé de me concentrer sur un seul langage : JavaScript. Ce n'était pas le meilleur pour les entretiens (les ingénieurs expérimentés le déconseillent sur Quora et ailleurs), mais je ne voyais pas en quoi cela importait. Le but de l'entretien n'était pas de tester mon choix de langage – c'était de tester ma capacité à penser de manière abstraite et à résoudre des problèmes complexes liés à l'informatique.
Le langage n'est qu'un outil (une autre croyance fondamentale que je tiens). En fait, utiliser un langage non typé comme JS me donnerait des opportunités de parler de ses limitations ou de ses forces, ce qui est une opportunité de démontrer que je comprends les compromis dans les choix de langage. Ainsi, je pourrais mettre en avant des connaissances et des perspectives plus larges sans avoir à tout implémenter en code.
Mais beaucoup des ressources que j'ai apprises utilisaient Java ou C++. Ces langages sont les langages dominants chez Google. Donc être obligé de lire ces langages et de comprendre les principes m'a forcé à ne pas trop me concentrer sur "recracher le code" et plus sur le raisonnement à travers le code afin de pouvoir l'écrire.
Tel était mon plan entier. Pratique, Reconnaissance de Motifs, Modèles Mentaux/Pensée par Premiers Principes, Conception de Systèmes, faire moins de choses vraiment bien, et se concentrer sur l'obtention d'entretiens plutôt que simplement apprendre plus de code.
Comment se démarquer lors des entretiens
Comme je l'ai mentionné, nous avons tous des avantages et des inconvénients. Et nous pensons tous que nos inconvénients sont spéciaux, énormes et que nos avantages sont communs, banals et probablement pas très utiles.
Ce n'est pas vrai. Logiquement, si nous pensons tous que nos inconvénients sont graves, alors nous devrions tous succomber à eux. Pourtant, certaines personnes les surmontent. Pour découvrir que d'autres l'avaient encore pire et ont surmonté ceux-là.
Il est bien mieux de se concentrer sur ce que nous pouvons bien faire. Pour moi, je croyais vraiment que je pouvais apporter beaucoup de valeur à l'équipe. Je ne me soucie pas d'être le plus intelligent ou le meilleur. Mais je me soucie d'être un apprenant exceptionnel, et de maintenir mon état d'esprit de croissance à tout prix.
Et donc j'ai essayé d'utiliser cela pour me démarquer autant que possible. J'ai appris à poser de très bonnes questions aux recruteurs, aux intervieweurs et aux responsables de l'embauche.
Mais il y avait une raison plus profonde à cela. Poser de bonnes questions était ma façon d'interviewer l'entreprise. Comme je l'ai dit, je ne voulais pas répéter les erreurs de la première moitié de ma carrière. Donc poser de très bonnes questions était important pour moi afin d'évaluer si l'entreprise était adaptée pour moi et pas seulement l'inverse.
Puisque j'avais décidé que j'allais valoriser l'équipe et l'apprentissage par-dessus tout, je n'ai jamais demandé la compensation jusqu'à ce que le recruteur l'aborde. Cela serait de toute façon inférieur à ce que je gagnais en tant qu'avocat !
Au lieu de cela, je me suis concentré très fort sur l'apprentissage de l'équipe, de sa dynamique, de ses croyances et valeurs de groupe, de la manière dont le manager résolvait les problèmes (surtout les problèmes de personnes), de ce qui intéressait l'équipe, de ce qui intéressait la division de l'entreprise, de l'état de son bilan, de sa stratégie, de son allocation de ressources et de son budget, et ainsi de suite.
Toutes ces choses étaient des choses que j'avais apprises dans d'autres industries, en tant que contributeur individuel, manager, exécutif, fondateur, etc.
Et toutes ces choses montraient aussi que j'étais très intentionnel. J'étais vraiment intéressé par l'équipe, l'entreprise, son produit et son avenir. Ce n'était pas juste un autre emploi pour lequel je postulais. C'était actif et personnel... pas passif et opportuniste.
Et je crois que cela m'a aidé à me démarquer. Peut-être pas pour tous les rôles pour lesquels j'ai passé des entretiens, mais pour beaucoup des offres que j'ai reçues.
Lorsque j'étais du côté de l'embauche, je préférais toujours les candidats qui étaient vraiment intéressés par le rôle, les personnes, le produit et l'entreprise. Ceux qui se présentaient juste "pour obtenir un emploi" n'avaient pas le genre d'énergie et de motivation que nous voulions.
Planification et stratégie d'entretien
Le dernier aspect de ma feuille de route nécessitait que je comprenne profondément les différents types de processus d'entretien de codage.
Cela incluait les entretiens techniques et non techniques, le format des entretiens, la manière dont les entreprises les organisent, les exécutent, les planifient, les dotent en personnel, les évaluent et les pondèrent. Mais cela nécessitait aussi que je comprenne mes forces et mes faiblesses.
Lorsque je visais les grandes entreprises technologiques aux États-Unis, je visais 2 à 3 entretiens par mois – un objectif énorme étant donné que je n'étais même pas aux États-Unis et que je me trouvais dans un fuseau horaire qui était 17 heures en avance sur la côte ouest.
Je devais planifier et structurer les entretiens à des heures bizarres afin de pouvoir accommoder mon travail de jour en tant que développeur ainsi que mon temps d'étude. Certains entretiens duraient 6 heures, d'autres 10 ou plus. Certains étaient des entretiens de type "programmation en binôme pour une journée".
Tout cela a nécessité une tonne de planification et d'entraînement mental. Je devais faire attention à bien dormir, à bien faire de l'exercice, à maintenir mon état d'esprit et ma confiance, à livrer dans mon travail de jour, à être présent pour ma famille, à étudier et à maintenir mon focus sur mes objectifs.
Pour cela, je devais être honnête avec moi-même sur ce que je faisais bien. Par exemple, je ne suis pas une personne du matin. Mais je peux supporter les nuits tardives. J'ai donc structuré les entretiens, le travail, le sommeil, ou même l'exercice en conséquence.
Il y avait certains entretiens qui étaient programmés à 2h du matin ou après, et je ne dormais pas avant (car je ne suis vraiment pas bon pour me réveiller à l'heure !). Je faisais donc un entraînement complet à 1h du matin pour augmenter mon énergie et ma concentration, puis je passais l'entretien, puis je dormais jusqu'à 10h, puis j'allais travailler et gérais mon emploi du temps en conséquence.
Je faisais aussi attention à planifier les entretiens de manière à ne pas en faire deux à la suite, sauf s'ils étaient très similaires et limités dans le temps. Par exemple, faire un test à domicile et un test chronométré la même semaine nécessitent une planification différente de faire un test à domicile et un entretien de codage en direct – tout en gérant le travail et la famille.
Pour planifier les entretiens de manière appropriée, je travaillais en étroite collaboration avec le recruteur et j'étais très transparent avec eux. Cela avait deux avantages : je gagnais en crédibilité et en confiance avec le recruteur pour être collaboratif et communicatif, et ils voyaient aussi que j'avais d'autres opportunités en cours, ce qui augmentait la valeur de ma candidature. La compétition est une bonne chose.
Réflexions finales
Je suis sûr que beaucoup d'entre vous s'attendaient à ce que cet article donne des conseils "d'initiés" et un ensemble spécifique de langages, et des questions DSA à apprendre. Je crois vous avoir donné quelque chose de bien meilleur. Plutôt que de vous donner du poisson, je vous montre comment pêcher.
Outre l'éthique, les conseils d'initiés ont une valeur limitée, surtout dans les grandes entreprises technologiques. Dans les grandes entreprises, les choses peuvent être très différentes d'une équipe à l'autre et d'une ville à l'autre. Vous devez comprendre les principes du recrutement et du développement de carrière, plutôt que simplement les langages et algorithmes spécifiques. Supposer que tous les entretiens sont identiques est une grosse erreur.
Et en ce qui concerne notre obsession pour les structures de données et les algorithmes... gérer votre carrière est l'algorithme ultime. Votre esprit est la structure de données ultime. Apprenez à travailler avec les deux et vous vous en sortirez toujours bien, malgré les échecs occasionnels. Les idées puissantes ne sont pas grandioses – elles sont élégamment minimales.
Si vous avez lu cet article, vous aurez remarqué que certaines des choses que j'ai liées incluent plusieurs façons de me contacter. Vous pouvez également être invité à mes webinaires, mini-cours et newsletters si vous voulez aller au-delà du simple "apprendre à coder" et apprendre à construire une carrière qui est faite pour vous.
Peut-être le message le plus important que je puisse vous laisser est qu'il est une erreur de s'obséder sur les grandes entreprises technologiques. Oui, elles sont géniales à faire partie, mais si nous croyons qu'elles sont la seule chose qui nous convient, nous allons manquer toutes les autres opportunités incroyables.
Les grandes entreprises technologiques ont du glamour en raison des tendances culturelles de nos jours. Bien sûr, c'est agréable de travailler pour une grande organisation, mais de nombreuses grandes organisations ne sont pas bien connues. De plus, ce qui est "génial" pour une personne est une douleur pour une autre.
Votre priorité numéro un est d'être heureux, épanoui et de vivre la vie que vous voulez. Cela ne vient pas d'une entreprise. Cela vient des personnes avec lesquelles vous passez du temps (surtout les collègues) et du type de travail que vous faites. Les grandes entreprises technologiques ont leur part de mauvais managers, coéquipiers et travail, comme toute autre entreprise.
Si vous construisez des compétences, empilez un excellent plan sur le bon état d'esprit, et entraînez-vous à fixer les bons objectifs, vous pouvez accomplir bien plus que vous n'auriez rêvé – avec ou sans les grandes entreprises technologiques.
Post-scriptum
Si vous souhaitez en savoir plus sur mon parcours d'avocat à ingénieur logiciel, consultez l'épisode 53 du podcast freeCodeCamp ainsi que l'épisode 207 de "Lessons from a Quitter". Ces épisodes fournissent le plan de mon changement de carrière.
Si vous êtes intéressé par l'auto-apprentissage du codage, le changement de carrière et devenir un codeur professionnel, ou devenir votre propre co-fondateur technique, n'hésitez pas à me contacter ici. Vous pouvez également consulter mon webinaire gratuit sur Changer de Carrière pour le Codage si c'est ce dont vous rêvez.