Comment je suis passé de débutant à ingénieur logiciel en 9 mois tout en travaillant à temps plein

Dans cet article, je vais partager comment je suis passé de zéro (ish) à une offre d'emploi en génie logiciel à six chiffres en neuf mois tout en travaillant à temps plein et en étant autodidacte.

Chaque fois que je commençais à lire une histoire à succès, je cherchais immédiatement les antécédents de l'auteur, en espérant que cela correspondrait au mien. Je n'ai jamais trouvé quelqu'un qui avait le même parcours que moi, et le mien ne correspondra probablement pas exactement au vôtre.

Néanmoins, j'espère que mon histoire inspirera les autres et agira comme un point de données précieux qui peut être ajouté à votre ensemble de données de réussite.

Divulgation complète

J'ai suivi un cours Visual Basic pour Applications (VBA) au lycée (il y a neuf ans). Dans mon cours d'ingénierie de première année (il y a sept ans), j'ai appris un peu de C, Python, Matlab et Labview. Je suis diplômé d'une bonne université avec un diplôme en génie chimique et un bon GPA (il y a trois ans). Je n'avais fait aucun programme en dehors de l'école, au lycée ou au collège, jusqu'à ce que je décide que je voulais apprendre l'année dernière.

Après l'université, j'ai trouvé un emploi d'ingénieur de procédés dans une raffinerie. J'y ai travaillé jusqu'à ce que je change de carrière en génie logiciel.

Pourquoi j'ai voulu changer de carrière

J'aimais résoudre des problèmes techniques, mais je savais que je voulais entrer dans le monde des affaires / startup à un moment donné. J'ai toujours gardé l'idée d'un MBA au fond de ma tête, mais chaque fois que je regardais le prix des meilleures écoles, mon intérêt diminuait.

Le 27 mai 2017, je me suis retrouvé à googler à nouveau sur les MBA et je suis tombé sur le génie logiciel. Cela semblait être un ajustement parfait.

Les ingénieurs en logiciel sont de plus en plus demandés, les salaires sont excellents et c'est le secteur idéal pour entrer dans le monde des startups sans avoir besoin d'une tonne de capital initial. Tout ce dont vous avez besoin est un ordinateur et vos possibilités sont illimitées (en quelque sorte).

Dans aucune autre discipline d'ingénierie, vous ne pouvez avoir qu'une idée, commencer à la construire, la montrer aux utilisateurs et itérer avec peu de capital et une faible barrière à l'entrée. En génie chimique, vous avez essentiellement besoin d'une usine en marche ou de beaucoup d'argent pour concevoir une usine si vous avez une idée pour un nouveau produit.

J'avais entendu parler de gens qui quittaient leur emploi et participaient à un bootcamp, mais plus j'en lis à ce sujet en ligne, plus je me suis rendu compte que vous pouvez tout apprendre tout seul si vous êtes engagé et concentré.

Vous pourriez prétendre que vous perdez sur le réseautage et les conseils de carrière fournis par un bootcamp. Cela peut être vrai, mais j'ai eu la chance de vivre dans la région de la baie, ce qui m'a permis d'assister à plusieurs rencontres, alors j'ai mis en réseau de cette façon.

D'ailleurs, le pire des cas était que je me rendais compte que je ne pouvais pas le faire moi-même, puis je quittais mon travail pour assister à un bootcamp.

Le but

Vous devez avoir un objectif. Surtout si vous essayez d'apprendre tout en travaillant à temps plein. Il est facile de laisser votre apprentissage s'éterniser si vous n'avez aucune pression externe qui vous pousse. Vous devez donc créer une pression interne. Votre objectif doit être simple et quantitatif. Vous devriez faire suffisamment de recherches pour arriver à un objectif raisonnable. Le mien était le suivant:

Obtenez un emploi en génie logiciel dans un délai d'un an avec un salaire égal ou supérieur à celui que je gagne actuellement.

Le plan

