Come prepararsi a un colloquio in Google e non superarlo. Due volte

Come prepararsi a un colloquio in Google e non superarlo. Due volte

Il titolo dell'articolo suona come un epic fail, ma in realtà le cose non sono così chiare. E in generale questa storia si è conclusa in modo piuttosto positivo, anche se non in Google. Ma questo è già un argomento per un altro articolo. In questo articolo parlerò di tre cose: come si è svolto il mio processo di preparazione, come si sono svolti i colloqui in Google e perché, secondo il mio punto di vista, le cose non sono così chiare come possono sembrare.

Come è iniziato tutto

Una fredda serata invernale a Cipro, improvvisamente mi è venuta in mente l'idea che le mie conoscenze in Computer Science classica sono piuttosto lontane dalla media, e bisognava fare qualcosa al riguardo. Se qualcuno non ha ancora letto perché la serata è cipriota e fredda, può scoprirlo qui qui. Dopo alcune riflessioni, ho deciso di iniziare a seguire un corso online su algoritmi e strutture dati. Da un ex collega ho sentito parlare del corso di Robert Sedgewick su Coursera. Il corso è composto da due parti (parte 1 e parte 2). Se le link cambiano, si può sempre cercare su Google utilizzando il nome dell'autore. Ogni parte dura 6 settimane. All'inizio della settimana si tengono le lezioni, e durante la settimana è necessario svolgere esercizi. La prima parte del corso copre le strutture dati di base, i principali tipi di ordinamenti e la complessità degli algoritmi. La seconda parte è già più avanzata, inizia con i grafi e termina con argomenti come la Programmazione Lineare e l'Intractabilità. Dopo aver riflettuto su tutto ciò, sono giunto alla conclusione che è proprio quello che mi serve. Qui, a proposito, un lettore curioso potrebbe chiedere: quale sia il legame con Google. E in effetti, fino a questo momento, non c'entrava affatto. Ma avevo bisogno di un obiettivo, poiché dedicare 12 settimane nelle sere senza un fine è un po' complicato. E quale obiettivo può esserci nell'acquisire nuove conoscenze? Certamente, la loro applicazione pratica. Nella vita quotidiana è piuttosto difficile, ma durante un colloquio in una grande azienda è molto più semplice. Una rapida ricerca su Google ha rivelato che Google (potete perdonarmi per la tautologia) è una delle più grandi aziende in Europa (e io stavo considerando proprio l'Europa), dove si tengono tali interviste. Infatti, il loro ufficio si trova a Zurigo, in Svizzera. Dunque, decisamente: studiamo e prepariamoci per un colloquio da Google.

Preparazione al primo accesso

12 settimane sono passate in un attimo e ho completato entrambi i corsi. Le mie impressioni sui corsi sono più che positive e posso raccomandarli a chiunque sia interessato. Mi sono piaciuti i corsi per i seguenti motivi:

  • Il relatore parla un inglese abbastanza chiaro
  • Il materiale è ben strutturato
  • Presentazioni fantastiche che mostrano il funzionamento di ciascun algoritmo
  • Selezione accurata dei materiali
  • Esercizi interessanti
  • Gli esercizi vengono controllati automaticamente sul sito, dopo di che viene generato un rapporto

Di solito, il mio lavoro sui corsi seguiva questo schema. In 1-2 giorni ascoltavo le lezioni. Poi effettuavo un rapido test sulla conoscenza del materiale. Il resto della settimana svolgevo l'esercizio in diverse iterazioni. Dopo il primo ricevevo il mio 30-70%, i successivi portavano il risultato al 97-100%. L'esercizio consisteva di solito nell'implementare un algoritmo, ad esempio Seam carving o bzip.

Dopo aver completato i corsi, ho realizzato che molte conoscenze comportano molte difficoltà. Se prima sapevo solo di non sapere nulla, ora ho cominciato a rendermi conto di cosa esattamente non so.

