Comment interrogez-vous une personne plus expérimentée que vous? [fermé]

La société pour laquelle je travaille souhaite recruter un développeur senior plus expérimenté que moi et attend de moi 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 plus compréhensive / plus expérimentée que moi.

Quelqu'un peut-il recommander quelques questions techniques d'entrevue à poser qui constituent un bon moyen d'évaluer les compétences en programmation de niveau supérieur, tout en restant celles que je peux comprendre?

Je dirais que j'ai passé le jr. niveau de programmeur, mais loin d'être senior. La plupart de ce que j'ai fait consiste à créer de petites applications (Web et de bureau), dont certaines sont assez compliquées, mais toutes ne sont destinées à être utilisées que par une poignée d'utilisateurs. Je sens que j'ai une compréhension correcte de la plupart des concepts de programmation et que je suis capable d'apprendre / d'enseigner moi-même à peu près n'importe quoi, mais je manque d'expérience. Comme mon patron aime me dire: "Vous ne savez pas ce que vous ne savez pas".

Nous souhaitons en particulier que la personne embauchée ait une expérience (que je n’ai pas encore): développement à plusieurs niveaux, environnement multi-utilisateurs, développement d’applications à grande échelle, messagerie bidirectionnelle, sessions partagées, etc. 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 tout s'est très bien passé. J'apprends beaucoup, pas seulement sur le codage, mais aussi sur des éléments tels que les modèles de conception, l'architecture logicielle, la documentation et la façon dont d'autres équipes de programmation plus importantes accomplissent des tâches bien remplies. Ce n'est pas toujours facile de faire venir quelqu'un pour indiquer de meilleures façons de faire ce que vous avez fait, mais si vous pouvez ravaler votre fierté et être prêt à essayer de nouvelles choses, vous pourrez en apprendre beaucoup.

Le processus d'entrevue s'est déroulé mieux que prévu. J'ai commencé à poser des questions sur des choses que je connaissais bien, puis à poser des questions sur des choses avec lesquelles je me débattais. Chaque fois que la personne interrogée disait quelque chose que je ne comprenais pas, je leur demandais de bien vouloir me l'expliquer, puis de l'écrire afin que je puisse l'examiner plus tard. Dans l’ensemble, j’ai eu l’impression que je pouvais avoir une assez bonne idée du niveau de compétence, de l’intelligence et des compétences des candidats.

Tu ne peux pas.

Au lieu de cela, je vous suggérerais de citer dans l'entretien une liste des problèmes que vous rencontrez aujourd'hui et de lui demander comment il les résoudrait .

C'est une méthode très intéressante pour les deux raisons suivantes:

1. C'est un conseil gratuit . Même si vous n'engagez pas le gars, il peut suggérer de bonnes solutions à vos problèmes .

2. S'il apporte des solutions intéressantes , il résoudra les problèmes . Le genre de gars que vous voulez embaucher.

Utilisez votre âge comme un avantage.

J'ai interviewé une tonne de personnes plus âgées que moi. Je prends une technologie que je ne sais assez bien et leur dire que je l' ai entendu parler de la technologie X, mais jamais utilisé. Je demande au candidat de me donner un aperçu de la technologie et de la manière dont il l'a utilisée dans un projet.

Cela fonctionne étonnamment bien. Premièrement, si le candidat utilise uniquement cette technologie X comme mot à la mode dans son curriculum vitae, son explication sera nulle / inutile. En outre, s’ils ne peuvent pas vous donner un bon exemple concret de la façon dont ils ont utilisé cette technologie dans leurs projets antérieurs, vous avez un grand drapeau rouge à cet endroit.

J'ai interviewé quelqu'un qui avait une expérience java Spring. J'avais utilisé Spring dans mon travail précédent, et l'une des principales caractéristiques de Spring est Injection de dépendance. J'ai dit au candidat que j'avais interviewé que j'avais entendu parler du printemps et que je ne l'avais jamais utilisé. Il a commencé à bavarder encore et encore, mais il 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 l'avoir explicitement demandé après avoir vu ces choses citées dans son CV. Il vient de me dire qu'ils étaient vraiment sympas et qu'il y a tant à apprendre, etc. etc. Il s'avère en réalité qu'il ne connaissait pas Jack ... et j'étais le seul à comprendre cela parce que j'étais un membre plus jeune de l'équipe de développement.

Alors, utilisez votre âge comme un avantage! Entrez, soyez confiant et posez des questions sur une technologie que vous connaissez bien.

N'oubliez pas que, juste parce qu'ils ont plus d'expérience que vous, ils ne sont peut-être pas un meilleur développeur que vous. La phrase "Un an d'expérience répété n fois." vient parce que cela se produit dans l’industrie. Par conséquent, votre première tâche au cours de l’entretien devrait être d’établir qu’ils possèdent bien 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'ils ont une tonne d'expérience dans une langue donnée, une bibliothèque, ou d'un cadre afin qu'ils pourraient encore venir à vous de temps en temps de poser des questions alors qu'ils sont apprendre quelque chose.