Une fois que vous avez un objectif, vous avez besoin d'un plan pour vous aider à y parvenir. C'est là que vous consommez autant d'histoires de réussite que possible. Aucun d'entre eux ne correspondra à votre situation exacte, mais vous pouvez prendre quelques conseils de chacun d'eux. J'ai développé (et répété) mon plan en utilisant des ressources telles que le subreddit learnprogramming, le forum freeCodeCamp et Medium.

Le 27 mai 2017, j'ai décidé que j'allais faire le saut dans le codage et j'ai plongé la tête la première. Ce jour-là, j'ai décidé de ne pas consacrer plus de 40 heures par semaine à mon travail, pour avoir le temps de coder après le travail et le week-end. Heureusement pour vous, j'ai bien documenté mes progrès.

Mon plan, à travers de nombreuses itérations, a fini par ressembler à ceci:

  1. Suivez un cours d'introduction à CS pour acquérir une solide compréhension de base des concepts de base de CS
  2. Suivez freeCodeCamp jusqu'à ce que je puisse créer moi-même des applications Web complètes au niveau du portefeuille
  3. Refactoriser pour nettoyer le code, ajouter des tests, se concentrer sur les concepts avancés
  4. Contribuez à l'open source
  5. Préparez-vous aux entretiens d'embauche

Pour commencer, mon plan était simple. À l'époque, je pensais que j'allais suivre le guide technique de Google, alors j'ai commencé par leur cours d'introduction recommandé, Udacity CS101.

Mois 0 - Udacity CS101, Harvard CS50

Le high de cette grande décision m'a donné une tonne d'énergie. Je commençais à coder dès que je rentrais du travail et je ne m'arrêterais pas avant d'aller me coucher. Et puis encore tout le week-end. Udacity CS101 a suivi le pourcentage d'achèvement, ce qui a été une grande motivation pour moi. J'ai enregistré mon pourcentage d'achèvement chaque jour après le codage. J'ai terminé les premiers 75% en 10 jours. Le dernier 25% était lourd en récursion, et c'était un peu plus difficile pour moi. Dans l'ensemble, il m'a fallu 20 jours pour terminer Udacity CS101.

Pendant que je prenais Udacity CS101, j'avais commencé à lire assez intensément le subreddit learnprogramming. J'ai lu qu'il était important pour les développeurs autodidactes qui cherchent à changer de carrière d'être actifs en ligne. J'ai décidé de créer de nouveaux comptes Twitter, Reddit, Stack Overflow, Medium et Quora en utilisant mon nom complet, afin de pouvoir créer une présence en ligne.

J'ai également décidé d'arrêter de lire des médias distrayants comme Instagram, Facebook et les subreddits non programmables. Je ne vérifierais mon téléphone que pour les actualités et les publications liées à la programmation. C'était crucial pour m'assurer que je découvrais les meilleurs parcours d'apprentissage et les meilleures ressources d'apprentissage. C'est à cause de cela que j'ai découvert Harvard CS50 sur edX.

Au départ, je me contentais de faire un cours d'introduction, mais tout le monde semblait recommander Harvard CS50, alors j'ai décidé de me lancer dans ce prochain. Les étudiants CS d'autres écoles avaient suivi ce cours et ont déclaré avoir appris plus en CS50 qu'un an ou deux à leur université pour étudier le CS. Le consensus général était que le cours était difficile mais en valait la peine. À la fin du mois 0, j'avais terminé les 5 premières conférences et devoirs.

Mois 1 - Harvard CS50, Linux, 1er Meetup, freeCodeCamp

J'ai terminé CS50 à peu près à la moitié du mois. Je ne vais pas trop commenter mon expérience avec CS50, car j'ai écrit un article détaillé sur mon expérience ici.

TLDR: C'est un excellent cours, je le recommande vivement. David Malan est un excellent conférencier, et il existe une tonne de ressources pour vous aider à le traverser. Vous commencez en C, passez à Python, puis terminez par le développement Web. C'est très dense et il y a beaucoup de matériel, mais je pense que cela en vaut la peine.