Poiché era solo maggio e avevo programmato il colloquio per l'autunno, ho deciso di continuare la mia formazione. Dopo aver esaminato i requisiti per la posizione, ho deciso di seguire parallelamente due direzioni: continuare lo studio degli algoritmi e seguire un corso base di apprendimento automatico. Per il primo obiettivo ho deciso di passare dai corsi a un libro, scegliendo il monumentale lavoro di Steven Skiena "Algoritmi. Manuale di progettazione" (The Algorithm Design Manual). Non così monumentale come quello di Knuth, ma comunque significativo. Per il secondo obiettivo, sono tornato su Coursera e mi sono iscritto al corso di Andrew Ng. Apprendimento automatico.

Sono passati altri 3 mesi e ho completato il corso e il libro.

Iniziamo con il libro. La lettura è risultata piuttosto interessante, anche se non semplice. In linea di massima, lo consiglierei, ma non in modo immediato. Complessivamente, il libro offre un'analisi più profonda di ciò che ho appreso nei corsi. Inoltre, ho scoperto (da un punto di vista formale) concetti come le euristiche e la programmazione dinamica. Ovviamente, li avevo già utilizzati in passato, ma non sapevo come si chiamassero. Nel libro ci sono anche diverse storie dalla vita dell'autore (War Story), che alleggeriscono un po' l'approccio accademico. La seconda metà del libro può essere, peraltro, trascurata; si concentra piuttosto sulla descrizione di problemi esistenti e sui metodi per risolverli. È utile se applicato regolarmente nella pratica, altrimenti si dimentica subito.

Il corso mi ha colpito molto. L’autore conosce chiaramente la materia e presenta le informazioni in modo interessante. Inoltre, gran parte del contenuto, in particolare l’algebra lineare e le basi delle reti neurali, era già familiare per me dall’università, quindi non ho riscontrato particolari difficoltà. La struttura del corso è abbastanza standard. Il corso è suddiviso in settimane. Ogni settimana ci sono prima lezioni alternate a brevi quiz. Dopo le lezioni viene assegnato un compito che deve essere completato, inviato e verrà controllato automaticamente. In breve, l’elenco degli argomenti trattati nel corso è il seguente:
— funzione di costo
— regressione lineare
— discesa del gradiente
— scaling delle feature
— equazione normale
— regressione logistica
— classificazione multiclass (uno contro tutti)
— reti neurali
— retropropagazione
— regolarizzazione
— bias/varianza
— curve di apprendimento
— metriche di errore (precisione, richiamo, F1)
— Support Vector Machines (classificazione a margine largo)
— K-means
— Analisi delle Componenti Principali
— rilevamento di anomalie
— filtraggio collaborativo (sistema di raccomandazione)
— discesa del gradiente stocastica, mini-batch, batch
— apprendimento online
— map reduce
— analisi del tetto
Dopo aver completato il corso, avevo una buona comprensione di tutti questi temi. Dopo 2 anni, però, quasi tutto è inevitabilmente dimenticato. Consiglio a chi non ha familiarità con il machine learning di seguire questo corso per ottenere una buona comprensione delle basi necessarie per progredire.

Primo approccio

Era già settembre e arrivava il momento di pensare a un colloquio. Dato che candidarsi tramite il sito non era molto pratico, ho iniziato a cercare conoscenti che lavorassero in Google. La mia scelta è ricaduta su datacompboy, poiché era l'unico che conoscevo direttamente (sebbene non personalmente). Ha accettato di inoltrare il mio curriculum e, poco dopo, ho ricevuto una mail da un recruiter che mi invitava a prenotare uno slot nel suo calendario per una prima conversazione. Dopo un paio di giorni c'è stata la chiamata. Abbiamo provato a comunicare tramite Hangouts, ma la qualità era scarsa, quindi siamo passati al telefono. Inizialmente abbiamo discusso rapidamente le consuete domande sul come, perché e cosa, per poi passare al colloquio tecnico. Questo consisteva in una decina di domande come "qual è la complessità di inserimento in una hash map?", "quali alberi bilanciati conosci?" Non è difficile, se si ha una conoscenza di base di queste cose. Il colloquio tecnico è andato bene e, in base ai risultati, abbiamo deciso di organizzare il primo colloquio dopo una settimana.

