Comment interviewer un candidat administrateur système? [fermé]

Quels types de questions poseriez-vous et quels scénarios décririez-vous, quels types de réponses rechercheriez-vous?

Je ne demande pas de questions spécifiques. Je voudrais savoir quelle stratégie d’entretien est bonne pour sélectionner des candidats qualifiés pour le poste.

Je pose des questions dans 3 catégories:

• Connaissances techniques - Je veux m'assurer que le candidat sait ce qu'il est supposé savoir. Par exemple, dites-moi la différence entre RAID 0, RAID 1, RAID 5, RAID 1 + 0 et RAID 0 + 1. Si vous êtes un administrateur des services d'annuaire AD, indiquez-moi les rôles FSMO au niveau de la forêt et du domaine et leur rôle. De plus, je leur demande en quelle technologie elles s’intéressent. Construisent-elles des robots à côté? Bien! Est-ce qu'ils programment des robots? Vraiment? J'ai donc quelqu'un qui peut faire un peu de code et qui connaît bien le problème du dépannage. Exceptionnel! Des choses comme ça.
• Personnalité - Je pose des questions sur la façon dont ils gèrent différents scénarios. Des situations telles que: "Le PM se rend compte qu'une erreur a été commise dans le calendrier. Vous savez que l'erreur est la faute du PM. Cette erreur va vous amener à travailler deux week-ends consécutivement. Comment la gérez-vous?" En gros, des questions qui révèlent ce que pense le candidat et s'il sait ou non ce qu'il faut faire pour faire partie d'une équipe. Cela ne supprimera pas les personnes qui connaissent les bonnes réponses et ne les fait pas, mais cela éliminera les personnes qui n'ont aucune idée de la façon de bien jouer avec les autres. Je pose également des questions sur la participation de la communauté.
• Expérience antérieure - Je demande généralement au candidat de me donner une situation ou un projet qui s'est bien déroulé dans le passé. Je veux savoir à quels défis ils ont été confrontés et comment ils les ont traités. Je demande aussi de me donner une situation où les choses ne se sont pas bien passées. Quelles ont été les leçons apprises par le candidat? Qu'est-ce que le candidat aurait pu faire en réfléchissant avec le recul pour éventuellement renverser la situation (et si le candidat ne le pouvait pas, le candidat le reconnaîtrait-il).

Cette réponse couvre les trois principaux domaines sur lesquels il faut enquêter. Toutefois, il convient de prendre en compte, notamment dans les plus petits magasins, où l’on s'attend à ce que les utilisateurs d’infrastructures soient multidisciplinaires, il faut poser des questions techniques très vastes, auxquelles on peut répondre à différents niveaux d’abstraction en fonction des besoins. l'expertise du candidat. Cela vous permet d'avoir une idée de ce dont chacun est capable et de démontrer son expertise spécifique, tout en vous permettant de comparer directement les réponses de différents candidats.

Une bonne question que j'ai déjà posée est:

Imaginez que je vous ai connecté à une machine ici et que j'ai installé un terminal. Vous tapez wget http://www.google.com/. Ce qui se produit?

Avec mon parti pris réseau, j'ai répondu en commençant par la résolution DNS, puis en passant à la configuration du proxy, puis à la décision de routage et à l'établissement d'une connexion TCP; un autre candidat a répondu en termes de conversation HTTP. Lorsque j'ai demandé à l'intervieweur quelle était la meilleure réponse qu'il avait entendue, il a répondu:

"Et bien, ça a commencé avec l'interruption du clavier ..."

Les questions techniques sont importantes, et la méthode de réponse est presque aussi importante que d'avoir la bonne réponse. (La dernière chose dont le service informatique a besoin est que quelqu'un sabote sa bonne volonté dans toute l'organisation avec hostilité et condescendance).

Mais voici ma question la plus importante -

Mon premier entretien avec une "vraie" société informatique a pris fin lorsque je suis arrivé à une question technique à laquelle j'ai répondu: "Je ne sais pas".

