🥇Se débarrasser de la peur de son premier emploi

Extrait du film "Harry Potter et le prisonnier d'Azkaban"

Le problème de ce monde est que les gens instruits sont pleins de doutes, mais les idiots sont pleins de confiance.

Charles Bukowski

J'ai récemment donné une autre leçon de programmation individuelle. Contrairement aux cours ordinaires, le sujet n’était pas la construction du langage ou la résolution de problèmes. L'étudiant a fait part de ses inquiétudes concernant son futur emploi. L'étudiant lui-même était plutôt intelligent. L'un de ceux qui viennent au cours termine l'ensemble du programme plus rapidement que quiconque et avec des solutions originales, mais il se sous-estime sincèrement tout le temps. À mon avis, ces doutes proviennent uniquement d’un manque d’information. J'ai essayé de combler cette lacune de manière impromptue pendant la leçon.

Les questions ressemblaient à ceci :

Chaque année, de nombreux étudiants obtiennent leur diplôme universitaire et partent tous à la recherche d'un emploi. Cela fait beaucoup de monde. Ils embaucheront probablement les meilleurs, mais je n’obtiendrai pas de place.
Et si je me trompe et que je me fais virer immédiatement ?
Et si, en cours de travail, ils se rendaient compte que je suis stupide et me mettaient à la porte ?

Cet étudiant n'était pas la première personne à qui je répondais à de telles questions. De nombreuses personnes en sont atteintes et il faut généralement les annoncer sans préparation. Cette fois, j'ai décidé d'écrire mon monologue dans un cahier. Je pensais que cela ferait quelques paragraphes, mais cela a finalement suffi pour un article entier.

L'article décrit le point de vue de mon point de vue et basé sur mon expérience. Cependant, notre monde est très diversifié et des choses étonnantes s’y produisent. Si vous n'êtes pas d'accord avec quelque chose ou si votre expérience est différente, veuillez écrire un commentaire.

L'article a été écrit par un développeur pour les développeurs. Cependant, si vous envisagez de faire des tests, de l'administration ou toute autre chose en informatique, certains conseils vous seront également utiles.

Ils ne vous embaucheront pas du tout

Quand on imagine que de nombreuses universités diplôment des centaines d’étudiants chaque année, cela devient inconfortable. Comment rivaliser avec une foule aussi nombreuse ?

Malheureusement, tous les diplômés n’ont pas une formation technique suffisante. Essayez de demander à un étudiant universitaire que vous connaissez : comment les membres de son groupe sont-ils admis aux examens dans des disciplines telles que les « bases de données » ou les « fondamentaux de l'algorithmique et de la programmation » ? Dans un groupe de 30 personnes, au mieux, il y aura 3 à 5 gars « avancés » qui ont tout fait eux-mêmes. Les autres les copient simplement, remplissent les réponses aux questions et les soumettent.

C’était comme ça quand j’étudiais seul. Cependant, mon expérience n'est peut-être pas représentative. J'ai donc posé cette question à plusieurs étudiants différents. La réponse était à peu près la même. Les répondants provenaient de différentes universités et collèges. Je laisserai les discussions sur les raisons en dehors du cadre de cet article. Je n’ai pas assez de temps pour une étude à part entière, je tirerai donc une conclusion des faits disponibles.

Parmi les centaines de diplômés, seules quelques dizaines intéressent les employeurs.

Peu de diplômés peuvent constituer une véritable compétition pour un étudiant compétent et bien préparé. Cependant, même si vous avez étudié consciencieusement, après le premier entretien, vous ne serez probablement pas embauché. Après le deuxième, probablement aussi. Tout peut bien se passer, mais il vaut mieux se préparer non pas à un assaut, mais à un siège. Une tentative infructueuse pour obtenir un emploi n'est qu'une raison pour travailler sur vos erreurs et réessayer. Je ne parlerai pas de la préparation aux entretiens. Beaucoup de choses ont déjà été écrites sur ce sujet sur Internet. Je dirai simplement qu’il y a des nuances dans les entretiens que votre programme de formation ne prendra probablement pas le temps d’expliquer. Recherchez vous-même ces informations, cela peut réduire le nombre de tentatives.

La folie est la répétition exacte de la même action. À maintes reprises, en espérant un changement

Albert Einstein

