Forum EduPython

Echanges autour d'EduPython.

Vous n'êtes pas identifié(e).

#1 2019-12-06 07:27:13

jadenfrancis
Membre
Inscription : 2019-12-06
Messages : 1

Guide de réussite pour développeur / architecte / ingénieur débutant

Le titre pourrait donner l'impression que je vais énumérer un ensemble de choses qui garantiront le succès. Ce n'est pas ce que ce poste est.

J'ai pensé que je pourrais partager quelques conseils pour les personnes qui commencent leur chemin dans les domaines du développement logiciel ou de la gestion et de l'exploitation des infrastructures informatiques, en commençant par les entretiens pour faire votre travail. J'observe constamment des personnes qui manquent des opportunités et obtiennent de mauvaises évaluations de performances car elles ne suivent pas certains des conseils ci-dessous.

Mais qui suis-je pour donner ce conseil? Eh bien, c'est Reddit / internet, je ne suis qu'une affiche anonyme, alors prenez tout conseil avec un grain de sel. Y compris le mien. Si vous êtes enclin à croire ce que je dis, ce conseil est basé sur:

une douzaine d'années dans le développement et l'architecture de logiciels dans des rôles de contributeur et de gestion

des centaines d'entrevues (en tant qu'enquêteur) et des dizaines (en tant qu'interviewé)

des dizaines d'offres reçues au cours des 10 dernières années (lorsque je cherchais des emplois) pour des postes de haut niveau en IC et IC / management

amour et passion pour le développement de logiciels et désir pour tous les professionnels de se développer, de se développer et de commencer le mentorat

Une chose qui mérite d'être mentionnée: certains conseils (environ 50%) que je fournis ici m'ont été donnés par quelqu'un d'autre à un moment donné de ma carrière. Certains événements se sont produits il y a longtemps, d'autres - il y a quelques mois. Ce que j'essaie de dire (prenez-le comme premier conseil) - n'arrêtez jamais d'apprendre et ne pensez jamais que vous savez tout. Les gens autour de vous ne cesseront de vous surprendre.

Commençons par les choses sur lesquelles je voulais me plaindre. Ce n’est en aucun cas une liste complète. Certaines choses avec lesquelles vous pourriez même être en désaccord. J'essaie simplement de partager les schémas / comportements que je crois être les principaux contributeurs à ma réussite professionnelle personnelle et à celle des autres personnes travaillant avec / sous moi.
Entrevues.

Veuillez vous préparer. Découvrez l'entreprise. Poser des questions.

Si vous réalisez des interviews à distance - soyez prêt et vérifiez votre audio / vidéo à l'avance. Obtenez une webcam et un micro décents.

Regardez votre CV. Regardez CHAQUE MOT / technologie. Si je vous demande tout de suite «comment avez-vous utilisé X?» Ou «pourquoi avez-vous décidé d'implémenter Y?», Pouvez-vous répondre en détail? Sinon, retirez-le de votre CV.

Lorsque vous ne comprenez pas la question, dites-le. Demandez une explication. Arrêtez d'inventer des réponses. Les bons enquêteurs ne sont pas là pour évaluer votre connaissance de chaque modèle ou de chaque algorithme (si c'est ce qu'ils font - vous ne voulez pas y travailler), ils sont là pour comprendre comment vous pensez et à quelle vitesse vous vous adaptez.

Si vous ne connaissez pas la réponse - arrêtez de deviner, soyez honnête. Informez l'enquêteur et demandez-lui s'il souhaite que vous essayiez de le deviner ou d'y réfléchir.

Parlez plus lors des entretiens. Lorsque vous pensez au problème - faites savoir à l'enquêteur ce que vous pensez et où vous allez avec. Ne vous asseyez pas là comme un koala avec une bouchée de feuilles.

Beaucoup d'entre vous lisez «reprendre les meilleures pratiques» en ligne et branchez maintenant des chiffres / pourcentages partout pour dire comment votre travail a amélioré l'entreprise. Bien pour vous. Mais s'il vous plaît, si vous en avez un, soyez prêt à répondre à la question «comment avez-vous mesuré cela?».

Arrêtez immédiatement de sauter au code. Si une question technique vous est posée, parlez d'abord d'un résumé. Synthétisez le problème en une question abstraite. Pensez à des exemples concrets. Supposons que vous soyez invité à "inverser l’arbre binaire". Ne commencez pas à écrire du pseudo (ou du vrai) code. Parlez-en d'abord. Dessinez l'arbre binaire, montrez que vous comprenez la question. Expliquez ce que la conversion fait réellement à l'arbre binaire.

Montrez de l'intérêt en général, pour les questions, la technologie, les gens. Si vous avez une question à laquelle vous n'avez pas pu répondre - rentrez chez vous, recherchez-la, envoyez un message (ou un e-mail) à l'intervieweur / recruteur (vous pouvez toujours demander à LinkedIn de lui envoyer un message) après l'entretien avec des réponses, des explications.

Si vous avez TOUJOURS une offre à négocier (sauf si vous en êtes satisfait à 100%). Mais ne vous fiez pas à ça. Je recommande d'avoir au moins deux offres (ou une offre et un appel de clôture) avant de négocier. Alors vous pouvez être honnête - «J'aime vraiment l'entreprise, j'aimerais travailler avec vous parce que X, Y et Z mais malheureusement, l'offre ne correspond pas tout à fait à mes attentes / marché et aux autres offres que j'ai reçues. Serait-il possible d'ajuster l'offre (par N dollars / avec un avantage spécifique / ajouter un bonus de signature / pour correspondre au taux du marché)? "

Il convient de mentionner que la plupart des entretiens sont, en réalité, des excréments de taureaux et les intervieweurs posent des questions qu'ils ont googlé il y a quelques minutes. Ça va toujours arriver de temps en temps - acceptez ces interviews comme un «mal nécessaire».

2) L'éthique du travail