La réponse fut: "Génial, quand pouvez-vous commencer?"

J'étais à peine sortie de l'université et mon intervieweur voulait savoir que j'étais capable de reconnaître les limites de mes connaissances / expériences. C'est quelque chose que j'ai gardé avec moi, et je pense que c'est l'attribut le plus important pour un administrateur système. Les connaissances spécifiques sont utiles et vous donneront un coup de pouce, mais si vous ne pouvez pas admettre que vous ne le savez pas, vous progresserez très lentement, voire pas du tout.

J'interviewe souvent des personnes pour des postes de premier échelon, ce qui signifie que je ne peux pas discuter d'un historique de travail significatif. Je discute habituellement de projets personnels, mais je pose toujours deux questions: "Pouvez-vous me décrire votre réseau domestique?" et "Comment sauvegardez-vous votre ou vos machines domestiques?" Une personne vraiment intéressée pourrait rester devant un tableau blanc pendant 30 minutes pour en discuter, entrer dans l'adressage IP, la sécurité sans fil, etc. Un pauvre candidat haussera les épaules et vous dira que c'est son frère qui l'a mis en place.

Ne posez pas de questions "triviales" - des questions avec une seule réponse très spécifique. Les gens peuvent oublier ce genre de chose lorsqu'ils sont stressés. Si leur travail exige qu'ils sachent quelle broche sur une interface V.35 est utilisée pour transmettre des données, ils peuvent le rechercher quand ils auront le travail. Les questions générales vous aident à en savoir plus sur les candidats que sur des anecdotes ... Nous n'aimons pas les casse-tête.

La pratique de l'administration système et réseau

Posez différents types de questions qui vous aideront à mieux connaître le candidat. Et comment ils s'intégreront à votre groupe de travail. Dans les temps anciens La plupart des SA étaient des physiciens, des astronomes, des mathématiciens et des ingénieurs. Pourquoi? Probablement parce qu'ils avaient d'excellentes compétences en matière de tir et prenaient de très bonnes notes.

Quelques questions à poser:

Technique

• Décris-moi, comme si je ne connaissais rien, comment fonctionne un réseau TCP / IP.
• Décris-moi, comme si je ne savais rien du fonctionnement d'un ordinateur (un appareil de base Von-Neumann)
• Dessinez-moi un schéma de réseau simple: vous avez 20 systèmes, 1 routeur, 5 commutateurs, 2 serveurs et un petit bloc IP. Aller.
• En fonction de l’offre d’emploi, que comptez-vous faire ici?
• Décrivez-moi ce que vous espérez accomplir ici.
• Quelle est la meilleure méthode pour garder la documentation à jour?
• Quel est le pire incident de récupération après sinistre dans lequel vous avez été impliqué? Dis moi ce que tu as fait.
• Pourquoi aimez-vous être SA?
• Comment vous évalueriez-vous en tant que SA?

Affaires

• Pensez-vous que l'informatique est le moteur de l'activité ou que l'entreprise est l'informatique?
• Que pensez-vous de notre modèle économique actuel?
• Que pourriez-vous faire pour nous rendre plus rentables?
• Comment l'interface informatique avec notre entreprise?

Personnel

• Quelle est votre blague préférée?
• Quel livre devrais-je lire demain? Pourquoi? (puis allez à la bibliothèque et parcourez-le)
• Qui est Thomas Limoncelli? (hé hé, GOTCHA!)

La plupart des gens peuvent bien paraître sur papier. Certaines personnes peuvent passer à travers des discussions techniques. Et beaucoup de gens parlent mal. Vous devez poser des questions ouvertes. Non "Oui ou Non", observez leurs processus de pensée et leurs capacités de dépannage. Les métaphores qu'ils utilisent pour décrire des processus complexes sont les plus révélateurs.

Embaucher un SA est une tâche très difficile. Il est peu probable qu'un entretien technique décrive les personnes que vous allez recruter. Ce n'est pas tellement ce qu'ils savent maintenant. C'est ce qu'ils sont disposés à apprendre et à quelle vitesse ils vont apprendre et l'appliquer.

