Salve a tutti voi, miei cari lettori!
Oggi voglio condividere i miei pensieri su un tema che mi sta a cuore da tempo e, possibilmente, discuterne nei commenti.
Spesso mi imbatto in articoli sulle cattive pratiche durante i colloqui per la posizione di programmatore, che a mio avviso sono piuttosto pertinenti e, spero, leggibili dai reparti HR delle aziende, siano esse grandi o piccole.
Nelle nostre zone, per quanto posso giudicare, c'è una richiesta per figure professionali interessanti come quella dell'ingegnere DevOps. Io personalmente non percepisco molto questa espressione (sì, la metodologia DevOps, ecc.), quindi vedo una certa differenza nei percorsi di sviluppo per questo gruppo di specialisti.
In primo luogo, credo fermamente che ogni persona abbia il proprio cerchio di interessi, anche nell'ambito lavorativo; cioè, a qualcuno piacciono le nuvole, qualcuno ama scavare a fondo nei server applicativi, configurare dettagliatamente Java, mentre altri preferiscono scrivere codice in Python o, Dio non voglia, codice yaml. Questo porta alla nascita di figure professionali come Infrastructure engineer, Build engineer, Senior Yaml Developer 🙂
Tutto ciò consente, da un lato, di trovare la persona più adatta per il vostro insieme di compiti, dall'altro crea incomprensioni durante i colloqui.
Basandomi sulla mia esperienza personale, ho condotto decine di colloqui e ho partecipato a vari eventi come intervistato; voglio condividere la mia visione su tutto ciò che sta accadendo.
Il primo e probabilmente il mio antipattern preferito è il desiderio di trovare qualcuno che faccia tutto, o l'incertezza su chi sia realmente necessario; vediamo un sacco di candidati e poi capiremo. Probabilmente questo si applica a qualsiasi settore, ma qui ci sono delle specificità.
Come ho notato, le persone sono più attratte da offerte di lavoro con la parola DevOps piuttosto che da quelle di System Administrator, anche se a livello Senior le aree di responsabilità sono estremamente diverse tra queste due discipline.
Qualsiasi datore di lavoro che ha realmente bisogno di un amministratore di sistema scrive nel titolo dell'offerta DevOps, elencando nel corpo della richiesta tutto ciò che viene in mente, K8S/Java/gradle/oracleDB, e così via, anche se internamente la persona si occuperà del supporto del cluster K8S e del stack OracleDB, staccato dal team.
Quindi quale sarà l'interazione nel formato Developers / Operations?
Si scopre che non esiste un processo di interazione con il team e, in generale, non c'è un reparto di operazioni, e dovrete anche configurarvi i computer degli sviluppatori.
Questa opzione, in realtà, si adatta a parte dei candidati, ma siamo sinceri, si tratta di un Senior System Administrator, quindi perché non vogliono scriverlo così e cosa c'è di vergognoso in questo? La differenza di stipendio tra i diversi nomi delle professioni? Ma il budget dell'azienda è uno, e qualunque nome si dia alla nave, essa navigherà secondo il suo budget.
E ho anche sentito che ora il candidato automatizza tutto rapidamente e si integra nello sviluppo del prodotto in Python; che differenza fa, in ogni luogo il Python è lo stesso. La differenza nella visione del mondo e negli approcci non viene considerata.
Di solito, poi differenzio il livello dei professionisti che arrivano e vedo le mie difficoltà specifiche per ciascuno di essi.
Junior — per me, un Junior DevOps è una persona che ha raggiunto un livello intermedio nella gestione di sistemi e nello sviluppo. È interessante differenziare tra gli appassionati di Linux che desiderano evolversi in un nuovo campo e gli sviluppatori che vogliono contribuire positivamente per i loro colleghi. Persone forti, con alcune competenze nel debug, nella ricerca di log, o con un certo numero di progetti realizzati.
Ho incontrato sia sistemisti che hanno provato qualcosa e desiderano avvicinarsi al cloud, sia persone che hanno esplorato il front-end e il back-end ma per vari motivi hanno trovato interesse nei processi DevOps.
A questo livello, mi confonde sempre quando le persone iniziano a elencare un enorme stack tecnologico, come Puppet e Ansible — perché non hai provato tutto? K8S, K3S — qual è la differenza? Quanti tipi di database conosci? Perché così pochi? Come funziona la crittografia in Java? Soprattutto quelli che provengono dallo sviluppo, sebbene siano figure molto utili, trovano sempre lavoro in questo campo.
Mi lascia sempre perplesso quando succedono cose del genere; la prima cosa che voglio chiedere è: perché??? La seconda è: l'intervistatore è davvero pronto a rispondere a domande su un così vario stack tecnologico? Non vogliono davvero assumere un junior e scaricare tutto su di lui?
Questo succede spesso in vari bodyshop, quando devono vendere una persona per un progetto e hanno bisogno di più parole accattivanti nel curriculum, oppure l'azienda non vuole assumere nessuno e guarda solo cosa offre il mercato dei junior.
Livello Middle
Ci sono diverse estremità, a mio avviso; prima di tutto, è difficile definire chiaramente se una persona è pronta per il livello medio; a volte cercano di abbassarla al livello junior, altre volte la trattano come un senior, cercando di ottenere un senior al prezzo di un middle (sì, finalmente decide il mercato, niente di personale).
La cosa più sorprendente che ho visto è tuffarsi profondamente nel coding, programmando in Python, gestendo il garbage collector di Java, ecco, questi sono argomenti più specifici, oppure scoprire lacune in conoscenze mai usate, navigando tra reti e tipi di driver di sistema operativo, sorridendo e godendo nel vedere come una persona possa dimenticare certe cose. E qui avviene la parte più interessante!
A livello intermedio, a mio avviso, lo specialista sviluppa un insieme di interessi e una propria prospettiva su cosa vuole fare: cavalcare l'onda con le tecnologie più recenti, inserendole in un cubo di inganno, oppure migliorarsi per grandi progetti aziendali, approfondendo le performance del codice.
Secondo me, è già il momento di chiedere dei processi a cui la persona ha lavorato, scoprire cosa è stato più interessante e cosa meno, e basarsi su queste conoscenze per costruire un cluster di domande, mappando necessariamente le domande sul proprio stack. Altrimenti, dopo aver condotto una conversazione affascinante per un paio d'ore sulla configurazione di un cluster OpenShift, si assume una persona e si chiede di costruire un sistema di monitoraggio. Probabilmente piacerà a entrambe le parti.
Livello Senior
Oh, il mio livello preferito.
Davanti a voi c'è un esperto solido, cresciuto in vari progetti, una persona che sa già cosa vuole e cosa non le piace tanto.
E ora inizia lo spettacolo:
— domande approfondite sull'amministrazione di sistema (vedi primo anti-pattern)
— domande approfondite su Linux in generale, provenienti da un ambito teorico lontano dalle conoscenze pratiche (la domanda principale sui livelli OSI)
— domande accademiche sulla programmazione (perché l'intervistatore stesso non conosce bene il settore, gli è stato semplicemente chiesto di intervistare un devops strano)
Voglio fare una piccola osservazione. Una volta, durante un colloquio, mi hanno chiesto di scrivere un pezzo di codice. Su un foglio. Come piace a tutti, ogni giorno scriviamo, il foglio è tutto per noi.
Dopo aver affrontato la task, dopo aver esaminato il mio foglio e la soluzione, è stato emesso un verdetto che l'algoritmo sarebbe stato non ottimale. Ho suggerito che l'intervistatore scrivesse il proprio algoritmo, a cui ho ricevuto la risposta "Non rientra nell'ambito del colloquio". Ho chiesto un minuto, ho modificato un po' il codice e ho mostrato, chiedendo se sarebbe stato più veloce o più lento. A cui ho ricevuto la risposta, passiamo alla domanda successiva. La differenza era nel funzionamento del codice nel ciclo e senza ciclo, avevo preparato una risposta sul perché fosse meglio fare così piuttosto che cosà. Dopo di che, non avevo voglia di rispondere a ulteriori domande e lavorare con quella persona.
È importante considerare che siamo tutti diversi e qualsiasi cosa potrebbe spaventare un candidato che per te non è rilevante.
— generalmente, gli specialisti di livello Senior hanno stack lavorativi ben definiti. E invece, si inizia a chiedere cose vicine. Per esempio, se nel vostro profilo c'è Ansible, bene, da noi c'è Puppet. Vi abbiamo contattato solo per questo, quindi parlateci di Puppet. Ottimo! Avete lavorato con OpenShift? Da noi si usa K8s, non vediamo differenze, ma la vostra esperienza non è rilevante. Fantastico!
C'è anche questa sottocategoria: personalmente prendo stagisti con potenziale per farli diventare Junior.
Vorrei che tutti capissero che uno stagista è un'entità ancora del tutto non formata. Mi spaventa moltissimo quando iniziano a chiedere agli stagisti di essere a livello di un Junior esperto e poi, con un sorriso soddisfatto, offrono tirocini (a volte non retribuiti, che incubo!).
Non farlo.
A mio avviso, uno stagista è o uno studente degli ultimi anni o qualcuno che ha davvero voglia di "entrare nel settore IT."
Con gli studenti è semplice: è fondamentale conoscere cosa studiano all'università, che esperienze hanno avuto, osservare su quali argomenti brillano gli occhi — se brillano, chiedere perché proprio nel DevOps e cosa ne sanno a riguardo. Sentire la persona e capire se sarà piacevole collaborare e se si desidera insegnare qualcosa proprio a quella persona.
Per coloro che vogliono "entrare nel settore IT", le cose sono un po' più rigorose: è importante valutare quanto una persona sia autodidatta, cosa ha fatto prima di arrivare al colloquio con voi. Uno dei buoni indicatori è controllare il profilo GitHub, se disponibile, la frequenza degli impegni e quali esercizi sono stati completati. Chiedete anche perché hanno scelto DevOps, dato che nel front-end ci sono più divertimento e creatività?
Infine, vorrei dare ancora una volta un consiglio: definite chi avete realmente bisogno e troverete subito la persona giusta. Identificate le esigenze, considerate il candidato come un professionista, trovate i suoi punti di forza e utilizzateli con successo nel vostro lavoro. Siate attenti con chi viene a colloquio, lui è lì per discutere, non per una competizione su chi può sorprendere l'altro.
Fonte: habr.com
