Come intervistare un candidato amministratore di sistema? [chiuso]

Che tipo di domande faresti e quali scenari descriveresti, che tipo di risposte cercheresti?

Non faccio domande specifiche. Vorrei sapere quale strategia di intervista è utile per selezionare i candidati qualificati per il lavoro.

Faccio domande in 3 categorie:

• Conoscenze tecniche - Voglio assicurarmi che il candidato sappia cosa dovrebbe sapere. Ad esempio, dimmi la differenza tra RAID 0, RAID 1, RAID 5, RAID 1 + 0 e RAID 0 + 1. Se un amministratore di Servizi directory AD, indicami i ruoli FSMO a livello di foresta e dominio e cosa fanno ciascuno di essi. Inoltre, è qui che chiedo a quale tecnologia siano interessati. Costruiscono robot sul lato? Buono! Programmano i robot detti? Veramente? Quindi ho qualcuno che sa fare un po 'di programmazione e conosce i problemi della risoluzione dei problemi. Eccezionale! Cose del genere.
• Personalità : faccio domande su come gestiranno diversi scenari. Situazioni come "Il PM si rende conto che c'è stato un errore nel programma. Sai che l'errore è colpa del PM. Quell'errore ti farà lavorare due fine settimana schiena contro schiena. Come lo gestisci?" Fondamentalmente domande che rivelano come pensa il candidato e se sanno o meno cosa fare per far parte di una squadra. Questo non eliminerà le persone che conoscono le risposte giuste e non le fanno, ma eliminerà le persone che non hanno idea di come giocare bene con gli altri. Faccio anche domande sul coinvolgimento della comunità.
• Esperienza precedente - Di solito chiedo al candidato di darmi una situazione o un progetto che in passato sono andati bene dove erano una parte importante. Voglio sapere quali sfide hanno dovuto affrontare e come le hanno gestite. Chiedo anche di darmi una situazione in cui le cose non sono andate bene. Quali sono state le lezioni apprese da quel candidato? Che cosa avrebbe potuto fare il candidato, pensando col senno di poi, per invertire eventualmente la situazione (e se il candidato non poteva, il candidato lo riconosce).

Questa risposta copre le tre aree principali che devono essere esaminate. Tuttavia, una cosa che deve essere consentita, in particolare nei negozi più piccoli in cui si prevede che le persone dell'infrastruttura siano multidisciplinari, è porre domande tecniche di portata molto ampia e alle quali è possibile rispondere a diversi livelli di astrazione a seconda del competenza del candidato. Ciò ti consente di avere un'idea di ciò di cui ciascuno è capace e ti consente di dimostrare la loro competenza specifica, consentendoti comunque di confrontare direttamente le risposte dei diversi candidati.

Una grande domanda che mi è stata posta una volta è:

Immagina di averti collegato a una macchina qui e di aver aperto un terminale. Scrivi wget http://www.google.com/. Che succede?

Io, con il mio pregiudizio per la rete, ho risposto iniziando con la risoluzione DNS, passando alla configurazione proxy e quindi alla decisione di routing e alla creazione di una connessione TCP; un altro candidato ha risposto in termini di conversazione HTTP. Quando chiesi all'intervistatore quale fosse la risposta migliore che avesse sentito, la sua risposta fu:

"Beh, è ​​iniziato con l'interruzione della tastiera ..."

Le domande tecniche sono importanti e il metodo di risposta è importante quasi quanto avere la risposta corretta. (l'ultima cosa di cui il reparto IT ha bisogno è qualcuno che sabota la sua buona volontà in tutta l'organizzazione con ostilità e condiscendenza).

Ma ecco la mia domanda più importante -

La mia prima intervista con una "vera" società IT è terminata quando ho avuto una domanda tecnica alla quale ho risposto "Non lo so".

La risposta è stata: "Fantastico, quando puoi iniziare?"

Ero appena uscito dal college e il mio intervistatore voleva sapere che ero in grado di riconoscere i limiti della mia conoscenza / esperienza. È qualcosa che ho tenuto con me e penso che sia l'attributo più importante per un amministratore di sistema. La conoscenza specifica è eccezionale e ti darà un vantaggio, ma se non puoi ammettere di non sapere, progredirai molto lentamente, se non del tutto.

Spesso intervisto le persone per posizioni di livello base, il che significa che non posso discutere una storia lavorativa significativa. Di solito parlo di progetti personali, ma due domande che faccio sempre sono "Puoi descrivermi la tua rete domestica?" e "Come si esegue il backup dei computer di casa?" Una persona veramente interessata potrebbe stare a una lavagna per 30 minuti a discuterne, a occuparsi di indirizzi IP, sicurezza wireless, ecc. Un povero candidato scrollerà le spalle e ti dirà che suo fratello lo ha installato.