L'intervista è avvenuta tramite Hangouts. All'inizio abbiamo parlato di me per circa 5 minuti, poi siamo passati al problema. Il compito riguardava i grafi. Ho capito rapidamente cosa dovevo fare, ma ho scelto l'algoritmo sbagliato. Quando ho iniziato a scrivere il codice, me ne sono reso conto e sono passato a un'altra opzione, che ho completato. L'intervistatore ha posto alcune domande sulla complessità dell'algoritmo e se ci fosse un modo più veloce. In quel momento, sono stato un po' insicuro e non sono riuscito a rispondere. Alla fine del tempo, ci siamo salutati. Poi, dopo circa 10 minuti, mi è venuto in mente che, al posto dell'algoritmo di Dijkstra che avevo usato, in questo caso specifico si sarebbe potuto usare la ricerca in ampiezza, che sarebbe stata più veloce. Dopo un po', il recruiter mi ha chiamato dicendo che l'intervista era andata bene e sarebbe stato meglio organizzare un'altra. Abbiamo fissato un appuntamento per un'altra settimana.

Questa volta è andata peggio. Se la prima volta l'intervistatore era amichevole e socievole, questa volta sembrava abbastanza cupo. Non sono riuscito a capire subito il compito, anche se le idee che ho espresso avrebbero potuto portare a una soluzione. Alla fine, dopo alcuni suggerimenti dell'intervistatore, ho trovato la soluzione. Anche questa volta si trattava di una ricerca in ampiezza, solo da più punti. Ho scritto le soluzioni, rispettando il tempo, ma ho dimenticato i casi limite. Dopo un po', mi ha chiamato il reclutatore per informarmi che l'intervistatore non era soddisfatto, poiché a suo avviso avevo bisogno di troppi suggerimenti (3 o 4) e cambiavo continuamente il codice mentre lo scrivevo. Dopo due colloqui, è stata presa la decisione di non andare avanti e di posticipare il prossimo colloquio di un anno, se avessi avuto voglia. Così ci siamo salutati.

E da questa storia ho tratto alcune conclusioni:

  • La teoria va bene, ma bisogna orientarsi rapidamente in essa.
  • La teoria senza pratica non aiuta. È necessario risolvere problemi e portare la scrittura del codice all'automatismo.
  • Molto dipende dall'intervistatore. E su questo non si può fare nulla.

Preparazione per il secondo tentativo

Dopo aver riflettuto sulla situazione, ho deciso di riprovare tra un anno e ho leggermente rivisto l'obiettivo. Se prima l'obiettivo principale era lo studio, con il colloquio in Google come una carota lontana, ora il colloquio era l'obiettivo e lo studio uno strumento.
Quindi, è stato sviluppato un nuovo piano che comprendeva i seguenti punti:

  • Continuare a studiare la teoria leggendo libri e articoli.
  • Affrontare problemi algoritmici per un totale di 500-1000.
  • Continuare a studiare la teoria guardando video.
  • Continuare a studiare la teoria attraverso corsi.
  • Studiare le esperienze di altre persone sui colloqui in Google.

Il piano è stato completato da me nell’arco di un anno. Di seguito descriverò cosa ho fatto in ciascuno dei punti.

Libri e articoli

Non riesco nemmeno a ricordare il numero di articoli letti, li ho letti sia in russo che in inglese. Il sito più utile si è rivelato probabilmente questo. Qui è raccolta una descrizione di un gran numero di algoritmi interessanti con esempi di codice.

