C'est un problème courant, et il existe une solution commune:

Écrivez quelque chose.

Créez une fausse entreprise dans votre tête. Trouvez un problème commercial qu'il doit résoudre avec un logiciel et résolvez-le. Montrez-leur ce code.

Expliquez vos NDA et vos informations confidentielles.

Personne ne cherche les secrets de l'entreprise. Ils cherchent à voir comment vous organisez vos pensées en architecture, vos pratiques de code, vos harnais de test, vos commentaires, etc.

Faites un petit projet et montrez-leur ce code. Personne ne s'attend à ce que vous montriez un code appartenant à vos anciens employeurs, en fait, je serais très inquiet si vous le faisiez et que je vous interviewais. Certaines personnes travaillent sur de petits projets open source pour cette raison.

C'est moins le code lui-même qui les intéresse que la façon dont vous l'écrivez.

Je ne suis pas un développeur professionnel mais je n'aurais aucun problème à trouver quelques centaines de lignes de code que j'ai faites en dehors de tout engagement de travail.

Si vous voulez le travail, vous sautez à travers les cerceaux. Si je vous ai demandé d'apporter du code à l'entrevue et que vous ne l'avez pas fait, mais que quelqu'un d'autre avec des compétences à peu près équivalentes l'a fait, devinez qui j'emploierais? Vous vous vendez à un employeur aux conditions de l'employeur, pas comme vous le souhaitez ... remettre en question leurs motivations à demander n'est pas constructif. C'est une compétition, donnez-vous tous les avantages que vous pouvez.

Demander est éthique. Attendre de vous que vous enfreignez une NDA ne l'est pas. Se plaindre de ne pas enfreindre une NDA est idiot et un bon signe que ce n'est pas un endroit où vous voulez travailler.

Demander à votre ancien patron s'il y a des choses que vous pouvez copier est absolument parfait. Il comprendra pourquoi vous demandez. Il comprendra également les règles de son entreprise et dira «oui» ou «non». Probablement "non". Peut-être vous donner la permission de copier certains codes que vous avez écrits, peut-être pas.

Et la chose évidente à faire est d'écrire du code. Écrivez la spécification pour une petite tâche qui peut être résolue en 100 lignes de code, et écrivez un code vraiment raffiné qui correspond à cette spécification. Vous avez donc quelque chose à montrer.

Ces autres entreprises ne veulent pas voir le code source de tous vos projets précédents. Ils veulent en fait voir le code source de vos projets personnels précédents ou des projets sur lesquels vous détenez toujours les droits.

Si vous n'avez pas au moins un projet personnel de votre choix, qu'il provienne d'un hackathon ou de quelque chose d'autre, alors cela pourrait soulever un drapeau rouge avec certains des employeurs les plus difficiles.

Faire pression sur votre ancien employeur pour obtenir le code est en fait une mauvaise approche. Cela peut renforcer le fait pour le nouvel employeur que vous n'avez pas de projet personnel à lui montrer et / ou que vous n'êtes pas capable d'en rédiger un par vous-même.

Mise à jour: Veuillez ne pas considérer cela comme signifiant que je suis d'accord avec cette opinion. Je déteste aussi ce même cercle que certains employeurs potentiels veulent que je traverse. J'ai des exemples de code que j'ai écrits et sur lesquels j'ai toujours les droits, mais ces projets sont souvent des projets à moitié terminés / à moitié cuits qui ne se rapprochent même pas du type de projets que je fais en tant qu'employé à temps plein.

L'important pour un employeur potentiel est de démontrer sa capacité à effectuer le travail pour lequel il embauche.

Comme d'autres l'ont dit, vous pourriez remettre du code open source. Le problème avec cela est que personne ne sera impressionné par un projet trivial qui n'a pris que quelques heures / jours à écrire et qui résout un faux problème. L'autre problème avec ceci est que l'employeur potentiel n'évaluera pas vraiment votre projet jusqu'au niveau du code source. Ce serait beaucoup de temps à investir. Leur donner un lien vers votre référentiel git n'est pas très efficace à moins que ce ne soit un projet vraiment étonnant et bien documenté.

Si vous voulez démontrer vos compétences, rassemblez des diapositives qui fournissent un aperçu de une solution que vous avez créée. Vous n'avez pas besoin d'afficher des lignes de code.

Commencez par expliquer le problème que vous avez résolu et donnez une idée de sa portée. Procédez avec des schémas architecturaux de haut niveau qui esquissent votre solution. Enfin, donnez une idée des décisions et des défis techniques clés de la mise en œuvre et détaillez les outils / bibliothèques particuliers que vous avez utilisés. Le cas échéant, certaines captures d'écran montrant le travail en action sont également bien. Ces diapositives suffiront à démontrer votre niveau de sophistication et vous poseront des questions auxquelles vous pourrez répondre avec des niveaux de détail fins.

Il serait bien sûr idéal de faire ce qui précède avec un projet open-source MAIS si vous êtes d'accord avec le petit risque, vous pouvez ÉGALEMENT le faire pour le travail de votre ancien employeur. Si vous créez des diapositives décrivant le travail de votre ancien employeur, ne les distribuez tout simplement pas. Vous devez les conserver sur votre ordinateur portable et les utiliser uniquement en direct. L'essentiel est que vous ne transmettez pas de code source et que vous ne faites que montrer ce que vous avez fait. Je n'ai jamais eu de problème avec cela et cela a fait une excellente présentation qui m'a valu d'être embauché plus d'une ou deux fois.

En tant que développeur actuel et personne impliquée dans le processus de recrutement (de développeurs) dans mon travail actuel, permettez-moi de vous offrir quelques conseils ...