Si je faisais partie d'un panel d'entrevue pour un administrateur système chez une société de logiciels où ils seraient tenus de faire fonctionner le logiciel de la société sur leurs serveurs, je serais intéressé de savoir ce que le candidat attend des développeurs. Comment interagissent-ils avec les développeurs - "nous contre eux" ou "réunissant tous des experts différents"? Ont-ils l'expérience d'une situation où développement et informatique (ou quel que soit le nom du département) se retrouvent en conflit, et comment cela a-t-il été résolu? Sont - ils intéressés à obtenir une prise de conscience de la technologie et de la terminologie utilisée par les développeurs, et sont - ils prêts à aider à éduquer les développeurs dans leurs propres domaines d'expertise, afin que chacun puisse mieux communiquer?

Certes, ce serait en partie pour satisfaire mon propre intérêt dans la relation entre administrateurs système et développeurs, ainsi que pour juger le candidat.

Assurez-vous qu'il ne livre pas simplement intelligemment. Je pense que c'est bien de donner une sorte de test à la main.

Les questions du «tableau blanc» sont celles qui séparent vraiment les moutons des chèvres. "C’est la limite du réseau; il s’agit d’une application Web qui s’exécute sur IIS, il s’agit de votre serveur SQL; c’est une boîte UNIX avec un autre service de boîte noire. Comment la rendre sécurisée, etc.? "

La seule réponse que j'ai eu à cela d'un candidat était un poleaxé "tu plaisantes, pas vrai?"

J'engage des administrateurs Linux pour une startup, alors mes questions sont celles qui devraient révéler l'expérience de l'inexpérience. Écran de téléphone:

1. Nommez autant de répertoires de niveau supérieur dans un système Linux moderne (FHS) que vous pouvez (il y en a environ 20, personne ne reçoit plus de 75%, même ceux qui le traitent tous les jours)?
2. A quoi sert la variable d'environnement PATH?
3. Nommez une personne célèbre pour son implication dans les logiciels libres / à source ouverte (autre que Linus Torvalds) (réponse la plus fréquente: Richard Stallman)

Pour l'interview téléphonique, j'essaie de leur faire parler de leurs projets précédents, de leur réseau domestique, du nombre d'ordinateurs qu'ils possèdent et de ce qu'ils en font, etc.

En personne, j'aime leur poser un problème réel et leur demander de le résoudre pour moi. Je vais comparer leur réponse avec la solution sur laquelle je réfléchis déjà. Si leur réponse est meilleure, mon projet avance. Si leur réponse est pire, le processus d’entretien a progressé. De toute façon, je peux rester impliqué dans mes propres projets et affiner ou rejeter des candidats ou des idées.

Sinon, on parle plus en profondeur de ce qu’ils attendent d’un environnement de travail, en essayant de savoir s’ils sont 9-5 ans ou s’ils se soucient vraiment de ce qu’ils font - sans autres facteurs, les types de Linux ont tendance se soucier (même s’ils peuvent être nul) et les ingénieurs réseau ont tendance à être âgés de 9 à 5 ans (qui peuvent aussi être nul) ... Juste mon expérience.

En supposant qu'ils réussissent tout cela, j'aime aussi les installer avec une nouvelle machine Linux sur un réseau isolé dont la configuration réseau est incorrecte, avec un équipement étrange connecté et un câble lâche pour le dernier "vissez-vous", et demandez-leur de le récupérer. en ligne. Je les laisse tranquilles et reviens périodiquement pour les vérifier, même si je pouvais tout aussi facilement planer si je voulais être un dur à cuire.

Il faut généralement environ 30 minutes à une personne qui a passé le reste de l’entrevue pour se rendre dans cet environnement totalement inconnu et le remettre en marche. C'est un test impressionnant du monde réel pour savoir exactement combien de temps il leur faut pour dépanner un environnement totalement nouveau et totalement brisé.

