Vaut-il la peine de lister les référentiels de test ou d'auto-apprentissage sur mon CV? [fermé]

J'ai un référentiel GitHub avec des programmes de jouets que j'écris quand j'apprends quelque chose. Par exemple, lorsque je lis un article sur un algorithme ou une structure de données, j'en rédige une mise en œuvre rapide pour m'assurer qu'il fonctionne et je le comprends.

Je résout parfois des puzzles d'algorithmes et de structures de données et cela est poussé dans le référentiel.

Est-ce que ce référentiel vaudrait la peine d'être relié à mon CV, ou est-ce que cela nuirait à mes chances d'être embauché?

J'ai entendu un jour un curriculum vitae décrit comme «un bilan qui ne montre que votre actif mais pas votre passif».

Sur la base de cette définition, vous souhaitez inclure des projets qui seront un atout pour vous d'obtenir le poste tout en laissant de côté ceux qui pourraient constituer un passif. Cela signifie qu'ils doivent être pertinents pour l'emploi pour lequel vous postulez et montrer votre meilleur travail . Même si vous considérez votre code comme des "programmes jouets", cela ne signifie pas qu'ils ne peuvent pas être bien structurés. Par conséquent, n'incluez pas de code jetable ou de hacks sales. Gardez-les dans un référentiel privé. Et bien sûr, vous devriez être en mesure de parler de vos programmes , des décisions de conception qui y sont associées, etc. J'ai eu un jour un candidat qui prétendait avoir réalisé ce projet génial un an auparavant, mais qui ne m'a rien dit à ce sujet. Pas si bon.

N'oubliez pas qu'un curriculum vitae doit être élaboré en tenant compte de l'intervieweur, et la plupart des gens ne veulent pas avoir à parcourir un traité juste pour déterminer si vous méritez une interview. Ils veulent que vous fournissiez les informations les plus pertinentes concernant le poste de manière concise. Cela nécessite une hiérarchisation minutieuse du contenu. J'ai tendance à personnaliser mon curriculum vitae par poste afin de mettre en évidence au mieux les informations pertinentes, et je pense que c'est une approche raisonnable pour cette question particulière.

Si vous postulez pour un poste de développeur général de bas niveau, une large gamme de programmes pourrait être utile. Peut-être que l'un des programmes de jouets illustre le moment où vous avez finalement "cliqué" avec des prototypes javascript, ou lorsque vous avez étudié votre premier LISP. Cela pourrait être bénéfique.

Cependant, si vous postuliez pour un poste qui vous obligeait à construire des compilateurs pour les systèmes de défense nationale, les exemples susmentionnés ne seraient d'aucune utilité pour les enquêteurs. Ils seraient beaucoup plus intéressés par d'autres types d'informations de base (projets de compilation auxquels vous avez contribué / dirigé, etc.)

Tout cela pour dire que j'essaierais d'évaluer la pertinence des projets de jouets par rapport à la position actuelle. S'ils semblent pertinents pour le poste actuel (p. Ex., Le poste nécessite une compétence de base, le poste nécessite une prédisposition générale à un apprentissage autonome, etc.), alors j'inclurais le référentiel. Sinon, des informations plus importantes peuvent être mises en évidence.

Ne mettez rien sur votre curriculum vitae que vous ne vous sentez pas à l'aise de voir quelqu'un examiner d'un œil critique. De même, ne demandez pas à un intervieweur potentiel de fouiller dans le référentiel pour trouver les bonnes choses, il vaut mieux avoir un petit référentiel avec des bibliothèques bien écrites ou des extraits de code, puis vous avez une application complète.

Si vous fournissez le lien vers un référentiel, assurez-vous qu'il existe un fichier README clairement défini qui peut pointer les gens vers les parties intéressantes du code que vous souhaitez afficher, ainsi qu'un bref aperçu de la raison exacte pour laquelle les choses sont ainsi les sont. Si vous divulguez le lien au début du processus d'embauche, il se peut que vous ne soyez pas là pour justifier vos décisions de conception, un README peut donc expliquer les choses en votre nom.

L'un des avantages de la mise à disposition du code pour les employeurs est que vous pouvez l'utiliser pour filtrer vos opportunités.

Un entretien d'embauche est bidirectionnel; Non seulement l'employeur évalue le candidat, mais le candidat doit également décider s'il veut réellement travailler pour l'employeur.

Lorsqu'un employeur fait une offre sans avoir d'abord vu le travail du programmeur, il y a de très bonnes chances que le même processus ait été utilisé auparavant, pour embaucher tout le monde. Un demandeur d'emploi devrait probablement être très réticent à accepter des offres lorsqu'il n'y a pas de raison évidente pour laquelle un non-programmeur n'aurait pas pu se qualifier pour le même poste (car il y en a sûrement eu)

Bien sûr, la plupart des employeurs ne demandent aux candidats de produire un code; et il semble être généralement sous la forme de "écrire une fonction sur ce tableau blanc" ou si vous êtes chanceux "écrire une fonction sur ce poste de travail inconnu". Bien que cela puisse faire un travail raisonnable pour séparer les candidats qui ne peuvent même pas écrire "Hello World!", Cela devient beaucoup moins instructif sur la différence entre qui peut écrire un bon code et qui peut garder son sang-froid dans une interview.

Et tant d'employeurs (bien que loin de la plupart) sont impatients de jeter un coup d'œil au type de code qu'un programmeur peut produire lorsqu'il est dans son cadre idéal, travaillant sur ce sur quoi il veut travailler, et sans aucune orientation particulière.

Pour en tirer le meilleur parti, c'est une bonne idée d' offrir le code avant même qu'un employeur ne le demande; S'ils ne sont simplement pas intéressés, trouvez une autre opportunité. S'ils sont intéressés, dites-leur quels projets vous aimeriez qu'ils examinent et pourquoi (et expliquez également pourquoi vous ne pensez pas que certains des autres projets sont aussi représentatifs, par exemple, vous appreniez le cadre à partir d'un livre) . Demandez-leur ensuite ce qu'ils ont pensé de ce qu'ils ont vu lors de votre prochaine conversation.

Si vous le considérez comme un portfolio, alors oui, je vous recommande de mettre ce lien dans votre CV. Je fais.

Un CV a exactement un but: vous faire passer à la prochaine étape du processus d'embauche. Tout ce qui entrave ce but est une mauvaise idée. En tant qu'ancien responsable du recrutement, je peux vous dire que le temps dont je disposais pour un seul candidat au cours du processus de sélection initial ne permettait pas plus que de lire le curriculum vitae et de décider de le déchiqueter ou non. Les gens qui m'ont envoyé un curriculum vitae de 7 pages (vraiment!) N'ont pas obtenu l'attention qu'ils désiraient. Les gens qui m'ont envoyé des CV qui étaient principalement des URL ne l'ont pas fait non plus. Plus tard, après avoir été plus investi dans les candidats restants, peut-être.

Un portefeuille est une bonne chose. Cela est particulièrement vrai dans certains aspects de notre entreprise, comme la conception Web. Mais sauf si vous êtes un graphiste, votre portfolio ne devrait pas être votre introduction.