Comment interviewez-vous quelqu'un qui a plus d'expérience que vous?
L'entreprise pour laquelle je travaille cherche à embaucher un développeur senior avec plus d'expérience que moi, et ils s'attendent à ce que je fasse la partie technique de l'entretien. Je ne programme que depuis quelques années et je ne suis pas sûr d'avoir les connaissances nécessaires pour évaluer les compétences de codage d'une personne qui a une meilleure compréhension/expérience que moi.
Quelqu'un peut-il recommander des questions d'entrevue techniques à poser qui sont un bon moyen d'évaluer les compétences de programmation de niveau supérieur, mais qui restent celles que je peux comprendre?
Je dirais que j'ai dépassé le jr. niveau programmeur, mais loin d'être senior. La plupart de ce que j'ai fait consiste à créer de petites applications (Web et bureau), certaines assez compliquées, mais toutes n'ont été conçues pour être utilisées que par une poignée d'utilisateurs. Je sens que j'ai une bonne compréhension de la plupart des concepts de programmation et que je suis capable d'apprendre/d'enseigner à peu près tout, mais je manque d'expérience. Comme mon patron aime me dire "tu ne sais pas ce que tu ne sais pas".
En particulier, nous aimerions que la personne que nous embauchons ait de l'expérience (que je n'ai pas): développement à plusieurs niveaux, environnement multi-utilisateurs, développement d'applications à grande échelle, messagerie bidirectionnelle, sessions partagées, et Multi-threading/BackgroundWorkers.
MISE À JOUR:
En réponse au commentaire de Thor ci-dessous, nous avons embauché quelqu'un il y a quelques mois et je pense que cela a très bien fonctionné. J'apprends beaucoup de choses, pas seulement sur le codage, mais aussi sur des choses comme les modèles de conception, l'architecture logicielle, la documentation et la façon dont d'autres grandes équipes de programmation font avancer les choses. Ce n'est pas toujours facile de faire venir quelqu'un et de lui indiquer de meilleures façons de faire les choses que vous avez faites, mais si vous pouvez ravaler votre fierté et être prêt à essayer de nouvelles choses, vous pouvez en apprendre beaucoup.
Le processus d'entrevue s'est mieux passé que ce à quoi je m'attendais. J'ai commencé à poser des questions sur des choses que je connaissais, puis à poser des questions sur certaines choses avec lesquelles je me débattais. Chaque fois que la personne interrogée disait quelque chose que je ne comprenais pas, je lui demandais de m'expliquer, puis de l'écrire afin de pouvoir le consulter plus tard. Dans l'ensemble, je sentais que je pouvais avoir une assez bonne idée du niveau de compétence du candidat, de son intelligence et de ce avec quoi il aimerait travailler.
Tu ne peux pas.
Au lieu de cela, je vous suggère de venir dans l'interview avec une liste de problèmes que vous avez aujourd'hui, et de lui demander comment il les résoudrait.
Cette méthode est très intéressante pour les deux raisons suivantes:
C'est conseil gratuit. Même si vous n'embauchez pas le gars, il peut suggérer de belles solutions à vos problèmes.
S'il vient avec des solutions intéressantes, c'est un solutionneur de problèmes. Le genre de gars que vous voulez embaucher.
tilisez votre âge comme avantage.
J'ai interviewé une tonne de personnes plus âgées que moi. Je choisis une technologie que je fais connais assez bien et je leur dis que j'ai entendu parler de la technologie X, mais que je ne l'ai jamais utilisée. Je demande au candidat de me donner un aperçu de la technologie et de la façon dont elle l'a utilisée dans un projet.
Cela fonctionne étonnamment bien. Tout d'abord, si le candidat n'utilise cette technologie X que comme mot à la mode dans son curriculum vitae, son explication n'aura aucun sens. De plus, s'ils ne peuvent pas vous donner un bon exemple concret de la façon dont ils ont utilisé cette technologie dans leurs projets passés, vous avez un gros drapeau rouge juste là.
J'ai interviewé quelqu'un qui avait Java Spring experience. J'avais utilisé Spring dans mon travail précédent, et l'une des grandes caractéristiques du printemps est l'injection de dépendance. J'ai dit au candidat que j'ai interviewé que j'avais entendu parler de Spring et ne l'a jamais utilisé. Il a commencé à bavarder indéfiniment, mais ne pouvait pas me dire où il avait utilisé Spring AOP et ne pouvait pas m'expliquer l'injection de dépendance, même après que j'ai explicitement demandé après avoir vu ces Il a juste dit qu'ils étaient vraiment cool, et il y a tellement de choses à apprendre, etc., etc. Il s'est avéré qu'il ne connaissait pas Jack ... et j'étais le seul à comprendre que b/c j'étais un membre plus jeune de l'équipe de développement.
Utilisez donc votre âge comme un avantage! Entrez, soyez confiant et posez quelques questions sur la technologie que vous connaissez bien.
N'oubliez pas que ce n'est pas parce qu'ils ont plus d'expérience que vous qu'ils ne peuvent pas être un meilleur développeur que vous. La phrase "Un an d'expérience répétée n fois." vient parce que vous voyez cela se produire dans l'industrie. Ainsi, votre première tâche lors de l'entretien devrait être d'établir qu'ils ont effectivement l'expérience pertinente et peuvent se présenter comme quelqu'un qui sait ce qu'ils font. De même, juste parce que quelqu'un a eu n années d'expérience dans l'industrie, cela ne signifie pas qu'il a une tonne d'expérience dans une langue, une bibliothèque ou un cadre donné, de sorte qu'il pourrait toujours vous venir de temps en temps de temps à poser des questions pendant qu'ils apprennent quelque chose.
Ensuite, rappelez-vous qu'un bon développeur senior est quelqu'un que vous devriez pouvoir approcher et poser des questions sur quelque chose avec lequel vous avez des problèmes. C'est le bon moment pour leur poser des questions de conception auxquelles vous avez eu des problèmes et voir comment ils répondent et quel est leur raisonnement dans leur explication. Ont-ils vu quelque chose de similaire avant ailleurs, font-ils une supposition éclairée basée sur l'expérience, ont-ils lu un article en ligne ou dans un journal?
Enfin, une autre chose à regarder est de savoir comment ils abordent le code de débogage. Dans ma propre expérience, j'ai constaté que quelle que soit la langue, certaines techniques de débogage ont tendance à être appliquées à l'universalité. Donnez au candidat un exemple de l'un des bogues les plus ésotériques que vous avez rencontrés et demandez-lui de vous expliquer comment il aborderait le bogue. Ont-ils un aperçu du problème qui n'est pas immédiatement évident?
En résumé, interviewer un candidat avec une interview impressionnante peut être intimidant, mais il y a quelque chose que vous devez couvrir quel que soit leur niveau (c.-à-d. Savent-ils réellement ce qu'ils font) et une fois que vous avez terminé, vous pouvez commencer à sonder pour voir comment ils appliquent leur expérience. La façon dont les candidats appliqueront leur expérience de travail antérieure va faire en sorte qu'un candidat se démarquera plus qu'un autre.
J'aime la réponse tilisez votre âge comme avantage , et je suggère quelque chose de similaire:
Utilisez votre niveau d'expérience inférieur comme un avantage
Cette personne sera probablement votre patron ou votre mentor, alors posez des questions d'une manière qui vous permettra de savoir si cette personne peut réellement vous encadrer.
Posez des questions compliquées qui pourraient être beaucoup plus faciles, ou qui incluent des problèmes trop compliqués. S'il est bon, il résoudra non seulement en essayant de répondre à la question/résoudre le problème, mais en réalité se rendra au vrai problème, en vous montrant les défauts de votre question. S'il parvient à le faire de manière polie sans vous intimider, il est gardien.
La chose vraiment importante est que vous vous assurez qu'il est le bon genre de développeur expérimenté pour ce dont vous avez besoin.
Au fur et à mesure que les gens avancent dans leur carrière, ils tendent à aller dans des directions différentes en fonction de ce qu'ils font. Vous pouvez interviewer des personnes qui sont des experts dans la gestion de grandes équipes de programmeurs ou qui travaillent avec du code hérité compliqué et assez brillantes dans ce qu'elles font sans qu'elles soient la personne qui convient à votre rôle. Alors essayez d'avoir une idée de ce que exactement vous recherchez à l'avance et pensez à des questions qui différencieront exactement le type de développeur pour votre travail des autres.
J'ai dû le faire plusieurs fois. J'ai appris à le faire par étapes.
- Commencez par les mêmes questions que je donne aux diplômés de l'université. Je l'ai fait parce que le poste pour lequel je faisais l'entretien technique était un poste de programmation où nous nous attendions à ce que le développeur soit impliqué dans le code, et je voulais m'assurer que les candidats pouvaient programmer. À une seule exception près, aucun des candidats ne le pouvait - ils étaient pires que tous les diplômés universitaires. Tous occupaient des postes de direction depuis trop longtemps.
- Pour le candidat qui a réussi un test de compétence de base en codage, j'avais quelques questions plus générales sur la façon de gérer le scénario X. Si vous faites des services Web dans votre projet, par exemple, pensez à une question intéressante sur les services Web et demandez au candidat comment il pourrait la résoudre. Je ne recommanderais pas que ce soit quelque chose sur lequel vous travaillez actuellement directement, principalement en raison du problème de la propriété intellectuelle et des données exclusives de l'entreprise. Ne donnez pas ces trucs!
- Passez du temps à poser des questions au candidat sur son curriculum vitae. C'est important. Vous pouvez découvrir ses meilleures et pires expériences en équipe, ses expériences en tant que superviseur, etc. Essayez d'avoir une idée du style de travail de la personne pour voir si elle s'intègre dans votre équipe.
Mon plus gros problème lors de l'entretien avec des candidats seniors était qu'ils étaient souvent très nerveux d'être interviewés par une personne junior, en particulier ceux qui ne pouvaient pas gérer mes tests de codage de base. Essayez de ne pas sembler menaçant dans les compétences que vous montrez tout au long de l'entretien - concentrez-vous sur elles, même si elles ne peuvent pas bien répondre à vos questions. Essayez de biaiser l'entrevue aux questions auxquelles ils peuvent répondre s'ils échouent sur les bases.
En ce qui concerne le processus d'entrevue, vous les traitez fondamentalement de la même manière que toute autre personne que vous embauchez. Il devrait y avoir un processus d'embauche similaire:
- Sélection, par CV ou recommandation d'agence.
- Test d'aptitude (combinant des choses comme FizzBuzz , strdup ()/isAlpha (), OOD, etc.)
- Entretien téléphonique (pour une élimination rapide s'ils ne communiquent pas bien)
- Entretien en face à face
- Exercice de codage écrit
- Rencontrez certains des membres de l'équipe.
- Pour une personne expérimentée, ce qui implique un risque plus élevé et des coûts plus élevés, des séries d'entretiens supplémentaires sont acceptables, mais vous devez clairement leur indiquer où elles en sont dans le processus (c'est-à-dire qu'il s'agit de 1 des 3 séries d'entretiens).
Il existe de nombreux autres messages sur ce site qui couvrent des sujets généraux de discussion que vous devriez couvrir dans le processus d'entrevue - voici ma réponse à l'un d'eux .
À tous les stades du processus d'entrevue, une personne expérimentée doit démontrer une excellente compréhension de ses spécialités annoncées. Vous pouvez les sonder, en profondeur, sur n'importe quel sujet que vous abordez pendant les discussions. Prenez les questions aux limites de votre niveau d'expérience/confort et voyez si elles peuvent continuer sans souci. Si vous avez besoin de sortir de la profondeur avec quelque chose que vous n'avez pas beaucoup d'expérience, faites une recherche sur le Web pour quelques exemples de questions (obtenez-en une sélection), lisez et comprenez les réponses avant l'entrevue, puis posez au candidat l'une de ces questions. Ne vous attendez pas à ce qu'ils connaissent toutes les réponses, alors ayez une sélection de questions.
Vous pouvez embaucher deux types d'ingénieurs expérimentés:
1) Expérience pertinente de l'industrie
Il s'agit de la personne à qui vous pouvez apporter votre liste de problèmes actuels et expliquer comment ils pourraient aborder ces problèmes. Vous devez évaluer leur niveau de compréhension de chacun des sujets spécifiques au domaine dans votre secteur. Comme vous êtes dans cette industrie, vous pouvez dire une réponse "stupide" à partir d'une "bonne" réponse et vous pouvez probablement aussi repérer une réponse "expérimentée". Contrairement à d'autres réponses, je ne m'attendrais pas à ce qu'ils résolvent réellement vos problèmes actuels - cela se produira lorsque vous les embaucherez - mais vous en avez besoin pour vous convaincre qu'ils le pourraient une fois qu'ils ont commencé.
2) Aucune expérience pertinente de l'industrie
Donc, ce candidat est peut-être en train de changer d'industrie mais a une bonne expérience dans les technologies/plates-formes/compétences de base dont vous avez besoin. Approfondissez ces éléments, mais ne vous attendez pas à ce qu'ils soient en mesure de trouver des solutions aux problèmes spécifiques au domaine, bien que vous puissiez simplement en parler. Par exemple, si votre entreprise est Facebook et que la personne que vous interviewez est passionnée par PHP et C++, il serait irréaliste de s'attendre à ce qu'ils connaissent tous les pièges des fermes de serveurs massives (sauf si ils le réclament sur leur CV).
Une chose que je n'ai pas vue explicitement signalée est: "Vous connaissez très bien la technologie X, et cela semble très intéressant. Pourriez-vous me l'expliquer en cinq minutes?"
Comme on s'attend très probablement à ce que vous puissiez maintenir le code qui sortira éventuellement de la nouvelle personne, il est crucial qu'il soit capable de l'expliquer aux autres programmeurs de manière efficace et efficace. Considérez qu'il s'agit de compétences en communication.
Une compréhension approfondie est nécessaire pour pouvoir rencontrer n'importe quel autre développeur à son niveau de compétence et communiquer des pensées et des idées à son niveau.
Si la personne ne peut pas communiquer verbalement, elle n'écrira probablement que le code pour le compilateur, pas pour le responsable.
Je suis d'accord avec Steven sur le mentorat. En fait, je dirais que vous pouvez lui poser des questions sur son point de vue sur le mentorat et comment le faire dans différents scénarios. Ensuite, évaluez en fonction de la réponse (vous pouvez obtenir des commentaires de votre patron si vous en avez envie ou discuter des réponses réelles dans le compte rendu).
Vous pouvez également poser des questions que vous poseriez à un pair, car le candidat devrait probablement être en mesure de résoudre ou au moins de comprendre votre travail.
choisissez certainement son cerveau dans l'interview sur les problèmes réels et les technologies que vous avez actuellement ou avez l'intention d'utiliser
en supposant qu'il est un développeur senior compétent et imaginatif, décidez d'embaucher ou non en fonction de si vous pensez que vous pouvez apprendre de lui/elle et bien travailler avec lui
vous n'interviewez pas votre futur patron, vous interviewez votre futur mentor. Ne choisissez pas quelqu'un qui connaît toutes les réponses mais ne peut pas enseigner
Je vous recommande sérieusement de lire le livre "Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent" .
Je n'ai jamais embauché personne, mais parfois, lorsque j'étais interviewé, je souhaitais à des idiots qui ne connaissent que les mots à la mode et m'interviewaient, que la ligne de raisonnement soit exposée dans ce livre. Le texte est très fluide et agréable à lire.
Et non, je ne fais pas de publicité uniquement parce que ce site est de l'auteur du livre. Le livre est vraiment génial et je le recommanderai à toute personne qui est en mesure d'embaucher des informaticiens, en particulier à ceux qui ne comprennent pas la technologie - De nos jours, il est très courant d'avoir un chef de projet ou un patron non technique.
Prenez un tas de problèmes que vous avez déjà résolus. Décrivez-lui ce qui a été fait pour résoudre le problème (gardez-le à la troisième personne; vous ne voulez pas mettre votre ego personnel en jeu ici). Demandez-lui ce qu'il aurait fait "différemment". Vous devriez être en mesure, sur la base de ce qu'il suggère, de déterminer si cela aurait été mieux ou pire, conceptuellement, que ce que vous avez fait.