Non vi sembra strano che quando state per cambiare lavoro e c'è bisogno di affrontare un colloquio, pensiate innanzitutto "devo prepararmi per il colloquio"? Risolvere esercizi su HackerRank, leggere Crack the Coding Interview, memorizzare come funziona un ArrayList e in cosa si differenzia da un LinkedList. Ah già, potrebbero chiedere anche delle ordinamenti, e sarebbe sicuramente poco professionale dire che il quick sort sarà probabilmente la scelta migliore.
Ma aspetta, tu programmi 8 ore al giorno, risolvi problemi interessanti e non banali, e nel tuo nuovo lavoro farai più o meno le stesse cose. Eppure, per superare un colloquio è necessario prepararsi in modo diverso, non tanto affinando le abilità quotidiane, ma imparando cose che non ti sono servite né nel tuo attuale lavoro né probabilmente serviranno nel prossimo. Alle tue obiezioni sul fatto che la computer science è nel nostro DNA, e che se ci risvegliassero nel mezzo della notte saremmo in grado di scrivere ad occhi chiusi, su un cuscino, un algoritmo di traversamento in ampiezza di un albero senza neppure rendere conto di ciò che stiamo facendo, io risponderei che se mi candidassi per un lavoro al circo e il mio numero principale fosse esattamente questo — allora sì, sarei d'accordo. È necessario testare questa abilità.
Ma perché testare abilità non rilevanti per il lavoro attuale? Solo perché è diventato di moda? Perché Google lo fa? O perché il tuo futuro team leader ha dovuto imparare tutti i metodi di ordinamento prima di affrontare il colloquio e ora pensa che "ogni buon programmatore deve conoscere a memoria l'implementazione per trovare un palindromo in una stringa".
Ecco, non sei Google (c). Ciò che Google può permettersi, le aziende normali non possono. Google, analizzando i dati dei suoi dipendenti, è giunto alla conclusione che, specificamente per le sue attività, è più efficace affidare i compiti agli ingegneri con una formazione olimpionica. Inoltre, costruendo il processo di selezione, possono permettersi di accettare il rischio di non assumere alcuni buoni ingegneri perché non sono in grado di risolvere facilmente problemi matematici. Ma per loro non è un problema, ci sono molte persone desiderose di lavorare in Google, la posizione si chiuderà.
Ora diamo un'occhiata fuori dalla finestra e, se davanti al vostro ufficio non ci sono ancora ingegneri che desiderano lavorare per voi che hanno piantato un campo tendato, e se i vostri sviluppatori cercano più frequentemente su stackoverflow quale ulteriore annotazione Spring devono inserire, piuttosto che le sottigliezze degli algoritmi di ranking, allora, probabilmente, è il momento di riflettere se valga la pena copiare Google.
Bene, se questa volta Google ha deluso e non ha fornito una risposta, che fare? Controllare esattamente ciò che lo sviluppatore farà al lavoro. Cosa apprezzate negli sviluppatori?
Stabilire i criteri per chi desiderate assumere e sviluppare test che verificano proprio quelle competenze.
ThoughtWorks
Cosa c'entra ThoughtWorks? Proprio qui ho trovato un esempio di colloquio esemplare. Chi sono quelli di ThoughtWorks? In breve, è una società di consulenza High-End con uffici in tutto il mondo, dalla Cina e Singapore fino ai continenti americani, che si occupa di consulenza nel campo dello sviluppo da circa 25 anni, avendo il proprio dipartimento Scientifico guidato da Martin Fowler. Se cercate una lista di 10 libri che devono essere letti per un ingegnere del software, probabilmente 2-3 di essi saranno scritti da persone di ThoughtWorks, come ad esempio Refactoring di Martin Fowler e Building Microservices: Designing Fine-Grained Systems di Sam Newman o Building Evolutionary Architectures
di Patrick Kua, Rebecca Parsons, Neal Ford.
Il business dell'azienda è costruito attorno alla fornitura di servizi piuttosto costosi, ma il cliente paga per una qualità fenomenale, che deriva dall'expertise, dagli standard interni e, naturalmente, dalle persone. Pertanto, qui è fondamentale assumere le persone giuste.
Chi sono queste persone giuste? Certamente ognuno ha le proprie. ThoughtWorks ha stabilito che, per il loro modello di business, i criteri più importanti per gli sviluppatori sono:
- La capacità di sviluppare in coppia. Proprio la capacità, non l'esperienza o l'abilità. Nessuno si aspetta che arrivino persone che praticano il Pair programming da 5 anni. Ma essere aperti al parere altrui e saper ascoltare è un'abilità necessaria.
- Essere in grado di scrivere test, e idealmente praticare il TDD.
- Comprendere il SOLID e la OOP e saperli applicare.
- Presentare le proprie opinioni. Un consulente deve lavorare con gli sviluppatori del cliente e con altri consulenti, e non è molto utile se una persona è brava a fare qualcosa, ma è completamente incapace di comunicarlo agli altri membri del team.
È ora importante valutare proprio queste competenze nel candidato. E qui voglio raccontare della mia esperienza durante il colloquio in ThoughtWorks. Posso dire subito che ho fatto il colloquio a Singapore e sono riuscito, ma il processo di reclutamento è standardizzato e non varierà molto da paese a paese.
Fase 0. HR
Come spesso accade, il colloquio con l'HR dura 20 minuti. Non mi soffermerò su questo, dirò solo che non avevo mai incontrato prima un HR che potesse parlare per 15 minuti della cultura dello sviluppo all'interno dell'azienda, spiegando perché usano il TDD e perché la programmazione in coppia. Di solito, su questo punto, gli HR si smarriscono e raccontano che il loro processo è normale: gli sviluppatori sviluppano, i tester testano, i manager dirigono.
Fase 1. Quanto sei bravo in OOP, TDD?
Un'ora e mezza prima dell'inizio del colloquio mi è stato inviato un compito per realizzare un simulatore di Mars Rover.
Compito Mars roverUn gruppo di rover robotici deve essere atterrato dalla NASA su un plateau su Marte. Questo plateau, che è curiosamente rettangolare, deve essere navigato dai rover in modo che le loro telecamere onboard possano ottenere una visione completa del terreno circostante da inviare sulla Terra. La posizione e il luogo di un rover sono rappresentati da una combinazione di coordinate x e y e una lettera che rappresenta uno dei quattro punti cardinali. Il plateau è diviso in una griglia per semplificare la navigazione. Un esempio di posizione potrebbe essere 0, 0, N, che significa che il rover si trova nell'angolo in basso a sinistra e sta guardando a Nord. Per controllare un rover, la NASA invia una semplice stringa di lettere. Le lettere possibili sono 'L', 'R' e 'M'. 'L' e 'R' fanno ruotare il rover di 90 gradi a sinistra o a destra rispettivamente, senza muoversi dalla sua posizione attuale. 'M' significa spostarsi in avanti di un punto della griglia, mantenendo la stessa direzione.
Si assume che il quadrato direttamente a Nord di (x, y) sia (x, y+1).
INPUT:
La prima riga di input è le coordinate superiori destra del plateau, le coordinate inferiori sinistra sono assunte come 0,0.
Il resto dell'input riguarda i rover che sono stati dispiegati. Ogni rover ha due righe di input. La prima riga indica la posizione del rover, e la seconda riga è una serie di istruzioni che dicono al rover come esplorare il plateau. La posizione è composta da due numeri interi e una lettera separati da spazi, corrispondente alle coordinate x e y e all'orientamento del rover.
Ogni rover terminerà in sequenza, il che significa che il secondo rover non inizierà a muoversi fino a quando il primo non avrà finito di muoversi.
OUTPUT:
L'output per ogni rover dovrebbe essere le sue coordinate finali e l'orientamento.
NOTE:
Implementa semplicemente i requisiti sopra e dimostra che un aspirapolvere funziona scrivendo test unitari per esso.
Creare qualsiasi forma di interfaccia utente è al di fuori dell'ambito.
Risolvere il problema seguendo un approccio TDD (Test Driven Development) sarà preferito.
Nel breve tempo disponibile, siamo più preoccupati per la qualità che per la completezza.
*Non posso condividere il compito che mi è stato inviato, è un compito vecchio, assegnato qualche anno fa. Ma credetemi, il principio è rimasto lo stesso.
È importante soffermarsi sui criteri di valutazione. Quante volte vi è capitato di trovarvi in una situazione in cui ciò che è importante per il candidato non lo è affatto durante la valutazione e viceversa? Non tutti la pensano come voi, ma molti possono adottare i vostri valori e seguirli se sono chiaramente definiti. Dunque, dai criteri di valutazione è subito evidente che le competenze più importanti in questa fase sono
- TDD;
- La capacità di utilizzare l'OOP e scrivere codice manutenibile;
- abilità nel programmazione in coppia
Dunque, mi hanno avvertito di dedicare queste 1.5 ore a riflettere su come intendo affrontare il compito, piuttosto che scrivere codice. Il codice lo scriveremo insieme.
Quando ci siamo sentiti per telefono, i ragazzi hanno brevemente raccontato chi sono e cosa fanno e hanno proposto di iniziare lo sviluppo.
Durante tutto il colloquio, non ho mai avuto la sensazione di essere in un colloquio. È come se stessi sviluppando codice in team. Se ti blocchi da qualche parte, loro aiutano, consigliano, discutono, anche litigano su come fare meglio. Durante il colloquio ho dimenticato come controllare in JUnit 5 che un metodo lanci un'eccezione — hanno suggerito di continuare a scrivere il test mentre uno di loro cercava su Google come fare.
Letteralmente poche ore dopo il colloquio ho ricevuto un feedback costruttivo — cosa è piaciuto e cosa no. Nel mio caso, mi hanno lodato per l'uso delle classi Sealed come alternativa all'oggetto null; per il fatto di aver scritto in pseudocodice come avrei voluto gestire il rover prima di scrivere codice, ottenendo così uno schizzo delle classi, almeno di quelle coinvolte nell'API del robot.
Fase 2. Raccontaci
Una settimana prima del colloquio mi hanno chiesto di preparare una presentazione su un qualsiasi argomento che mi interessasse. Il formato è semplice e familiare: 15 minuti di presentazione, 15 minuti di domande e risposte.
Ho scelto Clean Architecture di Uncle Bob. E di nuovo sono stato intervistato da un paio di persone. È stata la mia prima esperienza di presentazione in inglese e, forse, se fossi stato in una situazione di stress, non ce l'avrei fatta. Ma d'altra parte, non ho mai avuto la sensazione di essere in un colloquio. Tutto come al solito: parlo, loro ascoltano attentamente. Anche la tradizionale sessione di domande e risposte non somigliava a un colloquio, era evidente che le domande non erano fatte per “affondare” ma per un reale interesse nella mia presentazione.
Dopo un paio d'ore dal colloquio ho ricevuto un feedback: la presentazione è stata molto utile e hanno provato un sincero piacere ad ascoltarla.
Fase 3. Codice di qualità per la produzione
Avvisando che questa è l'ultima fase dei colloqui tecnici, mi è stato chiesto di portare a casa il codice in uno stato pronto per la produzione, dopo di che dovevo inviare il codice per una revisione e fissare colloqui dove i requisiti del compito sarebbero cambiati e il codice avrebbe richiesto modifiche. Anticipando, posso dire che la revisione del codice viene effettuata alla cieca, i revisori non conoscono né la posizione per cui il candidato si candida, né vedono il suo CV, neppure il suo nome.
Una chiamata, e di nuovo una coppia di ragazzi dall'altra parte dello schermo. Tutto come al primo colloquio: l'importante è non dimenticare il TDD, spiegare cosa fai e perché. Se non hai mai praticato il TDD prima, ti consiglio di iniziare subito, non perché sia necessario nelle aziende, ma perché semplifica notevolmente la tua vita e riduce il livello di stress, se vuoi. Ricordi quando dovevi cercare freneticamente un errore con il debugger, che si riproduceva solo attraverso il browser e che non riuscivi a riprodurre con i test? Ora immagina di dover catturare questo errore durante un colloquio: un paio di capelli bianchi te li sarai sicuramente guadagnati. Cosa ci offre il TDD? Modifichi il codice e, con sorpresa, ti rendi conto che ora i test sono rossi, ma non riesci a capire l'errore al primo colpo? Va bene, diciamo agli intervistatori “Ops”, premiamo Ctrl-Z e iniziamo a procedere a piccoli passi. E sì, la capacità di sviluppare utilizzando il TDD va coltivata, l'abilità di puntare all'obiettivo in modo che i tuoi test siano costantemente verdi, e non rossi per mezza giornata, solo perché “hai un grande refactoring”. Questa è esattamente una competenza come quella di scrivere codice manutenibile, o codice performante.
Quindi, quanto bene il tuo codice si presta alle modifiche dipende dal design che hai impostato inizialmente, da quanto è semplice e da quanto sono buoni i tuoi test.
Dopo il colloquio ho ricevuto un feedback dopo poche ore. In questa fase ho capito che praticamente avevo passato e mancava poco alla “riunione con Fowler”.
Fase 4. Finale. Abbastanza domande tecniche. Vogliamo sapere chi sei!
Ad essere sincero, questa formulazione della questione mi ha un po' confuso. Come si può capire che tipo di persona sono in un'ora di conversazione? E tanto meno come si può capirlo quando parlo in una lingua che non è la mia madrelingua, e, a dire il vero, in modo piuttosto impreciso e balbettante. Negli colloqui precedenti, per quanto mi riguarda, era più facile raccontare piuttosto che rispondere alle domande, e tutto era dovuto all'accento. Almeno uno degli intervistatori era asiatico — e il suo accento è, diciamo, un po' particolare per un orecchio europeo. Perciò ho deciso di adottare un approccio proattivo: preparare una presentazione su di me e all'inizio del colloquio proponendo di parlare di me con questa presentazione. Se accettano, ci saranno almeno meno domande per me; se rifiutano la proposta, beh, tre ore della mia vita spese per la presentazione non sono un prezzo troppo alto. Ma cosa scrivere nella presentazione? La biografia — Sono nato qui, allora, sono andato a scuola, ho finito l'università — a chi interessa?
Se si fa un po' di ricerca sulla cultura di Thoughtworks, si può trovare un articolo di Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], nel quale vengono descritti i 3 Pillars: Business Sostenibile, Eccellenza del Software e Giustizia Sociale.
Supponiamo che l'Eccellenza del Software sia già stata verificata. Resta da mostrare il Business Sostenibile e la Giustizia Sociale.
Pertanto, ho deciso di concentrarmi sull'ultimo.
Per iniziare, ho spiegato perché ThoughtWorks — da quando ero all'università leggevo il blog di Martin Fowler, da qui la mia passione per il Clean code.
I progetti possono essere presentati da diverse angolazioni. Ho sviluppato software per la medicina, che ha semplificato la vita ai pazienti, e, a quanto pare, ha persino salvato una vita. Ho sviluppato anche software per banche, un tipo di semplificazione della vita per i cittadini. Soprattutto se quella banca è utilizzata dal 70% della popolazione di un paese. Non sto parlando di Sberbank e nemmeno della Russia.
Vuoi sapere qualcosa di me? Va bene. Il mio hobby è la fotografia, tengo una macchina fotografica in mano da circa dieci anni e ho molte foto che non mi vergogno di mostrare. Inoltre, per un po' di tempo, ho aiutato un rifugio per gatti: ho fotografato gatti che avevano bisogno di una casa permanente. E con belle foto è molto più facile trovare una sistemazione per un gatto. Probabilmente ho fotografato un centinaio di gatti 🙂
Alla fine, l'80% della mia presentazione era dedicata ai gatti.
Subito dopo la presentazione, l'HR mi ha scritto che non conosce ancora i risultati del colloquio, ma tutto l'ufficio è già impressionato dai gatti.
Alla fine, ho ricevuto un feedback: ho soddisfatto tutti come persona.
Tuttavia, l'HR durante l'ultimo colloquio ha accennato in modo discreto che la Giustizia Sociale è molto positiva e importante, ma non tutti i progetti lo sono. E mi ha chiesto se questo mi spaventa. Insomma, ho esagerato un po' con la Giustizia Sociale, capita 🙂
Risultato
Come risultato, lavoro già da qualche mese a Singapore in Thoughtworks e vedo che anche qui molte aziende stanno adottando le 'migliori pratiche di colloquio' di Google, utilizzando foglietti e Whiteboard per il coding, pur non avendo bisogno di conoscenze oltre Spring, Symfony, RubyOnRails (sottolineare ciò che serve) nel lavoro. Gli ingegneri prendono una settimana di ferie prima del colloquio per 'prepararsi'.
In Thoughtworks, oltre a requisiti adeguati per i candidati, si pongono in cima a tutto questi principi:
Gioia del colloquio. Infatti, se volete ottenere i migliori talenti (e chi non li vuole?), il colloquio non è un mercato dove si scelgono schiavi, ma una visione reciproca, dove sia il datore di lavoro che il candidato si valutano a vicenda. E se il candidato associa emozioni piacevoli all'azienda, è molto probabile che scelga proprio quella azienda.
Molteplici intervistatori per mitigare il bias. In Thoughtworks, il pair programming è lo standard de facto. E se questa pratica può essere applicata ad altri settori, TW cerca di farlo. In ogni fase del colloquio ci sono due persone. In questo modo, ogni candidato è valutato da almeno 8 persone e TW cerca di selezionare intervistatori con diverse esperienze, provenienti da diversi ambiti (non solo tecnici) e generi.
Alla fine, la decisione di assunzione sarà basata sul parere di almeno 8 persone e nessuno ha diritto di voto decisivo.
Assunzione basata su attributi Invece di prendere decisioni basate su "mi piace/non mi piace" per i candidati, per ogni ruolo e per ogni fase è stato sviluppato un modulo che include gli attributi da valutare. In questo contesto, è fortemente consigliato valutare non l'esperienza in una determinata competenza, ma la capacità di applicarla. Pertanto, se un candidato non ha avuto opportunità di applicare alcune competenze, come TDD, ma comunque cerca di farlo e ascolta i consigli su un utilizzo corretto — ha tutte le possibilità di superare il colloquio.
Certificati di istruzione non richiesti TW non richiede ai candidati certificati obbligatori o un'istruzione in Informatica. Vengono valutate solo le competenze.
Questo è il primo colloquio, tra quelli che ho sostenuto in aziende straniere, per il quale non ho dovuto prepararmi. Dopo ogni fase, non mi sono sentito spremuto come un limone, al contrario, ero felice di poter applicare le migliori pratiche, che le persone dall'altra parte dello schermo lo apprezzano e le applicano ogni giorno.
Dopo alcuni mesi, posso dire che le aspettative sono state completamente soddisfatte. Cosa distingue ThoughtWorks da un'azienda normale? In un'azienda normale puoi trovare buoni sviluppatori e persone piacevoli, ma in TW la loro concentrazione è molto più alta.
Se vuoi unirti a ThoughtWorks, puoi visualizzare le posizioni aperte
Ti consiglio anche di dare un'occhiata a posizioni interessanti:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
Infrastacture: , ,
(Voglio avvertire onestamente che il link è referenziale, se entrerai in TW, riceverò un bel bonus). Scegli l'ufficio che preferisci, non è necessario limitarsi solo all'Europa, alla fine, ogni 2 anni TW sarà felice di trasferirti in un altro paese, poiché è parte della politica di ThoughtWorks, in questo modo la cultura si diffonde e si media.
Non esitare a porre domande nei commenti o a chiedere di consigliarti.
Se il tema ti sembra interessante, scriverò su come lavorare in ThoughtWorks e come si vive a Singapore.
Fonte: habr.com