Après avoir soigneusement trié le CV, il me restait encore 20 candidats. 20 personnes sur environ 150 ont réussi la première sélection qui m'a permis de passer trois à quatre heures à interviewer chacune d'entre elles. Les principaux critères de sélection pour moi étaient:

• capacité à s'entraîner sur un lieu
• habileté à choisir l'approche optimale
• habileté à rassembler et à résoudre un problème dans une situation non standard
• une bonne base de connaissances: cela signifie que le candidat doit connaître l’histoire de la technique informatique, posséder la théorie à un niveau élevé, savoir non seulement " quoi faire", mais aussi savoir "pourquoi" .

Pour connaître leurs compétences pour rassembler et résoudre un problème dans une situation non standard, on leur a demandé, par exemple: "Comment gâcher un système Windows, si vous avez un accès physique à l'ordinateur, mais n'avez pas mots de passe de compte? " et, après cela, je leur ai demandé "Comment patcher un système endommagé?". J'ai donné quelques exemples d'action sur les virus et demandé ce qu'ils feraient pour prévenir les dommages et rendre la fonctionnalité et les données perdues avec le moins d'instruments possible, ainsi que davantage de questions sur l'utilisation d'instruments non standard. Une fois, j'ai demandé à un candidat: "Quelle question poseriez-vous, si vous m'interviewiez, de savoir à quel point je suis bon avec des situations non standard?" :-)

Pour savoir à quel point ils réussissent à trouver une approche optimale, je leur ai appris un peu de pratique pour configurer Web, un serveur de messagerie ou une passerelle réseau pour des paramètres particuliers ("J'ai besoin que ce soit un serveur Web très rapide pour un petit nombre de clients connectés oui, je veux un langage de script côté serveur, pour me montrer des statistiques, que dois-je choisir et pourquoi croyez-vous que c’est mieux? Pouvez-vous me montrer sur notre serveur de test si vous avez il vous reste 20 minutes? ")

La capacité de formation sur un lieu - pas vraiment facile à vérifier, mais j’ai demandé à certains candidats de créer un exemple de fichier de configuration ou un script, puis je leur ai donné un petit indice pour savoir s’ils pourraient le faire mieux par la suite.

La base de connaissances - une de mes parties préférées: Qu'est-ce que l'OSI? Pourquoi TCP / IP appelé " pile de protocole "? Quels héros informatiques connaissez-vous? Qu'est-ce que Windows-registery? Et qu'en est-il des systèmes de type Unix?

Et chose très importante - ils DOIVENT aimer leur travail! "Avez-vous lu des auteurs classiques, tels que K & R?", "Depuis combien de temps s'intéresse-t-il beaucoup à la technique informatique?", "Avec quoi vous avez commencé à étudier l'informatique?", "Avez-vous des ordinateurs de test / un petit réseau à la maison?" (si c'est vrai, c'est un très bon signe!).

La liste de K. Brian Kelley est excellente, mais j'aimerais souligner qu'il est important de poser des questions de dépannage. Choisissez quelques problèmes difficiles que vous avez rencontrés et demandez au candidat de vous expliquer comment il essaierait de résoudre le problème. Il est important de connaître de nombreux détails techniques, mais à mon avis, il est très important de pouvoir résoudre les problèmes avec une approche méthodique.

J'aime poser des questions qui sont à l'opposé de la forme normale de cette même question. Par exemple, dans le développement Web, une question courante est la suivante: "quand publiez-vous un formulaire au lieu de GET?" Mais je demande le contraire: "Quand utilisez-vous GET au lieu de POST?" Cela oblige les gens à penser à des inconvénients plutôt qu'à des avantages, ou à envisager les compromis qu'ils font lorsqu'ils prennent une décision.

Une question représentative pour l'informatique peut impliquer deux choix technologiques similaires; peut-être une question du type "Quand choisiriez-vous un groupe de travail Windows au lieu d'un domaine?"