Ne dites jamais que le code / les solutions / l'architecture existants sont mal faits. Cela peut être faux / sous-optimal, mais il peut y avoir des raisons à cela. Parfois, sortir un morceau de code merdique est plus pertinent financièrement que de le rendre agréable, solide et testable. À la fin de la journée - tout ce que nous faisons est conçu pour faire de l'argent pour l'entreprise, d'une manière ou d'une autre. C’est le but principal. Ne pas écrire le meilleur code ou avoir la meilleure couverture. Gagner de l'argent et prévenir la perte d'argent.

Les révisions de code sont excellentes et nécessaires. Si vous pensez le contraire - corrigez votre état d'esprit. Découvrez pourquoi c'est important.

Lorsque vous commencez à travailler sur quelque chose (nouveau projet / ticket / correction / construction), réduisez toujours votre travail à une déclaration de problème (littéralement, 3-4 phrases; comme une histoire) que vous résolvez. Assurez-vous que l'énoncé du problème est correct, exécutez-le par le demandeur / les pairs / les gestionnaires. Concentrez-vous sur la résolution de ce problème
Si vous avez fait une erreur, admettez-le toujours. Assurez-vous que votre «J'ai eu tort» ou «J'ai fait une erreur» est vu / entendu par toutes les personnes concernées par le problème. "Je me trompe" est l'une des phrases les plus utilisées dans mon vocabulaire.

Si vous avez une discussion (argument) avec vos pairs sur quelque chose (exactitude du code, choix de l'architecture, conception de la solution, etc.) - défendez toujours poliment votre point jusqu'à ce que les deux parties soient d'accord. Si votre «adversaire» vous convainc qu'ils ont raison, admettez-le. Explicitement, dites «je me trompais, vous avez raison» et merci pour l'explication. Si vous pensez que vous ne vous trompez presque jamais - corrigez votre état d'esprit. Ajouter:

Dans le même temps, ne dites jamais que votre collègue / collègue a eu tort si telle est la conclusion de votre discussion. Oui, techniquement, ils ont peut-être eu tort (il n'y a pas d'argument avec une seule partie en erreur et vous le savez). Soyez reconnaissant pour leur contribution et pour vous laisser rebondir sur vos idées. Confirmez qu'ils sont d'accord avec la solution, remerciez-les et continuez.

Tenez vos promesses / délais. C'est facile à dire, je sais. Mais si vous avez promis de faire quelque chose - faites-le. Peu importe ce qu'il faut. Mais le plus important - apprenez comment NE PAS promettre. Prenez l'habitude de respecter à chaque échéance au moins 3 fois le temps dont vous pensez avoir besoin pour le faire. Vous allez probablement encore être en retard.

Apprenez à choisir vos batailles (c'est personnel pour tout le monde, certaines personnes vont toujours «avec le courant», certaines personnes font toujours plus d'efforts - découvrez ce qui fonctionne pour vous)

Ne passez pas aux solutions / implémentations. Lorsque vous avez un problème et que vous connaissez juste l'outil pour le résoudre, nous avons tendance à entrer dans la conversation avec lui [l'outil / le modèle / etc.] à l'esprit. Arrête de le faire. Abstenez le problème et décrivez la solution dans un langage commun. Décrivez les «services» et les «fonctionnalités» de la solution. Pensez aux interfaces. Ce n'est que lorsque tout le monde est d'accord sur une approche de haut niveau que l'on peut commencer à penser aux implémentations et aux outils / modèles pour résoudre chaque pièce du puzzle.

