Non ti sembra strano che, quando stai per cambiare lavoro e hai bisogno di affrontare un'intervista, pensi prima di tutto "devo prepararmi per l'intervista"? Risolvere problemi su HackerRank, leggere Crack the Coding Interview, imparare a memoria come funziona ArrayList e quali siano le differenze con LinkedList. Oh sì, potrebbero chiederti delle ordinamenti, e sarebbe decisamente poco professionale dire che il quick sort sia probabilmente la scelta migliore.
Ma aspetta, tu programmi otto ore al giorno, risolvi problemi interessanti e non banali, e nel tuo nuovo lavoro farai più o meno la stessa cosa. Tuttavia, per superare un'intervista è necessario prepararsi in qualche modo, addirittura imparare ciò che non ti è servito né nel tuo attuale lavoro, né probabilmente ti servirà nel prossimo. In risposta alle tue obiezioni sul fatto che la computer science è nel nostro DNA, e che se ci svegliassero nel cuore della notte dovremmo essere in grado di scrivere ad occhi chiusi un algoritmo di visita breadth-first senza nemmeno rendercene conto, ti risponderei che se dovessi entrare in un circo e il mio numero principale fosse proprio questo, allora sì, d'accordo, lo accetto. Ma è necessario testare questa competenza.
Ma perché verificare competenze non rilevanti per il lavoro attuale? Solo perché è diventato di moda? Perché lo fa Google? O perché il tuo futuro team leader ha dovuto imparare a memoria tutti i metodi di ordinamento prima di affrontare l'intervista e ora crede che "ogni buon programmatore debba sapere a memoria l'implementazione per trovare un palindromo in una stringa"?
Ecco, tu non sei Google (c). Ciò che Google può permettersi, le aziende normali non possono. Google ha analizzato i dati dei propri dipendenti e ha scoperto che, per le sue specifiche esigenze, gli ingegneri con un passato olimpico si adattano bene alle sue mansioni. Inoltre, costruendo il processo di selezione, possono permettersi di accettare il rischio di non assumere alcuni buoni ingegneri semplicemente perché non sono così bravi a risolvere problemi matematici. Ma per loro non è un problema, ci sono molte persone che desiderano lavorare in Google, la posizione sarà rapidamente coperta.
Ora, diamo un'occhiata fuori dalla finestra, e se davanti al tuo ufficio non ci sono ingegneri che desiderano lavorare per te accampati in tende, e i tuoi sviluppatori cercano più spesso su stackoverflow quale sia l'annotazione di Spring da utilizzare piuttosto che le sottigliezze degli algoritmi di ranking, evidentemente è arrivato il momento di riflettere se sia opportuno copiare Google.
Va bene, se questa volta Google ti ha deluso e non ha fornito risposte, cosa fare? Testare esattamente ciò che lo sviluppatore farà nel lavoro. Cosa apprezzi negli sviluppatori?
Definisci i criteri di chi desideri assumere e sviluppa test che verifichino esattamente queste competenze.
ThoughtWorks
E cosa c'entra ThoughtWorks? Proprio qui ho trovato l'esempio di un'intervista modello. Chi sono i ThoughtWorks? In breve, è una società di consulenza di alto livello con uffici in tutto il mondo, dalla Cina e Singapore fino alle Americhe, che si occupa di consulenza nel settore dello sviluppo da circa 25 anni, con un proprio dipartimento scientifico guidato da Martin Fowler. Se cerchi un elenco di 10 libri che ogni ingegnere del software deve leggere, probabilmente 2-3 di essi saranno scritti da persone di ThoughtWorks, come Refactoring di Martin Fowler e Building Microservices: Designing Fine-Grained Systems di Sam Newman.
di Patrick Kua, Rebecca Parsons, Neal Ford.
Il business dell'azienda si basa sulla fornitura di servizi abbastanza costosi, ma il cliente paga per una qualità fenomenale, che deriva dalla competenza, dagli standard interni e, naturalmente, dalle persone. Pertanto, qui è fondamentale assumere le persone giuste.
Chi sono queste persone giuste? Certamente, ognuno ha i propri criteri. ThoughtWorks ha identificato che, per il loro modello di business, i criteri più importanti per gli sviluppatori sono:
- Capacità di sviluppo in coppia. Proprio capacità, non esperienza o abilità. Nessuno si aspetta che le persone pratiche di Pair Programming da cinque anni. Ma essere aperti al parere altrui e saper ascoltare è una competenza necessaria.
- Capacità di scrivere test e, idealmente, praticare TDD.
- Comprendere SOLID e OOP e saperli applicare.
- Presentare la propria opinione. Come consulente, sarà necessario lavorare con gli sviluppatori del cliente, con altri consulenti, e non ha molto senso se una persona sa fare qualcosa bene, ma è completamente incapace di comunicarlo agli altri membri del team.
Ora è importante valutare queste competenze specifiche nel candidato. Vorrei condividere la mia esperienza di colloquio presso ThoughtWorks. Dico subito che ho sostenuto il colloquio a Singapore e sono stato selezionato, ma il processo di reclutamento è standardizzato e non varierà molto da un paese all'altro.
Fase 0. HR
Come spesso accade, si trattava di un colloquio di 20 minuti con HR. Non mi soffermerò su questo, posso solo dire che non avevo mai incontrato un HR capace di raccontare per 15 minuti la cultura dello sviluppo nella compagnia, perché utilizzano il TDD, perché la programmazione in coppia. Di solito su questo punto gli HR si spengono e dicono che il loro processo è il solito: i programmatori sviluppano, i tester testano, i manager coordinano.
Fase 1. Quanto sei bravo in OOP, TDD?
Un'ora e mezza prima del colloquio mi hanno inviato un compito per creare un simulatore del 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 esplorato dai rover in modo che le loro telecamere a bordo 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 da una lettera che rappresenta uno dei quattro punti cardinali. Una posizione di esempio potrebbe essere 0, 0, N, il 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 muoversi in avanti di un punto nella griglia e mantenere la stessa direzione.
Assumere che il quadrato direttamente a Nord di (x, y) sia (x, y+1).
INPUT:
La prima riga di input è le coordinate superiori a destra del plateau, le coordinate inferiori a sinistra sono considerate essere 0,0.
Il resto dell'input sono informazioni sui rover che sono stati dispiegati. Ogni rover ha due righe di input. La prima riga fornisce la posizione del rover e la seconda riga è una serie di istruzioni che indicano al rover come esplorare il plateau. La posizione è composta da due numeri interi e una lettera separati da spazi, corrispondenti alle coordinate x e y e all'orientamento del rover.
Ogni rover sarà completato in sequenza, il che significa che il secondo rover non inizierà a muoversi finché il primo non ha finito di muoversi.
OUTPUT:
L'output per ogni rover dovrebbe essere le sue coordinate finali e la direzione.
NOTE:
Implementa semplicemente i requisiti sopra e prova che un aspirapolvere funzioni scrivendo test unitari per esso.
Creare qualsiasi forma di interfaccia utente è al di fuori dell'ambito.
È preferibile risolvere il problema seguendo un approccio TDD (Test Driven Development).
Nel breve tempo disponibile, siamo più preoccupati per la qualità piuttosto che per la completezza.
*Non posso rivelare il compito che mi è stato inviato, è un compito precedente assegnato alcuni anni fa. Ma credetemi, i principi sono rimasti essenzialmente gli stessi.
Vorrei sottolineare i criteri di valutazione. Quante volte ti sei trovato di fronte a situazioni in cui aspetti importanti per il candidato non sono affatto rilevanti durante il processo di selezione e viceversa. Non tutti la pensano come te, ma molti possono adottare i tuoi valori e seguirli, se sono chiaramente delineati. Quindi, dai criteri di valutazione è subito chiaro che le competenze più importanti in questa fase sono
- TDD;
- Capacità di utilizzare l'OOP e di scrivere codice manutenibile;
- abilità nella programmazione in coppia.
Così, mi è stato detto di dedicare quest'ora e mezza a riflettere su come intendo svolgere il compito, anziché scrivere codice. Il codice lo scriveremo insieme.
Quando ci siamo connessi, i ragazzi mi hanno brevemente parlato di chi sono e cosa fanno e mi hanno invitato a iniziare lo sviluppo.
Durante tutta la durata dell'intervista non ho mai avuto l'impressione di essere a un colloquio. La sensazione era quella di sviluppare codice in team. Se ti fermi in qualche punto, loro ti aiutano, consigliano, discutono, persino litigano tra di loro su come procedere. Durante l'intervista ho dimenticato come controllare che un metodo in JUnit 5 lanci un'eccezione — hanno suggerito di continuare a scrivere il test mentre uno di loro cercava su Google come farlo.
Pochissime ore dopo il colloquio ho ricevuto un feedback costruttivo — cosa è piaciuto e cosa no. Nel mio caso, sono stato elogiato per l'uso delle classi Sealed come alternativa all'oggetto null; per il fatto che prima di scrivere il codice avevo redatto un pseudocodice su come avrei gestito il rover, ottenendo così una bozza delle classi, almeno quelle coinvolte nell'API del robot.
Fase 2. Raccontaci
Una settimana prima del colloquio mi è stato chiesto di preparare una presentazione su un argomento che mi interessava. Il formato è semplice e consueto: 15 minuti di presentazione, 15 minuti di domande e risposte.
Ho scelto la Clean Architecture di Uncle Bob. Anche in questo caso, sono stato intervistato da un paio di persone. Questa è stata la mia prima esperienza di presentazione in inglese, e probabilmente, se fossi stato in una situazione di stress — non ce l'avrei fatta. Ma anche in questo caso, non ho mai avuto l'impressione di essere a un colloquio. È stato tutto come al solito — io parlo, loro ascoltano attentamente. Anche la tradizionale sessione di domande e risposte non è sembrata un colloquio, si vedeva che le domande erano poste non per “affondare” ma perché erano realmente interessati alla mia presentazione.
Dopo qualche ora dal colloquio, ho ricevuto un feedback — la presentazione è stata molto utile e hanno trovato piacevole ascoltarla.
Fase 3. Codice di Qualità Produttivo
Avvertendo che questa era l'ultima fase dei colloqui tecnici, mi è stato chiesto di portare il codice a uno stato pronto per la produzione a casa, dopo di che avrei dovuto inviare il codice per la revisione e fissare colloqui in cui i requisiti del compito cambieranno e il codice richiederà modifiche. In anticipo, posso dire che la revisione del codice è condotta alla cieca, i revisori non conoscono né la posizione per cui il candidato sta applicando né vedono il suo CV, e nemmeno il suo nome.
Una videochiamata, e ancora una volta ci sono alcuni ragazzi dall'altra parte dello schermo. È tutto come al primo colloquio: la cosa principale è non dimenticare il TDD, spiegare cosa si sta facendo e perché. Se non hai mai praticato il TDD, 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 frenetico cercare un errore con il debugger che si verificava solo nel browser e non riuscivi a riprodurlo con i test? Ora immagina di dover catturare un errore del genere durante un colloquio — ti assicuro che ti verranno un paio di capelli bianchi. E cosa possiamo garantirci con il TDD? Hai modificato il codice e, inaspettatamente, hai visto che ora i test sono falliti, ma non riesci a capire dove sia l'errore al primo colpo? Va bene, dici agli intervistatori “Ops”, premi Ctrl-Z e inizi a procedere lentamente. E sì, devi sviluppare in te l'abilità di lavorare con il TDD, l'abilità di andare verso l'obiettivo in modo tale che i tuoi test siano sempre verdi e non rossi per mezza giornata perché “hai un grande refactoring”. È proprio la stessa abilità di scrivere codice mantenibile o codice ad alte prestazioni.
Quindi, quanto bene il tuo codice è modificabile dipende dal design che hai inizialmente creato, dalla sua semplicità e dalla qualità dei tuoi test.
Dopo il colloquio ho ricevuto un feedback dopo poche ore. A questo punto, ho capito che praticamente ero passato e mancava poco alla “riunione con Fowler”.
Fase 4. Finale. Abbastanza domande tecniche. Vogliamo sapere chi sei!
A dire il vero, questa formulazione mi ha un po' confuso. Come si può capire che tipo di persona sono in un'ora di conversazione? E soprattutto, come si può comprendere quando parlo in una lingua che non è la mia madrelingua, e, ad essere onesti, piuttosto male e in modo confuso. Nei colloqui precedenti era più facile per me raccontare che non rispondere a domande, e la colpa era dell'accento. Almeno uno degli intervistatori era asiatico — e il loro accento è, diciamo così, piuttosto specifico per un orecchio europeo. Così ho deciso di adottare un approccio proattivo — preparare una presentazione su di me e all'inizio del colloquio proporre di raccontare di me con questa presentazione. Se accettano, perlomeno ci saranno meno domande per me; se rifiutano l'offerta, beh, 3 ore della mia vita spese sulla presentazione — non è una tale alta cifra. Ma cosa scrivere nella presentazione? La biografia — Nato in un certo posto, a una certa data, andato a scuola, laureato all'università — chi se ne frega?
Se fai un po' di ricerche sulla cultura di Thoughtworks, puoi trovare un articolo di Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], in cui si descrivono i 3 Pillars: Sostenibilità Aziendale, Eccellenza del Software, e Giustizia Sociale.
Supponiamo che l'Eccellenza del Software sia già stata verificata. Resta da mostrare Sostenibilità Aziendale e Giustizia Sociale.
Ho deciso di concentrarmi soprattutto su quest'ultimo.
Per cominciare, ho raccontato perché ThoughtWorks — leggevo il blog di Martin Fowler già al college, da qui l'amore per il Clean Code.
Anche i progetti possono essere presentati da diverse angolazioni. Ho sviluppato software per la medicina che semplificava la vita dei pazienti e, a quanto pare, ha persino salvato una vita. Ho sviluppato anche software per banche, un altro tipo di semplificazione della vita per i cittadini. Soprattutto se quella banca è utilizzata dal 70% della popolazione del paese. Non parliamo di Sberbank e nemmeno della Russia.
Vuoi saperne di più su di me? Va bene. Il mio hobby è la fotografia, ho avuto una macchina fotografica in mano per circa 10 anni, ho alcune foto che non sono troppo imbarazzanti da mostrare. Inoltre, per un certo periodo, ho aiutato un rifugio per gatti: fotografavo i gatti che avevano bisogno di una casa permanente. E con foto belle, è molto più facile trovare una sistemazione per un gatto. Probabilmente, ho fotografato una cento di gatti 🙂
Alla fine, l'80% della mia presentazione era dedicato ai gatti.
Subito dopo la presentazione, l'HR mi ha scritto che non sapeva ancora i risultati del colloquio, ma già tutto l'ufficio era impressionato dai gatti.
Alla fine ho ricevuto un feedback — ho soddisfatto tutti come persona.
Ma l'HR, durante l'ultima conversazione, ha accennato col garbo che la giustizia sociale è molto importante e necessaria, ma non tutti i progetti lo sono. E ha chiesto se questo mi spaventasse. Insomma, ho esagerato un po' con la giustizia sociale, capita 🙂
Risultato
In sintesi, lavoro da alcuni mesi a Singapore in Thoughtworks, e vedo che anche qui molte aziende stanno adottando le 'migliori pratiche di colloqui' di Google, utilizzando fogli e Whiteboard per il coding, malgrado le conoscenze richieste vadano oltre Spring, Symfony, RubyOnRails (da sottolineare). Gli ingegneri prendono una settimana di ferie prima del colloquio per 'prepararsi'.
In Thoughtworks, oltre a requisiti adeguati per i candidati, vengono messi al centro principi come:
La gioia di fare colloqui. Questo vale per entrambe le parti. In effetti, se vuoi ottenere i migliori talenti (chi non lo vorrebbe?), il colloquio non è un mercato dove si scelgono schiavi, ma un'opportunità in cui sia il datore di lavoro che il candidato si valutano a vicenda. E se il candidato associa emozioni positive all'azienda, è molto probabile che scelga proprio quella.
Intervistatori multipli per mitigare i pregiudizi. In Thoughtworks, la programmazione in coppia è lo standard de facto. E se questa pratica può essere applicata in altri ambiti, TW cerca di farlo. Ogni fase del colloquio è condotta da 2 persone. In questo modo, ogni persona è valutata da un minimo di 8 persone, e TW cerca di selezionare gli intervistatori con diversi background, di vari settori (non solo tecnici) e generi.
Alla fine, la decisione di assunzione sarà presa sulla base del parere di almeno 8 persone, e nessuno ha diritto di voto decisivo.
Assunzione basata sulle competenze. Invece di prendere decisioni basate su 'mi piace/non mi piace' del candidato, per ogni ruolo e per ogni fase è stato sviluppato un modulo che include le competenze valutate. In questo processo, si raccomanda vivamente di valutare non l'esperienza in una determinata competenza, ma la capacità di applicarla. Così, se un candidato non ha avuto l'opportunità di applicare alcune abilità come TDD, ma cerca di farlo e ascolta i consigli sul corretto uso, ha tutte le possibilità di superare il colloquio.
Documenti educativi non richiesti. TW non richiede ai candidati certificati o titoli di studio in Informatica. Vengono valutate solo le competenze.
Questo è il primo colloquio, tra quelli che ho fatto 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, sapendo che le persone dall'altra parte dello schermo le apprezzano e le utilizzano ogni giorno.
Dopo alcuni mesi, posso dire che le aspettative sono state pienamente 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 è straordinaria.
Se vuoi unirti a ThoughtWorks, puoi vedere le posizioni aperte.
Ti consiglio inoltre di dare un'occhiata a posizioni interessanti:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
Infrastacture: , ,
(Voglio avvisarti onestamente che il link è referral, se ti unirai a TW, riceverò un piacevole bonus). Scegli l'ufficio che preferisci, non è necessario limitarsi solo all'Europa, in ogni caso, ogni 2 anni TW sarà felice di trasferirti in un altro paese, dato che è parte della politica di ThoughtWorks, in questo modo la cultura si diffonde e si omogeneizza.
Non esitare a fare domande nei commenti o a chiedermi di raccomandarti.
Se il tema ti è sembrato interessante, scriverò di come si lavora in ThoughtWorks e della vita a Singapore.
Fonte: habr.com