Non porre domande "banali" - domande con una sola risposta altamente specifica. Le persone possono dimenticare quel genere di cose quando sono sotto stress. Se il loro lavoro richiede loro di sapere quale pin su un'interfaccia V.35 viene utilizzato per trasmettere dati, possono cercarlo quando hanno il lavoro. Le domande generali ti aiutano a capire di più sui candidati che sulle curiosità ... Non ci piacciono nemmeno i rompicapo.

La pratica dell'amministrazione di sistemi e reti

Poni diversi tipi di domande che ti aiuteranno a conoscere il candidato. E come si adatteranno al tuo gruppo di lavoro. Nei tempi antichi. La maggior parte delle SA erano fisici, astronomi, matematici e ingegneri. Perché? Probabilmente perché ha avuto eccellenti capacità di risoluzione dei problemi e ha preso ottime note.

Alcune domande da porre:

Tecnico

• Descrivimi, come se non sapessi nulla, come funziona una rete TCP / IP.
• Descrivimi, come se non sapessi nulla di come funziona un computer (un dispositivo Von-Neumann di base)
• Disegnami un semplice diagramma di rete: hai 20 sistemi, 1 router, 5 switch, 2 server e un piccolo blocco IP. Partire.
• Sulla base della pubblicazione di lavoro, cosa ti aspetti di fare qui?
• Descrivimi cosa speri di realizzare qui.
• Qual è il metodo migliore per mantenere aggiornata la documentazione?
• Qual è il peggior incidente di disaster recovery in cui sei mai stato coinvolto? Dimmi cosa hai fatto.
• Perché ti piace essere una SA?
• Come valuteresti te stesso come una SA?

Attività commerciale

• Credi che l'IT guidi il business o che il business guidi l'IT?
• Cosa ne pensi del nostro attuale modello di business?
• Cosa potresti fare per renderci più redditizi?
• Come si interfaccia l'IT con la nostra azienda?

Personale

• Qual è la tua battuta preferita?
• Quale libro dovrei leggere domani? Perché? (poi vai in biblioteca e sfoglialo)
• Chi è Thomas Limoncelli? (eh eh, GOTCHA!)

Quasi tutti possono avere un bell'aspetto sulla carta. Alcune persone possono farsi strada attraverso discussioni tecniche. E molte persone sono poveri oratori pubblici. È necessario porre domande aperte. No "Sì o No", osserva i loro processi di pensiero e le loro capacità di risoluzione dei problemi. I più significativi sono le metafore che usano per descrivere processi complessi.

Assumere una SA è un compito molto difficile. È improbabile che un colloquio tecnico descriva chi assumerai. Non è molto quello che sanno ora. È ciò che sono disposti a imparare e quanto velocemente impareranno e applicheranno.

Se fossi parte di un panel di interviste per un amministratore di sistema presso una società di software in cui ci si sarebbe aspettati che il software della società fosse in esecuzione sui loro server, sarei interessato a sapere cosa si aspetta il candidato dagli sviluppatori. Come interagiscono con gli sviluppatori: "noi vs loro" o "tutti insieme con competenze diverse"? Hanno esperienza di una situazione in cui sviluppo e IT (o come viene chiamato il dipartimento) sono finiti in conflitto e come è stato risolto? Sono interessati ad acquisire una certa consapevolezza della tecnologia e della terminologia utilizzate dagli sviluppatori e sono disposti ad aiutare a educare gli sviluppatori nelle proprie aree di competenza, in modo che tutti possano comunicare meglio?

Certamente questo sarebbe in parte per soddisfare il mio interesse per la relazione tra amministratori di sistema e sviluppatori, nonché per giudicare il candidato.

Assicurati che non sia solo un libro intelligente. Sento che è bello mettere alla prova una specie di prova.

Le domande sulla "lavagna vuota" sono quelle che separano davvero le pecore dalle capre. "Questo è il limite della rete; questa è un'app Web che gira su IIS, questo è il tuo backend SQL; questa è una scatola UNIX con un altro servizio black-box su di essa. Come si rende tollerante ai guasti, sicuro, ecc.? "

L'unica risposta che ho avuto a questo da un candidato è stato un polizioso "stai scherzando, vero?"

Sto assumendo amministratori Linux per una startup, quindi le mie domande sono quelle che dovrebbero prendere in giro l'esperienza dall'inesperienza. Schermo del telefono:

1. Nomina quante più directory di livello superiore in un moderno sistema linux (FHS) puoi (ce ne sono circa 20, nessuno ne ottiene più del 75%, anche quelli che se ne occupano ogni giorno)?
2. A cosa serve la variabile d'ambiente PATH?
3. Nomina una persona famosa per il suo coinvolgimento con software open source / gratuito (diverso da Linus Torvalds) (risposta più frequente: Richard Stallman)