Ho letto 5 libri: Algorithms, 4th edition (Sedgewick, Wayne), Introduction to Algorithms 3rd Edition (Cormen, Leiserson, Rivest, Stein), Cracking the Coding Interview 4th edition (Gayle Laakmann), Programming Interviews Exposed 2nd edition (Mongan, Suojanen, Giguere), Elements of Programming Interviews (Aziz, Lee, Prakash). Possono essere suddivisi in 2 categorie. La prima include i libri di Sedgewick e Cormen. Questi trattano la teoria. Gli altri sono preparazione per i colloqui. Sedgewick nel suo libro spiega sostanzialmente le stesse cose che nei suoi corsi. È solo scritto. Non ha molto senso leggerlo attentamente se hai seguito il corso, ma vale la pena dargli un'occhiata. Se non hai seguito il corso, leggere è utile. Cormen mi è sembrato piuttosto noioso. Onestamente, l'ho affrontato con difficoltà. Ne ho ricavato solo teorema del maestro, e alcune strutture dati raramente usate (Fibonacci heap, albero di van Emde Boas, radix heap).

È utile leggere almeno un libro per prepararsi ai colloqui. Sono tutti costruiti più o meno secondo lo stesso principio. Descrivono il processo di colloquio nelle grandi aziende tecnologiche, forniscono nozioni di base di Computer Science, esercizi su questi concetti e la loro soluzione con relative spiegazioni. Tra i tre citati, consiglierei probabilmente Cracking the Coding Interview come principale, mentre gli altri possono essere letti per approfondire.

Problemi algoritmici

Questo è stato probabilmente il punto più interessante della preparazione. Certo, si può semplicemente sedere e risolvere problemi. Ci sono molti siti diversi per questo. Io ho principalmente utilizzato tre: Hackerrank, CodeChef e LeetCode. Su CodeChef i problemi sono suddivisi per difficoltà, ma non per argomenti. Su Hackerrank, invece, lo sono sia per difficoltà che per argomenti.

Ma come ho scoperto subito, c'è un modo più interessante. Si tratta delle competizioni (programming challenges o programming contests). Tutti e tre i siti le offrono. Tuttavia, con LeetCode c'è un problema: il fuso orario scomodo. Quindi non ho partecipato a quel sito. Hackerrank e CodeChef offrono un numero considerevole di diverse competizioni, della durata che varia da 1 ora a 10 giorni. Ogni formato ha diverse regole, ma si può parlare a lungo di questo. La sostanza principale, per cui le competizioni sono utili, è l'inserimento di un elemento competitivo (e di nuovo, tautologia) nel processo di apprendimento.

In totale ho partecipato a 37 competizioni su Hackerrank. Di queste, 32 erano a punteggio, mentre 5 erano sponsorizzate (ho persino ricevuto 25$ in una di esse) o puramente per divertimento. Nelle competizioni a punteggio sono entrato 10 volte nel top 4%, 11 volte nel top 12% e 5 volte nel top 25%. I migliori risultati sono stati 27/1459 in una competizione di 3 ore e 22/9721 in una settimanale.

Sono passato a CodeChef quando le competizioni su Hackerrank sono diventate meno frequenti. Ho partecipato a 5 competizioni in totale. Il mio miglior risultato è stato 426/5019 in una competizione di dieci giorni.

In totale, tra competizioni e semplicemente per divertimento, ho risolto un po' più di 1000 problemi, il che rientrava nei miei piani. Purtroppo, al momento non ho tempo libero per continuare l'attività competitiva e non ho nemmeno obiettivi per cui potrei giustificare il mio tempo non libero. Ma è stato divertente. Consiglio a chi è interessato di trovare menti affini. In due o in gruppo è molto più interessante. Mi sono divertito con un amico, quindi forse è stato per questo che è andato così bene.

Guarda il video

Dopo aver letto il libro di Skiena, mi sono interessato a ciò che fa. Proprio come Sedgwick, è professore all'università. Perciò, online puoi trovare video delle sue lezioni. Ho deciso di guardare il corso COMP300E — Programming Challenges — 2009 HKUST. Non posso dire che mi sia piaciuto molto. In primo luogo, la qualità del video non è eccezionale. In secondo luogo, non ho provato a risolvere i problemi trattati nel corso. Quindi il mio coinvolgimento non è stato molto alto.
Durante la risoluzione dei problemi, cercando di trovare l'algoritmo giusto, sono inciampato nei video di Tushar Roy. Ha lavorato ad Amazon e ora lavora in Apple. Come ho poi scoperto, ha anche un canale su YouTube, dove condivide analisi di diversi algoritmi. Al momento della scrittura dell'articolo, il canale contiene 103 video. Devo dire che le analisi che presenta sono fatte molto bene. Ho provato a guardare altri autori, ma non mi sono piaciuti. Quindi, questo canale lo consiglio sicuramente.

