Logo SilkHhom

7 questions que tous les développeurs devraient poser en entretien

Posté le 2 Juil 2019 dans Recrutement par

L’entretien, c’est le passage obligatoire avant chaque nouveau job. C’est toujours la même chose : on zieute ce que fait l’entreprise, souvent on survole un peu ce qu’elle propose pour garder contenance lors de notre rencontre avec elle. S’ils nous ont invités, c’est bien qu’ils cherchent également à nous convaincre de rester, non ? Il s’engage alors un moment particulier entre recruteur et candidat où il est question de trouver l’équilibre et de vérifier si notre projet professionnel concorde avec les aspirations de l’entreprise. C’est également le moment d’agir subtilement en exposant nos propres exigences.

Pour cela, il n’existe pas beaucoup de méthodes, la plus utile et la plus pertinente restent de poser des questions. Il est essentiel de repartir d’un entretien d’embauche en ayant posé au moins trois questions ! Il est aussi plus agréable de ne pas laisser un énorme blanc lors de la fameuse interrogation « vous avez des questions ? ». De plus, poser des questions montre que vous vous intéressez sincèrement à l’entreprise. Elles peuvent porter sur les technos, les collaborateurs, l’entreprise, le projet, … elles montrent dans tous les cas votre intérêt pour cette entreprise.

Voici sept exemples de questions faciles proposées par Artisan Développeur à glisser lors de l’entretien et qui te permettront quasi à coup sûr d’enclencher la discussion autour du projet qu’il faudra mener au sein de l’entreprise.

1. Quel gestionnaire de source utilisez-vous ?

Cette question à poser en entretien est une bonne entrée en matière. En effet, elle montre que vous vous intéressez à la chaîne d’outils utilisés et que vous lui accordez de l’importance. C’est aussi une question aisée pour le recruteur qui, dans la plupart des cas, vous répondra « git ».

Néanmoins, vous pouvez  vous laisser surprendre avec mercurial ou d’autres outils récents. Il est alors possible de pousser la conversation en demandant pourquoi ils ont préféré ces outils. Mine de rien, vous en savez déjà plus sur la culture de l’entreprise qu’il y a quelques minutes !

Si la réponse est SVN ou CVS, il peut être opportun de creuser pour comprendre pourquoi ils restent sur ce type d’outils obsolètes.

Et… si par malheur ils vous répondent « On utilise Dropbox pour partager nos fichiers de code », vous pouvez réfléchir à prendre vos jambes à votre cou !

2. Se renseigner sur l’ancienneté du code du projet

Une autre question aisée pour tâter un peu le terrain du projet. Cela vous aide à cerner le travail qui a été fait et que vous fournirez un fois embauché. Suivant le nombre de personnes qui ont déjà travaillé dessus, vous aurez une meilleure idée de la quantité de code. Si plusieurs développeurs sont déjà passés par là, il est facile d’imaginer l’inconstance du code et une documentation plus ou moins hasardeuse. Cela ne doit pas forcément être rédhibitoire, mais vous pousser à peut-être réévaluer la situation.

3. Évoquer le recensement des bugs

Cette question à poser durant l’entretien peut vite gêner ou poser problème car elle en dit long sur le type d’entreprise et explicite comment sont gérés les bugs et leur suivi. Cela vous permet aussi de comprendre comment sont remontés les bugs, comment ils sont traités et quel outil est utilisé pour les gérer. Ainsi, vous apprendrez aussi à travers cette question si une équipe est dédiée à la correction des bugs. Plusieurs profils d’entreprise se dégagent de cette interrogation.

– Les professionnels du bug et du débug :

tout est parfaitement sous contrôle, les bugs sont traqués, numérotés, ils savent leur nombre exact mais rechignent à dévoiler ce chiffre. Probablement car il est un peu élevé.

– Les bugs, qu’est-ce que c’est, ça ?

L’autre situation extrême, ils ne sont pas suivis et personne ne s’en occupe vraiment…

– Les indifférents :

oui, il y a des bugs, non on ne peut pas tous les gérer. Donc on ne les suit pas tellement mais on corrige de temps en temps histoire de.