Après CS50, j'ai décidé de configurer mon XPS 15 pour double démarrage Windows et Ubuntu. Ce fut un week-end frustrant. J'ai gâché mes cloisons et presque ma brique. J'étais sur le point de jeter mon ordinateur portable et d'en obtenir un nouveau.

Je me suis lentement sevré de Windows et j'ai finalement utilisé uniquement Ubuntu. Je voulais me forcer à me familiariser avec la ligne de commande qui, je pense, a fonctionné dans une certaine mesure, mais il me reste encore beaucoup de chemin à parcourir.

J'ai commencé 100 jours de code pour m'assurer de rester concentré et codé chaque jour.Il est important de documenter vos progrès. Si vous faites des progrès tous les jours, cela ne vous semblera pas grand-chose, mais en regardant un mois ou plusieurs mois en arrière, vous vous rendrez compte que vous avez en fait fait pas mal de progrès qui vous motivent à continuer.

Je savais que le réseautage me ferait ou me briserait, alors j'ai rassemblé le courage d'aller à ma première rencontre de codage. Je n'étais jamais allé à aucune rencontre et encore moins à une rencontre de codage. J'étais tellement nerveux qu'après avoir conduit là-bas, me garer et marcher jusqu'à la porte, j'ai failli me retourner et rentrer chez moi.

Cela a aidé que ce soit la première rencontre du groupe. J'ai vite compris qu'il n'y avait aucune raison d'être nerveux. Personne ne se connaissait, personne ne portait de jugement et tout le monde était impatient d'apprendre. C'était le début d'une frénésie de rencontres. J'ai fini par assister à plus de 50 rencontres en 9 mois.

Je suis content d'avoir commencé à me rencontrer tôt. La plupart des gens n'ont commencé à assister aux rencontres que lorsqu'ils cherchaient un emploi, mais à ce moment-là, il est presque trop tard. Il y a tellement de raisons de commencer tôt. Pour n'en nommer que quelques-uns:

  1. Développer des relations prend du temps. Commencer tôt signifie que vous avez des contacts qui peuvent se porter garant de vous lors de la recherche d'un emploi plus tard
  2. Parler de programmation avec des inconnus est un excellent moyen de se préparer aux entretiens
  3. Vous pouvez apprendre de nouveaux cadres, outils et ressources d'apprentissage de personnes qui sont en avance sur vous. Cela peut influencer votre futur plan d'apprentissage.

Il y avait une certaine incertitude à ce moment dans mon parcours de codage. C'était à peu près au moment où je devais décider quel type de développeur de logiciels je voulais être.

En fin de compte, j'ai choisi le développement Web car il me semblait qu'il y avait une forte demande et aussi beaucoup de ressources en ligne. Une fois que j'avais compris cela, j'avais besoin de savoir quoi faire ensuite. Certaines personnes ont recommandé qu'à ce stade, je devrais penser aux applications Web que je voulais créer, puis commencer. Certaines personnes ont recommandé The Odin Project ou freeCodeCamp.

Le gars qui dirigeait la rencontre hebdomadaire à laquelle j'assistais connaissait Ruby et voulait faire des projets avec Ruby. C'est l'une des principales raisons pour lesquelles j'ai pris la décision de me lancer dans le projet Odin.

Et puis deux jours plus tard, j'ai abandonné cette idée.

C'est l'un des inconvénients de la voie autodidacte. Une minute, vous pensez savoir quel chemin vous devez emprunter, mais le lendemain, vous vous demandez si c'était la bonne décision.

J'ai lu que Ruby tombait en disgrâce, et je l'ai prouvé en recherchant des emplois Ruby vs JavaScript, alors j'ai fini par démarrer freeCodeCamp. La seule chose qui m'a dérangé à propos de freeCodeCamp, c'est qu'ils ont proposé des idées de projets, donc chaque campeur fait les mêmes projets. Cela m'a préoccupé au début car je voulais me démarquer auprès des recruteurs. Cependant, j'ai fini par aimer freeCodeCamp, et maintenant je le recommande vivement. Pour plus de détails sur mon expérience et mes recommandations concernant freeCodeCamp, consultez mon article ici.