Partecipazione ai corsi

Qui non ho fatto molto. Ho guardato video del Android Developer Nanodegree di Google e ho completato un corso dell'ITMO Come vincere nelle competizioni di coding: segreti dei campioni. Il Nanodegree è abbastanza valido, anche se naturalmente non ho scoperto nulla di nuovo. Il corso dell'ITMO è un po' confuso sul piano teorico, ma gli esercizi erano interessanti. Non lo consiglierei come punto di partenza, ma in fondo il tempo speso non è stato sprecato.

Studiare l'esperienza di altre persone

Naturalmente molte persone hanno cercato di entrare in Google. Alcuni ce l'hanno fatta, altri no. Alcuni hanno scritto articoli a riguardo. Tra le cose interessanti, probabilmente posso evidenziare questo e questo. Nel primo caso, la persona ha preparato per sé una lista delle cose da imparare per diventare Software Engineer e entrare in Google. Alla fine è entrato in Amazon, ma questo non è così importante. Il secondo manuale è scritto da un ingegnere di Google, Larissa Agarova (Larrr). Inoltre, puoi anche leggere il suo blog.

Ha senso leggere le recensioni dei colloqui su Glassdoor. Sono tutte più o meno simili, ma si può trarre qualche utile informazione.

Non fornirò link ad altri articoli minori, riuscirai a trovarli facilmente su Google.

Seconda battuta

Ed è passato un anno. È stato un anno molto intenso dal punto di vista dello studio. Ma con l'arrivo di questa nuova autunno mi sentivo con conoscenze teoriche molto più approfondite e abilità pratiche consolidate. Mancavano solo poche settimane alla scadenza che mi era stata assegnata per la preparazione, quando improvvisamente ho ricevuto un'email da un recruiter di Google, nella quale mi chiedeva se avessi ancora il desiderio di lavorare in Google e se fossi disponibile a parlare con lui. Naturalmente, non avevo nulla in contrario. Ci siamo accordati per una chiamata una settimana dopo. Inoltre, mi hanno chiesto un curriculum aggiornato, al quale ho aggiunto una breve descrizione di ciò che ho fatto durante l'anno al lavoro e in generale.

Dopo aver parlato della vita, abbiamo deciso che dopo una settimana ci sarebbe stato un colloquio su Hangouts, tutto come l'anno scorso. È passata una settimana, è arrivato il momento del colloquio, ma l'intervistatore non si è presentato. Sono passati 10 minuti, e già iniziavo a innervosirmi, quando all'improvviso qualcuno è entrato nella chat. Come si è scoperto poco dopo, il mio intervistatore non è riuscito a presentarsi per qualche motivo e hanno trovato urgentemente un sostituto. La persona era un po' impreparata sia per quanto riguarda la configurazione del computer, sia per lo svolgimento del colloquio. Ma poi tutto è andato bene. Ho risolto rapidamente il compito, descrivendo dove c'erano possibili insidie e come evitarle. Abbiamo discusso diverse varianti del compito, la complessità dell'algoritmo. Poi abbiamo chiacchierato per altri 5 minuti, l'ingegnere ha condiviso le sue impressioni sul lavoro a Monaco (a Zurigo evidentemente non sono riusciti a trovare un sostituto), e così ci siamo salutati.

Nello stesso giorno mi ha contattato un recruiter e mi ha informato che il colloquio era andato benissimo e che erano pronti a invitarmi a un colloquio in ufficio. Il giorno dopo ci siamo sentiti via Hangouts e abbiamo discusso i dettagli. Poiché dovevo richiedere un visto, abbiamo deciso di fissare il colloquio tra un mese.

