Home » Sciences et technologies » 3 interviews cauchemardesques pour les développeurs de logiciels

3 interviews cauchemardesques pour les développeurs de logiciels

by Nouvelles
3 interviews cauchemardesques pour les développeurs de logiciels

Cette article a été initialement publié sur .cult par Nadya Primak. .cult est une plateforme communautaire basée à Berlin pour les développeurs. Nous écrivons sur tout ce qui concerne la carrière, réalisons des documentaires originaux et partageons des tas d’autres histoires inédites de développeurs du monde entier.

L’industrie de la technologie n’est pas connue pour avoir d’excellents processus d’entretien. Des entretiens notoires sur tableau blanc aux défis d’algorithmes nécessitant un diplôme en informatique pour comprendre même votre tête, il existe toutes sortes de normes et d’approches obsolètes pour interviewer les développeurs qui auraient dû disparaître il y a des années. Malheureusement, comme la plupart des systèmes hérités que nous aimons détester, ces processus d’entretien sont susceptibles d’apparaître de temps en temps dans votre carrière. Ou si vous êtes malchanceux comme moi, ils pourraient apparaître un peu plus souvent.

Pour être clair, je n’écris pas cet article pour interpeller des entreprises en particulier ou dans le but de nommer et d’humilier. Pour chaque entreprise dans laquelle j’ai rencontré ces problèmes, il y en a des centaines de milliers, voire des millions d’autres. L’une des façons les plus courantes pour les entreprises technologiques de pratiquer le contrôle d’accès est de rendre le processus d’entretien si difficile qu’il laisse tout le monde, sauf (généralement) les hommes blancs diplômés en informatique, se sentir comme s’ils n’étaient pas assez bons ou n’avaient pas leur place.

Rejoignez TNW à Valence !

Le cœur de la tech arrive au cœur de la Méditerranée

Dans cet article, vous allez lire quelques-unes des façons les plus courantes dont les entreprises peuvent faire de votre processus d’entretien un cauchemar et, espérons-le, être en mesure de les reconnaître dès le début afin de ne pas perdre votre temps. Je partagerai des anecdotes personnelles sur la façon dont ils m’ont touché et sur la façon dont je les ai dépassés et vous le pouvez aussi.

1. Entretiens au tableau blanc

Comme je l’ai dit dans l’introduction, les entretiens sur tableau blanc font partie de ces approches obsolètes avec lesquelles les entreprises technologiques aiment encore nous torturer. L’idée générale est que vous montez devant un tableau blanc et que vous écrivez un mappage de pseudo-code sur la façon de résoudre un algorithme.

Au cas où il ne serait pas immédiatement évident pourquoi cette approche craint, laissez-moi vous expliquer. Forcer un développeur à écrire du code à la main est intrinsèquement contre nature car cela nous fait sortir de la zone où nous faisons notre meilleur travail : devant un ordinateur. Cela nous prive également de notre outil le plus utile : les moteurs de recherche. Sans compter qu’elle n’a aucune incidence sur la réalité quotidienne du travail.

C’est particulièrement problématique pour les développeurs autodidactes, car les cours et les ressources en ligne les moins chers ont tendance à ne pas se concentrer sur les algorithmes, mais sur des compétences pratiques plus pratiques, comme la création d’applications. Même les étudiants qui sont allés dans une institution traditionnelle de 4 ans et qui se sont spécialisés en informatique ont souvent besoin de pratiquer ces algorithmes chaque fois qu’ils se présentent à des entretiens, car ils sont faciles à oublier.

J’ai perdu la trace du nombre d’interviews sur tableau blanc que j’ai eues, mais il y en a quelques-unes qui sont particulièrement nettes dans ma mémoire. L’un était pour une petite startup où j’interviewais 1: 1 et le gars qui m’interviewait était très maladroit. Je savais que l’algorithme qu’il me demandait d’écrire était relativement simple, mais pour une raison quelconque, mon cerveau ne pouvait tout simplement pas s’en souvenir. Au lieu de couper l’entretien plus tôt ou de me donner un indice, l’intervieweur a insisté pour faire traîner la partie du tableau blanc pendant un temps ridiculement long. J’ai passé plus d’une heure dans son bureau à me débattre avant d’arriver enfin à la solution. Naturellement, je n’ai pas obtenu le poste, mais j’étais tellement frustré après coup que mon humiliation a dû durer si longtemps.

La bonne nouvelle est que les interviews sur tableau blanc sont de plus en plus démodées. Il y a beaucoup de critiques à leur égard dans la communauté des développeurs et je peux probablement compter sur une main le nombre de développeurs que je connais qui aiment vraiment ce type d’interviews.

2. Évaluations techniques chronométrées

Si vous êtes allé au lycée aux États-Unis, vous avez probablement une place spéciale de haine dans votre cœur pour les tests chronométrés. La première fois que j’ai passé l’ACT, j’ai eu un mauvais score simplement parce que je ne pouvais pas m’empêcher de regarder l’horloge et de m’inquiéter du temps qu’il me restait. Cela n’a pas aidé qu’à mi-chemin, je doive aller aux toilettes, mais j’étais trop nerveux pour quitter la pièce à cause du temps que je risquais de perdre.