Mois 2 - YDKJS, freeCodeCamp Front End, React

J'ai commencé à lire You Don't Know JavaScript, car tout le monde l'a recommandé pour compléter freeCodeCamp. J'ai dû relire plusieurs sections car c'est assez dense, mais c'est une ressource parfaite pour apprendre la portée lexicale, les fermetures, les promesses et toutes les parties de JavaScript dont vous entendez parler et que vous voulez apprendre mais ne le faites jamais parce qu'elles semblent difficiles.

J'ai terminé la section frontale de freeCodeCamp. Le format de la liste de contrôle et le temps d'exécution estimé m'ont motivé à terminer rapidement. J'avais également hâte de passer à la section suivante et d'apprendre React. Cependant, cela signifiait également que mes projets avaient un style minimal. J'ai fait tout ce qu'il fallait pour réaliser les user stories et rien de plus.

Avec le recul, j'aurais peut-être dû me concentrer sur le fait de rendre les projets plus attrayants. Peut-être que cela m'aurait aidé à apprendre le CSS plus profondément.

L'étape suivante a été d'apprendre React, et j'étais plutôt excité.

J'en avais tellement entendu parler et j'étais prêt à m'intégrer aux enfants cool. Cependant, j'étais un peu hésitant étant donné les problèmes de licence à l'époque. Je suis vraiment content que ce ne soit plus un problème. Apprendre React a été difficile pour moi. Je n'étais pas au courant de bons tutoriels à l'époque (mais il semble qu'il y en ait une tonne maintenant).

J'ai essayé de lire la documentation et de suivre le didacticiel Tic-Tac-Toe de Facebook, mais je n'ai pas tout compris. On m'a dit que si cela ne fonctionnait pas pour moi, cela signifiait que je ne comprenais pas assez JavaScript. Alors je suis retourné à la lecture de You Don't Know JavaScript, mais encore une fois, c'était trop dense pour moi.

Mois 3 - freeCodeCamp React, CodeClub, démarrage du back-end freeCodeCamp

En fin de compte, j'ai juste décidé que je travaillerais à travers les projets freeCodeCamp React pour voir comment cela se passait. Ce code était moche, mais il m'a aidé à comprendre un peu mieux React.

Cette rencontre à laquelle j'avais participé chaque semaine a décidé qu'ils allaient créer des projets avec JavaScript full stack au lieu de Ruby, et ils ont décidé que le premier projet serait de créer un site Web pour le groupe Meetup, CodeClub.Social.

J'ai développé des cartes en utilisant l'API React et Meetup permettant à l'utilisateur de s'inscrire aux trois prochaines rencontres depuis notre site Web. C'était un peu difficile pour moi de faire une petite pause dans freeCodeCamp pour faire ça, mais c'était une opportunité que je ne pouvais pas laisser passer. J'étais heureux de travailler sur un projet avec un petit groupe de personnes. Cela m'a également aidé à apprendre Git et Github.

Avant la fin du mois, j'ai commencé à travailler sur la section back-end de freeCodeCamp.

Mois 4 - Terminé freeCodeCamp Back End, Yeggle

J'ai travaillé sur tous les projets d'API de freeCodeCamp, mais j'ai commencé à dévier de freeCodeCamp au niveau du projet Image Search Abstraction Layer.

J'avais hâte de créer des applications web full stack, donc dès que j'ai vu le titre de ce projet, j'ai eu une idée pour mon propre projet. Je créerais une application de nœud qui stockerait des URL imgur aléatoires dans une base de données, puis créerais un frontal qui produirait un nombre spécifié par l'utilisateur de ces images aléatoires. Ce que tout le monde dit est vrai: vous travaillez plus dur et avez plus de succès lorsque vous travaillez sur un projet qui était votre propre idée.