Mentre preparavo i documenti, ho discusso con il reclutatore riguardo al prossimo colloquio. Il colloquio standard in Google consiste in 4 domande algoritmiche e uno di System Design. Tuttavia, poiché mi stavo candidando come sviluppatore Android, mi è stato detto che parte del colloquio avrebbe avuto specificità relative ad Android. Non sono riuscito a ottenere informazioni precise dal reclutatore su quali fossero queste specificità. Da quanto ho capito, è una novità relativamente recente e lui stesso non ne era molto informato. Inoltre, sono stato iscritto a due sessioni di allenamento: su come affrontare un colloquio algoritmico e su come affrontare un colloquio di System Design. Le sessioni sono state di utilità media. Anche lì, nessuno è riuscito a dirmi quali domande vengono poste agli sviluppatori Android. Pertanto, la mia preparazione in questo mese si è ridotta a quanto segue:

  • L'acquisto di una lavagna per scrivere e la scrittura di 2-3 dozzine dei più popolari algoritmi a memoria. 3-5 ogni giorno. In totale, ognuno è stato scritto diverse volte.
  • Un ripasso di varie informazioni su Android, che non utilizzo ogni giorno.
  • La visione di alcuni video su Big Scale e simili.

Come già detto, nel frattempo stavo preparando i documenti per il viaggio. Innanzitutto, mi hanno chiesto dei dati per redigere una lettera di invito. Poi ho passato molto tempo a cercare di capire chi a Cipro si occupasse dei visti per la Svizzera, dato che l'ambasciata svizzera non si occupa di questo. Alla fine ho scoperto che è il consolato austriaco a gestirlo. Ho telefonato e prenotato un appuntamento. Lì mi hanno richiesto un pacco di documenti, ma nulla di particolarmente interessante. Foto, passaporto, permesso di soggiorno, una serie di certificati e naturalmente la lettera di invito. Nel frattempo, la lettera continuava a non arrivare. Alla fine, sono partito con una semplice stampa e questo è andato bene. La lettera è arrivata dopo circa 3 giorni; il FedEx cipriota non è riuscito a trovare il mio indirizzo e ho dovuto andarci di persona. Ho anche ritirato, sempre da FedEx, un pacco che non erano riusciti a consegnarmi, perché non avevano trovato l'indirizzo, e che era lì da giugno (5 mesi, incredibile). Non ne sapevo nulla, e ovviamente non mi aspettavo avessero qualcosa per me. Ho ottenuto il visto in tempo, dopo di che mi hanno prenotato un hotel e offerto opzioni per il volo. Ho modificato le opzioni per rendere il viaggio più comodo. Non c'erano voli diretti, quindi sono volato lì passando per Atene e sono tornato tramite Vienna.

Dopo che tutte le formalità per il viaggio erano state sistemate, passarono ancora alcuni giorni e finalmente partii per Zurigo. Arrivai senza imprevisti. Dall'aeroporto alla città presi il treno, che era veloce e comodo. Dopo aver girovagato un po' per la città, trovai l'hotel e mi sistemai. Poiché l'hotel era prenotato senza pasti, cenai nei dintorni e andai a letto, dato che il volo era al mattino e avevo già bisogno di riposare. Il giorno successivo feci colazione in hotel (a pagamento) e mi diressi verso l'ufficio di Google. A Zurigo, Google ha diversi uffici. Il mio colloquio non si svolgeva nel principale. In generale, l'ufficio sembrava piuttosto normale, quindi non ebbi modo di vedere tutti i vantaggi di un 'normale' ufficio Google. Mi registrai alla reception e mi sedetti in attesa. Dopo un po', uscì il reclutatore e mi spiegò il programma della giornata, poi mi portò in una stanza dove si sarebbero svolti i colloqui. In programma c'erano 3 colloqui, un pranzo e altri 2 colloqui.

Colloquio numero uno