Per l'intervista telefonica, provo a farli parlare dei loro precedenti progetti, della rete domestica, di quanti computer hanno e di cosa fanno con loro, ecc.

Di persona, mi piace dare loro un vero problema che sto affrontando e chiedere loro di risolverlo per me. Confronterò la loro risposta con qualunque soluzione stia già pensando. Se la loro risposta è migliore, il mio progetto procede. Se la loro risposta è peggiore, il processo di intervista è andato avanti. Ad ogni modo, posso rimanere impegnato con i miei progetti e perfezionare o scartare candidati o idee.

Altrimenti sta parlando più in profondità di ciò che si aspettano da un ambiente di lavoro, cercando di scoprire se sono un 9-5er o se effettivamente si preoccupano di quello che stanno facendo --- in assenza di altri fattori, i tipi di Linux tendono preoccuparsi (anche se possono fare schifo) e gli ingegneri di rete tendono ad essere 9-5 (che possono anche fare schifo) ... Solo la mia esperienza.

Supponendo che passino tutto questo, mi piace anche installarli con una nuova scatola Linux su una rete isolata la cui configurazione di rete è errata, con strane apparecchiature collegate e un cavo allentato per l'ultimo "fanculo", e farli recuperare in linea. Li lascio soli e periodicamente torno a controllarli, anche se potrei facilmente passare il mouse se volessi essere un duro per questo.

In genere sono necessari circa 30 minuti per qualcuno che ha superato il resto dell'intervista per entrare in questo ambiente totalmente sconosciuto e farlo funzionare di nuovo. È un fantastico test del mondo reale su quanto tempo impiegano per risolvere un ambiente completamente nuovo, completamente rotto.

Dopo un'attenta selezione del curriculum, avevo ancora 20 candidati. 20 persone di ~ 150 hanno superato la prima selezione che mi ha permesso di trascorrere tre-quattro ore per intervistare ognuna di esse. I principali criteri di selezione per me erano:

• capacità di allenamento in un luogo
• capacità di scegliere l'approccio ottimale
• capacità di raccogliere e risolvere un problema in una situazione non standard
• una buona base di conoscenze: ciò significa che il candidato dovrebbe conoscere la storia delle tecniche informatiche, possedere la teoria ad alto livello, sapendo non solo " cosa fare", ma anche sapere "perché" .

Per conoscere la loro abilità nel raccogliere e risolvere un problema in una situazione non standard, mi è stato chiesto loro, ad esempio: "Come rovinare un sistema Windows, se hai accesso fisico al computer, ma non ne hai password dell'account? " e, successivamente, ho chiesto loro "Come patchare il sistema viziato?". Ho fornito alcuni esempi di azione dei virus e ho chiesto cosa avrebbero fatto per prevenire danni e restituire funzionalità e dati persi con il minor numero possibile di strumenti, e più domande sull'uso di strumenti non standard. Una volta ho chiesto a un candidato: "Quale domanda faresti, se mi intervistassi, per sapere quanto sono bravo in situazioni non standard?" :-)

Per sapere quanto sono bravi a trovare un approccio ottimale, ho dato loro un po 'di pratica nella configurazione di web, mail server o gateway di rete per parametri particolari ("Ho bisogno che sia un web server molto veloce per un piccolo numero di client connessi ad esso, e sì, voglio un linguaggio di scripting lato server su di esso, per mostrarmi alcune statistiche, cosa dovrei scegliere e perché fai cosa è meglio? Potresti mostrarmi sul nostro server di test, se hai ti restano 20 minuti? ")

La capacità di allenarsi in un posto - non è davvero facile da controllare, ma ho chiesto ad alcuni candidati di creare un file di configurazione di esempio, o uno script, e poi ho dato loro un piccolo suggerimento per vedere se potevano farlo meglio dopo.

La base di conoscenza - una delle mie parti preferite: cos'è l'OSI? Perché TCP / IP chiamato " stack di protocollo "? Quali eroi dell'informatica conosci? Che cos'è il registro di Windows? E i sistemi simili a Unix?

E cosa molto importante: DEVONO amare il loro lavoro! "Hai letto alcuni degli autori classici, come K&R?", "Da quanto tempo ti interessi molto nelle tecniche informatiche?", "Con cosa hai iniziato a studiare i computer?", "Hai computer di prova / piccola rete a casa?" (se è vero, è un ottimo segno!).

La lista di K. Brian Kelley è fantastica, ma vorrei sottolineare che è importante porre domande sulla risoluzione dei problemi. Scegli un paio di problemi difficili che hai affrontato e chiedi al candidato di dirti come avrebbero cercato di risolvere il problema. Conoscere molte conoscenze tecniche è importante, ma secondo me è molto importante riuscire a risolvere i problemi con un approccio metodico.

