Dernièrement, tant d'histoires sur les mauvaises interviews ont été publiées sur le hub que les doutes se glissent parfois, et y a-t-il de bonnes interviews dans la nature? Donc, dans un souci de diversité, nous considérerons un exemple de bonne * approche. L'histoire ira du point de vue du développeur de l'employeur, qui est directement impliqué dans le processus d'embauche.
* probablement
Disposition
Une petite équipe produit (30-40 personnes) au sein d'une grande entreprise (plusieurs milliers de personnes). L'équipe comprend toutes les personnes impliquées dans le projet: développeurs full-stack et front-end, designers et front-endologues, testeurs, spécialistes des relations publiques, analystes, auteurs de textes, etc. En général, nous essayons d'externaliser des travaux moins spécialisés vers d'autres projets, et le développement mobile ne fait pas exception.
Nous avons une application mobile multiplateforme écrite en Xamarin Native pour iOS et Android. Dans le même temps, nous sommes complètement prêts à prendre le meilleur du développeur expérimenté qui n'a écrit que pour une seule plate-forme, à condition qu'il soit prêt à étudier le développement d'un deuxième système d'exploitation.
Étape 0 - rencontré deux solitude
Soit le développeur tombe sur un poste vacant et envoie un curriculum vitae, après quoi HR lui envoie des questions de clarification, soit HR tombe sur un curriculum vitae du développeur, après quoi il envoie environ la même série de questions.
Ces questions sont le filtre minimum pour l'adéquation; il n'y aura pas de problèmes techniques. De plus, le curriculum vitae et les réponses sont déjà transmis au développeur par l'employeur, et il décide d'aller plus loin ou non. Au cours du mois dernier, j'ai examiné quelques dizaines de CV et je n'ai aucune idée de ce que le candidat devrait écrire et répondre, de sorte que j'ai dû dire non à ce stade. Écrivez à la vacance du développeur Android «J'écris uniquement pour iOS, car Android craint»?
Étape 1 - Tâche de test ou exemple de code
La tâche de test est donnée sans limite de temps, bien qu'en pratique elle ne devrait pas prendre plus d'une soirée. Dans le cadre de l'application de test sera:
- trois écrans: deux listes chaînées + formulaire de saisie de données qui, si vous le souhaitez, peuvent être remplacées par une fenêtre modale
- travail en réseau
- travailler avec l'entrepôt de données (la tâche implique une base de données, si le développeur peut justifier une autre conclusion - nous sommes les bienvenus)
Cependant, tous les développeurs ne sont pas prêts à écrire un test, nous proposons donc immédiatement une alternative - envoyer le code d'une application prête à l'emploi, où il y aura le même ensemble (réseau, base de données, navigation sur les écrans, entrée utilisateur). Eh bien, d'autres options sont possibles:
- l'application est trop petite, le code n'est pas indicatif ou pose trop de questions, veuillez faire notre test
- l'application convient, mais il y a des nuances - veuillez apporter des améliorations mineures (moins que le soir)
Sur la base des résultats du test, nous appelons le développeur pour une entrevue ou refusons, mais dans le deuxième cas, un examen détaillé sera effectué - ce qui est bien fait, ce qui est discutable, quelles questions se posent, ce qui vaut la peine d'être lu, etc. En conséquence, tout le monde gagne:
- le candidat reçoit un code, qui peut ensuite être réutilisé lors d'un autre entretien avec des principes similaires, ainsi que des commentaires pour travailler sur vous-même. Ça marche? Eh bien, au moins on nous a envoyé des devoirs de test écrits à l'origine pour d'autres entreprises, donc cela semble fonctionner;
- l'employeur gagne du temps sur les questionnaires et autres trucs. Et quel bonheur l'intervieweur est un introverti, qui n'a pas besoin de mener 1-2 interviews par semaine, si vous le saviez!
Étape 2 - Entrevue
Lors de l'entretien, il sera certainement question non seulement de la vie et du lieu de travail précédent, mais aussi de questions sur la tâche de test. À ce stade, il est assez simple de comprendre si une personne a écrit un test, si elle sait ce qui y est écrit, si elle peut justifier l'une ou l'autre solution, quels sont ses horizons, etc. Les questions ne sont pas posées en l'air, mais avec la possibilité de prendre le clavier et de pousser ce code même. Parfois, nous vous demandons de réécrire un peu quelque chose à la volée ou de le corriger, nous posons des questions sur le formulaire "mais s'il y avait encore une telle exigence ..."
Ensuite, il y aura 1-2 petites tâches pratiques, elles dépendent de la tâche de test. Encore une fois, nous donnons le clavier en main (connecté à un ordinateur, un ordinateur avec un moniteur!) Et vous demandons d'écrire ou de modifier quelque chose. L'une de mes choses préférées est de donner une fonction fonctionnelle mais mal écrite pour 10-20 lignes et de suggérer de la refactoriser. Il devient immédiatement clair si le candidat a un mauvais code, ce qu'il sait des constructions de langage, s'il peut lire le code de quelqu'un d'autre plus loin dans la liste.
Et c'est tout. Dans un maximum de quelques jours, nous donnerons une réponse au candidat. Cependant, le plus souvent, la réponse est donnée le même jour). Et en cas d'échec, là encore il y aura une justification adéquate. Eh bien, si cela ne suffit pas, le candidat peut toujours demander aux développeurs des contacts de l'entretien pour clarifier certains points, et ils leur donneront très probablement.
Mais le candidat aurait pu tromper
En vérité. Pourrait même
envoyer un jumeau . Eh bien, il n'était peut-être pas trompeur, nous venons de faire une erreur lors de l'entretien. Dans un tel cas, il y a une chose merveilleuse appelée «période d'essai». De plus, travailler dans une grande entreprise (du moins dans notre cas) - l'échec à terminer une période probatoire ne signifie pas une séparation à cent pour cent de l'entreprise. En fin de compte, le développeur pourrait être assez bon, mais n'a pas pris racine dans une équipe particulière - dans ce cas, il y a toujours des projets alternatifs.
Alors arrête! J'ai reconnu l'équipe en question, je l'ai interviewée il y a quelques années, et là le schéma était très différent
Oui, je me repens, puis j'ai péché avec de petits sondages et interviews sans test. J'ai passé beaucoup de temps, autant le sien que celui de quelqu'un d'autre. Donc, quand il s'agissait de nouvelles recherches pour le développeur, j'ai décidé d'essayer une approche différente. Les développeurs écrivent-ils du code? Super! Montrez-moi votre code et je vous dirai si nous devons être interviewés.
Mais je l'ai découvert dans l'entreprise! Installé dans un autre projet, et là aussi, tout va mal!
Et voici la situation avec la ruse. Un flux décent de développeurs back-end / full-stack va à notre entreprise, et il y a plusieurs centaines de ces développeurs dans l'entreprise. Par conséquent, le processus de leur recrutement a déjà été assez bien réglé et standardisé. Pendant ce temps, il y a peu de développeurs mobiles dans l'entreprise, il nous est donc plus facile d'expérimenter des approches d'interview.
L'approche décrite a d'autres inconvénients!
Vous attend dans les commentaires. Nous discutons ;-)