Il primo colloquio riguardava Android. In effetti non aveva nulla a che vedere con gli algoritmi. Una sorpresa, però. Ma va bene, è anche più abituale. Mi hanno chiesto di realizzare un certo componente UI. Prima abbiamo discusso cosa e come fare. Ho proposto una soluzione in RxJava, spiegando cosa avrei fatto e perché. Mi hanno detto che andava bene, ma per favore facciamo con gli strumenti del framework Android. E in più scriviamo il codice sulla lavagna. Non solo del componente, ma di tutta l'Activity che utilizza quel componente. A questo non ero preparato. È una cosa scrivere un algoritmo di 30-50 righe sulla lavagna, un'altra è scrivere codice Android, anche se con abbreviazioni e commenti del tipo "beh, questo non lo scriverò perché è ovvio". È uscito un vero e proprio guazzabuglio su 3 lavagne. Cioè, ho risolto il compito, ma sembrava confuso.

Colloquio numero due

Questa volta l'intervista riguardava gli algoritmi. Gli intervistatori erano due. Uno era l'intervistatore principale, mentre l'altro era un giovane padawan (shadow interviewer). Dovevo ideare una struttura dati con determinate proprietà. Inizialmente abbiamo discusso il problema come al solito. Ho posto diverse domande e l'intervistatore ha risposto. Dopo un po', mi hanno chiesto di scrivere alcuni metodi della struttura ideata sulla lavagna. Questa volta è andata relativamente bene, anche se con alcuni piccoli errori, che ho corretto grazie ai suggerimenti dell'intervistatore.

Intervista numero tre

Questa volta si trattava di System Design, che si è rivelato essere anche Android. Dovevamo sviluppare un'applicazione con determinate funzionalità. Abbiamo discusso i requisiti per l'applicazione, il server e il protocollo di comunicazione. Poi ho iniziato a descrivere quali componenti o librerie avrei utilizzato per costruire l'applicazione. Ma quando si è parlato del Job Scheduler, ho avuto un intoppo. Il punto è che non l'ho mai usato nella pratica, perché al momento del suo rilascio mi ero appena trasferito a supportare applicazioni in cui non c'erano affatto attività per il suo utilizzo. Anche durante lo sviluppo delle successive è stato lo stesso. In teoria so cosa sia, quando e come viene applicato, ma non ho esperienza pratica. E all'intervistatore sembra che questo non sia piaciuto molto. Poi mi hanno chiesto di scrivere del codice. Sì, durante lo sviluppo dell'applicazione bisogna scrivere codice fin da subito. Di nuovo, codice Android sulla lavagna. È risultato nuovamente un po' brutto.

Pranzo

Doveva venire un'altra persona, ma non si è presentata. Anche Google ha le sue defaillance. Alla fine, ho pranzato con l'intervistatore precedente, il suo collega, e poco dopo si è unito il successivo intervistatore. Il pranzo è stato piuttosto buono. Inoltre, dato che non si trovava nella sede principale a Zurigo, la mensa sembrava abbastanza normale, anche se molto accogliente.

Intervista numero quattro

Finalmente algoritmi in tutta la loro essenza. Ho risolto il primo problema abbastanza rapidamente e in modo efficiente, anche se ho sbagliato su un caso al limite, ma con l'aiuto dell'intervistatore (che ha fornito proprio quel caso al limite) ho trovato il problema e l'ho corretto. Naturalmente, dovevo scrivere il codice sulla lavagna. Poi è stata proposta un'attività simile, ma più difficile. Per quella ho trovato un paio di soluzioni non ottimali e stavo per trovare quella ottimale, mi mancavano solo 5-10 minuti per sviluppare l'idea. E non ho avuto il tempo di scrivere il codice per essa.

Intervista numero cinque