Pour éviter que les entretiens ne tournent à la folie, vous devez vous améliorer après chaque nouvelle tentative. Mémorisez ou notez les questions qui vous ont été posées lors de l’entretien. À votre retour chez vous, parcourez cette liste et vérifiez-vous en utilisant Internet. De cette façon, vous comprendrez où vous et l’intervieweur avez commis une erreur. Cela arrive également. Passez en revue ou étudiez les sujets sur lesquels vous avez obtenu de mauvais résultats et réessayez.

À cela s’ajoute une saisonnalité prononcée du marché du travail. Les entreprises intelligentes planifient l’embauche en fonction des dates d’obtention du diplôme. Il y a plus de postes vacants pour les nouveaux arrivants au printemps qu’à d’autres moments. Cependant, la concurrence est plus forte en ce moment.

Stupide - se faire virer

Lorsqu'une personne sans expérience est embauchée, il y a des attentes correspondantes à son égard.

Un nouveau venu dans ce poste doit :

Connaissance des bases techniques générales
Étudier les spécificités du domaine de l'entreprise
Maîtriser les outils et les pratiques utilisées

Certaines organisations proposent des formations aux nouveaux arrivants sur les technologies, les outils et les procédures locales utilisées. Par exemple, les bonnes manières lors de l'utilisation de la messagerie d'entreprise, la procédure de modification des documents dans un wiki, les fonctionnalités locales de travail avec VCS et un outil de suivi des bogues.

Il existe également des cours d'initiation technique, mais leur utilité est discutable. En matière d'emploi, les employeurs sont convaincus que vous disposez d'un niveau de connaissances suffisant. Il est préférable de simplement suivre ces cours de bonne foi, comme une petite formalité. Peut-être qu’ils contiendront réellement quelque chose d’utile.

Lorsque vous commencez à travailler, n'oubliez pas qu'un débutant ne se verra certainement pas confier la résolution d'une tâche urgente, complexe et en même temps importante. Très probablement, il n’y aura qu’une seule de ces propriétés. Ou simple mais urgent : corriger la mise en page, envoyer un fichier à quelqu'un, reproduire le problème. Ou difficile, mais sans aucun espoir d'achèvement - pour que le débutant récupère plus de rake. Ou important, mais expérimental. Par exemple, un projet que tout le monde désire depuis longtemps, mais qui ne trouve pas le temps de le mettre en œuvre.

Les tâches de maîtrise des outils seront « difficiles » et artificielles. Il s'agira très probablement d'une version simplifiée du système principal. Ces tâches utilisent la même pile technologique et les mêmes termes de domaine que l'ensemble du projet. Dans ce cas, le résultat de l'exécution ne sera pas communiqué à l'utilisateur final. Cela peut être démotivant, mais il vaut mieux résister à ce sentiment. Une tâche artificielle doit être accomplie consciencieusement, comme si le sort du projet en dépendait.

Le résultat de la résolution de votre premier problème formera la première impression de vous parmi les collègues qui n'étaient pas présents à l'entretien.

Une autre option pour la tâche de maîtrise des outils consiste à « exécuter le projet sur une machine/un environnement de test local ». Parfois, ce processus est décrit dans les instructions. Mais ils sont généralement anciens et, dans certains endroits, obsolètes. Vous pouvez apporter de réels avantages au projet si vous rédigez de nouvelles instructions avec des éclaircissements sur les problèmes survenus. À l'université, il fallait sûrement rédiger un RGR pour un rapport sur certaines disciplines. C'est presque pareil ici. Le document doit refléter les actions qui doivent être effectuées pour le lancement.

Généralement, les étapes pour exécuter un produit sur un environnement de test ressemblent à ceci :

cloner un référentiel, passer à une branche ou une balise
créer un fichier de configuration
préparer la structure de la base de données
remplissez-le avec des données de test
construire ou compiler le projet,
exécuter un ensemble de scripts de console dans un certain ordre

Au cours du processus d’exécution d’un système localement, des problèmes inattendus surviendront inévitablement.

Les solutions trouvées aux problèmes doivent être ajoutées aux instructions de déploiement. La prochaine fois que vous suivrez les instructions, ces problèmes ne se poseront plus. Lorsque vous remplissez des fichiers de configuration et appelez des scripts, vous devez faire attention à quelle valeur est utilisée, où et à quoi elle doit correspondre. Par exemple, si un projet est assemblé à l'aide d'un système CI puis lancé par un script, il est alors important de comprendre où écrire le nom de la branche ou le numéro de validation. Il arrive que le script implique de transférer l'adresse IP ou le nom DNS de la base de données, son login et son mot de passe. Dans ce cas, vous devez savoir quelle adresse utiliser pour l'environnement de test, quels identifiants existent et quels mots de passe vous devez spécifier pour eux.