Vous êtes ainsi plus à même de jauger si les bugs sont un problème, ou pas, dans l’équipe. S’ils ne les prennent pas en compte, vous pourrez alors vous interroger sérieusement sur la qualité des projets finaux. Paradoxalement, une entreprise qui passe un temps énorme à corriger des bugs est plutôt une équipe qui génère beaucoup trop de bugs. Et le problème vient certainement de là, sinon, elle n’y investirait pas autant de temps.

4. Quelle bibliothèque de tests unitaires et fonctionnels est utilisée ?

Pour cette question d’entretien, la formulation est importante car vous souhaitez vraiment sous-entendre qu’il est normal d’écrire des tests automatiques. Cela peut alors entraîner un certain malaise si ce n’est pas le cas dans cette entreprise. Dans la plupart des situations, la réaction sera similaire à « Il y a quelques tests qui traînent avec xUnit » où x vaut votre langage favori. Cette réponse démontre que les tests ne font pas partie de la culture de la boîte. Mais est-ce vraiment un problème ?

Cela ne peut ne pas l’être si vous sentez qu’ils ont envie d’évoluer sur la question et de s’améliorer sur ce point.

Mais ça peut le devenir si vous savez que vous allez travailler sur du code legacy, une immense marre où vous risquerez de finir par vous noyer. C’est en plus proportionnel à la vieillesse du projet : plus il est vieux, plus il sera difficile de mettre en place des tests.

Cette question permet de défricher l’interrogation épineuse des tests avec leur place dans la culture de l’entreprise, leur développement et ce qu’ils apportent. Généralement, les entreprises sont intéressées par les tests mais ne sont pas en mesure de les mettre en place. À vous de voir s’ils semblent vouloir changer en se posant des questions ou si la situation est parfaitement statique et inchangeable car vue comme une perte de temps.

5. S’enquérir à propos de la couverture du code actuelle

Si cette demande obtient une réponse non chiffrée, cela signifie que l’entreprise ne mesure pas cette donnée. Au contraire, si elle est chiffrée, c’est que l’entreprise a conscience de l’importance des tests. Avec moins de 10%, cela veut dire que les tests ne sont pas mis en place. Entre 10 et 90% c’est que la couverture est prise en compte. Et au-dessus des 90%, l’entreprise travaille en TDD, ce qui est une excellente chose.

Voici l’occasion rêvée pour parler d’intégration continue, y en a-t-il une ? Qui s’en charge ? Pourquoi n’y en a-t-il pas ? Et s’il n’y en a pas, il s’agit de creuser, de comprendre si c’est par manque d’intérêt, de temps ou de moyen.

6. Comment prend-on une décision d’architecture ?

Cette interrogation est très utile pour situer votre futur poste au sein de l’entreprise. Si l’entreprise doit ajouter une brique à un projet ou faire un changement d’API, qui s’en occupe, comment est-ce géré ? Cela vous permet d’appréhender le leadership de l’entreprise, de voir qui prend les décisions, si les développeurs sont mis à contribution ou s’ils doivent simplement suivre les directions d’un architecte. C’est très utile pour évaluer votre future autonomie mais également pour cerner si des lead dev sont présents et en quelle proportion.

7. Combien de temps est alloué à la veille technologique et à la formation ?

Il est évident que cela vous permettra de situer la vision de l’entreprise sur l’auto formation et s’il est possible d’y accorder un temps par semaine, par exemple. Mais également de la situation du business vis-à-vis de l’auto formation. C’est aussi le moment opportun pour demander si certaines formations sont financées et comment cela se déroule lors de la mise en œuvre d’une nouvelle technologie. Il est préférable d’avoir des réponses concrètes pour visualiser si le schéma est déjà pensé ou si l’entreprise avance au cas par cas.

Avec ces sept questions à poser en entretien, vous voilà déjà avec de nombreuses clés en main pour cerner l’entreprise, sa vision du développement et son avancée côté technique. Vous venez aussi de démontrer un réel intérêt pour l’entreprise et les technologiques qu’elle utilise, c’est un point de marqué !

 


Dans tous les cas, vous pouvez toujours consulter nos offres d’emploi !


Source : artisandeveloppeur.fr




Laissez un commentaire



Mais aussi...