Tout le monde n'a pas de portfolio Git ou autre en ligne. J'ai réussi à faire face à plusieurs décennies de développement logiciel et je n'ai pas eu besoin d'en avoir un. On ne me l'a jamais demandé.

Bien que cela puisse être un avantage dans certains cas, je ne considère pas qu'un portfolio soit obligatoire. Laissez votre CV et votre technique d'entretien parler pour vous (et tout exercice de codage qu'ils pourraient vous lancer).

Personnellement, je ne crois pas qu'il faille passer toute la journée au travail à marteler le code, et puis fais la même chose quand je rentre à la maison.

Je travaille aux États-Unis. Je travaille comme programmeur depuis des décennies. Je n'ai pas de portfolios en ligne.

J'ai également interviewé des personnes pour plus d'une douzaine de postes. Je n'ai même jamais vu un CV avec un lien vers un portfolio en ligne.

Maintenant, cela peut être dû au fait que les postes pour lesquels j'interviewe impliquent le développement de code pour les clients, donc on s'attend à ce que le résultat du travail laisse au développeur un code nul à présenter. Le code, les exigences, les dessins sont la propriété du client. D'où le manque de portfolios en ligne.

Il est vrai que certains développeurs ont des portfolios en ligne, mais si votre travail ne vous permet pas de publier du code dans un portfolio, je ne pense pas que je serais impressionné par des exemples de base giflés ensemble juste pour avoir un portefeuille. Je ne m'inquiéterais pas du manque de portfolio. Cela fermera la porte sur certaines positions, mais il y a beaucoup d'autres positions qui ne nécessitent pas ou n'attendent pas un portefeuille.

Tout le monde esquive la question ici. Vous n'avez pas demandé "ai-je besoin d'une réputation en ligne?", Vous avez demandé " comment en créer une? "

Et j'ai bien peur que vous connaissiez déjà les réponses: contribuer à l'open source, écrire un blog, contribuer à Stack Overflow, etc.

Si votre entreprise ne vous permet pas de contribuer à l'open-source, passez à celui qui le fait ou faites-le pendant votre temps libre.

Si vous pensez que vous n'avez rien à écrire sur un blog, forcez-vous quand même à en écrire un. Vous trouverez des choses sur lesquelles écrire.

Si vous n'avez pas le temps de parcourir Stack Overflow, recherchez l'heure. Répondez à une question pendant l'exécution de votre build. Posez une question là-bas plutôt que de poser une question à un collègue.

Prenez Jon Skeet, par exemple. Il a un blog, un livre, des milliers de réponses Stack Overflow et 2700 contributions GitHub l'année dernière. Il a également un emploi à temps plein, une famille et des engagements hors ligne. Ce n'est pas de la chance - il trouve le temps.

De toute évidence, nous ne pouvons pas tous être Jon Skeet, il n'est qu'un exemple de ce qui est possible.

Il n'y a pas de raccourci pour construire une réputation en ligne . Les personnes qui réussissent sont celles qui trouvent le temps de le faire.

Je travaille en tant que pigiste, concepteur UI / UX et développeur front-end. Plus de 5 ans j'ai sous-traité du travail car j'hésitais à travailler directement avec les clients. Ce que j'ai fait pour développer ma marque personnelle:

• J'ai créé un portfolio avec des projets parallèles, des projets personnels, des designs et des sites Web que j'ai créés pendant mon temps libre. Cela semble prendre du temps, mais vous pouvez le faire étape par étape. Il a l'avantage de pouvoir être plus créatif et d'utiliser toutes les technologies. Je comprends que vous êtes occupé, mais vous pouvez travailler dessus à peine 30 minutes par jour et cela sera bientôt visible.

• Je partage constamment les articles que j'ai lus relatifs à mon travail sur Twitter / Linkedin.

• J'ai demandé des recommandations à mes collègues.

À mon avis, vous n'avez pas vraiment de question, c'est plutôt un message où vous soutenez qu'une présence en ligne n'est pas importante. Pour les emplois à temps plein, ce n'est pas si important, c'est plus précieux pour les pigistes. Dans ce cas, ne vous concentrez pas dessus, les recommandations devraient suffire.

Vous avez mentionné que vous êtes parvenu à votre conclusion sur la nature de votre travail grâce à vos hypothèses de confidentialité que vous attendez de vous en tant que développeur en raison des contrats que vous avez signés.

Je ne sais pas si cela est différent au Royaume-Uni, et cela peut varier selon l'endroit où vous avez travaillé, mais de nombreux NDA offrent des moyens acceptables de partager votre travail sans exposer de matériel confidentiel.

Je recommanderais vous examinez les documents que vous avez signés pour ces entreprises (et si vous n'en avez pas conservé des copies, je fortement vous recommande de le faire à l'avenir!) et voyez s'il existe des moyens pour vous de partager votre travail. Par exemple, une NDA sous laquelle je suis actuellement me permet de reproduire tout code que j'ai écrit pour l'entreprise tant que j'élimine les références à l'infrastructure interne.

Comme d'autres l'ont mentionné, tout le monde ne passe pas de temps à travailler sur open -source de logiciels et projets de loisirs; de nombreux développeurs se concentrent entièrement sur le monde professionnel et construisent leur portefeuille à travers leurs expériences.

Vous pourriez également trouver utile de créer des résumés de votre travail que vous avez effectué pour ces entreprises afin de mieux communiquer ce que vous 'ai fait aux futurs employeurs.

Les références, l'expérience et les compétences sont essentielles. Habituellement, la présence en ligne est un petit plus, mais pas du tout obligatoire.

Pour un recruteur, ne pas avoir de présence en ligne, mais avoir travaillé dans 4 entreprises différentes au cours des 12 dernières années, montre que tu lui as été utile. Si vous leur donnez quelqu'un à appeler, cela vous donne beaucoup plus d'informations sur vous professionnel que la plupart des comptes GitHub avec des projets publics.

Vous pourriez être un petit désavantage pour les nouvelles startups qui souhaitent en voir autant code de vous au préalable, mais pour les entreprises de taille moyenne à grande avec des ressources humaines, ne pas avoir de présence en ligne n'a pas d'importance, vraiment. Du moins, c'est ce que la plupart des recruteurs que je connais m'ont dit. En fin de compte, l'interview et votre performance comptent.

Écrivez quelque chose de clair et de concis. Ne passez pas 100 ou même 10 heures à l'écrire. Personne ne veut de toute façon lire du code long.

Par exemple, écrivez une fonction fibonnacci. Ajoutez du piquant si c'est trop fade.

Mais le fait est que vous n'avez pas à y consacrer et ne devriez pas y passer beaucoup de temps. Écrivez quelque chose de court et raffiné qui prendra moins de 5 minutes pour tout lire.

Au cas où cela aiderait, j'ai cherché et trouvé un nouvel emploi l'année dernière dans un secteur d'activité différent.
Sans code publié.
Sans blog.

On ne m'a pas demandé pour des échantillons de code ou ma présence en ligne. Connaissant cette société, je pense qu'ils en ont recherché une (c'est un compliment pour eux).

J'ai eu l'intention de créer un blog, de publier du code et de gagner des abonnés pour les mêmes raisons que vous dites. Pourrais-je trouver (avoir trouvé) le temps pour cela? Oui, mais comme vous, j'ai priorisé différemment - comme vous, j'ai choisi de me concentrer sur d'autres engagements. Je suis d'accord avec ce choix et j'espère que vous l'êtes.

À partir de l'année dernière, avant de changer d'emploi, j'ai commencé à faire certaines choses comme répondre à des trucs sur Stack Exchange (+ d'autres endroits) pendant mon heure de déjeuner, après le travail, ou en attendant que les choses soient compilées.
Je ne sais pas si cela m'aide du tout pour mes perspectives d'emploi, mais je dirai que les réactions de certaines personnes à mon message m'ont aidé à affiner la façon dont je publie les choses . Cela m'a également aidé à formuler les choses différemment dans les e-mails. Alors je continue à le faire - parce que je vois des résultats pour moi.

C'est un monde différent maintenant ... il y a cinq ans, il n'y avait pas de (réel) truc open source lié à MSFT auquel vous pourriez contribuer , mais maintenant C #, Visual Studio et beaucoup d'autres choses le sont. Trouvez quelque chose à faire, commencez par un petit quelque chose. Apprenez simplement quand et où vous le pouvez.

Dans cinq ans, ce sera à nouveau un monde différent ...
Soyez meilleur, soyez meilleur. Il n'y a pas une seule chose qui vous mènera là où vous voulez aller ... ni un portfolio, ni un code publié, ni aucune autre chose.

J'espère que cela aide

Vous n'avez pas besoin d'écrire beaucoup de code pour montrer vos compétences. Même une journée de travail bien faite peut montrer ce que vous pouvez vraiment faire. Tout dépend de la qualité du code que vous pouvez produire, pas de la quantité de contenu gratuit que vous avez produit à ce jour.

Comme d'autres l'ont mentionné, consacrez de 0,5 heure à 1 heure par jour à écrire un outil simple que vous-même trouveriez utile (je l'ai fait de cette façon). À la fin, vous aurez deux choses: un outil utile que vous utiliserez tous les jours et du code en ligne que les autres pourront voir. Point principal, la qualité sur la quantité.

Si vous préférez les articles de blog, n'écrivez pas sur le déballage d'un DVD Visual Studio 2017. Choisissez l'une des dernières technologies, apprenez-la en profondeur et partagez vos connaissances. Décrivez les avantages et les inconvénients, à partir de votre expérience, soyez technique et essayez de produire un contenu unique.

Je suis également au Royaume-Uni, donc ce qui fonctionne pour moi fonctionnera certainement pour vous.

Vous supposez qu'une présence commercialisable signifie être capable de divulguer le code ou les détails exacts du projet. Ce n'est pas le cas. Ce dont vous avez besoin n'est pas difficile à obtenir - j'ai travaillé à la fois pour de grandes API et des PME de 10 employés et aucune n'a refusé.

Vous voulez une lettre qui décrit votre travail et votre approche, mais sans sensible- aux détails du client. Voici un exemple de l'un des miens:

Notez qu'il ne divulgue rien sur le codage que j'ai fait, ni n'inclut des détails NDA . Il dit simplement comment je devais travailler et donne un aperçu de la nature du travail. D'autres lettres sur d'autres emplois mettent en évidence d'autres compétences ou des compétences spécifiques, donc lorsque je postule pour un poste, je peux choisir celles qui mettent en évidence ce qu'ils recherchent.

Mais quelle référence!

J'en ai 10 autres comme ça. Rien dans celui ci-dessus ne présente des projets spécifiques, en fait même le client est masqué. Mais cela a un poids et une crédibilité énormes , malgré tout. Il pourrait manquer des morceaux entiers, ou être délibérément assez vague pour ne pas révéler des zones de travail exactes ( "travaillé sur notre projet d'analyse client" ), et cela quand même être très puissant.

C'est ce que j'utilise à la place d'un portfolio. Cela fonctionnera pour vous aussi.

Ce type de référence est ce dont vous avez besoin, et si vous le demandez, un nombre surprenant de personnes se feront un plaisir de vous aider en vous le donnant.

Par rapport au contributeur open source moyen et aux médias sociaux, vous avez beaucoup moins de temps pour taper et beaucoup plus de temps pour réfléchir. Utilisez cela à votre avantage.

Utilisez votre temps de trajet pour écouter les podcasts originaux de Stack Overflow. Vous en apprendrez beaucoup sur le développement de logiciels et de produits et comment poser de bonnes questions.

Visez une petite contribution chaque jour. Il peut s'agir d'une question aussi simple que Stack Exchange, d'un épigramme sur Twitter ou d'un commentaire sur GitHub qui aide à corriger la progression d'un bug.

Pensez beaucoup et tapez un peu chaque jour. Le travail que vous faites en petites tranches de temps s'additionnera. Bonne chance!

Aucun portefeuille github ne peut battre un ancien employeur satisfait, prêt à témoigner, ou un ancien qui vous a gardé pendant plus de quatre ans, vous fournissant peut-être quelques rapports d'évaluation? Autrefois, la meilleure publicité était un client satisfait, il était une fois.