Les entretiens techniques ont beaucoup évolué depuis que je suis passé d'ingénieur logiciel à responsable ingénierie. Particulièrement dans l'ère post-Covid, l'accent a été mis davantage sur la personne, ce qui, à mon avis, est un changement important et bienvenu.
Au cours de la décennie passée à interviewer des centaines de codeurs, j'ai également eu le plaisir de travailler avec divers bootcamps, collèges et des centaines de demandeurs d'emploi individuels sur LinkedIn. À travers tous les changements au cours des dernières années, à travers les différents lieux et supports, quelque chose est resté constant tout au long : Les questions qu'on me pose.
Dans cet esprit, j'ai pensé - pourquoi ne pas créer une FAQ de mon point de vue en tant que responsable du recrutement ?
Bien que ce soit mon point de vue, il est basé sur des années d'observation et de données à l'appui. Mais cela étant dit, un conseil n'est pas un fait. Vous pouvez être en désaccord avec certains points, et c'est OK. Les opinions avec lesquelles nous ne sommes pas d'accord nous permettent de mieux comprendre nos propres points de vue. Au mieux, j'espère que ces réponses vous aideront à décrocher l'emploi de vos rêves. Au pire, j'espère qu'ils vous aideront à vous forger vos propres idées sur la façon d'aborder votre carrière.
Dans cette partie, je vais me concentrer sur les questions que j'ai reçues sur les portfolios et GitHubs .
Ai-je vraiment besoin d'un portfolio/site Web ?
Cela dépend vraiment - mais je suis extrêmement en faveur d'eux. Les CV me montrent votre côté professionnel. Les portfolios mettent en valeur votre personnalité, vos intérêts. Ils donnent aux recruteurs une idée différente de qui vous êtes et de la façon dont vous cherchez à évoluer.
Bien sûr, tout le monde n'en a pas besoin - ou n'a pas envie d'en construire un. Je connais de nombreux codeurs à succès qui n'ont pas de portfolio/site Web et n'en ont jamais eu besoin. En fait, la plupart des développeurs que je connais n'en ont pas. Et si c'est le cas, pourquoi est-ce que je pousse pour eux ?
La réponse simple est que c'est un jeu de cotes. Tech Hiring est un monde sauvage en ce moment - il y a beaucoup de demande, beaucoup de candidats, c'est ultra-compétitif mais les gens ont aussi du mal à trouver des emplois. Un portefeuille ne vous garantira pas de décrocher un emploi, mais il vous donne un avantage significatif sur les autres candidats à condition que vous le fassiez correctement.
Votre portefeuille n'a pas besoin d'être une entreprise énorme - et parce que les avantages l'emportent de loin sur les coûts, je pense que les construire a beaucoup de sens. Parce que les portfolios sont personnels, je pense que les gens sont submergés par "l'art du possible" - et ensuite ils ne produisent jamais rien.
Si vous construisez votre portefeuille de manière itérative, en commençant petit et en ne l'élargissant qu'au besoin et selon le temps dont vous disposez, c'est un excellent moyen de vous établir.
Pour en savoir plus, voici quelques ressources sur la façon de vous constituer un portefeuille qui tue :
Qu'est-ce que je mets même sur mon portefeuille?
Tout d'abord, connaissez votre public. Votre portefeuille n'est pas pour vos amis, votre famille - votre véritable public est le responsable du recrutement. Vous voulez concentrer votre contenu de manière à ce qu'il soit facile à consommer - alors concentrez-vous sur la façon dont vous présentez les choses. Considérez-le comme votre CV + votre créativité. Ajoutez-y du style mais rendez-le utilisable.
Je suis un grand fan des visuels rapides qui aident quelqu'un à se faire une idée de ce que vous pouvez faire - qu'il s'agisse de répertorier vos langues, de répertorier vos années d'expérience avec chacun, de répertorier vos projets, de le rendre visuel, interactif, mais ne le faites pas ajouter toute "friction" à elle non plus. Je veux dire par là que les diaporamas lents qui m'obligent à m'asseoir et à attendre que les choses apparaissent et disparaissent ne sont pas une bonne approche. Listez tout pour que je puisse le voir, le consommer et passer à autre chose.
Une autre chose est: donnez-lui un peu de vie. Ne donnez pas l'impression que vous l'avez construit il y a des années et que vous l'avez oublié - ajoutez des éléments dynamiques pour qu'il ait toujours l'air frais. Faites en sorte qu'il se nourrisse de votre Twitter, ou créez simplement une petite intégration dans votre blog, ou ayez simplement un "micro-blog" qui tient les gens au courant de ce sur quoi vous travaillez.
Le contenu principal est tout autour de vos projets. Qu'avez-vous construit, qu'est-ce que vous construisez. Incluez de belles descriptions qui couvrent ce que vous avez appris, ce qui vous a mis au défi, ce dont vous êtes fier, ce que vous feriez mieux. Impacts et résultats.
Ce modèle que j'ai créé est le strict minimum que vous devriez lister. Tout est statique, les éléments de conception sont minimes, mais cela aide vraiment un responsable du recrutement à comprendre qui vous êtes :
Comme vous pouvez le constater, les éléments clés à énumérer sont :
La pile technologique et les méthodologies que vous connaissez
Une mini bio
Liens importants - vers votre GitHub, votre CV, votre LinkedIn,
Des visuels rapides qui résument votre carrière
Projets, avec la pile technologique et des liens vers GitHub
Des sections "en direct" que vous pouvez facilement mettre à jour avec ce sur quoi vous travaillez/lisez (mettez-les à jour peut-être une fois par mois.)
Comme je l'ai déjà dit, cela devrait vous prendre plus d'un week-end pour construire quelque chose comme ça et cela aidera à donner à votre application un avantage supplémentaire.
Au fur et à mesure que vous progressez dans votre carrière, sa mise à jour devient assez triviale.
Ne puis-je pas simplement utiliser GitHub ?
Vous pouvez - oui. Mais ne vous contentez pas de déposer vos projets sur GitHub et de vous arrêter là. Créez une page de destination GitHub appropriée et utilisez-la comme portefeuille.
Vous pouvez le construire en utilisant les pages GitHub - suivez simplement les mêmes principes que ceux que j'ai énumérés ci-dessus.
Dois-je obtenir mon propre nom de domaine ?
Vous n'en avez pas besoin - mais avoir votre propre domaine, c'est comme avoir votre papeterie. C'est une belle touche.
À quel point dois-je personnaliser mon site Web ? Dois-je partager des photos de famille ? Recettes? Une photo de ma salamandre de compagnie ?
Partagez ce que vous aimez - sachez finalement que c'est le but. Ce n'est pas censé être un profil Facebook - mais ce n'est pas non plus censé être un profil LinkedIn non plus. Votre auditoire serait un gestionnaire d'embauche.
Aidez-les à apprendre à vous connaître socialement et professionnellement .
Dois-je m'inquiéter du référencement, des classements de pages, etc. ?
Non. C'est fini de le faire. Gardez votre HTML propre - mais ne vous inquiétez pas non plus.
Ne faites que ce qui est le plus pertinent pour les rôles que vous poursuivez : s'il s'agit d'un développeur Node, construisez des choses avec Node. S'il s'agit de SEO, alors bien sûr - optimiser pour les moteurs de recherche. Mais si vous êtes un ingénieur SQL, je ne vais probablement pas vous juger sur vos compétences en HTML/CSS.
Dois-je inclure un CV téléchargeable / mon email ?
Cela dépend en fin de compte de vous - mais si vous incluez l'un ou l'autre, méfiez-vous des informations que vous rendez publiques. Supprimez peut-être votre numéro de téléphone de votre CV téléchargeable. Assurez-vous que votre fournisseur de messagerie filtrera les spams.
Alternativement, dirigez les gens vers votre LinkedIn ou incluez un formulaire où ils peuvent entrer en contact avec vous.
À quoi devrait ressembler ma landing page GitHub ?
Rédigez un fichier ReadMe simple qui imite le contenu de votre portfolio. Simple, propre et élégant. Vous allez vouloir le maintenir à jour, alors assurez-vous de le construire de manière à ce que cela demande un minimum d'effort.
Épinglez vos projets et incluez des liens importants vers votre portfolio/LinkedIn.
Vous n'avez pas besoin d'en faire trop cependant. Bien qu'il y en ait d'étonnants, je pense que la simplicité est la meilleure approche (à moins que vous ne le construisiez à la place d'un portefeuille).
Pour référence, voici ma propre page d'accueil GitHub : GitHub - Alishah Novin
Dois-je vraiment créer mes pages de projet ?
Assurez-vous d'avoir un fichier Lisez-moi. Vous pouvez faire beaucoup avec eux - et je les approcherais comme si vous l'écriviez pour d'autres développeurs (en pensant secrètement au responsable du recrutement.)
Dans un cadre professionnel, vous aurez souvent besoin d'expliquer ce que fait un produit ou une fonctionnalité, comment il doit être utilisé, quelles sont ses limites, etc. C'est l'occasion pour vous de le montrer à un responsable du recrutement. d'autres développeurs qui consommeront votre projet, rappelez-vous que votre véritable public est le responsable du recrutement.
Fournissez un aperçu, fournissez des captures d'écran, fournissez un journal des modifications. Documentez les choses pour montrer que vous pouvez communiquer des concepts techniques.
Comme autre exemple, pour référence, ma page GitHub pour code / collision . Gardez à l'esprit qu'il y en a de bien meilleurs, mais j'ai construit cette page pour donner une idée de ce à quoi votre strict minimum devrait ressembler.
Ne vous contentez pas de télécharger votre projet et de l'appeler un jour.
Dois-je m'inquiéter de la qualité de mon code ou de la quantité de commentaires que j'ai faits ?
Votre code sera examiné, oui. Les gens chercheront des commentaires et les liront. Ils n'entreront probablement pas dans les détails, mais vous voudrez vous assurer que vos fichiers de code sont présentables.
Traitez-le comme vous le feriez pour un vrai projet. Surtout si vous avez amélioré un algorithme, assurez-vous qu'il apparaît dans vos commentaires de validation.
Les responsables du recrutement ne resteront probablement pas là à disséquer votre code pour s'assurer qu'il est hyper-efficace - mais ils l'examineront pour avoir une idée de ce que vous savez/ne savez pas.
Méfiez-vous de l'ingénierie excessive ou de l'écriture de code spaghetti trop compliqué. En fait, essayez de réduire les odeurs de code.
Une excellente ressource que j'aime et qui vous aide à écrire du code super présentable est Refactoring and Design Patterns .
Dois-je inclure mon GitHub sur mon CV ?
Oui. En tant qu'URL et non en tant que texte lié. Les CV sont imprimés - et, pour autant que je sache, vous ne pouvez pas cliquer sur un lien sur papier.
Dois-je inclure mon GitHub sur mon LinkedIn ?
Oui.
Dois-je m'inquiéter de l'activité de mon GitHub ?
Non. C'est une pression inutile que nous, les codeurs, nous mettons nous-mêmes. Nous voulons le mur de verdure tant convoité. Bien qu'avoir plusieurs engagements quotidiens soit formidable, cela ne vous garantira pas un emploi. Ne vous souciez plus d'avoir une fréquence élevée de commits, mais plutôt d'avoir des commits percutants : des projets qui montrent votre évolution et votre croissance en tant que développeur. Cela peut être juste quelques-uns par mois.
D'un autre côté, assurez-vous de ne pas avoir des tonnes et des tonnes de projets abandonnés/inachevés. Ayez des idées complètes - elles peuvent toutes être à différents stades d'achèvement, mais n'avez pas plus de 2 projets qui ne sont pas au stade MVP. Terminez ce que vous commencez. Sacrifiez la nouveauté pour la nuance.
Dois-je inclure des projets de cours ?
Les cours ne sont bons qu'en l'absence de vos propres projets. Gardez les cours visibles jusqu'à ce que vous ayez vos propres projets sur lesquels vous appuyer, puis masquez les devoirs.
Dois-je inclure tous mes projets ?
N'incluez que celles qui sont des idées complètes et complètes - elles ne doivent pas nécessairement être des produits complets. J'aime faire la distinction entre les projets et les produits. Un "produit" construit un clone complet de Twitter/Facebook. La taille et la portée des produits peuvent être si importantes que vous ne les terminerez peut-être jamais vraiment - et cela ne vous servira pas à grand-chose car cela submergera le responsable du recrutement.
Les "projets" sont des unités de travail plus discrètes. Une bibliothèque. Une expérience.
Vous devez absolument partager des projets et inclure dans votre rédaction ce qu'ils étaient - et ce que vous avez essayé de réaliser.
Inclure les "Produits" à condition qu'ils soient suffisamment avancés pour pouvoir se suffire à eux-mêmes. Si vous n'êtes jamais allé au-delà de l'écran de connexion, ne l'incluez pas.
Je vais répéter* (en fait, je ne fais que copier-coller)* : Assurez-vous que vous n'avez pas des tonnes et des tonnes de projets abandonnés/inachevés. Ayez des idées complètes - elles peuvent toutes être à différents stades d'achèvement, mais n'avez pas plus de 2 projets qui ne sont pas au stade MVP. Terminez ce que vous commencez. Sacrifiez la nouveauté pour la nuance.
Il convient de noter que toutes ces réponses sont mes propres opinions subjectives que j'ai généralisées dans les petites et les grandes entreprises. Ils reflètent mon style personnel, mais je soutiendrai également avec plaisir qu'ils ne sont pas non plus à 100% corrects. C'est ce qui a fonctionné pour moi - mais j'aime recevoir les commentaires et les opinions des autres.
Vous avez des questions auxquelles je n'ai pas répondu ? Connectez-vous avec moi sur LinkedIn et envoyez-les moi !
Également publié ici .