Voir quelque chose - dire quelque chose. Si vous voyez quelque chose qui pourrait être incorrect / inefficace, faites-le savoir.

Recommandations de développement / ingénierie logicielle
Ci-dessus, j'ai dit: «Parfois, sortir un morceau de code de merde est plus pertinent financièrement que de le rendre agréable, solide, testable». C'est vrai. Mais il y a certaines choses que vous ne devriez jamais faire:

Arrêtez de mettre des secrets (mots de passe / clés) en texte clair dans votre code. Que ce soit votre code au travail ou votre dépôt personnel sur GitHub - arrêtez-le. Les enquêteurs regardent les dépôts GitHub personnels liés dans les CV. Si je vois quelque chose comme ça dans votre repo personnel que vous avez décidé de partager avec moi - en tant qu'intervieweur, je vais immédiatement vous préjuger.

Arrêtez de coder en dur les valeurs que vous voudrez peut-être modifier à l'avenir. Utilisez les valeurs fournies par la configuration et implémentez les meilleures pratiques pour la gestion de la configuration dans votre langage / framework / outil.

Arrêtez de faire des commentaires de code inutiles et des messages de validation peu clairs / aléatoires. Cela vaut la peine de fournir des commentaires concis et détaillés et des messages de validation pertinents.

Si vous décidez de prendre un raccourci / de ne pas mettre en œuvre quelque chose / de mettre en œuvre quelque chose d'une manière «non conforme aux meilleures pratiques» - laissez un commentaire. Expliquer pourquoi.

Document. Documentez tout. Écrivez plus de documentation puis codez. Edit: la documentation n'est pas forcément des commentaires de code. Documents d'architecture, guides, meilleures pratiques, notes de réunion, annotations d'interface, descriptions de points de terminaison - tout cela relève de la documentation. Fondamentalement, le point que j'essaie de faire est: commencer par la documentation, décrire ce que votre code / système / solution est censé faire, pourquoi il est nécessaire, quels types de problèmes il résout (et quels types de problèmes sont hors de portée) ; assurez-vous de fournir une documentation de code suffisante; noter les résultats des discussions et les notes de réunion pour avoir une référence; si quelqu'un partage une expertise privilégiée avec vous - ne vous contentez pas de l'utiliser, notez-la et partagez-la si elle n'est pas déjà partagée.
Ne blâmez pas. Si vous déboguez / essayez de résoudre un problème, ne demandez pas «qui a fait ça?». La seule question à laquelle il faut répondre: "comment éviter que ce type d'erreur ne se reproduise?"

Si vous faites quelque chose de similaire (écrire le même code / effectuer la même action / déclencher le même processus) manuellement pour la 2e fois - quelque chose pourrait ne pas fonctionner. Si vous le faites pour la troisième fois, quelque chose ne va pas. Arrête toi là. Automatisez-le. Passez.

Pensez en dehors de la boîte. Lors de la résolution d'un problème, envisagez d'impliquer d'autres équipes / technologies. Le nombre de fois où j'ai vu des gens passer des heures ridicules à faire quelque chose qui est déjà résolu est écrasant.

Ne réinventez pas la roue. S'il existe une bibliothèque / module open source (qui est important) qui résout le problème pour vous - n'hésitez pas à l'utiliser au lieu de mettre en œuvre la vôtre (tant qu'elle est conforme à la politique de l'entreprise et aux exigences de sécurité / conformité). Mais (très important mais) parcourez le code tiers, écrivez vos propres tests si possible et soyez toujours prêt à le bifurquer et à le maintenir vous-même (c'est pourquoi l'open-source est important). Il est presque toujours plus long d'écrire votre propre solution, mais si vous le devez - regardez d'abord les autres solutions open source pour vous inspirer. Vous remarquerez peut-être des modèles / solutions utilisés par les auteurs qui sont meilleurs que les choses que vous aviez en tête.

C’est un peu plus difficile lorsque la solution est un produit commercial. Ici, vous devez réfléchir à deux fois au coût, au coût du support, à l'expertise et à la maintenance - pensez et consultez vos pairs, d'autres équipes, l'équipe d'approvisionnement (si vous en avez un) pour déterminer si cela en vaut la peine. Parfois, j’ai vu des entreprises qui choisissaient de mettre en œuvre leur propre solution et y consacraient beaucoup d’argent / temps pour gagner en «liberté». D'autres choisissent des solutions commerciales parce qu'elles apprécient leur temps plus que les dollars réels. Chaque chemin a son temps et son lieu.