Je garde toujours une note au crayon et à papier de toutes les choses étranges et bizarres que je rencontre dans le travail quotidien, pas le genre de chose qui est dans les livres "Comment ...". Je peux ensuite faire appel à une ou deux de ces situations lors d’une interview, souvent plus pour entamer une conversation qu’en guise de test, je suis plus intéressé par COMMENT ils gèrent la situation que s’ils connaissent la réponse. Je pose toujours une question sur les technologies de pointe pour savoir si elles sont intéressées par les nouvelles technologies (ou TROP intéressées en fait).

Un peu hors sujet - mais une histoire intéressante du blog officiel de Google:

Comment je suis arrivé à Google (Ch. 1)

Cependant, nos ingénieurs ont tendance à suivre des itinéraires plus variés, parfois plus curieux. Certains sont recrutés en dehors des études supérieures, ou par des amis ou d'anciens collègues. D'autres envoient simplement leur curriculum vitae à jobs@google.com. Pour quelques ingénieurs, cependant, le chemin a été plus intéressant.

Veuillez lire le reste du billet de blog à propos de cette méthode peu conventionnelle mais, à mon avis, valable pour embaucher les bonnes personnes.

Lors de l'entretien, je ne cherche pas vraiment à savoir si un candidat est capable de répondre à des questions techniques spécifiques. Je pense qu'il est plus important qu'un candidat sache où aller pour trouver une réponse.

Un candidat ne devrait pas simplement dire: "Je ne sais pas". Je cherche une réponse plus proche de "Je voudrais Google" ou quelque chose de similaire à "Je suis membre de [ACM | SAGE | LOPSA | Défaut de serveur] et je vérifie le site [archives de la liste de diffusion | | site Web. ] pour trouver de l’aide pour répondre à cette question ".

Savoir où un candidat se tournera quand il ne connaît pas la réponse à une question est un bon moyen de se faire une idée de ses capacités.

J'ai interviewé des personnes en tant qu'employé d'une grande entreprise et en tant que propriétaire d'une petite entreprise. La qualité numéro un que je recherche est une personnalité équilibrée entre «visionnaire» et «bricoleur».

Si vous avez trop de visionnaires, vous obtenez un système construit comme Twitter. (Si vous ne les avez pas lues, la moitié de leurs premières descriptions d'instructions d'ingénierie incitera la plupart des administrateurs à faire un facepalm et à se diriger vers le bar.) Si vous avez trop de bricoleur, vous avez 200 systèmes géniaux dans divers les états de délabrement partout, et tous vos sites Web fonctionnent sur une boîte de dix ans fonctionnant sous BSD 4.2 sous le bureau de l'administrateur système.

La meilleure personne que j'ai jamais embauchée a été un gars avec un double baccalauréat en religion et en philosophie dans une petite université privée du Connecticut. Il était créatif, dévoué, intelligent et persévérant face à l'adversité. Il vérifiait le code via un téléphone cellulaire attaché jusqu'à une heure avant la naissance de sa première fille. Il a continué à faire des choses incroyables et est maintenant le leader de la communauté d'un framework PHP majeur. Bon gars.

La pire personne avec laquelle j'ai travaillé était un gars très impliqué dans l'organisation pour laquelle nous travaillions tous les deux. Son père y travaillait et il y travaillait depuis le lycée. Il y a eu au moins une douzaine de fois où je lui ai presque dit que s'il n'aimait pas son travail, il devrait juste arrêter de fumer et sauver le reste de la migraine. C'était un bricoleur. Et co-incidemment, un grand fan de BSD et Gentoo.

En dehors de cela, tout administrateur système dans un rôle * nix devrait pouvoir décrire pourquoi c'est drôle .

Je demande toujours au candidat de s’évaluer de 1 à 10 ans sur certains aspects du poste. Ensuite, sur la base de cette réponse, je pose des questions qui correspondent au niveau où ils se sont placés.

Si le poste nécessite l'utilisation de scripts, je demanderai toujours des exemples. Dans une seconde interview, donnez-leur un scénario et demandez-leur d'automatiser leur réponse. Je dois juste être sûr que leur approche n'est pas un emporte-pièce.