E ancora un'intervista Android. Mi chiedo perché ho studiato algoritmi per tutto quest'anno?
All'inizio ci sono state alcune domande semplici. Poi l'intervistatore ha scritto del codice sulla lavagna e mi ha chiesto di trovare i problemi. Ho trovato, spiegato e corretto. Ne abbiamo discusso. Poi sono cominciate alcune domande inaspettate, del tipo «cosa fa il metodo Y nella classe X», «cosa c'è dentro il metodo Y», «cosa fa la classe Z». Qualcosa ho risposto, ma poi ho detto che nell'ultimo periodo del mio lavoro non mi ero trovato di fronte a queste cose e naturalmente non ricordavo chi, cosa e come faceva i dettagli. Dopo l'intervistatore ha chiesto cosa facessi attualmente. E le domande sono andate in questa direzione. Qui ho risposto molto meglio.

Dopo il colloquio finale mi hanno preso il pass, mi hanno augurato buona fortuna e mi hanno mandati via. Ho passeggiato un po' per la città, ho cenato e sono andato in hotel, dove sono caduto addormentato, dato che il volo era di nuovo presto al mattino. Il giorno dopo sono arrivato a Cipro senza problemi. Ho scritto un feedback sul colloquio a richiesta del reclutatore e ho compilato un modulo in un servizio apposito per il rimborso delle spese. Tra tutte le spese, Google paga direttamente solo i voli. L'hotel, il cibo e il trasporto sono coperti dal candidato. Poi compiliamo il modulo, alleghiamo le ricevute e lo inviamo a un'agenzia speciale. Loro lo elaborano e inviano abbastanza rapidamente il rimborso sul conto.

Ci sono volute circa due settimane per elaborare i risultati del colloquio. Dopo di che mi hanno informato che ero "un po' sotto la media". Cioè, non ce l'ho fatta. Se vogliamo essere specifici, 2 colloqui sono andati bene, 2 non molto bene, e il System Design è andato davvero male. Se almeno 3 fossero andati bene, avrei potuto competere, ma così non c'era possibilità. Mi hanno proposto di riprovare dopo un anno.

Inizialmente mi sono sentito un po' deluso, poiché avevo investito molte energie nella preparazione, e nel momento dell'intervista stavo già considerando di lasciare Cipro. Ottenere un lavoro in Google e trasferirmi in Svizzera sembrava una grande opportunità.

Conclusione

E ora arriviamo alla parte finale dell'articolo. Sì, ho fallito due volte nell'intervista di Google. È triste. Probabilmente sarebbe stato interessante lavorare lì. Ma possiamo anche guardare la questione da un'altra prospettiva.

  • In un anno e mezzo ho appreso una quantità enorme di cose relative allo sviluppo software.
  • Ho provato un grande piacere partecipando a competizioni di programmazione.
  • Sono stato a Zurigo per un paio di giorni. Quando ci tornerò ancora?
  • Ho acquisito un'esperienza interessante in un colloquio con una delle più grandi aziende IT del mondo.

Pertanto, tutto ciò che è accaduto in questi diciotto mesi può essere semplicemente considerato un apprendimento o un allenamento. I risultati di questo allenamento si sono già fatti sentire. La mia decisione di lasciare Cipro è maturata (a causa di alcune circostanze familiari), ho superato con successo diversi colloqui in un'altra azienda conosciuta e dopo 8 mesi mi sono trasferito. Ma questa è un'altra storia. Tuttavia, penso che valga la pena ringraziare Google sia per questi diciotto mesi in cui ho lavorato su me stesso, sia per i 2 giorni interessanti a Zurigo.

Cosa posso dire in conclusione. Se lavori nel settore IT, preparati per i colloqui in Google (Amazon, Microsoft, Apple, ecc.). Potrebbe essere che un giorno tu riesca a entrarci. Anche se non lo desideri, credimi, una tale preparazione non ti farà male. Nel momento in cui capirai di poter (anche solo con un po' di fortuna) superare un colloquio in una di queste aziende, si apriranno davanti a te molte più strade rispetto a prima della tua preparazione. E tutto ciò di cui avrai bisogno lungo il cammino sono un obiettivo, determinazione e tempo. Ti auguro successo 🙂

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS 🔥 Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS | ProHoster