Ensuite, rappelez-vous qu’un bon développeur senior est une personne à laquelle vous devriez pouvoir vous adresser et poser des questions sur quelque chose qui vous pose problème. C’est le bon moment pour leur poser quelques questions de conception qui posent problème et pour voir comment ils y répondent et quel est le raisonnement de leurs explications. Ont-ils déjà vu quelque chose de similaire quelque part 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 à examiner est la manière dont ils abordent le code de débogage. Selon ma propre expérience, quelle que soit la langue utilisée, certaines techniques de débogage ont tendance à être appliquées à l’universalité. Donnez au candidat un exemple d’un des bogues les plus ésotériques que vous avez rencontré et demandez-lui de vous expliquer comment il aborderait le bogue. Ont-ils une idée du problème qui n'est pas immédiatement évidente?

En résumé, interviewer un candidat avec un entretien impressionnant peut être intimidant, mais il y a quelque chose que vous devez couvrir, quel que soit son niveau (c.-à-d. Savent-ils réellement ce qu'il fait) et une fois que c'est terminé, vous pouvez commencer à chercher qu'ils voient comment ils appliquent leur expérience. La façon dont les candidats appliquent leur expérience de travail antérieure va être ce qui va rendre un candidat plus remarquable qu'un autre.

J'aime beaucoup la réponse « Utilisez votre âge» , et je suggérerais quelque chose de similaire:

Utilisez votre faible niveau d'expérience comme avantage

Cette personne sera probablement votre patron ou votre mentor, alors posez des questions de manière à vous permettre de savoir si cette personne peut réellement vous conseiller.

Posez des questions compliquées qui pourraient être beaucoup plus simples ou qui incluent des problèmes trop compliqués. S'il / elle est bon (e), il / elle tentera non seulement de répondre à la question / résoudra le problème, mais passera au problème réel, en vous montrant les failles de votre question. S'il réussit à le faire de manière polie sans vous intimider, il est gardien.

Ce qui compte vraiment, c’est que vous vous assuriez qu’il est le bon type de développeur expérimenté pour ce dont vous avez besoin.

Au fur et à mesure que les gens avancent dans leur carrière, ils ont tendance à aller dans des directions différentes. Vous interviewerez peut-être des experts en gestion de grandes équipes de programmeurs ou travaillant avec des codes complexes compliqués, et très brillants dans ce qu'ils font sans qu'ils soient la personne qui convient à votre rôle. Essayez donc d’avoir une idée de ce que vous recherchez exactement à l’avance et réfléchissez à des questions qui différencieront exactement le type de développeur de votre travail.

J'ai dû le faire plusieurs fois. J'ai appris à le faire par étapes.

1. Commencez avec les mêmes questions que je donne aux diplômés du collège. 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 puissent programmer. À une exception près, aucun des candidats ne pouvait - ils étaient pires que tous les diplômés des collèges. Tous occupaient des postes de direction depuis trop longtemps.
2. Pour le candidat ayant réussi un test de compétences de base en codage, j’avais quelques questions plus générales sur la manière de traiter les scénarios X. Si vous utilisez des services Web dans votre projet, par exemple, réfléchissez à une question intéressante relative aux services Web et demandez au candidat comment il le résoudrait. Je ne recommanderais pas que ce soit quelque chose sur lequel vous travaillez actuellement directement, principalement à cause de la question de la propriété intellectuelle et des données exclusives à la société. Ne donnez pas ce genre de choses!
3. Passez du temps à demander au candidat des informations sur son CV. C'est important. Vous pouvez découvrir ses meilleures et ses pires expériences d’équipe, ses expériences en tant que superviseur, etc. Essayez de vous familiariser avec le style de travail de la personne pour voir si elle convient à votre équipe.

Mon plus gros problème lors des entretiens avec des candidats seniors était qu’ils étaient souvent très nerveux d’être interviewés par un junior, en particulier ceux qui ne pouvaient pas gérer mes tests de codage de base. Essayez de ne pas paraître menaçante dans vos compétences tout au long de l'entretien - concentrez-vous sur elles, même si elles ne peuvent pas bien répondre à vos questions. Essayez de placer l'entretien aux questions auxquelles ils peuvent répondre s'ils échouent sur les bases.

En termes de processus d’entretien, vous les traitez fondamentalement de la même manière que toute autre personne que vous recrutez. Il devrait y avoir un processus de recrutement similaire:

1. Sélection, par CV ou recommandation d'agence.
2. Test d'aptitude (combinant des choses comme FizzBuzz , strdup () / isAlpha (), OOD, etc.)
3. Entretien téléphonique (pour une élimination rapide s'ils ne communiquent pas bien)
4. Entretien face à face
5. Exercice de codage écrit
6. Rencontrez quelques membres de l'équipe.
7. 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 se trouvent dans le processus (c'est-à-dire qu'il s'agit de l'une des 3 séries d'entretiens).

Il existe de nombreux autres articles sur ce site qui traitent de sujets généraux de discussion que vous devriez aborder dans le processus d’entrevue. Voici ma réponse à l’un d’eux .

À tous les stades du processus d’entretien, une personne expérimentée doit démontrer une excellente compréhension des spécialités annoncées. Vous pouvez les examiner, de manière très approfondie, sur n’importe quel sujet que vous couvrez pendant les discussions. Abordez les questions selon les limites de votre expérience / niveau de confort et voyez si elles peuvent continuer sans souci. Si vous avez besoin de quelque chose avec lequel vous n’avez pas beaucoup d’expérience, faites une recherche Web sur quelques exemples de questions (obtenez-en une sélection), lisez et comprenez les réponses avant l’entretien , puis posez la candidat aucune de ces questions. Ne vous attendez pas à ce qu'ils connaissent toutes les réponses, alors ayez une sélection de questions.

Vous pouvez engager deux types d'ingénieurs expérimentés:

1) Expérience pertinente dans l'industrie

C’est à cette personne que vous pouvez consulter votre liste de problèmes actuels et discuter de la façon dont ils pourraient les aborder. Vous devriez évaluer leur niveau de compréhension de chacun des sujets spécifiques à votre domaine dans votre secteur. Comme vous êtes dans ce secteur, vous pouvez distinguer une réponse "idiote" d'une réponse "bonne" et 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 avez besoin d'eux pour vous convaincre qu'ils pourraient le faire une fois qu'ils ont commencé.

2) Aucune expérience pertinente de l'industrie

Ce candidat est donc peut-être en train de changer de secteur, mais possède une bonne expérience des technologies / plateformes / compétences de base dont vous avez besoin. Approfondissez ces éléments, mais ne vous attendez pas à ce qu'ils soient en mesure de proposer des solutions aux problèmes spécifiques à un domaine, bien que vous puissiez simplement en parler. Par exemple, si votre entreprise est Facebook et que la personne que vous interviewez a une grande passion pour PHP et C ++, il serait irréaliste de s'attendre à ce qu'elle connaisse tous les pièges des énormes parcs de serveurs (à moins qu'ils ne l'indiquent dans leur CV).

Une chose que je n'ai pas vue explicitement mentionnée est la suivante: "Vous connaissez très bien la technologie X et cela semble très intéressant. Pourriez-vous m'expliquer, dans cinq minutes?"

Etant donné que vous serez probablement en mesure de conserver le code généré par la nouvelle personne, il est essentiel qu'elle soit capable de l'expliquer efficacement et efficacement aux autres programmeurs. Considérez que ce sont des compétences de communication.

Une compréhension approfondie est nécessaire pour pouvoir rencontrer tout autre développeur sur son niveau de compétence et communiquer des idées et des idées à ce 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 rôle de mentor. En fait, je dirais que vous pouvez lui poser des questions sur son point de vue sur le mentorat et comment il s'y prend dans différents scénarios. Ensuite, évaluez en fonction de la réponse (vous pouvez obtenir les commentaires de votre chef 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 capable de résoudre ou au moins de comprendre votre travail.

interroge définitivement son cerveau dans l'interview sur les problèmes réels et les technologies que vous avez actuellement ou que vous envisagez d'utiliser

en supposant qu'il s'agisse d'un développeur senior compétent et imaginatif, décidez d'embaucher ou non, si vous pensez pouvoir apprendre de lui / elle et bien travailler avec lui / elle.

vous n'interviewez pas votre futur patron, vous interrogez votre futur mentor. Ne choisissez pas quelqu'un qui connaît toutes les réponses mais ne peut pas enseigner

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 en jeu ici). Demandez-lui ce qu'il aurait fait "différemment". Vous devriez pouvoir déterminer, sur la base de ses suggestions, si cela aurait été meilleur ou pire, sur le plan conceptuel, que ce que vous avez fait.

Je vous recommande sérieusement de lire le livre "Smart and Gets Things Done: le guide concis de Joel Spolsky pour trouver le meilleur talent technique" .

Je n'ai jamais engagé de personnel, mais parfois, lorsque j'étais interviewé, je souhaitais que des idiots qui ne connaissent que les mots à la mode et qui m'interviewaient aient la ligne de raisonnement 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 provient de l'auteur du livre. Le livre est vraiment génial et je le recommanderai à quiconque est en mesure de recruter 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 chef non technique.