Comme les entretiens sur tableau blanc, les évaluations techniques chronométrées ont tendance à comporter des composants algorithmiques. Il y a quelques années, j’ai décidé d’essayer l’une de ces plates-formes où vous passez un test de codage pour créer un profil de développeur pour les entreprises qui souhaitent externaliser les éléments techniques à un tiers (Hired en est un exemple).

Il y avait trois défis différents que j’ai dû relever avec succès pour être admis sur la plateforme. Tous étaient lourds d’algorithmes et j’avais fait une pratique relativement minimale. J’ai fini par rester bloqué sur le deuxième défi et je n’ai pas eu assez de temps pour terminer le troisième. Il peut être très démoralisant de passer un test et d’avoir l’impression de n’avoir pratiquement aucune idée de ce que vous faites. Si vous êtes autodidacte, il y a de fortes chances que vous vous sentiez assez démoralisé car vous n’avez pas étudié les algorithmes à l’université.

La pression supplémentaire du timing ne reflète pas non plus la réalité de la plupart des emplois de développeur. Il n’y a pratiquement jamais de situation où vous n’avez que 20 minutes pour accomplir une tâche, en fait, le codage de nouvelles fonctionnalités prend généralement des jours, voire des semaines.

La bonne nouvelle est qu’il existe des plates-formes qui ont surgi pour aider les développeurs à se préparer à ces évaluations techniques chronométrées. Hackerrank est probablement le plus populaire et est un excellent outil pour les développeurs autodidactes et titulaires d’un diplôme en informatique pour approfondir ces compétences.

Contrairement aux entretiens sur tableau blanc, les évaluations techniques chronométrées ne mènent nulle part. Ils sont pratiques pour les responsables du recrutement car il leur suffit d’envoyer un lien au développeur et la plateforme administre le test et renvoie les résultats. Les responsables du recrutement qui choisissent d’utiliser ces plateformes ne sont pas nécessairement paresseux, ils peuvent simplement diriger une petite entreprise ou avoir trop d’autres tâches à jongler. Mais cela vaut quand même la peine de se méfier de ce type d’entretien et de savoir dans quoi on s’embarque.

3. Écrans de téléphone

Tous les écrans de téléphone ne sont pas techniques. Certains d’entre eux sont des conversations informelles avec le recruteur ou quelqu’un des RH. En fait, c’est généralement ce à quoi on pense avec un écran de téléphone. Cependant, parfois, les entreprises font preuve de créativité ou souhaitent raccourcir le processus d’entretien en sautant une évaluation technique et en se contentant de mener une session de questions-réponses par téléphone.

En théorie, cela pourrait être formidable. Pas d’évaluations techniques ou de projets à réaliser à la maison. Un petit coup de fil et le tour est joué ! C’était exactement mon état d’esprit lorsque j’ai rencontré ce type d’entretien pour la première fois. Mais mon attitude a changé rapidement après avoir obtenu le poste. J’ai réalisé que certains de mes collègues n’avaient pas du tout les compétences requises et pouvaient assez facilement duper le responsable du recrutement en leur faisant croire qu’ils étaient compétents.

L’autre danger des dépistages téléphoniques est le jargon technique. C’est encore plus un problème pour les développeurs autodidactes, mais il y a tellement de jargon dans le monde du codage que personne n’est à l’abri. Si on me demande au téléphone de définir un terme technique, il y a de bonnes chances que je connaisse le concept, mais pas par son nom, mais que j’ai oublié le terme auquel il est associé ou que je ne l’ai pas suffisamment rencontré pour essayer de mémoriser ce ça veut dire. Cela m’a amené à échouer aux dépistages téléphoniques dans le passé, ou à être invité à faire des devoirs supplémentaires à la maison.

Il est assez rare qu’une entreprise ne fasse qu’un écran de téléphone et ne donne pas une sorte de test de codage en personne ou en ligne, mais vous pouvez le rencontrer si vous effectuez un travail contractuel ou postulez pour une entreprise qui n’a pas beaucoup de technique postes. Avancez simplement avec prudence.

Plats à emporter

Les développeurs autodidactes doivent être plus conscients et se préparent souvent davantage aux entretiens que leurs pairs titulaires d’un diplôme en informatique. Cela se résume souvent à la différence d’être moins familier avec le jargon technique et les algorithmes, qui sont surestimés dans le processus d’entretien par rapport au travail quotidien réel des développeurs de logiciels.

Heureusement, certaines des approches d’entretien particulièrement désagréables comme les entretiens sur tableau blanc deviennent assez impopulaires, mais cela vaut toujours la peine d’être préparé et de savoir qu’il est possible que vous ayez des énigmes de tri ou une salade de mots jetée sur votre chemin.

Vous devez également savoir qu’il existe des entreprises qui proposent des défis de codage pratiques qui reflètent un meilleur environnement pour les programmeurs, car cela signifie qu’elles se soucient de l’expérience de leurs candidats (et probablement plus de leurs employés aussi). Il y a place à l’amélioration, mais aussi beaucoup de discussions sur la façon d’améliorer le processus d’entretien dans l’industrie, et heureusement, certaines entreprises écoutent et font de grandes améliorations.

You may also like

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.