Une fois que je l'ai fait fonctionner, j'étais très fier de moi. C'était moche et maladroit, mais cela a fonctionné.

Alors que je travaillais avec freeCodeCamp, j'apprenais quels projets seraient dans mes capacités. Je courais régulièrement à l'époque, donc je trouvais des idées sur mes courses et les écrivais quand je rentrais à la maison. De cette façon, j'aurais une liste d'idées de projets lorsque je serais prêt.

Je me suis enfin senti prêt à commencer à créer mes propres applications Web complètes utiles et raffinées à partager avec les utilisateurs et à intégrer à mon portefeuille. J'étais tellement prêt à commencer.

Lorsque je cherchais un nouveau restaurant, je me retrouvais toujours à ouvrir Yelp pour vérifier les avis, puis à ouvrir Maps pour vérifier leurs avis. Et si je créais une application qui comparait les deux côte à côte?

Alors j'ai fait Yeggle. J'ai utilisé Node / Express / React avec les API Google Maps et Yelp. Il y avait quelques obstacles que je ne pensais pas pouvoir surmonter, mais à la fin j'ai terminé et j'étais très fier de mon application. Ensuite, je l'ai posté sur Reddit, et personne ne s'en souciait. C'était un peu décevant, mais je ne me suis pas laissé abattre.

Mois 5 - StockIT

Je n'ai pas fait autant ce mois-ci, car j'ai commencé par deux semaines de vacances au Japon et en Thaïlande!

Mais j'ai commencé et terminé mon prochain projet. J'ai continué à lire à quel point il était difficile d'obtenir un emploi de développeur autodidacte, alors j'ai pensé que je devais faire quelque chose d'unique. Je me suis souvenu d'un jeu où un graphique boursier Dow Jones commençait à évoluer, et vous aviez une opportunité d'acheter et une opportunité de vendre, et l'objectif était de battre le marché. Le but du jeu était de vous montrer à quel point il était difficile de battre le marché.

Mon idée était de créer un jeu similaire à celui-là, mais au lieu du marché, vous joueriez contre un algorithme d'apprentissage automatique. J'ai donc créé StockIT.

J'ai suivi un didacticiel vidéo sur Pandas et Scikit Learn qui couvrait plusieurs techniques d'apprentissage automatique. Au départ, je voulais faire des techniques d'apprentissage en profondeur intéressantes, mais j'ai réalisé que cela prenait d'énormes ensembles de données et plus de temps que je ne voulais en passer.

Au lieu de cela, je suis resté fidèle à un modèle de régression linéaire simple. Je pensais que ce serait la partie la plus difficile, mais ce n'était pas le cas. Faire fonctionner D3 avec React a été la partie la plus difficile. Les deux bibliothèques voulaient contrôler le DOM. Il y avait quelques autres bibliothèques qui ont aidé à rejoindre les deux, mais j'ai senti qu'elles étaient trop gonflées. J'ai fini par utiliser D3 pour générer les SVG et React pour gérer le DOM qui a très bien fonctionné pour moi.

Cette fois, quand je l'ai partagé avec Reddit, tout le monde a adoré!

Il s'avère que, tout comme les VC, les redditors concernent uniquement l'apprentissage automatique. Tout l'amour de Reddit a été un grand regain de confiance. Les gens jouaient à mon jeu et en profitaient!

Mois 6 - jobSort (), préparation à la recherche d'emploi

Après StockIT, je suis entré directement dans mon prochain projet personnel. Je voulais créer un babillard d'emplois regroupant les plus petits sites Web de listes d'emplois axés sur la technologie tels que Stack Overflow, Github et Hacker News. Pour y ajouter ma propre tournure, j'ai décidé de le trier en fonction des technologies que l'utilisateur souhaitait dans un travail et à quel point il voulait chacune d'elles.

Par exemple, disons que je cherchais un emploi qui recherchait quelqu'un qui connaissait JavaScript, React et / ou Python, et que je voulais vraiment travailler avec JavaScript et React, mais je ne me souciais pas tellement de Python. Ensuite, je pourrais donner à JavaScript un 3, React un 3, et peut-être Python un 1. Les listes seraient alors triées en conséquence.

