Interviewer quelqu'un pour les compétences générales d'Unix [fermé]

Comment testeriez-vous un développeur qui prétend avoir une expérience shell * nix (juste pour être clair, nous ne voulons pas tester si quelqu'un peut développer sur * nix, seulement qu'il connaît sa voie en ligne de commande).

Je pensais à leur faire résoudre un problème d'obtention d'informations dans les fichiers journaux, ce qui impliquerait certaines notions de base comme cat, grep, cut, ... combinées avec des tuyaux.

Quelles autres connaissances de base demanderiez-vous? Encore une fois, ce n'est pas pour interviewer quelqu'un qui développera pour les systèmes * nix, et pas non plus pour les administrateurs système * nix, mais juste pour les développeurs réguliers qui ont parfois besoin de travailler sur un système * nix.

D'après mon expérience personnelle, le développeur travaillant sur un système * nix doit savoir:

• variables shell (comment définir / obtenir + des connaissances sur des variables spéciales comme PATH)
• redirection du shell (capture de la sortie d'un programme)
• tuyaux (extraire certaines informations du fichier journal est un excellent exemple)
• contrôle de processus (ps, nice / renice, kill)
• droits d'accès aux fichiers (ls / chmod / chown / chattr)
• utilisateurs (mais surtout dans le contexte de fichiers / processus, c'est-à-dire: ce processus est-il capable d'accéder à ce fichier? pourquoi il peut / ne peut pas?)

... et en bonus:

• démarrage / arrêt des services système

Un tel ensemble de compétences permet d'effectuer facilement la plupart des tâches liées aux développeurs.

D'après mon expérience avec mes nombreux collègues depuis que j'ai commencé à travailler, personne ne veut simuler les connaissances Unix: soit ils " connaissent leur chemin autour de la ligne de commande ", soit ils disent simplement "pas question!".

Demandez simplement si le candidat est disposé à travailler sur un poste de travail Unix et laissez-le vous dire jusqu'où il peut passer par bash. Il finira par nommer certaines commandes; les plus évidents sont cd, cat, moreou less, viou emacs, grep, awk, sed. Écoutez attentivement s'il mentionne man.

Si elle est pour le développement, il devrait être familier avec makeet Makefile, et une interface de ligne de commande de contrôle de code source ( svn, git, cleartool, hg, cvs...)

Pourquoi faire ceci?

Les shells * nix (et autres shells OS, fwiw) sont des environnements de travail très profonds et larges. Il est possible que quelqu'un passe des années à travailler là-bas et n'utilise qu'un très petit% de la capacité des obus.

Si vous ne vous attendez pas à ce que la personne a) programme shell, ou b) administre le système à partir du shell, alors pourquoi est-ce important? Tout ce qui sera fait sera à un niveau si basique qu'une feuille de triche pratique * nix compensera largement le "manque de compétences".

Du haut de ma tête, je leur demanderais probablement deux choses:

1. Lorsque vous avez utilisé la ligne de commande * nix auparavant, avez-vous rencontré un cas dans lequel une commande bien pensée vous a fait gagner beaucoup de temps? Si oui, élaborez.

2. Veuillez expliquer les principales différences entre la ligne de commande * nix et un bureau Windows standard. Quels sont les avantages et les inconvénients de chacun?

De toute évidence, le premier vous donnera une indication de la profondeur des connaissances du demandeur sur la ligne de commande. S'il a travaillé pendant des années sur un * nix, il ne vous dira pas simplement qu'il était fier d'avoir couru un grep. Ne vous attendez pas à ce qu'ils se souviennent des commandes exactes bien sûr (il y a toujours des pages de manuel pour cela), mais de l'idée générale de ce qu'ils ont fait.

La deuxième question vérifie à la place s'ils comprennent en quoi la ligne de commande est vraiment bonne et pour quoi ce n'est pas un outil approprié. Il est facile d'apprendre à utiliser un marteau, mais il est beaucoup plus difficile de passer à un autre outil au cas où le marteau ne conviendrait pas. Cette question vous donne donc une bonne indication de l'opinion du demandeur en dehors de la boîte * nix, plus elle est suffisamment ouverte pour qu'il puisse (et devrait) marquer avec ses connaissances. (Rien de pire que de répondre à quelque chose comme "euh .. Windows a ces fenêtres")

Cela dépend de ce que vous voulez qu'ils fassent.

Pour obtenir des informations sur les fichiers journaux, votre suggestion pour cat + grep est parfaitement logique. J'ajouterais ls, cd et moins / plus à cela.

Si vous vous attendez à ce qu'ils fassent également quelques modifications mineures (par exemple, dans les fichiers de configuration), il serait logique d'ajouter des tests pour vi et / ou emacs et pour des choses comme cp / mv / rm / mkdir.

