À quoi dois-je m'attendre de mon premier emploi en programmation? [fermé]

Je viens d'être embauché pour mon premier emploi en programmation! J'ai 25 ans et j'utilise Java de manière académique depuis 6 ans.

Maintenant que j'ai été embauché, je suis inquiet car mes compétences ne seront pas celles attendues par l'employeur. J'ai bien peur d'être affecté à un projet et de devoir poser beaucoup de questions que mes collègues sentiront comme des amateurs.

Est-ce une peur rationnelle? Quelles ont été vos premières expériences de travail en programmation? A quoi dois-je m'attendre? Quel conseil pourriez-vous me donner?

Merci.

Il y a trop de choses que vous ne pouvez pas apprendre à l'université . Il y a aussi beaucoup de choses spécifiques à l'entreprise . Dans les deux cas, vous avez le choix:

• soit vous demandez des explications à vos collègues,
• ou vous ne demandez rien à personne et vous prenez le risque de vous tromper.

Si j'engage une personne qui n'a pas d'expérience professionnelle, cela ne me dérangerait pas qu'elle pose beaucoup de questions les premières semaines ou les premiers mois. D'autre part, si elle craint de demander de l'aide et perd des heures à résoudre un problème qu'un autre développeur peut résoudre en quelques secondes ou commet des erreurs stupides qui pourraient facilement être évitées par une personne plus ouverte à la communication avec des pairs, cela me dérangera beaucoup plus.

Ne pas éviter les questions. C'est un bon moyen d'apprendre et de socialiser avec les personnes avec lesquelles vous allez travailler. Mais:

• Ne posez pas de questions simplement pour les poser.
• Rappelez-vous que les autres personnes ont leur propre travail et leurs propres délais. Ils ont autre chose à faire que de passer leur temps à vous aider pour chaque tâche.
• Ne vous attendez pas à ce que d'autres personnes fassent votre travail (tout comme il n'est jamais bienvenu de demander à Stack Overflow de faire votre travail).
• Notez que si vous dérangez un développeur, il perd dix minutes ou plus pour se concentrer à nouveau. Donc, ne posez pas de questions si vous pouvez trouver une réponse en quelques secondes sur Internet.

Exemple de mauvaises questions:

• "Hé, je veux créer un tableau comme {1, 2, 3, ... n-1, n} en PHP. Pouvez-vous m'aider?" Ici, vous montrez simplement que non seulement vous ne savez pas comment utiliser la documentation PHP, mais que vous ne vous souciez même pas de chercher sur Google ou de réfléchir un instant. Ce n'est pas grave si vous ne connaissez pas la rangeméthode en PHP. Ce n'est pas correct si vous ne le trouvez pas vous-même.

• "J'essaie d'implémenter des plugins, mais je ne sais pas ce qu'est CAS dans .NET Framework. Pouvez-vous m'expliquer, qu'est-ce que c'est?" Oui, il est plus facile de demander des explications, mais qu’en est-il de la recherche préalable de "CAS .NET Framework 4.0" dans Google?

• "Pourquoi me forcez-vous à utiliser le contrôle de version? J'ai toujours travaillé sans lui et je ne comprends pas pourquoi j'en aurais besoin maintenant." Vos collègues n’ont pas à expliquer pourquoi vous devez l’utiliser. Tout d’abord, c’est un guide de votre entreprise. Vous n'êtes pas ici pour dicter comment travailler. Deuxièmement, il existe de nombreux livres, articles de blog et réponses sur les sites Web SE expliquant pourquoi tout le monde doit utiliser le contrôle de version. Vous devez juste chercher.

Exemples de questions bienvenues:

• "Je souhaite valider les modifications apportées au contrôle de version, mais il existe un message d'erreur étrange. Il indique: [...]. Peut-être savez-vous ce que c'est?" Il est fort probable que votre collègue ait déjà vu ce message des dizaines de fois. Vous pouvez donc poser cette question.

• "Je lis la page 9 des conditions requises pour ce projet, partie 4.2.1, mais je ne suis pas sûr: est-ce à moi ou à l'administrateur de base de données de faire cette partie?" Il vaut mieux demander, que de passer trois jours à faire le travail déjà effectué par la DBA.

• "Je dois implémenter des plugins, mais après avoir lu ceci et cela, je ne comprends toujours pas ce qu'est un bac à sable et en quoi cela est-il lié à la sécurité. Pourriez-vous m'expliquer plus tard, quand vous serez libre?" Vous avez cherché. Vous avez fait un effort. Tu n'as pas compris. C'est bien de ne pas tout comprendre et il serait préférable de demander des explications plutôt que de passer un week-end à les chercher.

"La seule question stupide est celle qui reste sans réponse."

^ Sérieusement. Souviens-toi de ça.

Si vous êtes dans le milieu universitaire depuis 6 ans, je suppose (et espère ) que vous maîtrisez parfaitement les concepts techniques de base. À moins que vous ne vous trouviez dans une mauvaise situation avec un employeur terrible, ils devraient être conscients qu'être fraîchement sorti de l'école dans votre premier emploi, vous aurez une courbe d'apprentissage devant vous et vous attendrez à ce que vous fassiez des erreurs en cours de route. .

