Ne vous semble-t-il pas étrange que lorsque vous êtes sur le point de changer d'emploi et que vous devez passer un entretien, la première chose à laquelle vous pensez est « vous devez vous préparer pour l'entretien ». Résolvez des problèmes sur HackerRank, lisez Crack l'interview de codage, mémorisez le fonctionnement d'ArrayList et en quoi il diffère de LinkedList. Oh oui, ils pourraient également poser des questions sur le tri, et il ne serait évidemment pas professionnel de dire que le tri rapide serait probablement le meilleur choix.
Mais attendez, vous programmez 8 heures par jour, résolvez des problèmes intéressants et non triviaux, et dans votre nouveau travail vous ferez la même chose, plus ou moins. Mais néanmoins, pour réussir un entretien, vous devez d'une manière ou d'une autre vous préparer en plus, pas même perfectionner vos compétences quotidiennes, mais apprendre quelque chose dont vous n'aviez pas besoin dans votre emploi actuel et dont vous n'aurez probablement pas besoin lors de votre prochain. A vos objections selon lesquelles l'informatique est dans notre sang, et si vous nous réveillez en pleine nuit, nous sommes obligés d'écrire les yeux fermés sur une taie d'oreiller une promenade dans la largeur d'un arbre sans même reprendre conscience, je Je répondrai que si je trouve un emploi dans un cirque, et que mon truc principal, ce serait exactement ceci - alors peut-être que oui, je suis d'accord. Cette compétence doit être testée.
Mais pourquoi tester des compétences qui ne sont pas pertinentes pour votre emploi actuel ? Juste parce que c’est devenu à la mode ? Parce que Google fait ça ? Ou parce que votre futur chef d’équipe a dû apprendre toutes les méthodes de tri avant l’entretien et qu’il estime désormais que « tout bon programmeur doit connaître par cœur la mise en œuvre de la recherche d’un palindrome dans une chaîne ».
Eh bien, 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, est arrivé à la conclusion que les ingénieurs issus de l'Olympiade sont doués pour s'acquitter de leurs tâches spécifiques. De plus, en concevant leur processus de sélection, ils peuvent se permettre de prendre le risque de ne pas embaucher quelques bons ingénieurs parce qu'ils ne peuvent pas résoudre facilement les problèmes de mathématiques. Mais ce n'est pas un problème pour eux, il y a beaucoup de gens qui veulent travailler chez Google, le poste sera fermé.
Maintenant, regardons par la fenêtre, et si devant votre bureau les ingénieurs qui veulent travailler pour vous n'ont pas encore installé de camp de tentes, et que vos développeurs recherchent plus souvent sur stackoverflow quelle prochaine annotation Spring doit être installée, plutôt que les subtilités des algorithmes de classement, alors, apparemment, il est temps pour vous de réfléchir à la question de savoir si vous devez copier Google.
Eh bien, si cette fois-ci, Google échouait et ne fournissait pas de réponse, que devriez-vous faire ? Vérifiez exactement ce que le développeur fera au travail. Qu’appréciez-vous chez les développeurs ?
Définissez des critères pour déterminer qui vous souhaitez embaucher et développez des tests qui testent exactement ces compétences.
ThoughtWorks
Qu’est-ce que ThoughtWorks a à voir avec cela ? C’est là que j’ai trouvé un exemple d’entretien modèle pour moi-même. Qui est ThoughtWorks ? En bref, il s'agit d'une société de conseil haut de gamme avec des bureaux dans le monde entier, de la Chine à Singapour en passant par les continents américains, qui conseille dans le domaine du développement depuis environ 25 ans, possède sa propre division Science, dirigée par Martin Chasseur. Si vous recherchez une liste de 10 livres incontournables pour un ingénieur logiciel, alors peut-être 2 ou 3 d'entre eux seront écrits par les gars de ThoughtWorks, comme Refactoring par Martin Fowler et Building Microservices: Designing Fine-Grained Systems par Sam. Newman ou la construction d'architectures évolutives
par Patrick Kua, Rebecca Parsons, Neal Ford.
L'activité de l'entreprise repose sur la fourniture de services assez coûteux, mais le client paie pour une qualité phénoménale, composée d'expertise, de normes internes et, bien sûr, de personnes. Il est donc essentiel d’embaucher les bonnes personnes.
Quel genre de personnes ont raison ? Bien sûr, il y en a des différents pour chacun. ThoughtWorks a déterminé que les critères les plus importants pour son modèle économique de développeur sont :
- Capacité à se développer en binôme. C'est une capacité, pas une expérience ou une compétence. Personne ne s’attend à ce que viendront des personnes qui pratiquent la programmation en binôme depuis 5 ans, mais être réceptif aux opinions des autres et être capable d’écouter est une compétence nécessaire.
- Capacité à rédiger des tests et idéalement à pratiquer le TDD
- Comprendre SOLID et POO et être capable de les appliquer.
- Présentez votre avis. En tant que consultant, vous devez travailler avec les développeurs du client, avec d'autres consultants, et il n'y a pas beaucoup d'avantages si une personne sait bien faire quelque chose, mais est complètement incapable de le transmettre au reste de l'équipe.
Il est désormais important d’évaluer ces compétences particulières chez le candidat. Et ici, je veux parler de mon expérience d'entretien chez ThoughtWorks. Je dirai tout de suite que je suis allé à Singapour et que j'ai réussi, mais le processus de recrutement est unifié et ne différera pas beaucoup d'un pays à l'autre.
Étape 0. RH
Comme cela arrive souvent, un entretien de 20 minutes avec les RH. Je ne m'étendrai pas là-dessus, je dirai juste que je n'ai jamais rencontré une personne RH qui puisse parler 15 minutes de la culture de développement dans l'entreprise, pourquoi ils utilisent TDD, pourquoi le binôme programmation. Habituellement, les RH se fanent sur cette question et disent que leur processus est normal : les développeurs développent, les testeurs testent, les managers conduisent.
Étape 1. Dans quelle mesure êtes-vous bon en POO, TDD ?
1.5hXNUMX avant le début de l'entretien, on m'a confié la tâche de fabriquer un simulateur Mars Rover.
Mission rover sur MarsUne escouade de rovers robotiques doit être atterrie par la NASA sur un plateau de Mars. Ce plateau, curieusement rectangulaire, doit être parcouru 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'emplacement d'un mobile sont représentés par une combinaison de coordonnées x et y et par une lettre représentant l'un des quatre points cardinaux. Le plateau est découpé en quadrillage pour simplifier la navigation. Un exemple de position pourrait être 0, 0, N, ce qui signifie que le mobile se trouve dans le coin inférieur gauche et fait face au nord. Afin de 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 respectivement vers la gauche ou la droite, sans bouger de son emplacement actuel. «M» signifie avancer d'un point de grille et maintenir le même cap.
Supposons que le carré directement au nord de (x, y) soit (x, y+1).
ENTREE:
La première ligne de saisie correspond aux coordonnées supérieures droites du plateau, les coordonnées inférieures gauches sont supposées être 0,0.
Le reste des données est constitué d'informations relatives aux rovers qui ont été déployés. Chaque mobile dispose de deux lignes d'entrée. La première ligne indique 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 mobile.
Chaque mobile sera terminé séquentiellement, ce qui signifie que le deuxième mobile ne commencera pas à se déplacer tant que le premier n'aura pas fini de se déplacer.
SORTIE:
Le résultat de chaque mobile doit être ses coordonnées et son cap finaux.
NOTES:
Mettez simplement en œuvre les exigences ci-dessus et prouvez qu’un aspirateur fonctionne en écrivant des tests unitaires pour celui-ci.
La création de toute forme d’interface utilisateur est hors de portée.
Résoudre le problème en suivant une approche TDD (Test Driven Development) sera privilégié.
Dans le peu de temps disponible, nous sommes plus soucieux de la qualité que de l'exhaustivité.
*Je ne peux pas publier le devoir qui m'a été envoyé, il s'agit d'un ancien devoir qui a été confié il y a plusieurs années. Mais croyez-moi, fondamentalement, tout reste pareil.
Je voudrais particulièrement attirer l'attention sur les critères d'évaluation. Combien de fois avez-vous été confronté à une situation où des choses qui sont importantes pour un candidat n'ont absolument aucune importance lors de l'audit et vice versa. Tout le monde ne pense pas de la même manière que vous, mais beaucoup peuvent accepter et suivre vos valeurs si elles sont clairement énoncées. Ainsi, d'après les critères d'évaluation, il ressort immédiatement que les compétences les plus importantes à ce stade sont
- TDD ;
- Capacité à utiliser la POO et à écrire du code maintenable ;
- capacités de programmation en binôme
On m'a donc conseillé de passer cette heure et demie à réfléchir à la façon dont j'allais accomplir la tâche, plutôt qu'à écrire du code. Nous écrirons le code ensemble.
Lorsque nous avons téléphoné, les gars nous ont brièvement dit qui ils étaient et ce qu'ils faisaient et nous ont proposé de commencer le développement.
Pendant toute la durée de l’entretien, je n’ai jamais eu le sentiment d’être interviewé. On a le sentiment que vous développez du code en équipe. Si vous êtes coincé quelque part, ils vous aident, vous conseillent, discutent, voire se disputent sur la meilleure façon de procéder. Lors de l'entretien, j'ai oublié comment vérifier dans JUnit 5 qu'une méthode génère une exception - ils ont proposé de continuer à écrire le test, pendant que l'un d'eux cherchait sur Google comment le faire.
Quelques heures seulement après l'entretien, j'ai reçu des commentaires constructifs - ce que j'ai aimé et ce que je n'ai pas aimé. Dans mon cas, j'ai été félicité pour avoir utilisé les classes Sealed comme alternative à l'objet nul ; pour le fait qu'avant d'écrire le code, j'ai écrit en pseudocode comment je voudrais contrôler le rover, et j'ai ainsi reçu un croquis des classes, du moins celles qui sont impliquées dans l'API du robot.
Étape 2 : dites-nous
Une semaine avant l'entretien, on m'a demandé de préparer une présentation sur n'importe quel sujet qui m'intéressait. Le format est simple et familier : 15 minutes de présentation, 15 minutes de réponses aux questions.
J'ai choisi Clean Architecture d'Oncle Bob. Et encore une fois, j'ai été interviewé par quelques personnes. C'était ma première expérience de présentation en anglais et, peut-être, si j'avais été dans une situation stressante, je n'aurais pas pu y faire face. Mais encore une fois, je n’ai jamais eu le sentiment d’être à un entretien. Tout est comme d'habitude - je leur dis, ils écoutent attentivement. Même la traditionnelle séance de questions et réponses ne ressemblait pas à un entretien ; il était clair que les questions n'étaient pas posées pour « couler », mais celles qui les intéressaient vraiment dans ma présentation.
Quelques heures après l'entretien, j'ai reçu des commentaires : la présentation était très utile et ils ont vraiment apprécié l'écoute.
Étape 3. Code de qualité de production
Après avoir prévenu qu'il s'agissait de la dernière étape des entretiens techniques, on m'a demandé de ramener le code chez moi dans un état prêt pour la production, puis d'envoyer le code pour révision et de planifier des entretiens au cours desquels les exigences de la tâche changeraient et le code serait modifié. nécessitent des modifications. Pour l'avenir, je peux dire que la revue du code se fait à l'aveugle, les évaluateurs ne connaissent pas le poste pour lequel le candidat postule, ils ne voient pas son CV, ils ne voient même pas son nom.
Le téléphone sonna et encore une fois, il y avait quelques gars de l'autre côté du moniteur. Tout est comme lors du premier entretien : l'essentiel est de ne pas oublier TDD, de dire ce que l'on fait et pourquoi. Si vous n'avez jamais pratiqué le TDD auparavant, alors je vous recommande de commencer à le faire immédiatement, non pas parce que c'est nécessaire en entreprise, mais parce que cela vous simplifie considérablement la vie, réduit votre niveau de stress si vous le souhaitez. Rappelez-vous comment vous avez dû rechercher frénétiquement avec un débogueur une erreur qui ne peut être reproduite que via le navigateur, mais vous ne pouvez pas la reproduire avec des tests ? Imaginez maintenant que vous deviez détecter une telle erreur lors d'un entretien - vous êtes assuré d'avoir quelques cheveux gris. Qu'obtient-on avec TDD ? Nous avons modifié le code et réalisé de manière inattendue que désormais les tests étaient rouges, mais quelle est l'erreur que nous ne parvenons pas à comprendre du premier coup ? D'accord, nous disons « Oups » aux intervieweurs, appuyons sur Ctrl-Z et commençons à avancer à petits pas. Et oui, vous devez développer en vous la capacité de développer l'utilisation du TDD, la capacité d'aller vers l'objectif pour que vos tests soient en permanence verts, et non rouges pendant une demi-journée, car « vous avez beaucoup de refactoring ». C'est exactement la même compétence que l'écriture de code maintenable ou l'écriture de code productif.
Ainsi, la manière dont votre code peut être modifié dépend de la conception que vous avez en tête au départ, de sa simplicité et de la qualité de vos tests.
Après l’entretien, j’ai reçu des commentaires quelques heures plus tard. À ce stade, j’ai réalisé que j’avais presque terminé et qu’il ne restait plus grand-chose jusqu’à ce que je « rencontre Fowler ».
Étape 4. Finale. Assez de questions techniques. Nous voulons savoir qui vous êtes !
Pour être honnête, j’ai été quelque peu perplexe face à cette formulation de la question. Comment pouvez-vous comprendre quel genre de personne je suis en une heure de conversation ? Et plus encore, comment pouvez-vous comprendre cela alors que je parle une langue qui n'est pas ma langue maternelle et, à vrai dire, très moche et muette. Lors d'entretiens précédents, il m'était personnellement plus facile de parler que de répondre aux questions, et l'accent en était la cause. Au moins un des intervieweurs était asiatique – et leur accent, disons simplement, est quelque peu spécifique à l’oreille européenne. Par conséquent, j'ai décidé d'adopter une approche proactive - préparer une présentation sur moi-même et au début de l'entretien proposer de parler de moi avec cette présentation. S'ils sont d'accord, alors au moins j'aurai moins de questions ; s'ils rejettent l'offre, eh bien, 3 heures de ma vie consacrées à une présentation, ce n'est pas un prix si élevé. Mais que devez-vous écrire dans votre présentation ? Biographie - Né là-bas, à cette époque, allé à l'école, diplômé de l'université - mais qu'importe ?
Si vous recherchez un peu la culture Thoughtworks sur Google, vous trouverez un article de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] qui décrit les 3 piliers : entreprise durable, excellence logicielle et justice sociale.
Supposons que Software Excellence ait déjà été vérifié pour moi. Reste à démontrer l’Entreprise Durable et la Justice Sociale.
D’ailleurs, j’ai décidé de me concentrer sur ce dernier.
Pour commencer, je lui 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. Il a également développé un logiciel médical qui a simplifié la vie des patients et a même, selon les rumeurs, sauvé une vie. J'ai également développé des logiciels pour les banques, qui ont également facilité la vie des citoyens. Surtout si cette banque est utilisée par 70 % de la population du pays. Il ne s’agit pas de la Sberbank ni même de la Russie.
Tu veux en savoir plus sur moi? D'ACCORD. Mon passe-temps est la photographie, d'une manière ou d'une autre je tiens un appareil photo dans mes mains depuis environ 10 ans, il y a des photographies que je n'ai pas trop honte de montrer. Aussi, à un moment donné, j'ai aidé un refuge pour chats : j'ai photographié des chats qui avaient besoin d'un foyer permanent. Et avec de bonnes photos, il est beaucoup plus facile de placer un chat. J'ai probablement photographié une centaine de chats :)
Au final, 80 % de ma présentation était remplie de chats.
Immédiatement après la présentation, les RH m'ont é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 attendu des commentaires – j'ai satisfait tout le monde en tant que personne.
Mais lors de la conversation finale, les RH ont déclaré avec tact que la justice sociale est très bonne et nécessaire, mais que tous les projets ne sont pas comme ça. Et il m'a demandé si ça me faisait peur. En général, je suis allé un peu trop loin avec la Justice Sociale, ça arrive :)
Total
Du coup, je travaille à Singapour chez Thoughtworks depuis plusieurs mois maintenant, et je constate qu'ici trop d'entreprises adoptent les « meilleures pratiques d'entretien » de Google, utilisant des feuilles et un tableau blanc pour le codage, bien qu'elles aient plus de connaissances que Spring, Symfony, RubyOnRails ( Soulignez ce qui est nécessaire) ne sont pas requis dans le travail. Les ingénieurs prennent une semaine de congé avant un entretien pour se « préparer ».
Chez Thoughtworks, en plus des exigences adéquates pour le candidat, les principes suivants sont au premier plan :
Joie d'interviewer. De plus, pour les deux côtés. En effet, si vous voulez recruter le meilleur personnel (et qui ne le veut pas ?), alors un entretien n'est pas un marché où les esclaves sont choisis, mais un spectacle où l'employeur et le candidat s'évaluent mutuellement. Et si un candidat associe des émotions agréables à une entreprise, il est probable qu'il choisira cette entreprise en particulier.
Plusieurs intervieweurs pour atténuer les préjugés. Chez Thoughtworks, la programmation en binôme est la norme de facto. Et si cette pratique peut être appliquée à d’autres domaines, TW essaie de le faire. A chaque étape, l'entretien est mené par 2 personnes. Ainsi, chaque personne est évaluée par au moins 8 personnes, et TW essaie de sélectionner des enquêteurs ayant des parcours, des orientations (pas seulement des techniciens) et des sexes différents.
En fin de compte, la décision d'embauche sera prise sur la base des opinions d'au moins 8 personnes, et personne n'a de voix prépondérante.
Recrutement basé sur les attributs Au lieu de prendre une décision basée sur les goûts ou les dégoûts d'un candidat, un formulaire est développé pour chaque rôle et chaque étape qui inclut les attributs évalués. Dans le même temps, lors de l'évaluation, il est fortement recommandé d'évaluer non pas l'expérience dans une certaine compétence, mais la capacité de l'appliquer. Ainsi, si un candidat n'a pas pu appliquer des compétences, comme le TDD, mais qu'il essaie néanmoins de les appliquer, écoute les conseils pour les utiliser correctement, il a toutes les chances de réussir l'entretien.
Certificats d'études non requis TW ne nécessite aucune certification ou formation en informatique. Seules les compétences sont évaluées.
C'est le premier entretien que j'ai avec des entreprises étrangères auquel je n'ai pas eu à me préparer. Après chaque étape, je ne me sentais pas épuisé, mais au contraire, j'étais heureux de pouvoir appliquer les meilleures pratiques, que les gens de l'autre côté du moniteur l'apprécient et les appliquent au quotidien.
Après plusieurs mois, je peux dire que mes attentes ont été pleinement satisfaites. En quoi ThoughtWorks est-il différent d’une entreprise ordinaire ? Dans une entreprise ordinaire, vous pouvez trouver de bons développeurs et des gens sympas, mais chez TW, leur concentration est hors du commun.
Si vous souhaitez rejoindre ThoughtWorks, vous pouvez consulter nos postes ouverts
Je suggère également de prêter attention aux postes vacants intéressants :
Ingénieur logiciel principal : , , ,
Ingénieur logiciel sénior : , , ,
Ingénieur logiciel: , ,
Ingénieur de données senior :
Analyste Qualité :
Infrastructure: , ,
(Je tiens honnêtement à vous prévenir que le lien est un lien de parrainage, si vous allez sur TW, je recevrai un joli bonus). 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 se fera un plaisir de vous déménager dans un autre pays, car... Cela fait partie de la politique de ThoughtWorks, donc la culture est diffusée et homogénéisée.
N'hésitez pas à poser des questions dans les commentaires ou à me demander des recommandations.
Si le sujet semble intéressant, j'écrirai sur ce que signifie travailler chez ThoughtWorks et à quoi ressemble la vie à Singapour.
Source: habr.com