Image from the movie "Harry Potter and the Prisoner of Azkaban"
Le problème de ce monde est que les gens éduqués sont pleins de doutes, tandis que les idiots sont pleins de confiance.
Charles Bukowski
Récemment, j'ai donné une nouvelle leçon individuelle de programmation. Contrairement aux cours habituels, le sujet n'était pas la syntaxe du langage ni un problème à résoudre. L'étudiant a partagé ses inquiétudes concernant son avenir professionnel. Lui-même était plutôt intelligent. C'est un de ceux qui suivent les cours, terminent rapidement tout le programme avec des solutions originales, mais qui sous-estiment constamment leurs capacités. À mon avis, ce genre de doutes provient d'un manque d'informations. J'ai essayé de combler cette lacune en improvisant pendant le cours.
Les questions étaient à peu près les suivantes :
- Chaque année, de nombreuses diplômés d'universités recherchent un emploi. Il y a tellement de personnes. Ils vont sûrement prendre les meilleurs, et je n'aurai pas de place.
- Que se passe-t-il si je fais une erreur et qu'ils me renvoient immédiatement ?
- Que se passe-t-il si, pendant le travail, ils réalisent que je suis stupide et qu'ils me virent ?
Cet étudiant n'était pas la première personne à qui j'ai répondu à de telles questions. Elles surgissent chez beaucoup, et souvent je dois expliquer sans préparation. Cette fois, j'ai décidé de noter mon monologue dans un carnet. Je pensais que je ferais quelques paragraphes, mais cela a pris la forme d'un véritable article.
Dans cet article, je partage mon point de vue et mon expérience. Cependant, notre monde est extrêmement diversifié, et des choses étonnantes s'y produisent. Si vous n'êtes pas d'accord ou si votre expérience est différente, n'hésitez pas à laisser un commentaire.
L'article a été écrit par un développeur pour des développeurs. Toutefois, si vous envisagez de vous lancer dans le testing, l'administration ou toute autre tâche dans le domaine des TI, certains conseils vous seront également utiles.
Ils ne m'embaucheront pas du tout.
Quand on imagine que chaque année, de nombreuses universités forment des centaines d'étudiants, on se sent mal à l'aise. Comment rivaliser avec une telle foule immense ?
Malheureusement, tous les diplômés n'ont pas une formation technique adéquate. Essayez de demander à un étudiant de votre connaissance : comment les membres de son groupe obtiennent-ils l'accès aux examens pour des matières comme « bases de données » ou « principes de l'algorithmique et de la programmation » ? Dans un groupe de 30 personnes, au mieux, il y aura 3 à 5 étudiants « avancés » qui ont réellement fait tout le travail. Les autres se contentent de copier leurs réponses, de mémoriser celles-ci et de passer les examens.
C'était aussi le cas lorsque j'étais étudiant. Cependant, mon expérience pourrait ne pas être représentative. C'est pourquoi j'ai posé cette question à plusieurs étudiants de divers établissements. La réponse était à peu près la même. Les répondants venaient de différentes universités et collèges. Je laisserai les considérations sur les raisons en dehors de cet article. Je n'ai pas suffisamment de temps pour une recherche complète, donc je tirerai des conclusions basées sur les faits disponibles.
Parmi des centaines de diplômés, seules quelques dizaines intéressent réellement les employeurs.
Peu de diplômés peuvent rivaliser avec un étudiant compétent et bien préparé. Toutefois, même si vous avez étudié sérieusement, après votre premier entretien, vous ne serez probablement pas embauché. Après le deuxième, peut-être non plus. Tout peut se passer pour le mieux, mais mieux vaut se préparer non pas à une attaque, mais à un siège. Une tentative d'obtenir un emploi ratée est uniquement une occasion de travailler sur ses erreurs et d'essayer à nouveau. Je ne vais pas parler de la préparation aux entretiens. Beaucoup de choses ont déjà été écrites à ce sujet sur Internet. Je dirai juste qu'il existe des nuances en matière d'entretien, pour l'explication desquelles votre programme d'études n'a probablement pas prévu de temps. Cherchez cette information par vous-même, elle peut réduire le nombre de vos tentatives.
La folie, c'est de répéter inlassablement la même action, en espérant un changement.
Albert Einstein
Pour que le processus des entretiens ne devienne pas une folie, il est nécessaire de s'améliorer après chaque nouvelle tentative. Notez ou inscrivez les questions qui vous ont été posées lors de l'entretien. De retour chez vous, consultez cette liste et vérifiez-vous à l'aide d'Internet. Cela vous permettra de comprendre où vous vous êtes trompé et où l'intervieweur. Cela arrive aussi. Revenez sur les sujets pour lesquels vous avez mal répondu et essayez à nouveau.
De plus, il existe une saisonnalité marquée sur le marché du travail. Les entreprises avisées planifient les recrutements en tenant compte des dates de remise des diplômes. Au printemps, il y a plus d'offres pour les débutants que le reste de l'année. Cependant, la concurrence est également plus forte à cette période.
Un mauvais choix — vous serez licencié
Lorsque l'on recrute une personne sans expérience, des attentes précises l'accompagnent.
On attend d'un débutant au travail :
- Une connaissance de la base technique générale
- Une étude des particularités du domaine d'activité de l'entreprise
- Une maîtrise des outils et des pratiques utilisés
Dans certaines organisations, des sessions de formation sont organisées pour les débutants sur les technologies utilisées, les outils et les pratiques locales. Par exemple, les règles de courtoisie pour l'utilisation des courriels d'entreprise, le processus de modification des documents dans le wiki, les spécificités locales du travail avec les VCS et les systèmes de suivi des bogues.
Il existe également des cours d'introduction technique, mais leur utilité est douteuse. Si vous avez atteint le stade de l'embauche, cela signifie que les recruteurs ont constaté que vous disposez d'un certain niveau de connaissances. Il est préférable de suivre ces cours de manière sérieuse, comme une simple formalité. Peut-être qu'il y aura vraiment quelques éléments utiles.
Lorsque vous commencerez à travailler, rappelez-vous que l'on ne confiera pas à un débutant la tâche de résoudre un problème urgent, complexe et en même temps important. Il y aura probablement seulement une de ces caractéristiques. Soit une tâche simple mais urgente : corriger la mise en page, transférer un fichier à quelqu'un, reproduire un problème. Soit une tâche complexe, mais sans espoir de la terminer — juste pour que le débutant accumule des erreurs. Soit une tâche importante, mais expérimentale. Par exemple, un projet que tout le monde attend depuis longtemps, mais pour lequel personne n'a pu trouver le temps de le réaliser.
Les tâches d'apprentissage des outils seront « compliquées » et artificielles. Il s'agira probablement d'une version simplifiée du système principal. Dans ces tâches, on utilise le même ensemble de technologies et les mêmes termes du domaine que dans l'ensemble du projet. Cependant, le résultat ne sera pas remis à l'utilisateur final. Cela peut démotiver, mais il est préférable de résister à cette humeur. Une tâche artificielle doit être exécutée avec sérieux, comme si le sort du projet en dépendait.
Le résultat de la résolution de votre première tâche laissera une première impression sur vous auprès de collègues qui n'étaient pas présents à l'entretien.
Une autre façon d'aborder la maîtrise des outils est « de lancer un projet sur une machine locale/environnement de test ». Parfois, ce processus est décrit dans une documentation. Mais celle-ci est souvent ancienne et parfois obsolète. Vous pouvez apporter une réelle valeur au projet en écrivant une nouvelle documentation avec des précisions sur les problèmes rencontrés. Assurément, vous avez déjà dû rédiger des rapports pour certaines disciplines à l'université. C'est presque la même chose ici. Le document doit refléter les actions à réaliser pour le lancement.
En général, les actions pour lancer le produit dans un environnement de test sont à peu près les suivantes :
- cloner le dépôt, basculer sur une certaine branche ou un tag
- préparer un fichier de configuration
- préparer la structure de la base de données
- la remplir de données de test
- exécuter la construction ou la compilation du projet,
- lancer un ensemble de scripts console dans un certain ordre
Dans le processus de lancement du système localement, des problèmes imprévus surgiront inévitablement.
Les solutions trouvées aux problèmes doivent être ajoutées à la documentation de déploiement. Ainsi, lors du prochain suivi de cette documentation, ces problèmes ne se présenteront plus. Lors de la complétion des fichiers de configuration et de l'appel des scripts, il est important de prêter attention à quelle valeur est utilisée et à ce à quoi elle doit correspondre. Par exemple, si le projet est construit à l'aide d'un système CI puis lancé via un script, il est essentiel de savoir où indiquer le nom de la branche ou le numéro de commit. Il arrive que le script nécessite le passage adresses IP ou le nom DNS de la base de données, ses identifiants et son mot de passe. Dans ce cas, il est crucial de connaître l'adresse à utiliser pour l'environnement de test, quels sont les identifiants disponibles et quels mots de passe doivent y correspondre.
Certaines tâches peuvent sembler simples pour des développeurs expérimentés et poser problème aux stagiaires. C'est un phénomène normal.
Les développeurs doivent résoudre des problèmes techniques au quotidien. Les employés expérimentés ont déjà traité de nombreux problèmes, tandis que les nouveaux doivent encore les affronter. La meilleure tactique serait de noter toutes les erreurs rencontrées dans un document « solutions aux problèmes de ${nom_de_la_tâche} ». Pour chaque problème, il faut formuler une hypothèse sur la cause, chercher des solutions sur Internet et les essayer une par une. Les résultats de chaque tentative doivent également être consignés.
La présentation de vos recherches sous forme de document permettra :
- d'extraire de votre tête les petits détails. Par exemple, les paramètres de configuration, les adresses DNS/IP, les commandes en ligne et les requêtes SQL.
- de se rappeler « que faisais-je hier » lorsque la tâche s’étale sur plusieurs jours.
- de ne pas tourner en rond. Vous pourrez toujours relire ce que vous avez fait auparavant et comprendre que vous êtes revenus au problème initial.
- de répondre clairement à la question : « qu'as-tu fait aujourd'hui ? » même si la solution n'est pas encore prête.
Vous devez être capable de communiquer l'état de vos tâches à vos collègues.
Périodiquement, vos collègues souhaiteront connaître vos succès et partager les leurs. Un peu de temps peut être consacré à cela chaque jour ou chaque semaine.
Si vous ne suivez pas les problèmes rencontrés et résolus, la description de vos succès ressemblera à : « J'ai essayé de faire la tâche, mais je n'y arrive pas. Je cherche encore une solution ». De ce récit, il n'est pas clair si le stagiaire a fait quelque chose ou s'il a simplement lu des articles sur Habr. A-t-il besoin d'aide ? La situation a-t-elle changé depuis hier ?
Si vous tenez un document pour votre recherche de solutions, vous pourrez dire : « j'essaie de faire cette tâche. J'ai rencontré ces erreurs. J'ai résolu celles-ci de cette façon. Je n'ai pas encore réussi avec celle-là. J'ai ces hypothèses et options de solution. Je les teste en ce moment. »
Si la tâche peut être mesurée, des chiffres doivent apparaître dans le statut. Par exemple, pour la tâche « écrire des tests unitaires pour le module », on peut dire : « je prévois de faire 20 tests, j'en ai déjà écrit 10 ».
Plus vous donnerez de détails, mieux vos collègues comprendront ce que vous avez fait. Cela formera une bonne impression chez vos collègues et leur permettra de comprendre si vous avez besoin d'aide ou non.
N'hésitez pas à demander de l'aide.
Comme je l'ai mentionné plus haut, lorsque vous rencontrez un problème, vous devez formuler une hypothèse sur ses causes et envisager des solutions. Cependant, il arrive que les hypothèses ne se vérifient pas et que les solutions trouvées ne fonctionnent pas. Dans ce cas, il est préférable de demander de l'aide. Pour ne pas abuser de l'attention de vos collègues, il est important de passer un certain temps sur chaque problème par vous-même. Si vous ne parvenez pas à trouver de solution après quelques heures, il est temps de demander des conseils à des collègues plus expérimentés.
Il est préférable de commencer par la question : « Est-ce que quelqu'un a déjà rencontré ce problème ? » avec une brève description de la situation. Il est souhaitable de joindre un extrait du message d'erreur ou une capture d'écran. Il est conseillé d'envoyer ce message pour la première fois dans un chat général lié au travail. Cela évite de déranger ceux qui sont réellement occupés. Les collègues disponibles verront votre message et pourront aider.
Si personne ne vous aide après avoir posté dans le chat général, essayez de parler à un collègue expérimenté pendant une pause : déjeuner, aller chercher du thé/café, jouer au tennis ou fumer. Si cela ne fonctionne pas, signalez vos difficultés lors d'une réunion ou d'un stand-up.
Pour résoudre des problèmes connus, cela peut s'arrêter ici. Si le problème est nouveau, une enquête commencera, où il faudra agir en fonction des circonstances.
Les tâches « importantes » des débutants, qui sont nécessaires pour l'utilisateur final, seront ennuyeuses et petites. Par exemple, « ajouter une colonne supplémentaire dans le rapport » ou « corriger une faute de frappe dans le formulaire » ou « mettre en œuvre une méthode de modèle pour charger les attributs du client depuis la base de données ». L'objectif de ces tâches est que le nouveau venu se familiarise avec le domaine et s'intègre dans le travail quotidien.
Il est important non seulement de résoudre techniquement la tâche, mais aussi d'élargir ses connaissances dans le domaine.
Dans la description de la tâche, dans les chats et les conversations, on rencontrera des termes. Ils peuvent sembler être des noms familiers. Cependant, dans le cadre d'un système d'information, ils acquièrent un sens particulier et plus précis. La signification des termes trouvés est préférable d'enregistrer dans un document spécial — un glossaire des termes. Lors de l'ajout au glossaire, il suffit d'écrire votre compréhension du mot, mais pour la véritable explication, il vaut mieux s'adresser à l'analyste. S'il n'est pas disponible, alors aux anciens du projet. Tenir un glossaire des termes est l'un des moyens les plus simples de s'initier au domaine d'étude du projet.
Une fois que vous avez trouvé un langage commun avec vos collègues, ils commenceront à vous voir non pas comme un stagiaire novice, mais comme un spécialiste à part entière.
Il existe des tâches particulières, comme « écrire des tests unitaires pour un module ». Il est peu probable que l'on puisse y rester bloqué longtemps en cherchant des solutions. Cependant, c'est une tâche suffisamment sérieuse qui n'est pas seulement donnée pour former le stagiaire. Les tests écrits augmentent la stabilité du projet en réduisant les bugs dans l'application et le temps de test par des humains. Dans un monde idéal, les tests unitaires sont écrits au fur et à mesure du développement, mais la réalité est bien différente. Il arrive que le développeur du module garde tout cela en tête et ne voit pas la nécessité de les écrire. « Tout est évident, pourquoi tester ici ? » Parfois, les modules sont écrits dans le feu de l'action et il n'y a pas de temps pour les tests unitaires. Donc, dans la réalité, il peut ne pas y avoir de tests unitaires. C'est pourquoi la tâche d'écrire des tests unitaires est confiée à un novice. Ainsi, le stagiaire pourra s'intégrer plus rapidement au projet, et le projet pourra économiser le temps de spécialistes mieux rémunérés.
Il arrive que des stagiaires et des novices se voient attribuer le rôle de testeurs à part entière. En général, avant cela, il est nécessaire de déployer le produit localement et de lire les exigences. En guise de résultat, on attend du nouvel employé :
- des questions comme « si je fais cela, cela donnera ceci. Ce n'est pas dans les exigences. Comment cela devrait-il être ? »
- des tâches dans le système de gestion des bugs « les exigences sont écrites comme ça, mais dans les faits c'est différent ».
Les tests sont un domaine d'activité trop vaste pour cet article. Si on vous a assigné une telle tâche, recherchez sur Internet la meilleure façon de l'exécuter.
Si vous commettez des erreurs, vous serez licencié.
Dans une organisation normale, si jamais un employé inexpérimenté obtient accès à quelque chose de critique et endommage quelque chose, la responsabilité incombera à celui qui a permis cela. Parce qu'un débutant n'a pas par défaut accès à l'infrastructure critique. Sous une direction adéquate, on ne va pas faire porter tous les reproches à un stagiaire inexpérimenté.
S'il arrive quelque chose, on ne va pas licencier à cause d'un seul incident. Les gens apprennent de leurs erreurs. Un stagiaire qui a fait une erreur a reçu une leçon précieuse et cela le distingue fortement des autres stagiaires. Si on licencie celui qui a fait une erreur, un autre viendra à sa place et fera exactement la même chose.
L'essentiel est d'apprendre de ses erreurs et de ne plus les répéter.
En revanche, si une personne ne tire pas de leçons de ses erreurs, on essaiera de se séparer d'elle. Cependant, le monde est varié. Dans une organisation criminelle, on peut jeter quelqu'un par la fenêtre dès la première erreur. Mais il vaut mieux éviter de telles entreprises; pour cela, il est souhaitable de se renseigner au préalable ou d'en apprendre davantage lors de l'entretien.
Il est préférable de ne pas commettre d'incidents.
Même si vous n'êtes pas personnellement licencié pour votre erreur, un tel incident causera des problèmes indésirables à votre équipe et au projet dans son ensemble. Donc, faites particulièrement attention lors des opérations de suppression ou de création de tables dans la base de données, de fichiers, d'instances de services et de documents dans la base de connaissances du projet. Si vous rencontrez une nouvelle adresse de connexion, vérifiez avec au moins deux personnes différentes ce que vous pouvez y faire. Vérifiez vos droits dans les environnements non pas par essai et erreur, mais en utilisant les commandes appropriées. Par exemple, vérifier les droits de suppression de fichiers avec la commande `ls`, vérifier les droits de travail avec des tables dans MySQL avec la commande `SHOW GRANTS FOR ‘user’@’host’;`, etc. Pratiquement dans n'importe quel outil, vous aurez cette possibilité.
Lorsque vous éditez des fichiers, conservez une copie originale par précaution.
Entre le stagiaire et le consommateur final, plusieurs barrières sont mises en place.
Si vous pouviez immédiatement remettre votre produit au consommateur, vous pourriez ne pas chercher de travail et choisir de naviguer en 'libre navigation'. Mais tant que vous n'avez pas cette possibilité (ni cette responsabilité), vous devez passer par plusieurs étapes de contrôle dans le projet.
Le premier est l'évaluation par le mentor. Il évalue la solution du débutant d'un point de vue technique. Si aucun mentor n'a été désigné, il faut en trouver un. Pour cela, il suffit de choisir quelqu'un parmi les anciens du projet et de lui demander pendant la pause de jeter un œil à la solution : le problème a-t-il été résolu correctement ? S'il commence à regarder et à répondre, alors le mentor est trouvé. S'il ignore, il vaut mieux demander à quelqu'un d'autre.
La prochaine étape est l'assurance qualité. En russe, ce sont les testeurs. En soviétique, cela s'appelle le contrôle qualité et l'OTK. Ils doivent s'assurer que le résultat du travail du stagiaire correspond à la tâche qui lui a été assignée. Ils ne vont généralement pas lire le code en profondeur. La plupart du temps, les testeurs vont vérifier le projet assemblé que le développeur enregistre dans le système de contrôle de version.
La troisième étape est le gestionnaire de version. Il se peut qu'il n'y ait pas de personne dédiée à cette tâche, mais quelqu'un remplit néanmoins ce rôle. Il vérifie que les testeurs ont confirmé que le projet peut être publié. Ensuite, il exécute les actions nécessaires pour livrer le produit aux utilisateurs finaux.
Dans les petites organisations, ces barrières peuvent être absentes pour diverses raisons. Cependant, on ne confiera pas au débutant la tâche de modifier quelque chose d'important. Parce que ce risque n'est souhaitable pour personne.
Il faut d'abord se lancer dans la bataille, et ensuite on verra.
Napoléon Bonaparte
J'espère que cet article vous aidera à surmonter votre manque de confiance et à envoyer votre premier CV. Bien sûr, vous devez vous préparer à l'avance. Mais ne tardez pas trop. Vous avez probablement déjà étudié pendant plusieurs années à l'université ou au collège. Pourquoi attendre plus ? Après tout, il vaut mieux entendre un 'non' de la part d'un spécialiste et travailler sur ses erreurs, plutôt que de dire 'non' à soi-même chaque jour et de stagner dans sa croissance professionnelle.
Après avoir obtenu un emploi, vous devez vous concentrer sur votre progression en tant que membre à part entière de l'équipe. Cette progression s'accompagne généralement d'une augmentation de votre salaire.
Je vous souhaite patience et persévérance.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Quelles étaient vos premières tâches lors de votre premier emploi dans l'IT ?
Difficiles
Importantes
Urgentes
Aucune des réponses ci-dessus
75 utilisateurs ont voté. 20 utilisateurs se sont abstenu.
Que deviez-vous faire au début de votre premier emploi ?
Installer le produit localement
Tester le produit existant
Réaliser une tâche d'apprentissage fictive
Travailler sur un projet expérimental réel pour un client
63 utilisateurs ont voté. 25 utilisateurs se sont abstenus.
Combien d'étudiants de votre groupe pouvaient réaliser des tâches techniques de manière autonome pendant la formation?
1 sur 10
1 sur 5
Un sur deux
Tous, sauf une rare exception
70 utilisateurs ont voté. 19 utilisateurs se sont abstenus.
Source : habr.com