Tout d'abord, vous pouvez vous attendre à ce que presque tout employeur potentiel vous le demandera et voudrait voir le code de votre part. En fait, vous ne devriez pas vraiment vouloir travailler pour quelqu'un qui ne veut pas voir ça. Il y a une différence entre un candidat capable de répondre à certaines questions informatiques et un candidat capable d'écrire du bon code.

Deuxièmement, la plupart des personnes qui embauchent des développeurs gardent également leurs propres développeurs sous NDA. Ils ne voudraient pas que leurs employés partagent le code source qu'ils ont écrit mais qu'ils ne possèdent pas avec d'autres entreprises, ils devraient donc comprendre quand de nouveaux employés potentiels se retrouvent dans la même situation. Si l'employeur potentiel ne comprend pas votre incapacité à lui fournir un code protégé par NDA, vous ne souhaitez pas travailler pour lui de toute façon. Vous n'êtes même pas encore leur employé et ils vous demandent de rompre un contrat avec un ancien employeur, ce qui vous pose d'énormes problèmes personnels et professionnels. Pensez à ce que ce serait de travailler pour cette entreprise.

Troisièmement, encouragez votre employeur actuel à contribuer, en tant qu’entreprise, à la communauté open source, ou à permettre aux employés de consacrer un certain temps à projets open source qui sont pertinents pour le travail que vous faites. Par exemple, alors que mon lieu de travail actuel contient des tas de projets protégés par NDA dans notre compte Bitbucket, nous avons également un GitHub public et nos développeurs sont encouragés à y contribuer (et de nombreux des bibliothèques hébergées sont utilisées dans nos projets protégés par NDA). Pendant ce temps, pour un ancien employeur, j'ai dû développer cette bibliothèque et je l'ai fait avec l'accord de cet employeur qu'il s'agirait d'une bibliothèque open source.

Quatrièmement, lorsque vous bricolez, faites-le sur GitHub. Quand Apple a publié un nouveau langage et quelques fonctionnalités intéressantes liées à l'interface utilisateur pour Xcode, j'ai créé ce projet pour explorer beaucoup de ces nouvelles choses. J'étais un projet d'apprentissage, mais c'est mieux que rien. Mais je ne m'attends pas non plus nécessairement à ce que les candidats mangent, dorment et respirent du code, donc ne pas avoir le temps ou l'intérêt de travailler sur ce genre de projets ne me dérange pas particulièrement. Mais cela dit, si vous cherchez un emploi, ce n'est probablement pas une mauvaise idée de prendre quelques week-ends pour travailler sur ce type de projets et constituer un portfolio.

... parce que c'est juste ce que c'est, un portefeuille. Lorsque les artistes arrivent pour trouver un emploi quelque part, on s'attend à ce qu'ils apportent un portfolio de leurs travaux antérieurs afin que l'employeur ait une idée du type de travail que l'artiste peut apporter. Ce sera très avantageux pour votre carrière de développeur si vous disposez d'un portfolio de vos meilleurs travaux disponible gratuitement pour les employeurs potentiels.

Créez un compte github et commencez à écrire quelque chose. Peu importe ce que c'est, assurez-vous simplement que ce sont vos meilleurs efforts. Lorsque je reçois des CV à travers la porte pour des emplois, la première chose que je vérifie est s'ils ont un compte GitHub, la seconde est ce qu'ils ont contribué!

Si vous ne savez pas quoi écrire (et c'est un problème courant), écrivez du code pour résoudre les problèmes du Project Euler. Il démontrera votre approche de la résolution de problèmes, de la mise en page, de la documentation, etc.

Vous n'avez pas besoin d'écrire et de leur montrer du code, du moins pas pour la plupart des offres d'emploi respectables. Vous avez votre CV et vos réalisations, et je vous recommande fortement de suivre le «test Joel» et de n'interviewer que dans des entreprises où vous devez écrire du code lors de l'entretien . C'est là qu'ils vérifieront vos compétences en programmation.

Source: emplois que j'ai obtenus.

Si vous travaillez depuis des décennies et que vous n'avez rien à montrer, vous comprendrez l'accord que vous obtenez en tant que créateur dans notre société. Vos créations ont changé de mains pour de l'argent. Vous n'avez plus aucun droit (du moins aucun qui vous est utile) sur eux.

Si vous voulez vraiment qu'un portfolio soit affiché, vous devez faire attention à ne pas échanger tout ce que vous créez contre de l'argent. Engagez-vous dans certains projets de logiciels libres (naturellement, en obtenant l'autorisation de votre employeur si vos contrats de travail l'interdisaient autrement). Donnez quelque chose en retour à une grande communauté dont vous avez probablement tiré un profit pour vous-même et peut-être pour les entreprises pour lesquelles vous avez travaillé.

Si vous faites cela, vous pourrez montrer des engagements. Des choses que vous avez améliorées, des choses que vous avez écrites, qui s'intègrent dans des contextes plus larges. Des éléments que vous avez rédigés, accessibles au public et dont il est prouvé qu'ils sont les vôtres, qui remplissent un objectif et qui sont acceptés par une grande équipe qui est plus susceptible qu'improbable de procéder à des examens plus approfondis que la plupart des entreprises.

Je ne peux pas croire que tout le monde a manqué ça, MAIS:

Ceci est un TEST de votre personnage. Voyez, si vous partagez les informations de votre ancienne entreprise que vous ne devriez pas, alors vous êtes également capable de faire demi-tour et de le faire à l'entreprise à laquelle vous postulez.

Ce test est utilisé pour éliminer les personnes peu intègres. Déclinez simplement gracieusement. C'est aussi simple que ça.