Si vos compétences ne correspondaient pas à ce que recherchait l'employeur, ils ne vous auraient pas embauché. S'ils vous ont embauché même si vos compétences ne correspondent pas à ce qu'ils recherchent, vous ne voudrez probablement pas y travailler de toute façon.

Plus vous posez de questions, plus vite vous vous habituerez à votre nouvel environnement de travail. Cela dit, les ingénieurs n’apprécient généralement pas d’être constamment bousculés dans la mesure où il leur faut environ 15 minutes pour revenir dans le vif du sujet. Donc, je penserais peut-être à mettre toutes vos questions pertinentes dans un courrier électronique et à les envoyer à quelqu'un de "connaisseur" à la fin de la journée.

Certaines entreprises vous jumellent avec un mentor, d'autres non.

Arrêtez de vous inquiéter autant. Personne n'est de classe mondiale leur premier jour.

Mon premier travail en programmation consistait à reprendre un site Web écrit dans des langues que je ne connaissais même pas. J'étais l'unique développeur et je n'avais personne à qui demander de l'aide. J'avais très peur de ne pas durer longtemps (sans les forums, je n'aurais probablement pas). Alors qu'est-ce que j'ai fait? J'ai posé une tonne de questions sur les forums. Des tonnes. Je me sentais comme si je posais tellement de questions "amateurs" que j'ai fait mon avatar "je suis stupide" (c'est toujours là-bas ... quelque part).

Mon point est que la peur est naturelle, mais vous allez la surmonter et posez beaucoup de questions aux amateurs. C'est la meilleure façon d'apprendre. Au moins dans mon cas c'était, et l'est toujours.

De plus, lorsque je suivais ma formation en informatique dans l'armée, ils ont brièvement passé en revue chaque concept et ont déclaré: "Vous apprendrez votre travail sur votre premier poste d'affectation ... c'est simplement pour que vous sachiez quelque chose de ce que c'est."

Si vous posez des questions idiotes, mais que vous n'en posez qu'une, vos pairs ne vous haïront pas. Mais si vous n'apprenez jamais, ils diront à votre patron de vous licencier.

Votre Sich est hors de votre contrôle. Soit vous serez avec de bonnes personnes qui voudront que vous réussissiez, soit vous serez avec le mal qui voudra que vous échouiez.

Essayez de ne pas être nerveux et faites ce que vous pouvez. Et mettez beaucoup de travail supplémentaire à apprendre la langue et les applications de l'entreprise.

Lorsque vous posez une question, assurez-vous de:

• Préparer avant de demander
• Donnez à la personne à qui vous demandez le temps de sortir de la zone
• Essayez de faire en sorte que l'autre personne se sente intelligente

http://www.artificialworlds.net/blog/2011/02/12/how-to-ask-technical-questions-in-person/

Mon premier travail de programmation a été réalisé dans un langage et une infrastructure / une plate-forme auxquels je n'avais jamais touché auparavant (Visual C ++ / MFC, et j'ai été éduqué en C sur Unix avec un peu de Java).

Morale de l'anecdote: quand vous n'avez pas d'expérience commerciale, le premier employeur qui vous embauche vous voit généralement plus ou moins comme une table rase. Avec le recul, même si j’avais été embauché pour un rôle C sur Unix, plus de 95% de la courbe d’apprentissage au début de ce premier emploi aurait été beaucoup plus axé sur les compétences générales, le contrôle à la source, la gestion / politique du bureau, etc. des choses que l'expérience académique ne peut pas vraiment vous préparer. Sur le plan technique, ils s’attendent généralement à ce que vous soyez très agité les premiers mois ou les deux premiers mois - le choc causé au système par les aspects non techniques suffit à distraire. Ils le savent, alors ils n'attendent probablement pas grand chose.

MainMa a de bons conseils : essayez simplement de ne pas déranger les gens avec le genre de questions faciles à consulter par Google, qui devraient accompagner le territoire de quelqu'un qui a 6 ans d'expérience universitaire. Une bonne règle est que les connaissances en programmation générique doivent d'abord être étudiées avant de demander, alors qu'il est beaucoup plus sûr de connaître les connaissances internes à une entreprise / un domaine après avoir creusé un minimum.

Je suis aussi un jeune diplômé et je développe des logiciels de manière professionnelle depuis environ un an maintenant. Vous craignez les mêmes choses que je craignais aussi, alors vous n'êtes pas seul. J'ai l'impression d'avoir parcouru ce que vous décrivez ici. Le meilleur conseil que je puisse vous donner est le suivant:

1. Entourez-vous de personnes plus intelligentes que vous et prêtes à jouer le rôle de mentor. Soyez aussi poli que possible, lisez avec les gens et déterminez vos alliances. Tout le monde ne sera pas disposé à vous aider, mais vous saurez facilement qui sont les "bonnes personnes" et ceux avec qui vous voudrez être amis.
2. Posez des questions autant que possible si vous pensez que Google ne peut pas répondre.
3. Réalisez qu'il y en a beaucoup qui ne sont pas allés à l'école depuis un moment, et il est probable qu'ils vous voient comme un esprit neuf pour des idées. N'ayez pas peur de lancer des idées et n'ayez pas peur d'être en désaccord avec les autres.

C'est une mince ligne, mais vous saurez où la traverser et où pas. La meilleure chose à faire est d'être enthousiaste à l'idée d'apprendre et de s'entourer de personnes qui en savent plus que vous sur le développement de logiciels.