J'ai rencontré divers obstacles avec ce projet et j'ai dû changer de cap à quelques reprises, mais je me suis retrouvé avec un produit dont j'étais satisfait. Ma pile technique finale était React / Node / Express / MySQL. J'ai posté le projet sur le sous-répertoire cscareerquestions et j'ai obtenu 650 vues avant qu'il ne soit retiré car ils n'autorisent pas les projets personnels.

Le produit «final» est ici, et si vous souhaitez en savoir plus sur mes luttes et mes refacteurs, consultez mon article ici.

En raison de mes problèmes, jobSort () a pris une bonne partie du mois. J'ai fini par prendre un café avec un ami que j'avais rencontré lors de ma première rencontre, et il m'a conseillé de commencer à postuler pour un emploi maintenant. J'ai lu partout que tout le monde dit avoir attendu trop longtemps pour postuler. De plus, chaque fois que je voyais un message demandant quand postuler, le commentaire principal était toujours «maintenant».

Dans ma tête, j'allais travailler mon chemin à travers mon plan structuré pour construire mon portefeuille avec des projets personnels, puis travailler sur des contributions open source, puis me préparer aux entretiens, et enfin commencer à postuler à des emplois. Cet ami m'a convaincu d'abandonner ce plan et de commencer à postuler. Alors ce mois-ci, j'ai fait un portfolio et un CV. Le mois suivant, je commencerais à postuler.

Mois 7 - Essais, recherche d'emploi

Ce mois-ci, je me suis concentré sur la retouche de mes projets et sur ma candidature à des emplois. Je voulais aussi apprendre les tests et Redux.

J'ai ajouté flexbox à CodeClub.Social pour le rendre réactif. J'ai amélioré l'UX mobile sur jobSort (). J'ai ajouté des tests à jobSort () avec moka / chai / enzyme qui était difficile à mettre en place, facile à démarrer, puis difficile à obtenir une couverture à 100%.

À la fin du mois, j'avais postulé à 63 emplois. J'ai vu cela comme une auto-évaluation. Mon portfolio / CV était-il assez bon? Si oui, sur quoi ai-je besoin de travailler pour me préparer aux entretiens? Au début, j'ai postulé avec Hacker News: Who is Hiring, and Indeed.

Sur Hacker News, j'ai utilisé jobSort () pour déterminer les annonces pour lesquelles postuler. Sur Indeed, j'ai essayé des sociétés non logicielles pour voir si je pouvais même recevoir un appel ou une interview n'importe où.

Au début, je postulais rapidement et je ne personnalisais pas mon CV / lettre de motivation. Ensuite, j'ai décidé de personnaliser ma lettre de motivation et mon CV, puis j'ai essayé d'envoyer un e-mail à quelqu'un de l'entreprise. Cette méthode était clairement meilleure que l'approche au fusil de chasse.

J'ai reçu cinq appels ce mois-là - deux de sociétés de recrutement et trois de sociétés de logiciels comprenant:

  • un contrat DevOps / rôle de test dans une entreprise dotcom
  • une société d'analyse alimentaire de série B, et
  • une startup assez grande et réussie qui a été récemment achetée par une grande entreprise

J'ai dépassé l'écran des RH dans deux d'entre eux, mais aucun d'entre eux n'a donné lieu à un entretien sur place. J'étais plutôt content des trois appels et j'ai beaucoup appris d'eux.

Tout le monde a mentionné en ligne qu'on ne s'attend pas à ce que les développeurs juniors en sachent autant dès le départ, ils ont juste besoin d'être passionnés et enthousiastes à l'idée d'apprendre. Alors j'ai pensé, facile. Je suis passionné et enthousiaste à l'idée d'apprendre. Ce que j'ai appris de ces appels, cependant, c'est que personne ne recherchait un développeur junior. Ils s'attendent à ce que vous sachiez ce que vous faites dès le premier jour.