Mi piace fare domande che sono l'opposto della forma normale di quella stessa domanda. Ad esempio, nello sviluppo web una domanda comune è "quando si POST un modulo anziché ottenere?" Ma chiedo il contrario: "Quando usi GET anziché POST?" Ciò costringe le persone a pensare agli svantaggi anziché ai vantaggi o a considerare quali compromessi stanno facendo quando prendono una decisione.

Una domanda rappresentativa per l'IT potrebbe comportare due scelte tecnologiche simili; forse una domanda del tipo "Quando sceglieresti un gruppo di lavoro Windows anziché un dominio?"

Tengo sempre un appunto a penna e carta di tutte le cose strane e bizzarre che incontro durante il normale lavoro quotidiano, non il genere di cose che si trovano nei libri sul "come ...". Posso quindi chiamare una o due di queste situazioni in un'intervista, spesso più per iniziare una conversazione che come test, sono più interessato a COME gestiranno la situazione che se conoscessero la risposta. Faccio sempre una domanda sulla tecnologia "bleeding edge" per vedere se sono interessati alle nuove tecnologie (o TROPPO interessati ai fatti).

Un po 'fuori tema - ma una storia interessante dal suo blog ufficiale di Google:

Come sono arrivato a Google (cap. 1)

I nostri ingegneri, tuttavia, tendono a trovare percorsi più vari e talvolta più occasionali. Alcuni vengono reclutati fuori dalla scuola di specializzazione, o da amici o ex colleghi. Altri inviano semplicemente i loro curriculum a jobs@google.com. Per alcuni ingegneri, tuttavia, il percorso è stato più interessante.

Si prega di leggere il resto del post sul blog su quel metodo non convenzionale, ma - secondo me - valido per assumere le persone giuste.

Durante l'intervista, non sto davvero cercando di vedere se un candidato è in grado di rispondere a domande tecniche specifiche. Penso che sia più importante che un candidato sappia dove andare per trovare una risposta.

Un candidato non dovrebbe semplicemente dire "Non lo so". Sto cercando una risposta più simile a "Vorrei Google che" o qualcosa di simile a "Sono un membro di [ACM | SAGE | LOPSA | Server Fault] e vorrei controllare il sito Web [mailing list archives | ] per trovare aiuto per rispondere a questa domanda ".

Scoprire dove si rivolgerà un candidato quando non conoscono la risposta a una domanda è un buon modo per farsi un'idea delle proprie capacità.

Ho intervistato persone sia come dipendente di una grande azienda sia come proprietario di una piccola azienda. La qualità numero uno che cerco è una personalità equilibrata tra "visionario" e "armeggiare".

Se hai troppi visionari, ottieni un sistema costruito come Twitter. (Se non l'hai letto, metà delle loro prime descrizioni delle loro istruzioni di ingegneria porteranno la maggior parte dei tipi di amministratori a fare un facepalm e andare al bar.) Se hai troppi armeggi, hai 200 fantastici sistemi in vari stati di sfacelo dappertutto e tutti i tuoi siti web sono in esecuzione su una scatola di dieci anni con BSD 4.2 sotto la scrivania del sysadmin.

La persona migliore che abbia mai assunto era un ragazzo con una doppia laurea in Religione e Filosofia presso un piccolo college privato nel Connecticut. Era creativo, dedicato, intelligente e perseverante di fronte alle avversità. Stava controllando il codice tramite cellulare legato fino a un'ora prima della nascita della sua prima figlia. Ha continuato a fare cose straordinarie ed è ora il leader della comunità di un importante framework PHP. Bravo ragazzo.

La persona peggiore con cui abbia mai lavorato era un ragazzo molto impegnato nell'organizzazione per cui lavoravamo entrambi. Suo padre lavorava lì e lui lavorava lì dal liceo. Ci sono state almeno una dozzina di volte in cui gli ho quasi detto che se non gli piaceva il suo lavoro, avrebbe dovuto abbandonare e salvare il resto di noi dal mal di testa. Era un armeggiatore. E per coincidenza, un grande fan di BSD e Gentoo.

Oltre a ciò, qualsiasi amministratore di sistema in un ruolo * nix dovrebbe essere in grado di descrivere perché questo è divertente .

Chiedo sempre al candidato di valutarsi da 1 a 10 su alcuni aspetti della posizione. Quindi, sulla base di quella risposta, faccio domande che corrispondono al livello che si sono posti.

Se la posizione richiede l'uso di script, chiederò sempre degli esempi e poi in una seconda intervista fornirò loro uno scenario e chiederò loro di automatizzare la loro risposta. Devo solo essere sicuro che il loro approccio non sia il cookie cutter.