Certaines tâches peuvent sembler simples aux développeurs expérimentés mais difficiles aux stagiaires. C'est normal.

Les développeurs doivent résoudre des problèmes techniques chaque jour. Les employés expérimentés ont déjà résolu de nombreux problèmes auparavant, tandis que les nouveaux arrivants n'y sont pas encore parvenus. La meilleure tactique consiste à enregistrer toutes les erreurs rencontrées dans le document « résoudre les problèmes avec ${task name} ». Pour chaque problème, vous devez formuler une hypothèse sur la cause, trouver des solutions sur Internet et les essayer une par une. Le résultat de chaque tentative doit également être enregistré.

L'enregistrement de votre recherche sous forme de document vous permettra de :

déchargez les petits détails de votre tête. Par exemple, les paramètres de configuration, les adresses DNS/IP, les commandes de console et les requêtes SQL.
rappelez-vous « qu’est-ce que j’ai fait hier » lorsque la tâche dure plusieurs jours
ne tournez pas en rond. Vous pouvez toujours lire ce que vous avez fait auparavant et comprendre que vous êtes revenu au problème initial
Répondez clairement à la question : « qu’avez-vous fait aujourd’hui ? » même s’il n’existe pas encore de solution toute faite.

Vous devez être capable de communiquer le statut de vos tâches à vos collègues

De temps en temps, des collègues s’intéresseront à vos réussites et partageront les leurs. Prévoyez du temps pour cela quotidiennement ou hebdomadairement.

Si vous ne gardez pas une trace des problèmes rencontrés et résolus, alors décrire vos succès ressemblera à : « J'ai essayé de faire la tâche, mais je n'y arrive pas. Je cherche toujours une solution. D'après cette histoire, il n'est pas clair si le stagiaire faisait quelque chose ou s'il était simplement assis et lisait. A-t-il besoin d'aide ? La situation a-t-elle changé depuis hier ?

Si vous conservez un document à la recherche de solutions, vous pouvez dire « J'essaie de faire cette tâche. J'ai eu des erreurs comme celle-ci. C'est ainsi que j'ai décidé. Je n'ai pas encore traité de celui-ci. Il existe ces hypothèses et ces solutions. Je les vérifie maintenant."

Si la tâche peut être mesurée d’une manière ou d’une autre, alors le statut doit contenir des chiffres. Par exemple, pour la tâche « écrire des tests unitaires pour un module », vous pouvez dire « Je prévois de faire 20 tests, maintenant j'en ai écrit 10 ».

Plus vous fournissez de détails, mieux vos collègues comprendront ce que vous avez fait. Cela créera une attitude positive à votre égard parmi vos collègues et leur permettra de comprendre si vous avez besoin d'aide ou non.

N'hésitez pas à demander de l'aide

J'ai écrit ci-dessus que lorsqu'un problème survient, vous devez formuler une hypothèse sur ses causes et ses solutions possibles. Cependant, il arrive que les hypothèses ne soient pas justifiées et que les solutions trouvées indépendamment au problème ne fonctionnent pas. Dans ce cas, il vaut mieux demander de l’aide. Afin de ne pas abuser de l'attention de vos collègues, vous devez vous asseoir vous-même sur chaque problème. Si vous n’avez pas réussi à trouver une solution en quelques heures, il est temps de demander conseil à des camarades plus expérimentés.

Un bon point de départ est de demander : « quelqu'un a-t-il déjà rencontré ce problème ? » avec une brève description du problème. Il est conseillé de joindre un morceau du message d'erreur ou une capture d'écran. Il est préférable d'envoyer ce message pour la première fois à une discussion professionnelle générale. De cette façon, vous ne distraire pas ceux qui sont très occupés de leur travail. Les collègues gratuits verront votre message et pourront vous aider.

Si après un message dans le chat général personne ne vous a aidé, essayez de rencontrer un collègue expérimenté pendant une pause : déjeuner, aller prendre un thé/café, une partie de tennis ou une pause cigarette. Si cela ne fonctionne pas, signalez vos difficultés lors de la réunion ou du stand-up.

Si les problèmes connus sont résolus, tout cela pourrait s’arrêter là. Si le problème est nouveau, alors une enquête sera ouverte, où il faudra agir selon les circonstances.

