Intervistare qualcuno per le abilità generali di unix [chiuso]

Dalla mia esperienza personale, lo sviluppatore che lavora su un sistema * nix deve sapere:

• variabili di shell (come impostare / ottenere + conoscenza di quelle speciali come PATH)
• reindirizzamento della shell (cattura dell'output di un programma)
• pipe (l'estrazione di alcune informazioni dal file di log è un esempio eccellente)
• controllo del processo (ps, nice / renice, kill)
• diritti di accesso ai file (ls / chmod / chown / chattr)
• utenti (ma principalmente nel contesto di file / processi, ovvero: questo processo è in grado di accedere a questo file? perché può / non può?)

... e come bonus:

• avvio / arresto dei servizi di sistema

Tale set di abilità consente di svolgere con facilità la maggior parte delle attività relative agli sviluppatori.

Dalla mia esperienza con i miei numerosi colleghi da quando ho iniziato a lavorare, nessuno vuole fingere la conoscenza di Unix: o loro " conoscono la loro linea di comando " o semplicemente dicono "no way!" .

Basta chiedere se il candidato è disposto a lavorare su una workstation Unix e lasciare che ti dica fino a che punto può passare attraverso bash. Alla fine nominerà alcuni comandi; le più ovvie sono cd , cat , more o less , vi o emacs , grep , awk , sed . Ascolta attentamente se menziona man .

Se è in via di sviluppo, dovrebbe avere familiarità con make e Makefile, e qualche interfaccia di comando a riga di comando sorgente ( svn , git , cleartool , hg , cvs ... )

Perché farlo?

Le shell * nix (e altre shell OS, fww) sono ambienti di lavoro molto profondi e ampi. È possibile che qualcuno impieghi anni a lavorare lì e utilizzare solo una piccola percentuale della capacità delle shell.

Se non ti aspetti che la persona abbia a) un programma di shell, o b) amministri il sistema dalla shell, allora perché è importante? Tutto ciò che viene fatto sarà a un livello così elementare che un utile trucchetto * nix compenserà la "mancanza di abilità".

In cima alla mia testa probabilmente chiederei loro due cose:

1. Quando hai usato la linea di comando * nix in precedenza, hai riscontrato un caso in cui un comando ben ponderato ti ha salvato un sacco di tempo? Se è così, elaborati.

2. Si prega di spiegare le principali differenze tra la linea di comando * nix e un desktop Windows standard. Quali sono i vantaggi e gli svantaggi di ciascuno?

Chiaramente, il primo ti darà un'indicazione di quanto profonda sia la conoscenza del candidato sulla linea di comando. Se ha lavorato per anni su un * nix, non ti dirà semplicemente che era orgoglioso di aver corso un grep. Non aspettarti che ricordino esattamente i comandi esatti (ci sono sempre manpage per questo), ma l'idea generale di cosa hanno fatto.

La seconda domanda controlla invece se capiscono a cosa serve veramente la linea di comando e per quello che non è uno strumento adatto. È facile imparare a usare un martello, ma è molto più difficile passare a un altro strumento nel caso in cui il martello non sia adatto. Quindi questa domanda ti dà una buona indicazione del punto di vista del candidato al di fuori della casella * nix, in più è sufficientemente aperto in modo che possa (e dovrebbe) segnare con le sue conoscenze. (Niente di peggio che rispondere a qualcosa come "uh .. windows ha quelle finestre")

Dipende da ciò che vuoi che facciano.

Per ottenere informazioni dai file di log il tuo suggerimento per cat + grep ha perfettamente senso. Aggiungerei ls, cd e less / more a questo.

Se ti aspetti che facciano anche alcune modifiche minori (ad esempio nei file di configurazione), allora avrebbe senso aggiungere test per vi e / o emacs e per cose come cp / mv / rm / mkdir.

Consiglio di conoscere emacs o vi / m, tar, sed, e / f / grep, i vari compilatori, alcuni script di shell. Forse eseguire un test in cui devono utilizzare questi strumenti per afferrare del codice da un file senza aprirlo, inserirlo in un altro programma; quindi compila il programma che si interromperà su qualche errore banale. Devono quindi utilizzare un editor di testo per entrare e trovare l'errore, far funzionare il codice e archiviare il file binario. Poi spediscilo da qualche parte mentre dai il permesso al destinatario di eseguirlo.

