Intervista a qualcuno per le competenze generali di unix [chiuso]

Come testeresti uno sviluppatore che afferma di avere esperienza della shell * nix (solo per essere chiari, non vogliamo testare se qualcuno può svilupparsi su * nix, solo che conoscono la linea di comando).

Stavo pensando di far sì che risolvessero il problema di ottenere informazioni dai file di registro, il che avrebbe comportato alcune nozioni di base come cat, grep, cut, ... combinate con le tubazioni.

Quali altre conoscenze di base vorresti chiedere? Ancora una volta, questo non è per intervistare qualcuno che svilupperà per i sistemi * nix, e non anche per gli amministratori di sistema * nix, ma solo per gli sviluppatori regolari che a volte hanno bisogno di fare un po 'di lavoro su un sistema * nix.

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

• variabili shell (come impostare / ottenere + conoscenza di quelli speciali come PATH)
• reindirizzamento della shell (acquisizione dell'output di un programma)
• pipe (l'estrazione di alcune informazioni dal file di registro è un esempio eccellente)
• controllo di 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 facilmente 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 " conoscono la loro linea di comando " o semplicemente dicono "assolutamente no!".

Chiedi semplicemente se il candidato è disposto a lavorare su una workstation Unix e lascia che ti dica fino a che punto può superare bash. Alla fine nominerà alcuni comandi; il maggior numero di quelli ovvi sono cd, cat, moreo less, vio emacs, grep, awk, sed. Ascolta attentamente se menziona man.

Se è per lo sviluppo, dovrebbe avere familiarità con makee Makefile, e un po 'l'interfaccia a riga di comando controllo del codice sorgente ( svn, git, cleartool, hg, cvs...)

Perché farlo

Le shell * nix (e altre shell del sistema operativo, prima guerra mondiale) sono ambienti di lavoro molto profondi e ampi. È possibile che qualcuno passi anni lavorando lì e utilizzi solo una percentuale molto piccola della capacità delle conchiglie.

Se non ti aspetti che la persona a) programma shell, o b) amministrare il sistema dalla shell, allora perché è importante? Tutto ciò che verrà fatto sarà ad un livello così basilare che un utile cheat sheet * nix compenserà più che altro la "mancanza di abilità".

Dalla parte superiore della mia testa probabilmente chiederei loro due cose:

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

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

Chiaramente, il primo ti fornirà un'indicazione di quanto siano approfondite le conoscenze del richiedente sulla linea di comando. Se ha lavorato per anni su un * nix, non ti avrebbe semplicemente detto che era orgoglioso di aver corso un grep. Non aspettarti che ricordino esattamente i comandi (ci sono sempre delle manpage per quello), ma l'idea generale di quello che hanno fatto.

La seconda domanda invece verifica se capiscono in cosa è veramente brava la linea di comando e per cosa 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 della visione del richiedente al di fuori della casella * nix, inoltre è abbastanza aperta da poter (e dovrebbe) segnare con le sue conoscenze. (Niente di peggio che rispondere a qualcosa come "uh .. windows ha quelle finestre")

Dipende da cosa vuoi che facciano.

Per ottenere informazioni dai file di registro tuo suggerimento per cat + grep ha perfettamente senso. Aggiungerei ls, cd e meno / più a quello.

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

Consiglierei 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 usare questi strumenti per prendere un po 'di codice da un file senza aprirlo, inserirlo in un altro programma; quindi compilare il programma che si interromperà per qualche banale errore. Devono quindi utilizzare un editor di testo per accedere e trovare l'errore, far funzionare il codice e archiviare il file binario. Quindi spediscilo da qualche parte mentre dai le autorizzazioni al destinatario per eseguirlo.

Non so te, ma sarei un po 'seccato se il mio intervistatore mi chiedesse e non sapessi come lavorare su Linux.

Non dovresti davvero preoccuparti di ciò che sanno in questo momento , ma di ciò che possono imparare se ne viene data 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 desideri che abbiano. SE questo non è per qualcuno che svilupperà per i sistemi * nix, e non anche per gli amministratori di sistema * nix, ma solo per gli sviluppatori regolari che a volte hanno bisogno di fare un po 'di lavoro su un sistema * nix, di quanta esperienza hanno effettivamente bisogno?

Tutto ciò di cui uno sviluppatore potrebbe aver bisogno in * nix shell (ls, chmod, cat ecc.) Potrebbe probabilmente essere scritto su un unico cheat sheet. In tal caso, richiedere * nix conoscenza della shell dove non è necessario potrebbe eliminare alcuni buoni candidati.

Di solito scelgo un compito semplice e chiedo alla persona di scrivere uno script 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 "da quando è cambiato" foo_backup ".

'Spiega il processo di login in Linux, con tutti i dettagli che ti senti a tuo agio' è una buona domanda. Il processo di accesso coinvolge il passaggio di utenti, autorizzazioni e proprietà e molta filosofia generale di 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 quella di altri, ciò significa che "ottengono" Unix.

Un altro valido è qualsiasi cosa con analisi dei log o rapidi controlli di sicurezza. Se riescono a sommare la larghezza di banda totale distribuita per un particolare vhost da un registro Apache, o scoprire se ci sono altri utenti nel sistema con un uid di 0, sono utili sulla riga 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 imbroglio) e guardali andare via. Se conoscono le pagine man e sanno costruire espressioni multi-pipe al volo, questo è un buon segno. Se hanno bisogno di google per tutto, allora il loro skillset è discutibile.

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

se armeggiano sul compito specifico che gli dai, potresti non pensare che siano intelligenti. ma se fai domande generali, dai loro la possibilità di mostrarti ciò che sanno, che può essere sostanziale ma in modo diverso da quello che ti stavi chiedendo.

I guru di Unix hanno comandi a riga di comando 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 pensi che sarebbe più facile da capire essendo scritto in cinese;)

Puoi aspettarti che, indipendentemente dalla programmazione della shell, conosceranno almeno un linguaggio di script aggiuntivo, come Perl.

Conoscerebbero gli interni di configurazione del sistema Unix, quindi se chiedi loro di cambiare il layout della tastiera (fg aggiungi un po 'di rilegatura a destra alt +) non verrebbero confusi.

Anche la gestione dei pacchetti installati non sarebbe un problema. L'installazione di Oracle, l'esecuzione di 4 server applicazioni, ciascuno con altra JVM - anche nessun problema. Anche la configurazione della rete virtuale, il routing avanzato e il filtraggio delle porte, le macchine virtuali ecc., La gestione della sicurezza, vanno anche lì.