Les tâches « importantes » pour débutants dont l’utilisateur final a besoin seront ennuyeuses et petites. Par exemple, « ajouter une colonne supplémentaire au rapport » ou « corriger une faute de frappe dans le formulaire imprimé » ou « implémenter une méthode modèle pour charger les attributs client à partir du SGBD ». Le but de ces tâches est que le débutant se familiarise avec le domaine et s'intègre dans le travail quotidien.

Il est important non seulement de résoudre techniquement le problème, mais également d'élargir les connaissances dans le domaine.

Les termes apparaîtront dans la description de la tâche, dans les discussions et les conversations. Ils peuvent ressembler à des noms familiers. Cependant, dans le cadre du système d'information, ils ont une signification particulière, plus précise. La signification des termes découverts est mieux enregistrée dans un document spécial - un dictionnaire de termes. Lors de l'ajout au dictionnaire, il suffit d'écrire votre compréhension du mot, mais pour un véritable décodage il vaut mieux contacter un analyste. S'il manque, adressez-vous aux anciens du projet. La tenue à jour d'un dictionnaire de termes est l'un des moyens les plus simples de se familiariser avec le domaine d'un projet.

Une fois que vous aurez trouvé un langage commun avec vos collègues, ils commenceront à vous considérer non pas comme un nouveau stagiaire, mais comme un spécialiste à part entière.

Il existe des tâches spéciales, par exemple « écrire des tests unitaires pour un module ». On peut difficilement rester coincé là-dessus pendant longtemps à chercher des solutions. En même temps, c'est assez sérieux et n'est pas réservé uniquement à la formation des stagiaires. Les tests écrits augmentent la stabilité du projet en réduisant les bugs dans l'application et en réduisant le temps des tests humains. Dans un monde idéal, les tests unitaires sont écrits immédiatement pendant le développement, mais la réalité est toujours différente. Il arrive que le développeur d'un module le garde complètement en tête et ne voit pas la nécessité de les écrire. "Tout est évident, qu'y a-t-il à tester ?" Parfois, les modules sont écrits en mode précipité et il ne reste plus de temps pour les tests unitaires. Ainsi, dans le monde réel, il se peut qu’il n’y ait pas de tests unitaires. Par conséquent, la tâche de rédaction des tests unitaires est confiée à un débutant. De cette façon, le stagiaire pourra s'habituer plus rapidement au projet et le projet pourra faire gagner du temps aux spécialistes les mieux payés.

Il arrive que les stagiaires et les nouveaux arrivants se voient confier le rôle de testeurs à part entière. Habituellement, avant de faire cela, vous devez déployer le produit localement et lire les exigences. En conséquence, le nouvel employé devra :

des questions comme « si vous faites comme ça, ça se passera comme ça. Ce n'est pas dans les exigences. Ça devrait être?"
tâches dans le outil de suivi des bogues « les exigences le disent, mais en réalité, c'est écrit différemment ».

Les tests sont un domaine trop vaste pour cet article. Si une tâche similaire vous est confiée, recherchez sur Internet la meilleure façon de l’accomplir.

Si tu fais une erreur, tu seras viré

Dans une organisation normale, s'il arrive soudainement qu'un employé inexpérimenté accède à quelque chose de critique et gâche quelque chose, alors celui qui a permis que cela se produise sera à blâmer. Car un débutant, par défaut, n’a pas accès aux infrastructures critiques. Avec des conseils adéquats, ils ne laisseront pas tous les chiens se perdre avec un stagiaire inexpérimenté.

Si quelque chose arrive, ils ne vous licencieront pas à cause d’un seul incident. Les gens apprennent de leurs erreurs. Le stagiaire qui a commis une erreur a appris une leçon précieuse et est très différent des autres stagiaires. Si vous licenciez quelqu'un qui fait une erreur, quelqu'un d'autre viendra à sa place et fera la même erreur.

L’essentiel est d’apprendre de ses erreurs et de ne pas les répéter.

Si une personne ne tire pas de conclusions de ses erreurs, elle essaiera de lui dire au revoir. Pourtant, le monde est diversifié. Dans certaines organisations de gangsters, ils peuvent immédiatement vous jeter par la fenêtre à la première erreur. Mais il est préférable d’éviter de telles entreprises en se renseignant d’abord ou en se renseignant davantage lors de l’entretien.

Il vaut mieux éviter les incidents