Non so voi, ma mi arrabbierò se il mio intervistatore mi ha chiesto e non sapevo come lavorare su Linux.

Non dovresti davvero preoccuparti di ciò che sanno esattamente ora , ma cosa possono imparare se ne hanno la possibilità. Imparare gli strumenti * nix non è troppo difficile ma richiede un po 'di determinazione: dovresti davvero testare l'abilità piuttosto che la conoscenza.

Dipende dal livello di esperienza che vuoi che abbiano. Se questo non è per qualcuno che svilupperà per sistemi * nix, e non per gli amministratori di sistema * nix, ma solo per gli sviluppatori regolari che a volte hanno bisogno di lavorare su un sistema * nix, quanta esperienza hanno effettivamente bisogno?

Qualcosa che uno sviluppatore di questo tipo potrebbe aver bisogno di shell * nix (ls, chmod, cat, ecc.) potrebbe probabilmente essere scritto su un foglio di cheat di una singola pagina. In tal caso, richiedere la conoscenza della shell * nix dove non è richiesto potrebbe eliminare alcuni buoni candidati.

Solitamente scelgo un compito semplice e chiedo alla persona di scrivere uno script di shell su una lavagna.

"Hai una directory" foo "e una directory di backup" foo_backup ". Scrivi uno script di shell per vedere cosa è cambiato in" foo "dato che" foo_backup "è cambiato.

'Spiega il processo di login in Linux, con tutti i dettagli che ritieni più comodi' è una buona domanda. Il processo di login comporta il passaggio di utenti, permessi e proprietà e molta filosofia generale Unix. Se possono spiegare chiaramente come e perché c'è un /etc/passwd e /etc/shadow , e come un utente non privato può cambiare la propria password ma non le altre ', significa che' ottengono 'Unix.

Un altro buon esempio è l'analisi del log o i controlli di sicurezza rapidi. Se riescono a sommare la larghezza di banda totale offerta per un particolare vhost da un log di Apache, o scoprire se ci sono altri utenti nel sistema con un uid di 0, sono a portata di mano sulla linea di comando.

E una cosa da NON fare a loro: non farli fare su carta / lavagna. Dai loro un sistema live (ma niente internet perché è quasi un inganno) e guardali andare. Se sanno come orientarsi tra le pagine man e possono creare al volo le espressioni multi-pipe, è un buon segno. Se hanno bisogno di google per tutto, allora il loro skillset è discutibile.

perché farli scrivere un programma funzionale? cosa c'è di sbagliato nel dire "dimmi la differenza tra grep e sed, o cosa fa il comando X? ecc. In questo modo, puoi guidarli un po '.

se non riescono a capire l'incarico specifico che gli dai, potresti non pensare che siano intelligenti. ma se fai domande di carattere generale, dai loro la possibilità di mostrarti quello che sanno, che può essere sostanziale ma in un modo diverso da quello che ti stavi chiedendo.

I guru Unix hanno comandi di linea di base come sed, grep ecc in un dito e possono facilmente usarli per ottenere ciò che vogliono, usando tutti i tipi di virgolette, espressioni regolari avanzate ecc. quindi a volte vedi lo script e pensa sarebbe più facile capire di essere scritto in cinese;)

Ci si può aspettare che, indipendentemente dalla programmazione della shell, conoscano almeno un ulteriore linguaggio di scripting, come Perl.

Potrebbero conoscere gli interni di configurazione del sistema Unix, quindi se chiedete loro di cambiare il layout della tastiera (per esempio aggiungete un collegamento a destra + alt) non saranno confusi.

Anche la gestione dei pacchetti installati non sarebbe un problema. L'installazione di Oracle, con 4 server applicativi, ciascuno con JVM, non presenta alcun problema. Configurazione della rete virtuale, routing avanzato e filtraggio delle porte, macchine virtuali ecc., Gestione della sicurezza - anche lì.