Ces appels m'ont appris que je devais

  • être assez bon pour ajouter de la valeur dès le premier jour
  • être suffisamment confiant pour les convaincre que je peux ajouter de la valeur dès le premier jour

Mois 8 - Night Shift, Redux, Open Source, Entretien sur site

J'ai commencé ce mois-ci à travailler le quart de nuit pendant 40 jours à mon travail à plein temps - 6 jours par semaine, 12 heures par jour, 17 heures-5 heures. Pouah.

Je savais que je ne pourrais pas en faire autant ce mois-ci, mais j'avais un objectif et je voulais l'atteindre, donc je ne pouvais pas prendre un mois de congé.

J'ai remanié jobSort pour utiliser Redux, ce qui n'était étonnamment pas aussi difficile que je le pensais. J'ai écouté beaucoup de podcasts à ce sujet et lu des articles de blog à ce sujet, et cela n'a jamais vraiment eu de sens jusqu'à ce que je commence à l'utiliser.

J'aime beaucoup le flux de données avec Redux. C'est intéressant de voir maintenant les gens se plaindre de Redux. Je ne pense pas être qualifié pour exprimer fortement mes opinions, mais j'aime le modèle réducteur.

C'était censé être le mois de l'open source pour moi. J'allais faire ma première contribution open source, et ce serait une grande contribution à une bibliothèque fantastique. J'allais contribuer à React!

Tout le monde a dit que c'était une base de code difficile à lire et encore moins à contribuer. Mais j'avais besoin de me démarquer, j'avais besoin d'être unique. Je savais que ma contribution ne serait pas significative, mais je voulais quand même le faire.

Je commencerais par lire les documents jusqu'au bout, puis en parcourant la base de code. Regardez chaque numéro, chaque PR. La lecture complète de la documentation React a été un excellent exercice, et je suis content de l'avoir fait. Mais je me suis vite rendu compte que le problème avec la contribution à React est qu'il n'y a tout simplement pas beaucoup de «bons premiers problèmes», et ils sont rapidement rattrapés.

Lors de l'une des rencontres auxquelles j'ai assisté, Anthony Ng m'a recommandé d'essayer Downshift, une bibliothèque à saisie semi-automatique de Kent C. Dodds. C'était un changement de jeu. C'était juste dans ma timonerie. La bonne difficulté, la bonne quantité de problèmes à résoudre, pas trop de collaborateurs, un mainteneur super utile, un code propre et bien testé. En plus de tout cela, c'était une solution parfaite à certains problèmes que j'avais avec mon application jobSort ().

Vers la moitié du mois, j'ai reçu un e-mail de l'une des entreprises auxquelles j'ai postulé le mois précédent. Ils ont mis en place un écran de téléphone initial, puis un écran de téléphone technique. Les technologies qu'ils recherchaient étaient exactement ce que j'avais appris - React, Redux et D3. J'ai surtout parlé de mes projets et des raisons pour lesquelles j'ai pris certaines décisions. Après cela, ils m'ont demandé de venir sur place pour une entrevue. Mon premier entretien sur place!

Je ne m'étais pas préparé du tout pour les entretiens, alors j'y suis allé avec l'espoir de ne pas obtenir le poste, mais j'acquérirais une expérience d'entrevue précieuse. Je courais aussi sur trois heures de sommeil puisque je travaillais toujours le quart de nuit, ce qui n'aidait pas. Heureusement, la partie technique n'était pas le tableau blanc, juste une session de programmation en binôme d'une heure. C'était un défi assez simple, mais j'étais très nerveux.

Au début, je m'inquiétais de m'assurer de tout savoir sans chercher. Quand j'ai réalisé que je n'allais pas terminer le défi, j'ai réalisé que je devais arrêter de m'inquiéter de ce que l'intervieweur pensait de moi et juste débordement de Google / stack pour trouver des réponses. Je n'ai pas fini par finir et j'ai pensé que j'avais lamentablement échoué.

