Non ti sembra strano che quando stai per cambiare lavoro e si presenta la necessità di sostenere un colloquio, la prima cosa a cui pensi è “devi prepararti per il colloquio”. Risolvi problemi su HackerRank, leggi Crack the coding interview, memorizza come funziona ArrayList e in cosa differisce da LinkedList. Oh sì, potrebbero anche chiedere informazioni sull'ordinamento e sarebbe ovviamente poco professionale dire che l'ordinamento rapido sarebbe molto probabilmente la scelta migliore.
Ma aspetta, programmi 8 ore al giorno, risolvi problemi interessanti e non banali e nel tuo nuovo lavoro farai la stessa cosa, più o meno. Tuttavia, per superare un colloquio, devi in qualche modo prepararti ulteriormente, nemmeno affinare le tue capacità quotidiane, ma imparare qualcosa di cui non avevi bisogno nel tuo lavoro attuale e che difficilmente ti servirà in quello successivo. Alle tue obiezioni che l'informatica è nel nostro sangue, e se ci svegli nel cuore della notte siamo obbligati a scrivere ad occhi chiusi su una federa una passeggiata nel largo di un albero senza nemmeno riprendere conoscenza, io risponderò che se trovassi un lavoro nel circo, e il mio trucco principale sarebbe esattamente questo - allora forse sì, sono d'accordo. Questa abilità deve essere testata.
Ma perché testare competenze irrilevanti per il tuo lavoro attuale? Solo perché è diventato di moda? Perché Google fa questo? Oppure perché il tuo futuro caposquadra ha dovuto imparare tutti i metodi di ordinamento prima del colloquio e ora ritiene che “ogni buon programmatore debba conoscere a memoria l’implementazione della ricerca di un palindromo in una stringa”.
Beh, tu non sei Google (c). Ciò che Google può permettersi, le aziende ordinarie non possono. Google, dopo aver analizzato i dati dei suoi dipendenti, è giunta alla conclusione che gli ingegneri con un background olimpico sono bravi a svolgere i suoi compiti specifici. Inoltre, progettando il processo di selezione, possono permettersi di correre il rischio di non assumere alcuni bravi ingegneri perché non riescono a risolvere facilmente i problemi di matematica. Ma questo per loro non è un problema, ci sono tante persone che vogliono lavorare in Google, la posizione sarà chiusa.
Ora guardiamo fuori dalla finestra, e se davanti al tuo ufficio gli ingegneri che vogliono lavorare per te non hanno ancora allestito un campo tendato, e i tuoi sviluppatori cercano più spesso su StackOverflow quale annotazione della prossima primavera dovrà essere installata, piuttosto che le complessità degli algoritmi di ranking, quindi, a quanto pare, è tempo per te di pensare se dovresti copiare Google.
Ebbene, se questa volta Google fallisse e non fornisse una risposta, cosa dovresti fare? Controlla esattamente cosa farà lo sviluppatore al lavoro. Cosa apprezzi negli sviluppatori?
Stabilisci criteri per chi vuoi assumere e sviluppa test che mettono alla prova esattamente queste competenze.
ThoughtWorks
Cosa c'entra ThoughtWorks con tutto questo? Qui è dove ho trovato un esempio di intervista modello per me stesso. Chi sono ThoughtWorks? In breve, si tratta di una società di consulenza High-End con sedi in tutto il mondo, dalla Cina, Singapore ai continenti americani, che svolge attività di consulenza nel campo dello sviluppo da circa 25 anni, ha una propria divisione Science, guidata da Martin Fowler. Se cerchi un elenco di 10 libri da leggere per un ingegnere del software, forse 2-3 di essi saranno scritti dai ragazzi di ThoughtWorks, come Refactoring di Martin Fowler e Building Microservices: Designing Fine-Grained Systems di Sam Newman o la costruzione di architetture evolutive
di Patrick Kua, Rebecca Parsons, Neal Ford.
L'attività dell'azienda si basa sulla fornitura di servizi piuttosto costosi, ma il cliente paga per una qualità fenomenale, che consiste in competenza, standard interni e, ovviamente, persone. Pertanto, assumere le persone giuste è fondamentale qui.
Che tipo di persone hanno ragione? Naturalmente ce ne sono diversi per ognuno. ThoughtWorks ha stabilito che i criteri più importanti per il proprio modello di business degli sviluppatori sono:
- Capacità di svilupparsi in coppia. È abilità, non esperienza o abilità. Nessuno si aspetta che arrivino persone che praticano la programmazione in Pair da 5 anni, ma essere ricettivi alle opinioni degli altri e saper ascoltare è una competenza necessaria.
- Capacità di scrivere test e idealmente di praticare TDD
- Comprendere SOLID e OOP ed essere in grado di applicarli.
- Presenta la tua opinione. Come consulente, devi lavorare con gli sviluppatori del cliente, con altri consulenti, e non c'è molto vantaggio se una persona sa fare bene qualcosa, ma non è completamente in grado di trasmetterla al resto del team.
Ora è importante valutare queste particolari competenze nel candidato. E qui voglio parlare della mia esperienza di intervista presso ThoughtWorks. Dirò subito che sono andato a Singapore e sono stato promosso, ma il processo di reclutamento è unificato e non differirà molto da paese a paese.
Fase 0. HR
Come spesso accade, un colloquio di 20 minuti con l'HR. Non mi soffermerò su questo, dirò solo che non ho mai incontrato una persona delle risorse umane che potesse parlare per 15 minuti della cultura dello sviluppo in azienda, perché usano TDD, perché accoppiare la programmazione. Di solito, le risorse umane si arrabbiano su questa domanda e affermano che il loro processo è normale: gli sviluppatori sviluppano, i tester testano, i manager guidano.
Fase 1. Quanto sei bravo in OOP, TDD?
Un'ora e mezza prima dell'inizio dell'intervista, mi è stato inviato il compito di realizzare un simulatore di Mars Rover.
Задание Mars roverUna squadra di rover robotici verrà fatta atterrare dalla NASA su un altopiano su Marte. Questo altopiano, curiosamente rettangolare, deve essere percorso dai rover in modo che le loro telecamere di bordo possano ottenere una visione completa del terreno circostante da inviare sulla Terra. La posizione e l'ubicazione di un rover è rappresentata da una combinazione di coordinate xey e da una lettera che rappresenta uno dei quattro punti cardinali della bussola. L'altopiano è suddiviso in una griglia per facilitare la navigazione. Una posizione di esempio potrebbe essere 0, 0, N, il che significa che il rover si trova nell'angolo in basso a sinistra ed è rivolto 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 rispettivamente di 90 gradi a sinistra o a destra, senza spostarsi dalla posizione attuale. "M" significa avanzare di un punto della griglia e mantenere la stessa direzione.
Supponiamo che il quadrato direttamente a nord di (x, y) sia (x, y+1).
INGRESSO:
La prima riga di input rappresenta le coordinate in alto a destra dell'altopiano, si presuppone che le coordinate in basso a sinistra siano 0,0.
Il resto dell'input sono informazioni relative ai rover che sono stati schierati. Ogni rover ha due linee di input. La prima riga fornisce la posizione del rover e la seconda riga è una serie di istruzioni che dicono al rover come esplorare l'altopiano. La posizione è composta da due numeri interi e una lettera separati da spazi, corrispondenti alle coordinate xey e all'orientamento del rover.
Ogni rover verrà terminato in sequenza, il che significa che il secondo rover non inizierà a muoversi finché il primo non avrà finito di muoversi.
USCITA:
L'output per ciascun rover dovrebbe essere le sue coordinate finali e la sua direzione.
NOTE:
Implementa semplicemente i requisiti di cui sopra e dimostra che un aspirapolvere funziona scrivendo test unitari per esso.
La creazione di qualsiasi forma di interfaccia utente non rientra nell'ambito.
Sarà preferibile risolvere il problema seguendo un approccio TDD (Test Driven Development).
Nel poco tempo a disposizione, ci preoccupiamo più della qualità che della completezza.
*Non riesco a pubblicare il compito che mi è stato inviato, questo è un vecchio compito assegnato diversi anni fa. Ma credetemi, fondamentalmente tutto rimane uguale.
Vorrei attirare in particolare l'attenzione sui criteri di valutazione. Quante volte ti sei imbattuto in una situazione in cui le cose importanti per un candidato sono completamente irrilevanti durante l'audit e viceversa. Non tutti la pensano come te, ma molti possono accettare e seguire i tuoi valori se sono chiaramente affermati. Quindi, dai criteri di valutazione è subito chiaro che le competenze più importanti in questa fase sono
- TDD;
- Capacità di utilizzare l'OOP e scrivere codice gestibile;
- capacità di programmazione in coppia
Quindi, sono stato avvertito di trascorrere quell'ora e mezza pensando a come avrei svolto il compito, piuttosto che scrivere codice. Scriveremo insieme il codice.
Quando abbiamo parlato al telefono, i ragazzi ci hanno detto brevemente chi sono e cosa fanno e si sono offerti di iniziare lo sviluppo.
Durante tutta l'intervista non ho mai avuto la sensazione di essere intervistato. C'è la sensazione che stai sviluppando codice in una squadra. Se rimani bloccato da qualche parte, ti aiutano, ti consigliano, discutono e persino discutono tra loro su come farlo al meglio. Durante il colloquio, ho dimenticato come verificare in JUnit 5 che un metodo lancia un'eccezione: si sono offerti di continuare a scrivere il test, mentre uno di loro cercava su Google come farlo.
Letteralmente poche ore dopo il colloquio, ho ricevuto un feedback costruttivo: cosa mi è piaciuto e cosa no. Nel mio caso, sono stato elogiato per aver utilizzato le classi Sealed come alternativa all'oggetto null; per il fatto che prima di scrivere il codice ho scritto in pseudocodice come vorrei controllare il rover, e così ho ricevuto uno schizzo delle classi, almeno quelle coinvolte nell'API del robot.
Passaggio 2: raccontacelo
Una settimana prima del colloquio, mi è stato chiesto di preparare una presentazione su qualsiasi argomento che mi interessasse. Il formato è semplice e familiare: 15 minuti di presentazione, 15 minuti di risposta alle domande.
Ho scelto Clean Architecture di Uncle Bob. E ancora una volta sono stato intervistato da un paio di persone. Questa è stata la mia prima esperienza di presentazione in inglese e, forse, se mi fossi trovata in una situazione stressante, non sarei stata in grado di farcela. Ma ancora una volta, non ho mai avuto la sensazione di essere ad un colloquio. Tutto è come al solito: dico loro, ascoltano attentamente. Anche la tradizionale sessione di domande e risposte non era come un’intervista; era chiaro che le domande non venivano poste per “affondare”, ma quelle che realmente interessavano loro nella mia presentazione.
Un paio d'ore dopo l'intervista, ho ricevuto un feedback: la presentazione è stata molto utile ed è stato davvero piacevole ascoltarla.
Fase 3. Codice di qualità della produzione
Avendo avvertito che questa era l'ultima fase dei colloqui tecnici, mi è stato chiesto di portare il codice a casa in uno stato pronto per la produzione, quindi inviare il codice per la revisione e programmare i colloqui in cui i requisiti per l'attività sarebbero cambiati e il codice sarebbe stato modificato. richiedere modifiche. Guardando al futuro, posso dire che la revisione del codice viene effettuata alla cieca, i revisori non conoscono la posizione per la quale il candidato si candida, non vedono il suo CV, non vedono nemmeno il suo nome.
Il telefono squillò e di nuovo c'erano un paio di ragazzi dall'altra parte del monitor. Tutto è uguale al primo colloquio: l'importante è non dimenticare TDD, raccontare cosa fai e perché. Se non hai mai praticato il TDD prima, allora ti consiglio di iniziare a farlo immediatamente, non perché sia necessario nelle aziende, ma perché ti semplifica notevolmente la vita, riduce il livello di stress se lo desideri. Ricordi come dovevi cercare freneticamente con un debugger un errore che può essere riprodotto solo tramite il browser, ma non puoi riprodurlo con i test? Ora immagina che dovrai cogliere un simile errore durante un'intervista: ti garantiranno un paio di capelli grigi. Cosa otteniamo con TDD? Abbiamo cambiato il codice e inaspettatamente ci siamo resi conto che ora i test sono rossi, ma qual è l'errore che non riusciamo a capire la prima volta? Ok, diciamo "Oops" agli intervistatori, premiamo Ctrl-Z e iniziamo a fare piccoli passi avanti. E sì, devi sviluppare in te stesso la capacità di sviluppare utilizzando TDD, la capacità di andare verso l'obiettivo in modo che i tuoi test siano permanentemente verdi, e non rossi per mezza giornata, perché "hai molto refactoring". Questa è esattamente la stessa abilità di scrivere codice gestibile o scrivere codice produttivo.
Quindi, quanto bene il tuo codice può essere modificato dipende dal progetto che hai in mente per cominciare, da quanto è semplice e da quanto sono buoni i tuoi test.
Dopo il colloquio, ho ricevuto feedback nel giro di poche ore. A questo punto, mi sono reso conto che avevo quasi finito e che mancava molto poco prima di "incontrare Fowler".
Fase 4. Finale. Basta domande tecniche. Vogliamo sapere chi sei!
Sinceramente sono rimasto un po’ perplesso da questa formulazione della domanda. Come puoi capire che tipo di persona sono in un'ora di conversazione? E ancora di più, come puoi capirlo quando parlo una lingua che non è la mia lingua madre e, francamente, molto schifosa e impacciata. Nelle interviste precedenti, per me personalmente era più facile parlare piuttosto che rispondere alle domande, e la colpa era dell'accento. Almeno uno degli intervistatori era asiatico - e il loro accento, beh, diciamo solo, è in qualche modo specifico per l'orecchio europeo. Pertanto, ho deciso di adottare un approccio proattivo: preparare una presentazione su di me e all'inizio del colloquio offrirmi di parlare di me stesso con questa presentazione. Se sono d'accordo, almeno ci saranno meno domande per me; se rifiutano, beh, 3 ore della mia vita spese per una presentazione non sono un prezzo così alto. Ma cosa dovresti scrivere nella tua presentazione? Biografia - Nato lì, a quel tempo, andato a scuola, laureato all'università - ma chi se ne frega?
Se cerchi un po' su Google la cultura Thoughtworks, troverai un articolo di Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] che descrive i 3 pilastri: business sostenibile, eccellenza del software e giustizia sociale.
Supponiamo che il software Excellence sia già stato verificato per me. Resta da mostrare Business Sostenibile e Giustizia Sociale.
Inoltre, ho deciso di concentrarmi su quest'ultimo.
Per cominciare, gli ho spiegato perché ThoughtWorks: avevo letto il blog di Martin Fowler al college, da qui il mio amore per il codice pulito.
I progetti possono anche essere presentati da diverse angolazioni. Ha anche sviluppato un software per la medicina che ha semplificato la vita dei pazienti e, secondo alcune indiscrezioni, ha persino salvato una vita. Ho sviluppato anche software per le banche, che hanno reso la vita più facile anche ai cittadini. Soprattutto se questa banca viene utilizzata dal 70% della popolazione del Paese. Non si tratta di Sberbank e nemmeno della Russia.
Vuoi sapere di me? OK. Il mio hobby è la fotografia, in un modo o nell’altro ho in mano una macchina fotografica da circa 10 anni, ci sono fotografie che non mi vergogno troppo di mostrare. Inoltre, un tempo, ho aiutato un rifugio per gatti: ho fotografato gatti che avevano bisogno di una casa permanente. E con buone fotografie è molto più facile posizionare un gatto. Probabilmente ho fotografato un centinaio di gatti :)
Alla fine, l’80% della mia presentazione era piena di gatti.
Subito dopo la presentazione, l'HR mi ha scritto che non conosceva ancora i risultati del colloquio, ma l'intero ufficio era già impressionato dai gatti.
Alla fine ho aspettato il feedback: ho soddisfatto tutti come persona.
Ma durante la conversazione finale, le risorse umane hanno affermato con tatto che la giustizia sociale è molto buona e necessaria, ma non tutti i progetti sono così. E mi ha chiesto se mi spaventava. In generale, ho esagerato un po' con la giustizia sociale, succede :)
risultato
Di conseguenza, lavoro a Singapore presso Thoughtworks da diversi mesi ormai, e vedo che qui troppe aziende stanno adottando le "migliori pratiche di intervista" di Google, utilizzando fogli e lavagna per la codifica, nonostante abbiano più conoscenze di Spring, Symfony, RubyOnRails (sottolinea ciò che è necessario) non è richiesto nel lavoro. Gli ingegneri si prendono una settimana di pausa prima di un colloquio per “prepararsi”.
In Thoughtworks, oltre ai requisiti adeguati per il candidato, sono in primo piano i seguenti principi:
La gioia di intervistare. Inoltre, per entrambe le parti. In effetti, se vuoi ottenere il personale migliore (e chi non lo vuole?), allora un colloquio non è un mercato in cui vengono scelti gli schiavi, ma uno spettacolo in cui sia il datore di lavoro che il candidato si valutano a vicenda. E se un candidato associa emozioni piacevoli a un'azienda, è probabile che sceglierà questa particolare azienda
Multiple interviewers to mitigate bias. Presso Thoughtworks, la programmazione in coppia è lo standard de facto. E se questa pratica può essere applicata ad altri ambiti, TW tenta di farlo. In ogni fase, l'intervista è condotta da 2 persone. Pertanto, ogni persona viene valutata da almeno 8 persone e TW cerca di selezionare intervistatori con background diversi, direzioni diverse (non solo tecnici) e genere.
Alla fine, la decisione sull'assunzione verrà presa sulla base delle opinioni di almeno 8 persone e nessuno avrà un voto decisivo.
Assunzioni basate sugli attributi Invece di prendere una decisione in base alle simpatie o antipatie di un candidato, viene sviluppato un modulo per ciascun ruolo e ciascuna fase che include gli attributi da valutare. Allo stesso tempo, durante la valutazione, si consiglia vivamente di valutare non l'esperienza in una determinata abilità, ma la capacità di applicarla. Pertanto, se un candidato non è stato in grado di applicare alcuna abilità, come il TDD, ma cerca comunque di applicarle, ascolta consigli su come usarle correttamente, ha tutte le possibilità di superare il colloquio.
Certificati di istruzione non richiesti TW non richiede alcuna certificazione o formazione in informatica. Si valutano solo le competenze.
Questa è la prima intervista che ho avuto con aziende straniere per la quale non dovevo prepararmi. Dopo ogni fase non mi sentivo esausto, ma al contrario ero felice di poter applicare le migliori pratiche, che le persone dall’altra parte del monitor le apprezzassero e le applicassero ogni giorno.
Dopo diversi mesi posso dire che le mie aspettative sono state pienamente soddisfatte. In che modo ThoughtWorks è diversa da una normale azienda? In un'azienda normale puoi trovare bravi sviluppatori e persone simpatiche, ma in TW la loro concentrazione è fuori scala.
Se sei interessato a unirti a ThoughtWorks, puoi visualizzare le nostre posizioni aperte
Suggerisco anche di prestare attenzione ai posti vacanti interessanti:
Ingegnere software capo: , , ,
Senior Software Engineer: , , ,
Ingegnere del software: , ,
Ingegnere dati senior:
Analista della qualità:
Infrastruttura: , ,
(Vorrei onestamente avvisarti che il link è un link di riferimento, se vai su TW riceverò un bel bonus). Scegli l'ufficio che preferisci, non devi limitarti all'Europa, dopotutto ogni 2 anni TW sarà felice di trasferirti in un altro paese, perché... questo fa parte della politica di ThoughtWorks, quindi la cultura è diffusa e omogeneizzata.
Sentiti libero di porre domande nei commenti o chiedermi consigli.
Если тема показалась интересной, я напишу про то, как работается в ThoughtWorks и как живётся в Сингапуре.
Fonte: habr.com