Ne vous semble-t-il pas étrange que lorsque vous envisagez de changer d'emploi et que vous devez passer un entretien, vous pensiez d'abord à « il faut se préparer à l'entretien » ? Résoudre des exercices sur HackerRank, lire Crack the Coding Interview, mémoriser comment fonctionne un ArrayList et en quoi il diffère d'un LinkedList. Ah oui, on pourrait aussi vous demander des triages, et il serait clairement non professionnel de dire que le quick sort serait probablement le meilleur choix.
Mais attendez, vous programmez 8 heures par jour, vous résolvez des problèmes intéressants et non triviaux, et au nouveau travail, vous ferez à peu près la même chose. Pourtant, pour passer l'entretien, vous devez vous préparer d'une manière ou d'une autre, même pas en perfectionnant vos compétences quotidiennes, mais en apprenant ce qui ne vous a pas été utile dans votre poste actuel et peu susceptible de l'être au suivant. À vos objections sur le fait que l'informatique est dans notre sang, et que si on nous réveille au milieu de la nuit, nous devons écrire en fermant les yeux sur un oreiller une traversée en largeur d'un arbre sans même prendre conscience, je répondrai que si je postulais à un cirque et que mon principal tour était exactement cela — alors oui, peut-être que je suis d'accord. Il faut vérifier cette compétence.
Mais pourquoi vérifier des compétences non pertinentes pour le travail actuel ? Seulement parce que c'est à la mode ? Parce que Google le fait ? Ou parce que votre futur leader d'équipe a dû apprendre tous les algorithmes de tri avant de passer l'entretien et qu'il pense maintenant que « chaque bon programmeur doit savoir par cœur l'implémentation pour trouver un palindrome dans une chaîne ».
Eh bien, sachez que vous n'êtes pas Google (c). Ce que Google peut se permettre, les entreprises ordinaires ne le peuvent pas. Google, après avoir analysé les données de ses employés, en est arrivé à la conclusion que, pour ses tâches spécifiques, il était judicieux d'avoir des ingénieurs ayant un passé olympique. De plus, en construisant le processus de sélection, ils peuvent se permettre d'assumer le risque de ne pas embaucher plusieurs bons ingénieurs simplement parce qu'ils n'arrivent pas à résoudre des problèmes mathématiques aussi facilement. Mais pour eux, ce n'est pas un problème, il y a beaucoup de candidats désireux de travailler chez Google, le poste sera pourvu.
Jetons un coup d'œil par la fenêtre, et si des ingénieurs cherchant à travailler pour vous n'ont pas encore monté leur campement devant votre bureau, et si vos développeurs passent plus de temps à chercher quelle annotation Spring il faut ajouter sur Stack Overflow plutôt que sur les subtilités des algorithmes de classement, il est sans doute temps de se demander s'il est judicieux de copier Google.
D'accord, si cette fois Google vous a déçu et n'a pas donné de réponse, que faire ? Vérifiez exactement ce que le développeur fera au travail. Qu'appréciez-vous chez les développeurs ?
Établissez des critères pour le type de candidat que vous souhaitez embaucher et concevez des tests qui évaluent précisément ces compétences.
ThoughtWorks
Quel rapport avec ThoughtWorks ? C'est ici que j'ai trouvé un exemple d'entretien exemplaire. Qui sont ThoughtWorks ? Pour faire simple, c'est une entreprise de conseil haut de gamme avec des bureaux partout dans le monde, de la Chine à Singapour et jusqu'aux continents américains, spécialisée dans le conseil en développement depuis environ 25 ans, avec sa division Science dirigée par Martin Fowler. Si vous cherchez une liste de 10 livres incontournables pour un ingénieur logiciel, il y a de fortes chances que 2-3 d'entre eux soient écrits par des gens de ThoughtWorks, comme Refactoring de Martin Fowler et Building Microservices: Designing Fine-Grained Systems de Sam Newman ou Building Evolutionary Architectures.
par Patrick Kua, Rebecca Parsons, Neal Ford.
Le modèle commercial de l'entreprise repose sur la fourniture de services relativement coûteux, mais le client paie pour une qualité phénoménale, qui repose sur l'expertise, les normes internes et, bien sûr, les gens. Il est donc essentiel de recruter les bonnes personnes.
Qui sont ces bonnes personnes ? Bien sûr, cela varie d'une personne à l'autre. ThoughtWorks a déterminé que pour leur modèle d'affaires, les critères les plus importants pour les développeurs sont :
- La capacité à travailler en binôme. Pas seulement l'expérience, mais la capacité. Personne ne s'attend à ce que des personnes pratiquant le Pair programming depuis 5 ans viennent. Mais être réceptif aux opinions des autres, savoir écouter, est une compétence essentielle.
- Savoir écrire des tests, et idéalement pratiquer le TDD.
- Comprendre SOLID et la POO et savoir les appliquer.
- Présenter son point de vue. Un consultant doit travailler avec les développeurs du client, avec d'autres consultants, et il n'y a pas beaucoup d'avantages si une personne est capable de bien faire quelque chose mais totalement incapable de le communiquer aux autres membres de l'équipe.
Il est maintenant important d'évaluer précisément ces compétences chez le candidat. Ici, je souhaite partager mon expérience lors de l'entretien chez ThoughtWorks. Je dirai simplement que je l'ai passé à Singapour et que j'ai réussi, mais le processus de recrutement est unifié et ne sera pas très différent d'un pays à l'autre.
Étape 0. RH
Comme c'est souvent le cas, un entretien de 20 minutes avec les RH. Je ne m'attarderai pas là-dessus, je dirai seulement que je n'ai jamais rencontré de RH capables de parler pendant 15 minutes de la culture de développement dans l'entreprise, pourquoi ils appliquent le TDD, pourquoi la programmation en binôme. En général, à cette question, les RH s'appesantissent et racontent que leur processus est classique : les développeurs développent, les testeurs testent, les managers poussent.
Étape 1. Quelle est votre maîtrise de l'OOP, du TDD ?
À 1h30 avant le début de l'entretien, on m'a envoyé la tâche de créer un simulateur Mars Rover.
Tâche Mars RoverUne équipe de rovers robotiques doit être posée par la NASA sur un plateau sur Mars. Ce plateau, qui est curieusement rectangulaire, doit être navigué par les rovers afin que leurs caméras embarquées puissent obtenir une vue complète du terrain environnant à renvoyer sur Terre. La position et l'orientation d'un rover sont représentées par une combinaison de coordonnées x et y ainsi qu'une lettre représentant l'un des quatre points cardinaux. Le plateau est divisé en une grille pour simplifier la navigation. Une position d'exemple pourrait être 0, 0, N, ce qui signifie que le rover est dans le coin inférieur gauche et fait face au nord. Pour contrôler un rover, la NASA envoie une simple chaîne de lettres. Les lettres possibles sont 'L', 'R' et 'M'. 'L' et 'R' font tourner le rover de 90 degrés à gauche ou à droite respectivement, sans se déplacer de son emplacement actuel. 'M' signifie avancer d'un point de grille et maintenir la même orientation.
Supposez que la case directement au nord de (x, y) est (x, y+1).
ENTRÉE :
La première ligne d'entrée est les coordonnées du coin supérieur droit du plateau, les coordonnées du coin inférieur gauche sont supposées être 0,0.
Le reste de l'entrée concerne les rovers qui ont été déployés. Chaque rover a deux lignes d'entrée. La première ligne donne la position du rover, et la deuxième ligne est une série d'instructions indiquant au rover comment explorer le plateau. La position est composée de deux entiers et d'une lettre séparés par des espaces, correspondant aux coordonnées x et y et à l'orientation du rover.
Chaque rover sera terminé séquentiellement, ce qui signifie que le deuxième rover ne commencera pas à se déplacer tant que le premier n'aura pas terminé de se déplacer.
SORTIE :
La sortie pour chaque rover doit être ses coordonnées finales et son orientation.
REMARQUES :
Implémentez simplement les exigences ci-dessus et prouvez qu'un aspirateur fonctionne en écrivant des tests unitaires pour cela.
Créer une interface utilisateur de quelconque forme est hors du champ.
Résoudre le problème en suivant une approche TDD (Développement Piloté par les Tests) sera préféré.
Dans le court laps de temps disponible, nous nous préoccupons davantage de la qualité que de l'exhaustivité.
*Je ne peux pas révéler la tâche qui m'a été envoyée, c'est une ancienne tâche qui a été donnée il y a plusieurs années. Mais croyez-moi, le principe est resté fondamentalement le même.
Il convient de souligner les critères d'évaluation. Combien de fois avez-vous été confronté à des situations où des éléments importants pour le candidat sont totalement insignifiants lors du contrôle et vice versa ? Tout le monde ne pense pas de la même manière que vous, mais beaucoup peuvent adopter vos valeurs et les suivre si elles sont clairement énoncées. Ainsi, il est clair dès le départ que les compétences les plus importantes à ce stade sont
- TDD;
- La capacité à utiliser la POO et à écrire un code maintenable;
- la capacité à programmer en binôme
Ainsi, on m'a prévenu de prendre ces 1,5 heures pour réfléchir à la manière dont je vais aborder la tâche, plutôt que d'écrire du code. Nous écrirons le code ensemble.
Lorsque nous avons eu notre appel, les gars ont brièvement expliqué qui ils étaient et ce qu'ils faisaient, et ont proposé de commencer le développement.
Tout au long de l'entretien, je n'ai jamais eu l'impression d'être en entretien. On a l'impression que vous développez du code en équipe. Si vous êtes bloqué quelque part, ils aident, conseillent, discutent, même débattent entre eux sur la meilleure manière de procéder. Lors de l'entretien, j'ai oublié comment vérifier dans JUnit 5 qu'une méthode lance une exception - ils ont proposé de continuer à écrire le test pendant qu'un d'eux cherchait comment le faire.
Littéralement quelques heures après l'entretien, j'ai reçu un retour constructif - ce qui a plu et ce qui n'a pas plu. Dans mon cas, j'ai été félicité pour l'utilisation des classes scellées comme alternative à l'objet null; pour avoir écrit avant de coder un pseudocode sur la façon dont je souhaite contrôler le rover, et ainsi obtenu un croquis de classes, au moins celles impliquées dans l'API du robot.
Étape 2. Parlez-nous
Une semaine avant l'entretien, on m'a demandé de préparer une présentation sur un sujet qui m'intéresse. Le format est simple et habituel : 15 minutes de présentation, 15 minutes de réponses aux questions.
J'ai choisi Clean Architecture by Uncle Bob. Et à nouveau, j'ai été interviewé par plusieurs personnes. C'était ma première expérience de présentation en anglais, et je dois dire que si j'avais été dans une situation stressante, je ne m'en serais pas sorti. Mais encore une fois, je n'ai jamais eu l'impression d'être en entretien. Tout était comme d'habitude — je raconte, ils écoutent attentivement. Même la traditionnelle session de questions-réponses ne ressemblait pas à un entretien, on voyait que les questions posées n'avaient pas pour but de me “couler”, mais étaient vraiment celles qui les intéressaient dans ma présentation.
Quelques heures après l'entretien, j'ai reçu des retours — la présentation était très utile et ils ont pris un plaisir sincère à l'écouter.
Étape 3. Code de qualité production
En prévenant que c'était la dernière étape des entretiens techniques, on m'a demandé de rendre le code prêt pour la production à la maison, puis d'envoyer le code pour une révision et de planifier un entretien où les exigences de la tâche changeraient et où le code devrait être modifié. Pour anticiper, je peux dire que la révision du code se fait en aveugle, les réviseurs ne connaissent ni le poste pour lequel le candidat postule, ni son CV, et ne voient même pas son nom.
Appel et de nouveau une paire de gars de l'autre côté de l'écran. Tout est comme lors de la première interview : n'oubliez pas le TDD, parlez de ce que vous faites et pourquoi. Si vous n'avez pas pratiqué le TDD auparavant, je vous recommande de commencer immédiatement, non pas parce que c'est nécessaire dans les entreprises, mais parce que cela simplifie considérablement votre vie et réduit votre niveau de stress, si vous le souhaitez. Vous vous rappelez combien de fois vous deviez chercher désespérément une erreur avec le débogueur qui ne se reproduisait que dans le navigateur, et que vous ne pouviez pas la reproduire avec les tests ? Maintenant, imaginez que vous devez attraper une telle erreur pendant l'entretien — quelques cheveux gris sont assurés. Que nous apporte le TDD ? Vous avez modifié le code et, à votre grande surprise, vous constatez maintenant que les tests sont en rouge, et vous ne comprenez pas tout de suite où est l'erreur ? D'accord, nous disons aux intervieweurs "Oups", nous appuyons sur Ctrl-Z et commençons à avancer par petites étapes. Et oui, il est nécessaire de développer l'aptitude à travailler avec le TDD, la capacité d'aller vers un objectif de manière à ce que vos tests soient constamment verts, et non rouges pendant une demi-journée parce que "vous avez une grosse refonte". C'est exactement la même compétence que celle d'écrire du code maintenable ou performant.
Ainsi, la capacité de votre code à résister aux changements dépend du design que vous avez initialement mis en place, de sa simplicité et de la qualité de vos tests.
Après l'entretien, j'ai reçu des retours quelques heures plus tard. À ce stade, j'ai compris que j'avais presque réussi et qu'il ne restait plus grand-chose avant "la rencontre avec Fowler".
Étape 4. Finale. Des questions techniques. Nous voulons savoir qui vous êtes !
Pour être honnête, cette formulation de la question m'a un peu déconcerté. Comment peut-on comprendre qui je suis vraiment en une heure de conversation ? Et surtout, comment cela peut-il être compris lorsque je parle dans une langue qui n'est pas ma langue maternelle, et, pour être franc, de manière assez médiocre et maladroite. Lors des précédents entretiens, il m'était plus facile de raconter que de répondre aux questions, tout cela à cause de l'accent. Au moins un des intervieweurs était asiatique — et leur accent est, disons, quelque peu spécifique à l'oreille européenne. C'est pourquoi j'ai décidé d'adopter une approche proactive — de préparer une présentation sur moi-même et, au début de l'entretien, de proposer de parler de moi à l'aide de cette présentation. S'ils acceptent, il y aura au moins moins de questions de leur part ; s'ils déclinent l'offre, eh bien, trois heures de ma vie consacrées à cette présentation ne sont pas un prix très élevé. Mais que devrais-je écrire dans la présentation ? Une biographie — Je suis né ici, à telle date, j'ai été à l'école, j'ai terminé l'université — qui cela intéresse-t-il vraiment ?
Si l'on fait un peu de recherche sur la culture de Thoughtworks, on peut trouver un article de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], qui décrit les 3 piliers : Entreprise durable, Excellence du logiciel et Justice sociale.
Supposons que mon Excellence du logiciel ait déjà été vérifiée. Il me reste à montrer l'Entreprise durable et la Justice sociale.
En fait, j'ai décidé de mettre l'accent sur le dernier.
Pour commencer, j'ai expliqué pourquoi ThoughtWorks — j'ai lu le blog de Martin Fowler à l'université, d'où mon amour pour le code propre.
Les projets peuvent également être présentés sous différents angles. J'ai développé des logiciels pour la médecine, qui ont simplifié la vie des patients, et même, dit-on, sauvé une vie. J'ai également développé des logiciels pour des banques, qui simplifient également la vie des citoyens. Surtout si cette banque est utilisée par environ 70 % de la population du pays. Il ne s'agit pas de Sberbank, ni même de la Russie.
Voulez-vous en savoir plus sur moi ? D'accord. Mon hobby est la photographie, j'ai en quelque sorte un appareil photo dans les mains depuis environ 10 ans, et j'ai des photos que je n'ai pas trop honte de montrer. De plus, à un moment donné, j'ai aidé un refuge pour chats : je photographiais des chats qui avaient besoin d'un foyer permanent. Avec de bonnes photos, il est beaucoup plus facile de placer un chat. Je crois que j'ai pris des photos d'une centaine de chats 🙂.
Au final, 80 % de ma présentation était remplie de chats.
Juste après la présentation, le RH m'a écrit qu'il ne connaissait pas encore les résultats de l'entretien, mais que tout le bureau était déjà impressionné par les chats.
En fin de compte, j'ai reçu des retours — j'ai satisfait tout le monde en tant que personne.
Mais le RH, lors de la conversation finale, a mentionné avec tact que la Justice Sociale est très bien et nécessaire, mais que tous les projets ne sont pas comme ça. Il a demandé si cela m'effrayait. En gros, j'ai un peu exagéré avec la Justice Sociale, ça arrive 🙂
Conclusion
Au final, cela fait déjà plusieurs mois que je travaille à Singapour chez Thoughtworks, et je vois que de nombreuses entreprises ici adoptent les "meilleures pratiques d'entrevue" de Google, utilisant des feuilles et des tableaux blancs pour coder, alors que des connaissances au-delà de Spring, Symfony, RubyOnRails (à souligner) ne sont pas requises dans le travail. Les ingénieurs prennent une semaine de congé avant l'entretien pour "se préparer".
Chez Thoughtworks, en plus d'exiger des candidats des critères raisonnables, des principes tels que :
La Joie de l'Entretien. Pour les deux parties. En effet, si vous souhaitez obtenir les meilleurs talents (et qui ne le veut pas ?), l'entretien ne doit pas être perçu comme un marché où l'on choisit des esclaves, mais comme une rencontre où l'employeur et le candidat s'évaluent mutuellement. Et si le candidat associe des émotions agréables à l'entreprise, il est très probable qu'il choisisse cette entreprise.
Multiple interviewers to mitigate bias. Chez Thoughtworks, le pair programming est la norme de facto. Et si cette pratique peut être appliquée dans d'autres domaines, TW essaie de le faire. À chaque étape, l'entretien est mené par deux personnes. Ainsi, chaque personne est évaluée par au moins 8 personnes, et TW cherche à sélectionner des intervieweurs avec des horizons différents, de diverses disciplines (pas seulement des techniciens) et de différents sexes.
Au final, la décision d'embauche sera prise sur la base de l'avis d'au moins 8 personnes, et personne n'a le droit de vote décisif.
Recrutement basé sur les attributs Au lieu de prendre une décision basée sur "aime/n'aime pas" le candidat, un formulaire a été développé pour chaque rôle et chaque étape, incluant les attributs à évaluer. Lors de l'évaluation, il est fortement recommandé d'évaluer non pas l'expérience dans une compétence particulière, mais la capacité à l'appliquer. Ainsi, si un candidat n'a pas eu l'occasion d'appliquer certaines compétences, comme TDD, mais qu'il essaie néanmoins de les utiliser et écoute des conseils sur leur utilisation correcte, il a toutes les chances de réussir l'entretien.
Les certificats d'éducation ne sont pas requis TW ne demande pas de certificats obligatoires ou d'éducation en informatique. Seules les compétences sont évaluées.
C'est le premier entretien que j'ai passé dans des entreprises étrangères pour lequel je n'ai pas eu besoin de me préparer. Après chaque étape, je ne me sentais pas épuisé, au contraire, j'étais heureux de pouvoir appliquer les meilleures pratiques, que les gens de l'autre côté de l'écran les apprécient et les utilisent également chaque jour.
Après quelques mois, je peux dire que mes attentes ont été totalement satisfaites. Qu'est-ce qui distingue ThoughtWorks d'une entreprise ordinaire ? Dans une entreprise ordinaire, vous pouvez trouver de bons développeurs et des gens sympathiques, mais chez TW, leur concentration est exceptionnelle.
Si vous souhaitez rejoindre ThoughtWorks, vous pouvez consulter les offres d'emploi ouvertes
Je vous suggère également de jeter un œil aux offres d'emploi intéressantes :
Lead Software Engineer : , , ,
Senior Software Engineer : , , ,
Software Engineer : , ,
Senior Data Engineer :
Quality Analyst :
Infrastructure : , ,
(Je tiens à prévenir que le lien est de référence, si vous rejoignez TW, je recevrai un bonus agréable). Choisissez un bureau qui vous plaît, vous n'êtes pas obligé de vous limiter à l'Europe, après tout, tous les 2 ans, TW sera heureux de vous transférer dans un autre pays, car c'est une partie de la politique de ThoughtWorks, ainsi la culture se diffuse et se normalise.
N'hésitez pas à poser des questions dans les commentaires ou à me demander de vous recommander.
Si le sujet vous intéresse, j'écrirai sur ce que c'est que de travailler chez ThoughtWorks et comment c'est de vivre à Singapour.
Source : habr.com