Je recommanderais qu'ils connaissent emacs ou vi / m, tar, sed, e / f / grep, les divers compilateurs, certains scripts shell. Peut-être exécuter un test où ils doivent utiliser ces outils pour récupérer du code d'un fichier sans l'ouvrir, l'insérer dans un autre programme; puis compilez le programme qui se cassera sur une erreur triviale. Ils doivent ensuite utiliser un éditeur de texte pour aller chercher l'erreur, faire fonctionner le code et archiver le binaire. Envoyez-le ensuite quelque part tout en donnant au destinataire l'autorisation de l'exécuter.

Je ne sais pas pour vous, mais je serais un peu ennuyé si mon intervieweur me le demandait et je ne savais pas comment travailler sur Linux.

Vous ne devriez pas vraiment vous soucier de ce qu'ils savent en ce moment , mais de ce qu'ils peuvent apprendre s'ils en ont l'occasion. Apprendre les outils * nix n'est pas trop difficile, mais cela demande un peu de détermination - vous devriez vraiment tester la capacité plutôt que les connaissances.

Cela dépend du niveau d'expérience que vous souhaitez qu'ils aient. SI ce n'est pas pour quelqu'un qui va développer pour les systèmes * nix, et pas non plus pour les administrateurs système * nix, mais juste pour les développeurs réguliers qui ont parfois besoin de travailler sur un système * nix, de quelle expérience ont-ils réellement besoin?

Tout ce dont un développeur pourrait avoir besoin dans des shells * nix (ls, chmod, cat, etc.) pourrait probablement être écrit sur une feuille de triche d'une seule page. Si c'est le cas, l'exigence de connaissances du shell * nix là où elle n'est pas requise peut éliminer certains bons candidats.

Je choisis généralement une tâche simple et demande à la personne d'écrire un script shell sur un tableau blanc.

"Vous avez un répertoire" foo "et un répertoire de sauvegarde" foo_backup ". Écrivez un script shell pour voir ce qui a changé dans" foo "depuis que" foo_backup "a changé.

«Expliquez le processus de connexion sous Linux, avec autant de détails que vous vous sentez à l'aise» est une bonne question. Le processus de connexion implique de changer les utilisateurs, les autorisations et les propriétaires, et beaucoup de philosophie générale Unix. S'ils peuvent expliquer clairement comment et pourquoi il y a un /etc/passwdet /etc/shadow, et comment un utilisateur non privé peut changer son propre mot de passe mais pas les autres ', cela signifie qu'il' obtient 'Unix.

Une autre bonne chose est l'analyse des journaux ou les audits de sécurité rapides. S'ils peuvent ajouter la bande passante totale servie pour un vhost particulier à partir d'un journal Apache, ou trouver s'il y a d'autres utilisateurs dans le système avec un UID de 0, ils sont pratiques sur la ligne de commande.

Et une chose à ne PAS leur faire: ne les faites pas le faire sur papier / tableau blanc. Donnez-leur un système en direct (mais pas d'Internet car c'est presque de la triche) et regardez-les partir. S'ils connaissent les pages de manuel et peuvent créer des expressions multi-canaux à la volée, c'est un bon signe. S'ils ont besoin de Google pour tout, alors leurs compétences sont discutables.

pourquoi leur faire écrire un programme fonctionnel? qu'est-ce qui ne va pas en disant "dites-moi la différence entre grep et sed, ou que fait la commande X? etc. de cette façon, vous pouvez les guider un peu.

S'ils tâtonnent sur la tâche spécifique que vous leur donnez, vous pourriez ne pas penser qu'ils sont intelligents. mais si vous posez des questions générales, vous leur donnez la chance de vous montrer ce qu'ils savent, ce qui peut être substantiel mais d'une manière différente de ce que vous vous demandiez.

Les gourous d'Unix ont des commandes de ligne de commande de base telles que sed, grep etc. dans un doigt et peuvent facilement les utiliser pour atteindre ce qu'ils veulent, en utilisant toutes sortes de citations, des expressions régulières avancées, etc., donc parfois vous voyez le script et pensez qu'il serait plus facile à comprendre étant écrit en chinois;)

Vous pouvez vous attendre à ce que, indépendamment de la programmation shell, ils connaissent au moins un langage de script supplémentaire, tel que Perl.

Ils connaîtraient les configurations internes du système Unix, donc si vous leur demandez de changer la disposition du clavier (fg ajoutez une liaison à droite alt +), ils ne seraient pas confus.

La gestion des packages installés ne poserait également aucun problème. Installation d'Oracle, exécution de 4 serveurs d'applications, chacun avec une autre machine virtuelle Java - également aucun problème. Configuration du réseau virtuel, routage avancé et filtrage des ports, machines virtuelles, etc., gestion de la sécurité - y va également.