Tittelen på artikkelen høres ut som episk feil, men i virkeligheten er ikke alt så enkelt. Og generelt endte denne historien veldig positivt, men ikke i Google. Men dette er et tema for en annen artikkel. I denne samme artikkelen vil jeg snakke om tre ting: hvordan forberedelsesprosessen min gikk, hvordan intervjuene hos Google fant sted, og hvorfor, etter min mening, ikke alt er så klart som det kan virke.
Hvordan det hele begynte
En kald kypriotisk vinterkveld gikk plutselig tanken opp for meg at min kunnskap om klassisk informatikk var veldig langt fra ens gjennomsnittlig, og noe måtte gjøres med det. Hvis noen forresten ikke har lest hvorfor kvelden er kypriotisk og kald, så kan du finne ut om det . Etter litt omtanke ble det bestemt å starte med å ta et nettkurs om algoritmer og datastrukturer. Fra en av mine tidligere kolleger hørte jeg om Robert Sedgewicks kurs på Coursera. Kurset består av to deler ( и ). Hvis koblingene plutselig endres, kan du alltid Google forfatterens navn. Hver del varer i 6 uker. Forelesninger holdes i begynnelsen av uken, og i løpet av uken må du fortsatt gjøre øvelser. Første del av kurset dekker grunnleggende datastrukturer, grunnleggende sorteringstyper og kompleksiteten til algoritmer. Den andre delen er allerede mer avansert, starter med grafer og slutter med slike ting som lineær programmering og intractability. Etter å ha tenkt på alt ovenfor, kom jeg til den konklusjonen at dette er akkurat det jeg trenger. Forresten, kan en nysgjerrig leser spørre, hva har Google med det å gjøre? Og faktisk, inntil dette øyeblikket hadde han ingenting med det å gjøre i det hele tatt. Men jeg trengte et mål, siden det å studere 12 uker på kveldene uten mål er litt vanskelig. Hva kan hensikten være med å tilegne seg ny kunnskap? Selvfølgelig, deres anvendelse i praksis. I hverdagen er dette ganske problematisk, men under et intervju med et stort selskap er det enkelt. En rask Google viste at Google (tilgi tautologien) er et av de største selskapene i Europa (og jeg så spesielt på Europa) som gjennomfører slike intervjuer. Kontoret deres ligger nemlig i Zürich, Sveits. Så det er bestemt - la oss studere og gå på et intervju hos Google.
Forbereder seg på den første tilnærmingen
De 12 ukene gikk fort og jeg fullførte begge kursene. Mitt inntrykk av kursene er mer enn positivt, og jeg kan anbefale dem til alle som er interessert. Jeg likte kursene av følgende grunner:
- Foreleseren snakker ganske tydelig engelsk
- Materialet er godt strukturert
- Nydelige presentasjoner som viser innsiden av hver algoritme
- Kompetent valg av materiale
- Interessante øvelser
- Øvelser sjekkes automatisk på siden, hvoretter det genereres en rapport
Arbeidet mitt med kurs gikk vanligvis slik. Jeg hørte på forelesninger på 1-2 dager. Deretter tok de en rask test av kunnskapen om materialet. Resten av uken gjorde jeg øvelsen i flere iterasjoner. Etter den første fikk jeg mine 30-70%, de påfølgende brakte resultatet til 97-100%. Øvelsen innebar vanligvis å implementere en eller annen algoritme, f.eks. eller .
Etter å ha fullført kursene innså jeg at mye kunnskap kommer med mye sorg. Hvis jeg før bare visste at jeg ikke visste noe, begynte jeg nå å innse at det var jeg som ikke visste.
Siden det bare var mai måned, og jeg planla intervjuet til høsten, bestemte jeg meg for å fortsette utdannelsen. Etter å ha gjennomgått kravene til stillingen ble det besluttet å gå i to retninger parallelt: fortsette å studere algoritmer og ta et grunnkurs i maskinlæring. For det første målet bestemte jeg meg for å bytte fra kurs til en bok og valgte Steven Skienas monumentale verk «Algorithms. The Algoritme Design Manual. Ikke like monumental som Knut sin, men likevel. For det andre målet dro jeg tilbake til Coursera og meldte meg på Andrew Ngs kurs. .
Ytterligere 3 måneder gikk og jeg fullførte kurset og boken.
La oss starte med boken. Lesingen viste seg å være ganske interessant, men ikke lett. I prinsippet vil jeg anbefale boken, men ikke med en gang. Samlet sett gir boken et mer inngående blikk på hva jeg lærte på kurset. I tillegg oppdaget jeg (fra et formelt synspunkt) slike ting som heuristikk og dynamisk programmering. Naturligvis hadde jeg brukt dem før, men jeg visste ikke hva de het. Boken inneholder også en rekke historier fra forfatterens liv (War Story), som noe utvanner presentasjonens akademiske karakter. Den andre halvdelen av boken kan forresten utelates, den inneholder heller en beskrivelse av eksisterende problemer og metoder for å løse dem. Det er nyttig hvis det brukes regelmessig i praksis, ellers vil det bli glemt umiddelbart.
Jeg var mer enn fornøyd med kurset. Forfatteren kan tydelig tingene sine og snakker på en interessant måte. Pluss en god del av det, nemlig lineær algebra og det grunnleggende om nevrale nettverk, husket jeg fra universitetet, så jeg opplevde ingen spesielle vanskeligheter. Oppbyggingen av kurset er ganske standard. Kurset er delt inn i uker. Hver uke er det forelesninger blandet med korte prøver. Etter forelesningene får du en oppgave som du skal gjøre, levere, og den blir automatisk sjekket. Kort fortalt er listen over ting som undervises i kurset som følger:
- kostnadsfunksjon
- lineær regresjon
- gradientnedstigning
- funksjonsskalering
- normal ligning
- logistisk regresjon
– flerklasseklassifisering (én mot alle)
- nevrale nettverk
- tilbakeforplantning
- regulering
— skjevhet/varians
— læringskurver
— feilmålinger (presisjon, tilbakekalling, F1)
— Støtte vektormaskiner (klassifisering med stor margin)
— K-betyr
— Hovedkomponentanalyse
- oppdagelse av anomalier
— samarbeidsfiltrering (anbefalingssystem)
— stokastiske, minibatch, batchgradientnedstigninger
— læring på nett
- kart reduksjon
- takanalyse
Etter endt kurs var det en forståelse av alle disse temaene. Etter 2 år var nesten alt naturlig glemt. Jeg anbefaler det til de som ikke er kjent med maskinlæring og ønsker å få en god forståelse av grunnleggende ting å gå videre med.
Første forsøk
Det var allerede september og det var på tide å tenke på et intervju. Siden det er ganske katastrofalt å søke gjennom nettstedet, begynte jeg å se etter venner som jobber hos Google. Valget falt på , siden han var den eneste jeg kjente direkte (selv om ikke personlig). Han gikk med på å videresende CV-en min, og snart mottok jeg et brev fra rekruttereren som tilbød å reservere en plass på kalenderen hans for den første samtalen.Et par dager senere fant samtalen sted. Vi prøvde å kommunisere via Hangouts, men kvaliteten var forferdelig, så vi byttet til telefonen. Først diskuterte vi raskt standarden hvordan, hvorfor og hvorfor, og gikk deretter over til teknisk screening. Det besto av et dusin spørsmål i ånden "hva er vanskeligheten med å sette inn i et hash-kart", "hvilke balanserte trær kjenner du." Det er ikke vanskelig hvis du har grunnleggende kunnskap om disse tingene. Screeningen gikk bra og basert på resultatene bestemte de seg for å organisere det første intervjuet om en uke.
Intervjuet fant også sted via Hangouts. Først snakket de om meg i ca 5 minutter, så gikk de videre til problemet. Problemet var på grafene. Jeg skjønte raskt hva som måtte gjøres, men jeg valgte feil algoritme. Da jeg begynte å skrive kode skjønte jeg dette og byttet til et annet alternativ, som jeg fullførte. Intervjueren stilte flere spørsmål om kompleksiteten til algoritmen og spurte om det kunne gjøres raskere. Jeg ble på en eller annen måte matt og klarte det ikke. På dette tidspunktet var tiden ute og vi sa farvel. Så, etter omtrent 10 minutter, gikk det opp for meg at i stedet for Dijkstra-algoritmen som jeg brukte, kunne jeg i dette spesielle problemet bruke bredde-først-søk, og det ville være raskere. Etter en tid ringte rekruttereren og sa at intervjuet totalt sett gikk bra og at et nytt burde organiseres. Vi ble enige om en uke til.
Denne gangen ble ting verre. Hvis intervjueren første gang var vennlig og sosial, var han denne gangen noe dyster. Jeg kunne ikke finne ut av problemet med en gang, selv om ideene jeg kom opp med i prinsippet kunne føre til løsningen. Til slutt, etter flere oppfordringer fra intervjueren, kom løsningen til meg. Denne gangen viste det seg å være et bredde-første søk igjen, kun fra flere punkter. Jeg skrev løsningene, møtte dem i tide, men glemte kantsakene. Etter en tid ringte rekruttereren og sa at denne gangen var intervjueren misfornøyd, fordi etter hans mening trengte jeg for mange hint (3 eller 4 stykker) og jeg endret hele tiden koden mens jeg skrev. Basert på resultatene fra to intervjuer ble det besluttet å ikke gå videre, men å utsette neste intervju i ett år hvis jeg ønsket det. Derfor sa vi farvel.
Og fra denne historien trakk jeg flere konklusjoner:
- Teori er bra, men du må raskt navigere i den
- Teori uten praksis vil ikke hjelpe. Vi må løse problemer og bringe koding til automatikk.
- Mye avhenger av intervjueren. Og ingenting kan gjøres med det.
Forbereder til andre løpetur
Etter å ha tenkt over situasjonen, bestemte jeg meg for å prøve igjen om et år. Og litt redigert målet. Hvis hovedmålet tidligere var å studere, og et intervju hos Google var som en fjern gulrot, nå var det å bestå et intervju målet, og å studere var midlet.
Så en ny plan ble utviklet, som inkluderte følgende punkter:
- Fortsett å studere teori ved å lese bøker og artikler.
- Løs algoritmiske problemer i mengden 500-1000 stykker.
- Fortsett å lære teorien ved å se videoer.
- Fortsett å studere teori gjennom kurs.
- Studer andres erfaringer med intervjuer hos Google.
Jeg fullførte planen i løpet av et år. Deretter vil jeg beskrive nøyaktig hva jeg gjorde for hvert av punktene.
Bøker og artikler
Jeg husker ikke engang hvor mange artikler jeg leste; jeg leste dem både på russisk og engelsk. Sannsynligvis den mest nyttige siden . Her kan du finne en beskrivelse av et stort antall interessante algoritmer med kodeeksempler.
Jeg leste 5 bøker: 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), elementer i programmeringsintervjuer (Aziz, Lee, Prakash). De kan deles inn i 2 kategorier. Den første inkluderer bøker av Sedgwick og Corman. Dette er en teori. Resten er forberedelse til intervjuet. Sedgwick forteller om det samme i boken som på sine kurs. Bare skriftlig. Det er ikke mye vits i å lese det nøye hvis du har tatt kurset, men det er uansett verdt å skumme. Hvis du ikke har sett kurset, er det fornuftig å lese det. Cormen virket for kjedelig for meg. For å være ærlig hadde jeg vanskelig for å mestre det. Jeg tok den ut derfra , og flere sjelden brukte datastrukturer (Fibonacci-haug, van Emde Boas-tre, radix-haug).
Det er verdt å lese minst én bok for å forberede seg til et intervju. De er alle bygget etter omtrent samme prinsipp. De beskriver intervjuprosessen i store teknologibedrifter, gir grunnleggende ting fra Datavitenskap, problemer for disse grunnleggende tingene, løsninger på problemer og analyse av løsninger. Av de tre ovenfor vil jeg nok anbefale Cracking the Coding Interview som den viktigste, og resten er valgfrie.
Algoritmiske problemer
Dette var sannsynligvis det mest interessante forberedelsespunktet. Du kan selvfølgelig sette deg ned og løse problemer dumt. Det finnes mange forskjellige sider for dette. Jeg brukte hovedsakelig tre: , и . På CodeChef er problemer delt inn etter vanskelighetsgrad, men ikke etter emne. På Hackerrank både etter kompleksitet og etter emne.
Men som jeg umiddelbart fant ut selv, er det en mer interessant måte. Og dette er konkurranser (programmeringsutfordringer eller programmeringskonkurranser). Alle tre nettstedene gir dem. Riktignok er det et problem med LeetCode - en upraktisk tidssone. Det er derfor jeg ikke deltok på denne siden. Hackerrank og CodeChef gir et ganske stort antall forskjellige konkurranser, som varer fra 1 time til 10 dager. Ulike formater har forskjellige regler, men det kan vi snakke om lenge. Hovedpoenget hvorfor konkurranser er bra er introduksjonen av et konkurransedyktig (og igjen tautologi) element i læringsprosessen.
Totalt deltok jeg i 37 konkurranser på Hackerrank. Av disse var 32 klassifiserte, og 5 ble enten sponset (jeg mottok til og med $25 i en av dem) eller for moro skyld. I rangeringen var jeg i topp 10% 4 ganger, i topp 11% 12 ganger og i topp 5% 25 ganger. De beste resultatene var 27/1459 på 3 timer og 22/9721 i uken.
Jeg byttet til CodeChef da Hackerrank begynte å arrangere konkurranser sjeldnere. Totalt klarte jeg å delta i 5 konkurranser. Beste poengsum var 426/5019 i ti dagers konkurransen.
Totalt, på konkurranser og sånn, løste jeg litt mer enn 1000 oppgaver, som passet inn i planen. Nå er det dessverre ikke ledig tid til å fortsette konkurranseaktiviteter, likesom det ikke er noe mål som den ufrie tiden kan avskrives for. Men det var gøy. Jeg anbefaler de som er interessert i dette å finne likesinnede. Sammen eller i en gruppe er det mye mer interessant. Jeg koste meg med dette med en venninne, så det gikk kanskje bra.
Se video
Etter å ha lest boken til Skiena ble jeg interessert i hva han gjorde. I likhet med Sedgwick er han universitetsprofessor. I denne forbindelse kan videoer av kursene hans bli funnet på nettet. Jeg bestemte meg for å vurdere kurset . Jeg kan ikke si at jeg likte det veldig godt. For det første er ikke videokvaliteten særlig god. For det andre forsøkte jeg ikke å løse problemene som ble diskutert i kurset selv. Så engasjementet var ikke særlig høyt.
Mens jeg løste problemer og prøvde å finne den riktige algoritmen, kom jeg over videoen til Tushar Roy. Han jobbet hos Amazon og jobber nå hos Apple. Som jeg senere fant ut selv, har han , hvor han legger ut en analyse av ulike algoritmer. I skrivende stund inneholder kanalen 103 videoer. Og jeg må si at analysen hans ble gjort veldig bra. Jeg prøvde å se andre forfattere, men på en eller annen måte fungerte det ikke. Så jeg kan absolutt anbefale denne kanalen for visning.
Tar kurs
Jeg gjorde ikke noe spesielt her. Så en video fra Googles Android-utvikler Nanodegree og tok et kurs fra ITMO . Nanodegree er ganske bra, selv om jeg naturligvis ikke lærte noe nytt av det. Kurset fra ITMO er litt skjevt i forhold til teorien, men problemstillingene var interessante. Jeg vil ikke anbefale å begynne med det, men i prinsippet var det vel brukt tid.
Lær av andres erfaringer
Selvfølgelig prøvde mange mennesker å komme inn på Google. Noen kom inn, noen ikke. Noen har skrevet artikler om dette. Av de interessante tingene vil jeg nok nevne и . I det første tilfellet utarbeidet personen en liste over hva han trenger å lære for å bli programvareingeniør og komme inn på Google. Det endte til slutt opp i Amazon, men det er ikke så viktig lenger. Den andre håndboken ble skrevet av Google-ingeniør, Larisa Agarkova (). I tillegg til dette dokumentet kan du også lese .
Det er fornuftig å lese anmeldelser av intervjuer på Glassdoor. De er alle mer eller mindre like, men du kan få litt nyttig informasjon.
Jeg vil ikke gi lenker til andre små artikler; du kan enkelt finne dem på Google.
Andre kjøring
Og nå har det gått et år. Det viste seg å være veldig intenst studiemessig. Men jeg nærmet meg den nye høsten med mye dypere teoretisk kunnskap og utviklet praktiske ferdigheter. Det var fortsatt noen uker igjen før slutten av året tildelt meg for forberedelse, da det plutselig dukket opp et brev fra en rekrutterer fra Google i posten, der han spurte meg om jeg fortsatt hadde et ønske om å jobbe i Google og ville Jeg har noe imot å snakke med ham. Naturligvis hadde jeg ikke noe imot det. Vi ble enige om å ringe om en uke. De ba meg også om en oppdatert CV, der jeg la en kort beskrivelse av hva jeg hadde gjort i løpet av året på jobb og generelt.
Etter å ha kommunisert for livet, bestemte vi oss for at om en uke skulle det være et Hangout-intervju, akkurat som i fjor. Det gikk en uke, det var tid for intervju, men intervjueren dukket ikke opp. 10 minutter gikk, jeg begynte allerede å bli nervøs, da plutselig noen brast inn i chatten. Som det viste seg litt senere, kunne intervjueren min av en eller annen grunn ikke dukke opp, og det ble raskt funnet en erstatning for ham. Personen var noe uforberedt både med tanke på oppsett av datamaskinen og med tanke på å gjennomføre intervjuet. Men så gikk alt bra. Jeg løste problemet raskt, beskrev hvor fallgruvene var mulige, og hvordan de kunne omgås. Vi diskuterte flere ulike versjoner av problemet og kompleksiteten til algoritmen. Så snakket vi i ytterligere 5 minutter, ingeniøren fortalte oss inntrykkene sine av å jobbe i München (de fant tilsynelatende ikke en akutt erstatning i Zürich), og så skiltes vi.
Samme dag tok rekruttereren kontakt med meg og sa at intervjuet gikk bra og de var klare til å invitere meg til intervju på kontoret. Dagen etter ringte vi via Hangouts og diskuterte detaljene. Siden jeg trengte å søke om visum, bestemte vi oss for å planlegge et intervju om en måned.
Mens jeg forberedte dokumentene diskuterte jeg samtidig det kommende intervjuet med rekruttereren. Et standardintervju hos Google består av 4 algoritmeintervjuer og ett System Design-intervju. Men siden jeg søkte som Android-utvikler, ble jeg fortalt at en del av intervjuet ville være Android-spesifikk. Jeg kunne ikke riste det ut av rekruttereren nøyaktig hva og hva detaljene ville være. Så vidt jeg forstår ble dette innført relativt nylig og han selv var lite bevisst. Jeg ble også meldt på to treningsøkter: hvordan bestå et algoritmisk intervju og hvordan bestå et systemdesignintervju. Øktene var av gjennomsnittlig nytte. Der var det heller ingen som kunne fortelle meg hva de spør Android-utviklere om. Derfor kokte min forberedelse for denne måneden ned til følgende:
- Kjøpe et merkebrett og skrive 2-3 dusin av de mest populære algoritmene på det fra minnet. 3-5 stykker hver dag. Til sammen ble hver skrevet flere ganger.
- Oppdater minnet ditt med forskjellig informasjon på Android som du ikke bruker hver dag
- Ser på noen videoer om Big Scale og sånt
Som jeg allerede sa, forberedte jeg samtidig dokumenter for turen. Til å begynne med ba de meg om informasjon for å lage et invitasjonsbrev. Så prøvde jeg lenge å finne ut hvem på Kypros som utsteder visum til Sveits, siden den sveitsiske ambassaden ikke tar seg av dette. Det viste seg at det østerrikske konsulatet gjør dette. Jeg ringte og avtalte en avtale. De ba om en haug med dokumenter, men ikke noe spesielt interessant. Foto, pass, oppholdstillatelse, en haug med forskjellige attester og selvfølgelig et invitasjonsbrev. I mellomtiden kom ikke brevet. Til slutt gikk jeg med en vanlig utskrift og det fungerte ganske bra. Selve brevet kom 3 dager senere, og den kypriotiske FedEx klarte ikke å finne adressen min, og jeg måtte hente den selv. Samtidig fikk jeg en pakke fra samme FedEx, som de heller ikke kunne levere til meg, siden de ikke fant adressen, og som hadde ligget der siden juni (5 måneder, Karl). Siden jeg ikke visste om det, antok jeg naturligvis ikke at de hadde det. Jeg mottok visumet mitt i tide, hvoretter de booket meg et hotell og tilbød meg flyalternativer. Jeg har justert alternativene for å gjøre det mer praktisk. Det var ikke lenger direktefly, så jeg endte opp med å fly dit via Athen og tilbake via Wien.
Etter at alle formalitetene med turen var ordnet, gikk det noen dager til og jeg fløy faktisk til Zürich. Kom dit uten uhell. Fra flyplassen til byen tok jeg toget – raskt og greit. Etter å ha vandret litt rundt i byen fant jeg et hotell og sjekket inn. Siden hotellet var booket uten mat, spiste jeg middag ved siden av og la meg, fordi flyet var om morgenen og jeg ville allerede sove. Dagen etter spiste jeg frokost på hotellet (for ekstra penger) og dro til Google-kontoret. Google har flere kontorer i Zürich. Intervjuet mitt var ikke sentralt. Og generelt så kontoret ganske vanlig ut, så jeg hadde ikke mulighet til å se på alle godsakene til et "vanlig" Google-kontor. Jeg registrerte meg hos administratoren og satte meg ned for å vente. Etter en tid kom rekruttereren ut og fortalte meg planen for dagen, hvorpå han tok meg med til rommet hvor intervjuene skulle foregå. Egentlig inneholdt planen 3 intervjuer, lunsj og 2 intervjuer til.
Intervju nummer én
Det første intervjuet var bare på Android. Og det hadde ingenting med algoritmer å gjøre. Overraskelse, skjønt. Vel, ok, det er enda mer vanlig på denne måten. Vi ble bedt om å lage en viss UI-komponent. Først diskuterte vi hva og hvordan. Han tilbød seg å lage en løsning ved å bruke RxJava, beskrev nøyaktig hva han ville gjøre og hvorfor. De sa at dette absolutt er bra, men la oss gjøre det ved å bruke Android-rammeverket. Og samtidig skal vi skrive koden på tavlen. Og ikke bare en komponent, men hele aktiviteten som bruker denne komponenten. Det var dette jeg ikke var klar for. Det er én ting å skrive en 30-50 linjers algoritme på tavlen, og en annen ting å skrive nudler med Android-kode, selv med forkortelser og kommentarer i ånden "vel, jeg vil ikke skrive det, siden det allerede er åpenbart." Resultatet ble en slags vinaigrette for 3 brett. De. Jeg løste problemet, men det så teit ut.
Intervju nummer to
Denne gangen handlet intervjuet om algoritmer. Og det var to intervjuere. Den ene er den faktiske intervjueren, og den andre er en ung padawan (skyggeintervjuer). Det var nødvendig å komme opp med en datastruktur med visse egenskaper. Først diskuterte vi problemet som vanlig. Jeg stilte forskjellige spørsmål, svarte intervjueren. Etter en tid ble de bedt om å skrive flere metoder for den oppfunne strukturen på tavlen. Denne gangen var jeg mer eller mindre vellykket, om enn med noen få mindre feil, som jeg korrigerte etter oppfordring fra intervjueren.
Intervju nummer tre
Denne gangen System Design, som plutselig også viste seg å være Android. Det var nødvendig å utvikle en applikasjon med en viss funksjonalitet. Vi diskuterte kravene til applikasjonen, serveren og kommunikasjonsprotokollen. Deretter begynte jeg å beskrive hvilke komponenter eller biblioteker jeg ville bruke når jeg bygger applikasjonen. Og så, når man nevner Job Scheduler, var det litt forvirring. Poenget er at jeg aldri brukte det i praksis, siden jeg på tidspunktet for utgivelsen nettopp hadde byttet til støtteapplikasjoner der det ikke var noen oppgaver for bruk. Det samme skjedde ved utvikling av påfølgende. Det vil si at jeg i teorien vet hva denne tingen er, når og hvordan den brukes, men jeg har ingen erfaring med å bruke den. Og intervjueren så ikke ut til å like det noe særlig. Så ba de meg skrive litt kode. Ja, når du utvikler en applikasjon må du umiddelbart skrive kode. Igjen Android-kode på brettet. Det viste seg skummelt igjen.
Lunsj
En annen person skulle komme, men det gjorde han ikke. Og Google gjør feil. Som et resultat gikk jeg til lunsj med den forrige intervjueren, hennes kollega, og litt senere ble neste intervjuer med. Lunsjen var ganske grei. Igjen, siden dette ikke er hovedkontoret i Zürich, så spisestuen ganske vanlig ut, men veldig fin.
Intervju nummer fire
Til slutt, algoritmer i sin reneste form. Jeg løste det første problemet ganske raskt og umiddelbart effektivt, selv om jeg gikk glipp av ett kanttilfelle, men etter oppfordring fra intervjueren (han ga akkurat denne kantsaken) fant jeg problemet og rettet det. Selvfølgelig måtte jeg skrive koden på tavlen. Da ble en lignende oppgave gitt, men vanskeligere. For den fant jeg et par ikke-optimale løsninger og fant nesten den optimale, 5-10 minutter var ikke nok til å fullføre tanken. Vel, jeg hadde ikke tid til å skrive koden for det.
Intervju nummer fem
Og igjen Android-intervju. Jeg lurer på hvorfor jeg studerte algoritmer hele året?
Først var det noen enkle spørsmål. Så skrev intervjueren kode på tavlen og ba om å finne problemer i den. Fant det, forklarte det, fikset det. Diskutert. Og så begynte noen uventede spørsmål i ånden av "hva gjør metode Y i klasse X", "hva er inne i metode Y", "hva gjør klasse Z". Selvfølgelig svarte jeg på noe, men så sa jeg at jeg ikke har støtt på dette i arbeidet mitt i det siste, og naturlig nok husker jeg ikke hvem som gjør hva og hvordan i detalj. Etter det spurte intervjueren hva jeg gjorde nå. Og spørsmålene gikk på dette emnet. Jeg har allerede svart mye bedre her.
Etter slutten av siste intervju tok de passet mitt, ønsket meg lykke til og sendte meg videre. Jeg gikk litt rundt i byen, spiste middag og dro til hotellet, hvor jeg la meg, siden flyet igjen var tidlig på morgenen. Dagen etter kom jeg trygt til Kypros. På forespørsel fra rekruttereren skrev jeg tilbakemelding på intervjuet og fylte ut et skjema i en spesiell tjeneste for å returnere pengene som ble brukt. Av alle utgifter betaler Google direkte kun for billetter. Hotell, mat og reise betales av kandidaten. Deretter fyller vi ut skjemaet, legger ved kvitteringene og sender det til et spesialkontor. De behandler dette og overfører penger til kontoen ganske raskt.
Det tok en og en halv uke å behandle intervjuresultatene. Deretter ble jeg informert om at jeg var "litt under baren." Det vil si at jeg kom litt til kort. Mer spesifikt gikk 2 intervjuer bra, 2 litt ikke så bra, og System Design ikke så bra. Nå, hvis minst 3 hadde gått bra, så ville vi ha vært i stand til å konkurrere, ellers er det ingen sjanse. De tilbød seg å komme tilbake om et nytt år.
Først var jeg selvfølgelig opprørt, fordi det hadde blitt brukt mye krefter på forberedelser, og da intervjuet ble gjennomført, tenkte jeg allerede på å forlate Kypros. Å bli med i Google og flytte til Sveits virket som et flott alternativ.
Konklusjon
Og her kommer vi til den siste delen av artikkelen. Ja, jeg mislyktes i Google-intervjuet to ganger. Det er trist. Det ville nok vært interessant å jobbe der. Men du kan se på saken fra den andre siden.
- På halvannet år lærte jeg en enorm mengde ting knyttet til programvareutvikling.
- Jeg hadde det veldig gøy å delta i programmeringskonkurranser.
- Jeg dro til Zürich for et par dager. Når skal jeg dit igjen?
- Jeg hadde en interessant intervjuopplevelse hos et av de største IT-selskapene i verden.
Dermed kan alt som skjedde i løpet av disse halvannet årene rett og slett betraktes som trening, eller trening. Og resultatene av denne treningen gjorde seg gjeldende. Ideen min om å forlate Kypros modnet (på grunn av familieforhold), jeg bestod flere intervjuer med et annet kjent selskap og flyttet etter 8 måneder. Men det er en helt annen historie. Jeg tror imidlertid at jeg fortsatt bør takke Google både for det halvannet året jeg jobbet med selv, og for 2 interessante dager i Zürich.
Hva kan jeg si til slutt? Hvis du jobber innen IT, forbered deg på intervjuer hos Google (Amazon, Microsoft, Apple osv.). Kanskje du en dag drar dit for å komme dit. Selv om du ikke vil, tro meg, en slik forberedelse vil ikke gjøre deg noe verre. I det øyeblikket du innser at du kan (selv om bare med flaks) få et intervju med et av disse selskapene, vil mange flere veier være åpne for deg enn før du begynte forberedelsene. Og alt du trenger underveis er hensikt, utholdenhet og tid. Jeg ønsker deg suksess :)
Kilde: www.habr.com