Salve a tutti voi, miei cari lettori!
Oggi voglio condividere i miei pensieri su un argomento che mi sta molto a cuore e, forse, discuterne nei commenti.
Mi imbatto abbastanza spesso in articoli sulle cattive pratiche di colloqui per la posizione di programmatore, che a mio avviso sono piuttosto realistiche e, si spera, lette dagli HR delle aziende grandi e piccole.
Nella mia zona, per quanto posso giudicare, c'è richiesta per entità interessanti come gli ingegneri DevOps. Sono tra coloro che non comprendono molto bene questa espressione (sì, sì, metodologia DevOps, ecc.), quindi vedo alcune differenze nei percorsi di sviluppo di questo gruppo di specialisti.
In primo luogo, credo fermamente che ogni persona abbia il proprio ambito di interesse, anche in ambito lavorativo; cioè, a qualcuno piacciono le nuvole, a qualcun altro piace scavare a fondo nei server applicativi, configurare profondamente Java, oppure scrivere codice in Python o, per amor del cielo, codice YAML. Qui entrano in gioco i cosiddetti ingegneri delle infrastrutture, ingegneri di build, Senior Yaml Developer 🙂
Tutto ciò consente, da un lato, di trovare una persona che si adatta al meglio al vostro insieme di compiti, ma dall'altro crea incomprensioni durante i colloqui.
Basandomi sulla mia esperienza personale, dopo aver condotto un certo numero di colloqui e aver partecipato a vari eventi come risponditore, voglio condividere il mio punto di vista su tutto ciò che sta accadendo.
Il primo e, probabilmente, il mio antipattern preferito è il desiderio di avere qualcuno che faccia tutto o di non capire chi sia necessario, guardiamo a una miriade di candidati e lì decideremo. Probabilmente, questo è applicabile a qualsiasi campo, ma ci sono delle particolarità.
Come ho notato, le persone tendono a preferire le offerte di lavoro con la parola DevOps piuttosto che System Administrator, anche se a mio avviso, a livello Senior, i compiti sono massicciamente differenti in questi due ambiti.
Qualsiasi datore di lavoro che realmente ha bisogno di un sistemista scrive nel titolo dell'offerta DevOps, elencando nel corpo della richiesta praticamente tutto, K8S/Java/gradle/oracleDB e così via, mentre in realtà la persona sarà impegnata nella manutenzione di un cluster K8S e nel supporto del stack OracleDB separato dal team.
Beh, quindi, quale interazione c'è tra il formato Developers/Operations?
Successivamente si scopre che non esiste alcun processo di interazione con il team e, in generale, non c'è un reparto operations, e dovrai anche configurare i computer dei programmatori.
Questa opzione in realtà si adatta a una parte dei candidati, ma diciamo che dobbiamo essere onesti, si tratta di un Senior System Administrator, quindi perché non vogliono scriverlo così e cosa c'è di così vergognoso? La differenza di stipendio tra diversi titoli professionali? Ma il budget dell'azienda è uno solo, e come lo chiami, lui navigherà secondo il suo budget.
Beh, ho sentito che ora i candidati automatizzano tutto in fretta e si integrano nello sviluppo del prodotto in Python, non c'è differenza, in ogni caso Python è lo stesso. La differenza nella visione del mondo e negli approcci non viene considerata.
Di solito, io differenzio il livello degli specialisti che arrivano e vedo separatamente le mie problematiche per ciascuno di loro.
Junior — personalmente per me, un Junior DevOps è una persona che ha acquisito una conoscenza intermedia dell'amministrazione di sistema / sviluppo. Qui è piacevole differenziare i forti Linuxisti che vogliono crescere in un nuovo campo, oppure i programmatori che desiderano lavorare bene per altri programmatori. Persone solide, con alcune competenze nel debugging, nella ricerca dei log, oppure con un certo numero di progetti già codificati.
Ho incontrato sia amministratori di sistema che hanno provato qualcosa e vogliono avvicinarsi al cloud, sia quelli che hanno provato frontend, backend e per qualche motivo hanno trovato il loro interesse nei processi DevOps.
A questo livello, mi sconcerta sempre quando iniziano a citare un'enorme gamma di tecnologie, Puppet, Ansible — perché non hai provato tutto? K8S, K3S — quali sono le differenze? Quanti tipi di database conosci? Perché così pochi? Come funziona la crittografia in Java? Soprattutto per coloro che provengono dallo sviluppo, anche se sono risorse molto utili, per loro c'è sempre lavoro in quest'area.
Mi lascia sempre perplesso quando accade qualcosa del genere, la prima cosa che voglio chiedere è — perché??? La seconda cosa che viene in mente è — l'intervistatore è pronto a rispondere a domande su un tale variegato stack? Non desiderano davvero assumere un junior e caricare tutto su di lui?
Spesso questo accade in vari body shop, quando è necessario vendere una persona per un certo progetto e servono più parole accattivanti per il curriculum oppure l'azienda non vuole assumere nessuno, ma guarda semplicemente quali sono i junior disponibili.
Livello Middle
Ci sono diverse estremità secondo me, prima di tutto è difficile probabilmente definire chiaramente cosa rende una persona un mid-level, o si cerca di abbatterla a junior, o si inizia a trattarla come un senior, cercando di conquistarla al prezzo di un mid-level (sì, il mercato decide, niente di personale)
La cosa più sorprendente che ho visto è andare in profondità nel coding, usando Python, tormentando il garbage collector di Java, cioè affrontando temi più specifici, oppure al contrario, rivedere le lacune in conoscenze non utilizzate da tempo, correre tra reti, tipi di driver di sistema, sorridendo e maliziosamente pensando a come una persona possa aver dimenticato tutto questo. E qui accade la parte più interessante!
A livello mid-level, secondo me, un professionista sviluppa un ambito di interesse e una visione personale su ciò con cui vuole lavorare - cavalcare il trend con le tecnologie più recenti, infilando nella scatola qualcosa di all'apparenza allettante, oppure prepararsi per un 'grande' enterprise, addentrandosi nel miglioramento delle performance del codice.
Secondo me vale già la pena chiedere dei processi con cui la persona ha lavorato, chiedere cosa è stato più interessante e cosa no, e basare su queste conoscenze un cluster di domande, mappando necessariamente le domande sul proprio stack. Altrimenti, dopo aver avuto una conversazione affascinante di un'ora o due sulla configurazione di un cluster OpenShift, si rischia di assumere una persona e metterla a lavorare sulla monitorizzazione. Probabilmente piacerà ad entrambe le parti.
Livello Senior
Oh, il mio livello preferito.
Davanti a voi c'è un esperto solido, che si è formato su vari tipi di progetti, una persona che sa già cosa vuole e cosa non le piace particolarmente.
E qui inizia lo spettacolo:
— domande approfondite sull'amministrazione di sistemi (vedi il primo antipattern)
— domande approfondite su Linux in generale, da un'ottica teorica, lontana dalla pratica (la domanda di livello OSI è la top)
— domande accademiche sul coding (perché l'intervistatore stesso non conosce bene l'argomento, è stato semplicemente chiesto di intervistare un devops strano)
Faccio qui una piccola nota. Una volta, durante un colloquio, mi è stato chiesto di scrivere un pezzo di codice. Su un foglietto. Proprio come tutti amano, ogni giorno scrivono, il foglietto è tutto per noi.
Dopo aver affrontato il compito, dopo aver esaminato il mio foglio e trovato la soluzione, è stato emesso il verdetto che l'algoritmo non sarebbe stato ottimale. Ho proposto che l'intervistatore scrivesse il proprio algoritmo, a cui ho ricevuto risposta "Questo non fa parte del colloquio". Ho chiesto un minuto, ho modificato un po' il codice e ho mostrato, chiedendo se così sarebbe stato più veloce o più lento. A ciò ho ricevuto una risposta, passiamo alla prossima domanda. La differenza era nel funzionamento del codice nel ciclo e senza ciclo e avevo preparato una risposta sul perché fosse meglio farlo in quel modo piuttosto che in quest'altro. Beh, dopo questo non avevo più voglia di rispondere alle domande e lavorare con questa persona.
Bisogna tenere in considerazione che siamo tutti diversi e qualsiasi cosa, che per voi può essere insignificante, può spaventare un candidato.
— di solito i professionisti di livello Senior hanno chiaramente descritto il loro stack di lavoro, eppure no, bisogna iniziare a girovagare per cose vicine, per esempio, hai scritto Ansible, ottimo, ma noi usiamo Puppet, ti abbiamo chiamato semplicemente così, dai raccontaci qualcosa su Puppet. Perfetto! Hai lavorato con OpenShift? Noi abbiamo K8s, non conosciamo le differenze, ma la tua esperienza non è rilevante. Meraviglioso!
C'è anche un sottogruppo — personalmente prendo stagisti per farli crescere fino a junior.
Vorrei che tutti capissero che uno stagista è ancora un'entità non completamente formata. Mi spaventa terribilmente quando gli stagisti iniziano a essere trattati come se fossero Junior esperti e poi, con un'espressione soddisfatta, si propone un tirocinio (a volte non retribuito, un incubo!).
Non è necessario.
A mio avviso, uno stagista è o uno studente degli anni superiori, oppure qualcuno che desidera ardentemente "entrare nell'IT".
Con gli studenti è semplice: è ottimo sapere che cosa stanno facendo all'università, cosa hanno fatto da soli, osservare su quali argomenti brillano gli occhi — se brillano, chiedere perché proprio in devops e cosa sanno a riguardo. Sentire la persona e capire se sarà piacevole lavorare con lui, se si desidera insegnare qualcosa a questa persona in particolare.
Con quelli che vogliono "entrare nell'IT", la situazione è un po' più severa — vedere quanto una persona sia autodidatta, cosa ha fatto prima di arrivare a te per il colloquio, qui sarebbe utile controllare GitHub, se ce l'hanno, la densità degli commit e quali esercizi sono stati fatti. Chiedere anche perché devops, visto che nel frontend è più divertente e intrigante?
Infine, vorrei dare ancora una volta un consiglio: chiarite chi vi serve realmente e troverete immediatamente la persona giusta. Identificate le esigenze, considerate lo specialista come tale, scoprire i suoi punti di forza e utilizzarli con successo nel vostro lavoro. Siate attenti all'interlocutore, è venuto da voi per un colloquio, non per una competizione su chi è in grado di superare l'altro.
Fonte: habr.com