Même si vous n’êtes pas personnellement licencié pour une erreur, un tel incident entraînera des problèmes indésirables pour votre équipe et pour le projet dans son ensemble. Par conséquent, soyez particulièrement prudent avec les opérations de suppression ou de création de tables dans la base de données, de fichiers, d'instances de service et de documents dans la base de connaissances du projet. Si vous tombez sur l'adresse d'une nouvelle connexion, vérifiez auprès d'au moins deux personnes différentes ce qui peut y être fait. Vérifiez vos droits dans les environnements non pas par essais et erreurs, mais en utilisant les commandes appropriées. Par exemple, les droits de suppression de fichiers à l'aide de la commande `ls`, les droits de travailler avec des tables dans MySQL à l'aide de la commande `SHOW GRANTS FOR 'user'@'host';`, etc. Dans presque tous les outils, vous aurez une opportunité similaire.

Lorsque vous modifiez des fichiers, conservez une copie de l'original pour vous-même, au cas où.

Plusieurs barrières sont construites entre le stagiaire et l'utilisateur final.

Si vous pouviez immédiatement donner votre produit au consommateur, vous ne pourriez pas trouver un emploi, mais vous lancer dans une « baignade libre ». Mais même si vous n'avez pas une telle opportunité (et en même temps une telle responsabilité), vous devez passer par plusieurs étapes de contrôle du projet.
Le premier d’entre eux est la vérification par un mentor. Il évalue la décision du débutant d'un point de vue technique. Si aucun mentor n’a été désigné, vous devez en trouver un. Pour ce faire, vous devez choisir l'un des anciens du projet et lors d'une pause lui demander d'examiner la solution : le problème a-t-il été résolu correctement ? S'il commence à chercher et à réagir, alors un mentor a été trouvé. S’il l’ignore, cela vaut la peine de demander à quelqu’un d’autre.

La prochaine étape est l’assurance qualité. En russe - testeurs. Dans le style soviétique - département de contrôle standard et de contrôle qualité. Ils doivent s'assurer que la performance du stagiaire est conforme à la tâche qui lui est assignée. Ils liront rarement le code. Le plus souvent, les testeurs vérifient le projet construit, que le développeur stocke dans le système de contrôle de version.

La troisième étape est le gestionnaire de versions. Il n’y a peut-être pas de personne distincte pour cette tâche, mais quelqu’un joue quand même ce rôle. Il vérifie que les testeurs ont confirmé que le projet peut être publié. Après cela, il exécute les activités nécessaires pour livrer le produit aux utilisateurs finaux.
Dans les petites organisations, ces obstacles peuvent ne pas exister pour diverses raisons. Cependant, ils ne confieront pas à un débutant la tâche de changer quelque chose d'important. Parce que personne n’a besoin de ce risque.

Il faut d’abord s’impliquer dans la bataille, et ensuite nous verrons.
Napoleon Bonaparte

J'espère que cet article vous aidera à surmonter votre incertitude et à soumettre votre premier CV. Bien sûr, vous devez d’abord vous préparer. Mais il n’est pas nécessaire de trop s’étendre. Vous avez probablement déjà étudié plusieurs années dans une université ou un collège. Où aller ensuite ? En fin de compte, il vaut mieux entendre « non » une fois de la part d'un spécialiste et travailler sur les erreurs que de se dire « non » tous les jours et d'arrêter de grandir professionnellement.

Une fois embauché, vous devez vous concentrer sur votre évolution du statut de stagiaire à celui de membre à part entière de l’équipe. Ce type de croissance 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 à l'enquête. se connecters'il te plait.

Quelles ont été vos premières tâches lors de votre premier emploi en informatique ?

complexe
Important
Urgent
Aucune des réponses ci-dessus

75 utilisateurs ont voté. 20 utilisateurs se sont abstenus.

Que deviez-vous faire au début lors de votre premier emploi ?

Installer le produit localement
Tester un produit existant
Réaliser une formation, fausse tâche
Réaliser un projet expérimental et réel pour un client

63 utilisateurs ont voté. 25 utilisateurs se sont abstenus.

Combien d'étudiants de votre groupe ont été capables de réaliser de manière indépendante des devoirs dans des matières techniques pendant la formation ?

1 de 10
1 de 5
Chaque seconde
Tout, à de rares exceptions près

70 utilisateurs ont voté. 19 utilisateurs se sont abstenus.

Source: habr.com

Se débarrasser de la peur du premier emploi