Juste être embauché en tant que développeur senior, jamais même été développeur junior, à quoi dois-je m'attendre? [fermé]

Je suis pigiste et codeur de nuit depuis un certain temps, et récemment, j'ai été embauché après plusieurs niveaux d'entretiens dans une belle entreprise de New York, même si j'ai quelques lacunes dans des domaines spécifiques. Est-ce courant pour les entreprises d'embaucher des seniors avec moins d'expérience? Vont-ils attendre quelques semaines pour respecter une certaine courbe d'apprentissage?

Je ne sais rien du travail dans une entreprise, c'est pourquoi je m'inquiète. Après une semaine, je vérifie et explore toujours les sources, mais après une semaine de travail, il semble que certains collègues considèrent que je suis lent. Je suis bon en mathématiques, en physique, en algorithmes, mais j'ai encore besoin de me renseigner sur tous les modèles utilisés dans cette entreprise.

Quelqu'un ici a déjà reçu un membre senior moins expérimenté de son équipe? Est-ce acceptable?

Je prévois d'avoir une réunion avec mon patron pour arrêter de m'inquiéter à ce sujet. Ça semble être une bonne idée?

[ÉDITER]

Merci pour ces réponses. Je suis définitivement un - nouveau - développeur senior. Je suis retourné au bureau avec plus de confiance lundi. Je suppose qu'il est normal de se sentir un peu incompétent devant des modèles / sources inconnus pendant les premières semaines lorsque vous recevez un bon salaire.

Il n'y a pas de définition communément acceptée de "développeur senior". Des définitions peuvent exister au sein des organisations, mais un développeur senior représente généralement quelqu'un:

1. Avec une expérience en développement logiciel (3-5 ans minimum),
2. Peut travailler sans supervision constante (souvent sans supervision),
3. Familier avec l'environnement et les outils de développement,
4. Capable de superviser ou d'enseigner aux développeurs juniors,
5. Capable de concevoir et de mettre en œuvre des projets de petite à moyenne taille.

Il est difficile de parler de votre situation spécifique, mais il y a généralement une courbe d'apprentissage lorsque vous rejoignez une nouvelle équipe.

Quelle que soit la qualité des outils et des processus qu'ils utilisent, chaque équipe a un historique de décisions qui les conduisent à leur état actuel. Si l'organisation utilise des bibliothèques ou des environnements personnalisés, ma première question serait de poser des questions sur la documentation et la formation . Les grandes entreprises peuvent avoir une formation officielle pour les nouveaux employés, même les plus âgés. Lisez toutes les conceptions existantes, la documentation de l'environnement de construction, les processus, etc. Si celles-ci n'existent pas, proposez de les documenter .

Je demanderais ensuite de me jumeler avec un développeur senior existant . C'est généralement le moyen le plus rapide d'apprendre ce qui est attendu et comment les choses fonctionnent. Comment ont-ils résolu ce problème? Combien d'efforts ont-ils consacré aux tests unitaires et aux examens? Pourquoi l'ont-ils fait de cette façon et non de cette façon? Assurez-vous que l'autre développeur vous aide à configurer votre environnement de développement et vous guide également tout au long du processus de publication .

Expliquez-leur que vous connaissez le langage et les outils, mais pas leurs techniques. Par exemple, si vous avez fait les choses différemment auparavant et que vous pensez que c'est mieux que leur façon, suggérez-le avec prudence et respect.

Espérons que le jumelage avec eux ne les ralentira pas. Ils peuvent même apprécier une autre paire d'yeux pour détecter les fautes de frappe et les problèmes avant de s'engager dans le contrôle des sources.

Enfin, sachez que vous n'allez pas comprendre pleinement un grand projet dans une semaine, alors commencez à corriger de petits bugs ou fonctionnalités . Assurez-vous que votre copain les examine et que vous obtenez tous les commentaires. Vous allez manquer des choses. Vous ferez des erreurs. C'est bon. Apprenez d'eux, ne les répétez pas et travaillez dur. Si vous êtes bon dans ce que vous faites, vous y arriverez.

Après une semaine, je vérifie et explore toujours les sources, mais après une semaine de travail, il semble que certains collègues considèrent que je suis lent.

Une semaine est une courte période de temps. Même après un mois, vous vérifierez toujours les sources. Vous n'êtes pas engagé par cette entreprise pour connaître son code par cœur. Vos outils de développement ou IDE sont là pour vous aider. Si un problème survient avec certains collègues après une semaine, demandez-leur simplement comment ils fonctionnent et quels outils utilisent-ils. S'ils considèrent que vous êtes lent après une semaine, c'est totalement abusif. Le temps minimum nécessaire pour comprendre une application existante est d'environ un mois. Surtout avec les affaires d'entreprise, c'est parfois ou la plupart du temps non documenté du tout. Vous êtes un humain, pas un ordinateur.

Vous devriez demander à vos collègues de cesser de vous montrer que vous êtes lent ou qu'ils sont meilleurs que vous, c'est insensé! Bien sûr, ils sont plus rapides que vous, car ils ont écrit les trucs ... Quelqu'un vous donne le travail, vous avez été embauché pour ce que vous êtes capable de faire et ce que vous avez fait auparavant, alors ces gars ne devraient que vous accueillir, aider vous avec une explication de kickstarter, des stand-ups quotidiens et des débriefings hebdomadaires. S'ils continuent avec ce comportement, c'est très inquiétant et vous devriez envisager de résoudre ce problème avec un manager ou de partir.

Je suis bon en mathématiques, en physique, en algorithmes, mais j'ai encore besoin de me renseigner sur tous les modèles utilisés dans cette entreprise.

C'est assez normal et cela peut prendre des mois. Essayez de travailler d'abord sur de très petits morceaux de l'application, puis vous apprendrez et pourrez avoir une vue globale du code, des processus (c'est peut-être aussi important que le code), de la méthodologie (même si ce n'est pas formel), etc.

Même pour les personnes expérimentées dans le «travail en entreprise», être sur vos gardes n'est pas forcément une mauvaise chose, cela vous tient alerte et concentré. Tant que vous gardez votre confiance et ne restez pas paralysé.

Cela devient plus facile. En travaillant sur une grande base de code, il faut s'attendre à ce que vous ayez besoin de temps pour vous familiariser avec ses subtilités. J'ai passé plus d'une décennie à travailler pour un certain nombre d'entreprises avant de passer au développement (il y a un peu plus d'un an) et j'ai encore des moments de doute lorsque je traite des problèmes complexes ou des quantités de code intimidantes (notre code le nombre de lignes de base s’élève à plusieurs millions), mais je me contente de continuer, de garder Google, StackOverflow et ce site Web ouvert, de travailler et je ne suis pas trop fier de demander de l’aide. Vous faites partie d'une équipe, vous n'êtes plus le seul codeur de votre bureau à domicile. Bénéficiez de l'expérience et des connaissances de vos collègues.

Vous avez été embauché après plusieurs niveaux d'entretiens , cela signifie qu'ils ont fait un choix éclairé en vous embauchant. Soyez cool, vous avez le travail. Cela signifie qu'il existe déjà un niveau de confiance dans vos capacités et que vous codez depuis un certain temps maintenant. Vous ferez bien.