Général

Apprenez le contrôle des sources (Git). Apprenez-le très bien.

Passez du temps à comprendre COMMENT et POURQUOI les choses fonctionnent comme elles fonctionnent. Si vous apprenez un nouveau langage / cadre / outil - lisez toute la documentation que vous pouvez trouver.

Si vous lisez de la documentation / un livre / un article et voyez un mot / concept / phrase que vous ne comprenez pas - apprenez ce que c'est.

Apprenez les principes généraux de développement. Apprenez ce qu'est SOLID. Découvrez quels sont les modèles de développement logiciel courants. Apprenez quand les utiliser et ne pas les utiliser. Comprenez les avantages et les inconvénients de chacun. Même si vous êtes un administrateur système, apprenez-le

Lisez toutes les notes de publication de vos principaux langages / frameworks / outils. Faites attention et comprenez les changements et améliorations majeurs ainsi que les raisons derrière les décisions des responsables d'ajouter une fonctionnalité / fonction, des cas d'utilisation pour de nouvelles fonctionnalités / fonctions et leurs limites.

Prenez possession des problèmes. Si vous avez besoin de l’aide ou de l’aide des autres pour le résoudre, continuez à «embêter» poliment les gens s’ils ne vous recontactent pas. Ne laissez pas les choses s’asseoir là et vous faire oublier.

Si vous ne savez pas comment une certaine chose fonctionne / pourrait fonctionner - il est très souvent plus efficace et plus rapide de la tester rapidement. «Que se passerait-il si X se produisait?» - au lieu d'essayer de trouver la réponse en parcourant le code ou en essayant de la trouver dans la documentation (sans succès) - essayez simplement. Après l'avoir essayé, assurez-vous de comprendre COMPLÈTEMENT pourquoi cela s'est produit. J'aime dire: vous devriez pouvoir continuer à répondre au type de question «et comment ça marche?» Jusqu'à ce que vous arriviez à «et que le code soit exécuté sur le CPU» ou «et que le système produise un résultat» de réponse. C'est à ce moment-là que vous êtes allé assez profondément.

Si vous êtes développeur, apprenez et comprenez la partie DevOps pour votre langage / framework. Comprenez comment votre code est compilé, empaqueté, publié, déployé et mis à niveau. Si vous êtes un DevOps / sysadmin - apprenez et comprenez la partie développement. Comprenez comment les développeurs choisissent sur quoi travailler, comment ils effectuent les révisions, quelle est la politique de branchement.

Pour tout nouveau système / sous-système sur lequel vous travaillez, posez-vous les questions suivantes: «que se passe-t-il si le système sur lequel il fonctionne meurt?», «Comment le système va-t-il évoluer avec 1000 fois plus de charge / utilisateurs», «comment les autres utilisateurs va interagir avec mon système? ».

Arrêtez de trop optimiser. Si votre code / système fonctionne bien, laissez-le. Jusqu'à ce que vous commenciez à remarquer des problèmes potentiels dans votre surveillance. Ce qui nous amène au point suivant:

Surveillez tout ce que vous pouvez. Si vous écrivez du code, pensez à un moyen de surveiller ses performances. Depuis le tout début. Si vous construisez des systèmes, pensez à toutes les mesures que vous devez surveiller. Encore une fois, depuis le début.

Sauvegardez tout ce que vous pouvez. Code - sauvegardez-le (et utilisez le contrôle de code source!). Données - sauvegardez-les. Paramètres - sauvegardez-le.

Découvrez les outils / IDE que vous préférez utiliser (ou que vous devez utiliser par l'entreprise), lisez la documentation et passez du temps à parcourir les paramètres. Chacun. Comprenez ce qu'ils font. Configurez correctement. Exportez et sauvegardez les paramètres
Rappelez-vous toujours: vous êtes facilement remplaçable. Aussi talentueux que vous pourriez être, aussi bien informé dans un domaine de niche que vous pourriez l'être - il y a toujours quelqu'un de meilleur. N'essayez pas de «thésauriser» les connaissances pour assurer la sécurité de l'emploi. Cela ne fonctionne pas à long terme. Soyez honnête et essayez de le rendre facile pour quiconque vient après vous.

Apprenez toujours comment quelque chose fonctionne jusqu'au moment "aha!";)

Hors ligne

Pied de page des forums