Comme je pensais avoir échoué à la programmation en binôme, je me suis senti détendu pour le reste de l'entrevue. En fin de compte, j'ai quitté l'entrevue la tête haute. Dans le pire des cas, j'ai eu une expérience d'entrevue précieuse et, dans le meilleur des cas, j'ai reçu ma première offre d'emploi.

Mois 9 - Offre d'emploi

J'ai fini par recevoir ma première offre d'emploi 9 mois et 7 jours après ce premier jour où j'ai décidé que j'allais me plonger tête la première dans la programmation avec l'intention de changer de carrière. Je me sentais confiant étant donné que j'avais reçu une offre après mon premier entretien sur place, mais en même temps, si je n'acceptais pas l'offre, que se passerait-il si c'était la seule offre que je recevrais pendant plusieurs mois? J'ai fini par accepter l'offre et je suis content de ma décision. Je voulais être payé pour coder!

Conseil

Jusqu'à présent, j'ai surtout partagé mon histoire avec quelques conseils parsemés. Si vous lisez ceci, il est probable que vous envisagiez de changer de carrière ou que vous soyez en train d'apprendre à coder dans le but de changer de carrière. J'espère que les conseils ci-dessous vous aideront à élaborer un plan ou à vous en tenir à votre plan actuel et à atteindre votre objectif.

  1. Découvrez ce qui vous motive et utilisez-le à votre avantage. Pour moi, il s'agissait de listes de contrôle, de documenter mes progrès et d'interagir avec diverses communautés de programmation. Si vous n'êtes pas motivé pour atteindre votre objectif, rien d'autre ne compte car vous ne finirez pas.
  2. Fixez-vous des objectifs et atteignez-les. Je dirais que vous devriez avoir des objectifs mensuels et peut-être même des objectifs quotidiens. Des objectifs mensuels pour vous assurer que vous êtes sur la bonne voie pour atteindre votre objectif principal et des objectifs quotidiens pour vous assurer que vous faites réellement des progrès quotidiens. Une stratégie qui a fonctionné pour moi était de fixer mes objectifs quotidiens la veille au soir. De cette façon, vous ne pouvez pas faire de travail improductif toute la journée et avoir l'impression d'avoir fait des progrès alors que vous ne l'avez pas vraiment fait. Cela vous oblige à comparer vos réalisations quotidiennes avec vos objectifs quotidiens.
  3. Allez aux rencontres bien avant de penser que vous êtes prêt. Aller à des rencontres peut sembler effrayant, mais comme je l'ai mentionné ci-dessus. Mais, en général, tout le monde est gentil et prêt à aider. Vous pourriez trouver des gens qui ne sont pas intéressés à parler avec vous, mais ils sont minoritaires et personne ne portera de jugement. De plus, tout le monde aime donner des conseils (comme je le fais en ce moment).
  4. Contribuez à l'open source bien avant de penser que vous êtes prêt. Lorsque vous commencez à programmer, Github ressemble à cet endroit effrayant où vous ne voulez jamais aller. C'est en fait très accueillant pour les débutants et c'est un excellent endroit pour voir du bon code et faire réviser votre propre code. Si vous n'êtes toujours pas convaincu, consultez mon article, Pourquoi vous devriez contribuer à l'open source maintenant.
  5. Commencez à postuler bien avant de penser que vous êtes prêt. Celui-ci a été difficile pour moi parce que je pensais que j'étais différent. Je pensais que je n'avais pas besoin de tester le marché pour avoir une idée de ce sur quoi travailler. Je pensais que je saurais quand je serais prêt à postuler. Je vous le dis maintenant. Vous ne saurez pas quand postuler. Alors vous pourriez aussi bien commencer maintenant. Vous ne devriez pas devenir fou et postuler auprès de 300 entreprises avant d'apprendre les boucles. Mais sachez que la meilleure façon de savoir ce que vous devez apprendre est d'appliquer et de tester le marché.

Maintenant, revenez et codez!