Artiklens titel lyder som episk fiasko, men i virkeligheden er alt ikke så enkelt. Og generelt endte denne historie meget positivt, dog ikke i Google. Men dette er et emne for en anden artikel. I samme artikel vil jeg tale om tre ting: hvordan min forberedelsesproces forløb, hvordan interviewene hos Google fandt sted, og hvorfor alt efter min mening ikke er så klart, som det kunne se ud.
Hvordan det hele begyndte
En kold cypriotisk vinteraften faldt tanken pludselig op for mig, at mit kendskab til klassisk datalogi var meget langt fra endog gennemsnitligt, og det skulle der gøres noget ved. Hvis der i øvrigt ikke er nogen, der endnu har læst, hvorfor aftenen er cypriotisk og kold, så kan du finde ud af det . Efter lidt overvejelse blev det besluttet at starte med at tage et online kursus om algoritmer og datastrukturer. Fra en af mine tidligere kolleger hørte jeg om Robert Sedgewicks kursus på Coursera. Kurset består af to dele ( и ). Hvis linkene pludselig ændres, kan du altid Google forfatterens navn. Hver del varer 6 uger. Der holdes forelæsninger i starten af ugen, og i løbet af ugen mangler du stadig at lave øvelser. Første del af kurset dækker grundlæggende datastrukturer, grundlæggende sorteringstyper og kompleksiteten af algoritmer. Den anden del er allerede mere avanceret, startende med grafer og slutter med ting som Lineær Programmering og Intractability. Efter at have tænkt over alt det ovenstående kom jeg til den konklusion, at det er præcis, hvad jeg har brug for. I øvrigt kan en nysgerrig læser spørge, hvad har Google med det at gøre? Og faktisk, indtil dette øjeblik havde han slet ikke noget med det at gøre. Men jeg havde brug for et mål, da det er lidt svært at studere 12 uger om aftenen uden et mål. Hvad kunne formålet være med at tilegne sig ny viden? Selvfølgelig, deres anvendelse i praksis. I hverdagen er dette ret problematisk, men under et interview med en stor virksomhed er det nemt. En hurtig Google viste, at Google (tilgiv tautologien) er en af de største virksomheder i Europa (og jeg kiggede specifikt på Europa), der udfører sådanne interviews. Deres kontor ligger nemlig i Zürich, Schweiz. Så det er besluttet - lad os studere og gå til et interview hos Google.
Forberedelse til den første tilgang
De 12 uger gik hurtigt og jeg gennemførte begge kurser. Mit indtryk af kurserne er mere end positivt, og jeg kan anbefale dem til alle interesserede. Jeg kunne godt lide kurserne af følgende grunde:
- Underviseren taler ret tydeligt engelsk
- Materialet er godt struktureret
- Smukke præsentationer, der viser indersiden af hver algoritme
- Kompetent valg af materiale
- Interessante øvelser
- Øvelser tjekkes automatisk på sitet, hvorefter der genereres en rapport
Mit arbejde på kurser forløb som regel sådan. Jeg lyttede til foredrag på 1-2 dage. Derefter tog de en hurtig test af deres viden om materialet. Resten af ugen lavede jeg øvelsen i flere iterationer. Efter den første fik jeg mine 30-70%, de efterfølgende bragte resultatet til 97-100%. Øvelsen gik som regel ud på at implementere en eller anden algoritme, f.eks. eller .
Efter at have gennemført kurserne indså jeg, at meget viden kommer med en masse sorg. Hvis jeg før blot vidste, at jeg ikke vidste noget, begyndte jeg nu at indse, at det var mig, der ikke vidste det.
Da det kun var maj måned, og jeg planlagde samtalen til efteråret, besluttede jeg at fortsætte min uddannelse. Efter at have gennemgået kravene til den ledige stilling, blev det besluttet at gå i to retninger parallelt: fortsætte med at studere algoritmer og tage et grundkursus i maskinlæring. Til det første mål besluttede jeg at skifte fra kurser til en bog og valgte Steven Skienas monumentale værk "Algorithms. Algorithm Design Manual. Ikke så monumental som Knuts, men alligevel. Til det andet mål gik jeg tilbage til Coursera og tilmeldte mig Andrew Ngs kursus. .
Der gik yderligere 3 måneder, og jeg afsluttede kurset og bogen.
Lad os starte med bogen. Læsningen viste sig at være ret interessant, omend ikke let. I princippet vil jeg anbefale bogen, men ikke med det samme. Overordnet set giver bogen et mere dybdegående indblik i, hvad jeg lærte på kurset. Derudover opdagede jeg (fra et formelt synspunkt) sådanne ting som heuristik og dynamisk programmering. Jeg havde naturligvis brugt dem før, men jeg vidste ikke, hvad de hed. Bogen indeholder også en række fortællinger fra forfatterens liv (War Story), som noget udvander præsentationens akademiske karakter. Anden halvdel af bogen kan i øvrigt udelades, den indeholder snarere en beskrivelse af eksisterende problemer og metoder til at løse dem. Det er nyttigt, hvis det regelmæssigt bruges i praksis, ellers vil det blive glemt med det samme.
Jeg var mere end tilfreds med kurset. Forfatteren kan tydeligvis sit kram og taler på en interessant måde. Plus en hel del af det, nemlig lineær algebra og det grundlæggende i neurale netværk, huskede jeg fra universitetet, så jeg oplevede ingen særlige vanskeligheder. Opbygningen af kurset er ganske standard. Kurset er opdelt i uger. Hver uge er der foredrag blandet med korte tests. Efter forelæsningerne får du en opgave, som du skal lave, aflevere, og den bliver automatisk tjekket. Kort fortalt er listen over ting, der undervises i på kurset, som følger:
- omkostningsfunktion
- lineær regression
- gradient nedstigning
- skalering af funktioner
- normal ligning
- Logistisk regression
— multiklasse klassifikation (én mod alle)
- neurale netværk
- tilbageformering
- regulering
— bias/varians
— indlæringskurver
— fejlmålinger (præcision, genkald, F1)
— Support Vector Machines (klassificering med stor margin)
— K-betyder
— Hovedkomponentanalyse
- opdagelse af anomalier
— kollaborativ filtrering (recommeder-system)
— stokastiske, mini-batch, batch-gradient-nedstigninger
— online læring
- kort reducere
- loftsanalyse
Efter at have gennemført kurset var der en forståelse af alle disse emner. Efter 2 år var næsten alt naturligt glemt. Jeg anbefaler det til dem, der ikke er fortrolige med maskinlæring og ønsker at få en god forståelse af grundlæggende ting at komme videre med.
Første løb
Det var allerede september, og det var tid til at tænke på et interview. Da det er ret katastrofalt at ansøge via siden, begyndte jeg at lede efter venner, der arbejder hos Google. Valget faldt på , da han var den eneste, jeg kendte direkte (selvom ikke personligt). Han indvilligede i at videresende mit CV, og snart modtog jeg et brev fra rekrutteringsmedarbejderen, der tilbød at reservere en plads i hans kalender til den første samtale. Et par dage senere fandt opkaldet sted. Vi prøvede at kommunikere via Hangouts, men kvaliteten var forfærdelig, så vi skiftede til telefonen. Først diskuterede vi hurtigt standarden hvordan, hvorfor og hvorfor, og gik derefter videre til teknisk screening. Det bestod af et dusin spørgsmål i ånden "hvad er vanskeligheden ved at indsætte i et hash-kort", "hvilke balancerede træer kender du." Det er ikke svært, hvis du har en grundlæggende viden om disse ting. Screeningen gik godt, og på baggrund af resultaterne besluttede de at tilrettelægge det første interview om en uge.
Interviewet fandt også sted via Hangouts. Først talte de om mig i cirka 5 minutter, og gik så videre til problemet. Problemet var på graferne. Jeg indså hurtigt, hvad der skulle gøres, men jeg valgte den forkerte algoritme. Da jeg begyndte at skrive kode, indså jeg dette og skiftede til en anden mulighed, som jeg gennemførte. Intervieweren stillede flere spørgsmål om kompleksiteten af algoritmen og spurgte, om det kunne gøres hurtigere. Jeg blev på en eller anden måde kedelig og kunne ikke gøre det. På dette tidspunkt var tiden gået, og vi sagde farvel. Så, efter cirka 10 minutter, gik det op for mig, at i stedet for Dijkstra-algoritmen, som jeg brugte, kunne jeg i dette særlige problem bruge bredde-først-søgning, og det ville være hurtigere. Efter nogen tid ringede rekruttereren og sagde, at samtalen generelt gik godt, og at der skulle arrangeres endnu en. Vi blev enige om endnu en uge.
Denne gang blev tingene værre. Hvis intervieweren første gang var venlig og omgængelig, var han denne gang noget dyster. Jeg kunne ikke finde ud af problemet med det samme, selvom de ideer, jeg kom med, i princippet kunne føre til dets løsning. Til sidst, efter flere opfordringer fra intervieweren, kom løsningen til mig. Denne gang viste det sig igen at være en bredde-første søgning, kun fra flere punkter. Jeg skrev løsningerne, mødte dem til tiden, men glemte kantsagerne. Efter nogen tid ringede rekruttereren og sagde, at denne gang var intervieweren utilfreds, fordi jeg efter hans mening havde brug for for mange hints (3 eller 4 stykker), og jeg ændrede konstant koden, mens jeg skrev. På baggrund af resultaterne af to interviews blev det besluttet ikke at gå videre, men at udsætte næste samtale et år, hvis jeg ønskede det. Derfor sagde vi farvel.
Og ud fra denne historie trak jeg flere konklusioner:
- Teori er god, men du skal hurtigt navigere i den
- Teori uden praksis hjælper ikke. Vi skal løse problemer og bringe kodning til automatik.
- Meget afhænger af intervieweren. Og det kan der ikke gøres noget ved.
Forberedelse til anden løbetur
Efter at have tænkt over situationen besluttede jeg at prøve igen om et år. Og redigerede lidt i målet. Hvis hovedmålet tidligere var at studere, og et interview hos Google var som en fjern gulerod, nu var det at bestå et interview, og at studere var midlet.
Så der blev udviklet en ny plan, som indeholdt følgende punkter:
- Fortsæt med at studere teori ved at læse bøger og artikler.
- Løs algoritmiske problemer i mængden af 500-1000 stykker.
- Fortsæt med at lære teorien ved at se videoer.
- Fortsæt med at studere teori gennem kurser.
- Undersøg andres erfaringer med interviews hos Google.
Jeg gennemførte planen inden for et år. Dernæst vil jeg beskrive, hvad jeg præcist gjorde for hvert af punkterne.
Bøger og artikler
Jeg kan ikke engang huske antallet af artikler, jeg læste; jeg læste dem både på russisk og på engelsk. Sandsynligvis den mest nyttige side . Her kan du finde en beskrivelse af en lang række interessante algoritmer med kodeeksempler.
Jeg læste 5 bøger: Algorithms, 4. udgave (Sedgewick, Wayne), Introduction to Algorithms 3rd Edition (Cormen, Leiserson, Rivest, Stein), Cracking the Coding Interview 4. udgave (Gayle Laakmann), Programmeringsinterviews Exposed 2. udgave (Mongan, Suojanen) , Giguere), Elementer af programmeringsinterviews (Aziz, Lee, Prakash). De kan opdeles i 2 kategorier. Den første omfatter bøger af Sedgwick og Corman. Dette er en teori. Resten er forberedelse til samtalen. Sedgwick fortæller om det samme i bogen som på sine kurser. Bare på skrift. Det nytter ikke så meget at læse det grundigt, hvis du har taget kurset, men det er alligevel værd at skimme. Hvis du ikke har set kurset, giver det mening at læse det. Cormen virkede for kedelig for mig. For at være ærlig havde jeg svært ved at mestre det. Jeg tog den lige derfra , og flere sjældent brugte datastrukturer (Fibonacci heap, van Emde Boas træ, radix heap).
Det er værd at læse mindst én bog for at forberede sig til et interview. De er alle bygget efter nogenlunde samme princip. De beskriver interviewprocessen i store teknologivirksomheder, giver basale ting fra Datalogi, problemer for disse basale ting, løsninger på problemer og analyse af løsninger. Af de tre ovenstående vil jeg nok anbefale Cracking the Coding Interview som den vigtigste, og resten er valgfri.
Algoritmiske problemer
Dette var nok det mest interessante forberedelsespunkt. Du kan selvfølgelig sætte dig ned og løse problemer dumt. Der er mange forskellige sider til dette. Jeg brugte primært tre: , и . På CodeChef er problemer opdelt efter sværhedsgrad, men ikke efter emne. På Hackerrank både efter kompleksitet og efter emne.
Men som jeg straks selv fandt ud af, er der en mere interessant måde. Og det er konkurrencer (programmeringsudfordringer eller programmeringskonkurrencer). Alle tre websteder giver dem. Sandt nok er der et problem med LeetCode - en ubelejlig tidszone. Derfor deltog jeg ikke på denne side. Hackerrank og CodeChef giver et ret stort antal forskellige konkurrencer, der varer fra 1 time til 10 dage. Forskellige formater har forskellige regler, men det kunne vi tale om i lang tid. Hovedpointen, hvorfor konkurrencer er gode, er introduktionen af et konkurrencedygtigt (og igen tautologi) element i læringsprocessen.
I alt deltog jeg i 37 konkurrencer på Hackerrank. Af disse var 32 klassificerede, og 5 var enten sponsoreret (jeg modtog endda $25 i en af dem) eller for sjov. På ranglisten var jeg i top 10% 4 gange, i top 11% 12 gange og i top 5% 25 gange. De bedste resultater var 27/1459 på 3 timer og 22/9721 i ugen.
Jeg skiftede til CodeChef, da Hackerrank begyndte at være vært for konkurrencer sjældnere. I alt nåede jeg at deltage i 5 konkurrencer. Den bedste score var 426/5019 i den ti dage lange konkurrence.
I alt løste jeg ved konkurrencer og bare sådan lidt mere end 1000 opgaver, som passede ind i planen. Nu er der desværre ikke fritid til at fortsætte konkurrenceaktiviteter, ligesom der ikke er et mål, som den ledige tid kan afskrives til. Men det var sjovt. Jeg anbefaler dem, der er interesseret i dette, at finde ligesindede. Sammen eller i en gruppe er det meget mere interessant. Jeg hyggede mig med det her med en ven, så måske gik det godt.
Se video
Efter at have læst Skienas bog blev jeg interesseret i, hvad han lavede. Ligesom Sedgwick er han universitetsprofessor. I denne forbindelse kan videoer af hans kurser findes online. Jeg besluttede at gennemgå kurset . Jeg kan ikke sige, at jeg kunne lide det meget. Først og fremmest er videokvaliteten ikke særlig god. For det andet forsøgte jeg ikke selv at løse de problemer, der blev diskuteret i kurset. Så engagementet var ikke særlig højt.
Mens jeg løste problemer og prøvede at finde den rigtige algoritme, stødte jeg på Tushar Roys video. Han arbejdede hos Amazon og arbejder nu hos Apple. Som jeg senere selv fandt ud af, har han , hvor han poster en analyse af forskellige algoritmer. I skrivende stund indeholder kanalen 103 videoer. Og jeg må sige, at hans analyse var lavet meget godt. Jeg prøvede at se andre forfattere, men på en eller anden måde virkede det ikke. Så jeg kan klart anbefale denne kanal til visning.
Tager kurser
Jeg lavede ikke noget særligt her. Så en video fra Googles Android Developer Nanodegree og tog et kursus fra ITMO . Nanodegree er ret godt, selvom jeg naturligvis ikke lærte noget nyt af det. Forløbet fra ITMO er teorimæssigt lidt skævt, men problemerne var interessante. Jeg vil ikke anbefale at starte med det, men i princippet var tiden givet godt ud.
Lær af andres erfaringer
Selvfølgelig forsøgte mange mennesker at komme ind på Google. Nogle kom ind, nogle kom ikke. Nogle har skrevet artikler om dette. Af de interessante ting vil jeg nok nævne и . I det første tilfælde forberedte personen sig selv en liste over, hvad han skal lære for at blive softwareingeniør og komme ind på Google. Det endte til sidst i Amazon, men det er ikke så vigtigt længere. Den anden manual blev skrevet af Googles ingeniør, Larisa Agarkova (). Udover dette dokument kan du også læse .
Det giver mening at læse anmeldelser af interviews på Glassdoor. De er alle mere eller mindre ens, men du kan få nogle nyttige oplysninger.
Jeg vil ikke give links til andre små artikler; du kan nemt finde dem på Google.
Andet løb
Og nu er der gået et år. Det viste sig at være meget intenst i forhold til studier. Men jeg gik ind til det nye efterår med meget dybere teoretisk viden og udviklede praktiske færdigheder. Der var stadig et par uger tilbage inden udgangen af det år, jeg havde tildelt mig til forberedelse, da der pludselig faldt et brev fra en rekrutterer fra Google med posten, hvor han spurgte mig, om jeg stadig havde lyst til at arbejde hos Google og ville Jeg gider tale med ham. Det gad jeg naturligvis ikke. Vi blev enige om at ringe om en uge. De bad mig også om et opdateret CV, hvortil jeg tilføjede en kort beskrivelse af, hvad jeg havde lavet i løbet af året på arbejdet og generelt.
Efter at have kommunikeret for livet besluttede vi, at der om en uge ville være et Hangout-interview, ligesom sidste år. Der gik en uge, det var tid til interviewet, men intervieweren dukkede ikke op. Der gik 10 minutter, jeg var allerede begyndt at blive nervøs, da der pludselig var en der brød ind i chatten. Som det viste sig lidt senere, kunne min interviewer af en eller anden grund ikke dukke op, og der blev hurtigt fundet en afløser til ham. Personen var noget uforberedt både i forhold til opsætning af computeren og i forhold til at gennemføre interviewet. Men så gik alt godt. Jeg løste problemet hurtigt, beskrev, hvor faldgruber var mulige, og hvordan de kunne omgås. Vi diskuterede flere forskellige versioner af problemet og kompleksiteten af algoritmen. Så talte vi i yderligere 5 minutter, ingeniøren fortalte os sine indtryk af at arbejde i München (de fandt åbenbart ikke en akut afløser i Zürich), og så skiltes vi.
Samme dag kontaktede rekruttereren mig og sagde, at samtalen gik godt, og de var klar til at invitere mig til en samtale på kontoret. Næste dag ringede vi via Hangouts og diskuterede detaljerne. Da jeg skulle ansøge om visum, besluttede vi at planlægge en samtale om en måned.
Mens jeg forberedte dokumenterne, diskuterede jeg samtidig det kommende interview med rekrutteringsmanden. Et standardinterview hos Google består af 4 algoritmiske interviews og et System Design-interview. Men da jeg søgte et job som Android-udvikler, fik jeg at vide, at en del af interviewet ville være Android-specifikt. Jeg kunne ikke ryste det ud af rekrutteringsmedarbejderen præcis, hvad og hvad de specifikke detaljer ville være. Så vidt jeg har forstået, blev dette indført relativt for nylig, og han var selv ikke særlig opmærksom. Jeg var også tilmeldt to træningssessioner: hvordan man består et algoritmisk interview og hvordan man består et systemdesign-interview. Sessionerne var af gennemsnitlig nytte. Der var der heller ingen, der kunne fortælle mig, hvad de spørger Android-udviklere om. Derfor kogte min forberedelse til denne måned ned til følgende:
- At købe et markørtavle og skrive 2-3 dusin af de mest populære algoritmer på det fra hukommelsen. 3-5 stykker hver dag. I alt er hver skrevet flere gange.
- Opdater din hukommelse med forskellige oplysninger på Android, som du ikke bruger hver dag
- Ser et par videoer om Big Scale og sådan noget
Som jeg allerede sagde, var jeg samtidig ved at forberede dokumenter til turen. Til at begynde med bad de mig om oplysninger til at lave et invitationsbrev. Så forsøgte jeg i lang tid at finde ud af, hvem på Cypern der udsteder visa til Schweiz, da den schweiziske ambassade ikke beskæftiger sig med dette. Det viste sig, at det østrigske konsulat gør dette. Jeg ringede og lavede en aftale. De bad om en masse dokumenter, men ikke noget særligt interessant. Foto, pas, opholdstilladelse, en masse forskellige certifikater og selvfølgelig et invitationsbrev. I mellemtiden kom brevet ikke. Til sidst gik jeg med en almindelig udskrift, og det fungerede ganske godt. Selve brevet ankom 3 dage senere, og den cypriotiske FedEx kunne ikke finde min adresse, og jeg måtte selv hente den. Samtidig modtog jeg en pakke fra samme FedEx, som de heller ikke kunne levere til mig, da de ikke fandt adressen, og som havde ligget der siden juni (5 måneder, Karl). Da jeg ikke vidste om det, antog jeg naturligvis ikke, at de havde det. Jeg modtog mit visum til tiden, hvorefter de bookede mig et hotel og tilbød mig flymuligheder. Jeg har justeret mulighederne for at gøre det mere bekvemt. Der var ikke længere direkte fly, så jeg endte med at flyve dertil via Athen og tilbage via Wien.
Efter at alle formaliteterne med turen var afklaret, gik der et par dage mere, og jeg fløj faktisk til Zürich. Kom dertil uden hændelser. Fra lufthavnen til byen tog jeg toget – hurtigt og bekvemt. Efter at have vandret lidt rundt i byen fandt jeg et hotel og tjekkede ind. Da hotellet var booket uden mad, spiste jeg aftensmad ved siden af og gik i seng, for flyveturen var om morgenen, og jeg ville allerede sove. Næste dag spiste jeg morgenmad på hotellet (for ekstra penge) og gik til Google-kontoret. Google har flere kontorer i Zürich. Mit interview var ikke det centrale. Og generelt så kontoret ganske almindeligt ud, så jeg havde ikke en chance for at se på alt det gode ved et "normalt" Google-kontor. Jeg registrerede mig hos administratoren og satte mig ned for at vente. Efter noget tid kom rekruttereren ud og fortalte mig planen for dagen, hvorefter han tog mig med til det lokale, hvor samtalerne skulle foregå. Faktisk indeholdt planen 3 interviews, frokost og yderligere 2 interviews.
Interview nummer et
Det første interview var netop på Android. Og det havde overhovedet ikke noget med algoritmer at gøre. Overraskelse dog. Nå, okay, det er endnu mere almindeligt på denne måde. Vi blev bedt om at lave en bestemt UI-komponent. Først diskuterede vi hvad og hvordan. Han tilbød at lave en løsning ved hjælp af RxJava, beskrev, hvad han præcis ville gøre og hvorfor. De sagde, at dette bestemt er godt, men lad os gøre det ved hjælp af Android-rammen. Og samtidig vil vi skrive koden på tavlen. Og ikke kun en komponent, men hele den aktivitet, der bruger denne komponent. Det var det, jeg ikke var klar til. Det er én ting at skrive en 30-50 linjers algoritme på tavlen, og en anden ting at skrive nudler med Android-kode, selv med forkortelser og kommentarer i ånden "jamen, det vil jeg ikke skrive, da det allerede er indlysende." Resultatet blev en slags vinaigrette til 3 brædder. De der. Jeg løste problemet, men det så dumt ud.
Interview nummer to
Denne gang handlede interviewet om algoritmer. Og der var to interviewere. Den ene er den egentlige interviewer, og den anden er en ung padawan (skyggeinterviewer). Det var nødvendigt at komme med en datastruktur med bestemte egenskaber. Først diskuterede vi problemet som sædvanligt. Jeg stillede forskellige spørgsmål, svarede intervieweren. Efter nogen tid blev de bedt om at skrive flere metoder til den opfundne struktur på tavlen. Denne gang havde jeg mere eller mindre succes, dog med et par mindre fejl, som jeg rettede efter interviewerens foranledning.
Interview nummer tre
Denne gang System Design, som pludselig også viste sig at være Android. Det var nødvendigt at udvikle en applikation med en vis funktionalitet. Vi diskuterede kravene til applikationen, serveren og kommunikationsprotokollen. Dernæst begyndte jeg at beskrive, hvilke komponenter eller biblioteker jeg ville bruge, når jeg byggede applikationen. Og så, når man nævner Job Scheduler, var der en vis forvirring. Pointen er, at jeg aldrig brugte det i praksis, da jeg på tidspunktet for dets udgivelse lige havde skiftet til at understøtte applikationer, hvor der ikke var nogen opgaver til dets brug. Det samme skete ved udvikling af efterfølgende. Det vil sige, at jeg i teorien ved, hvad denne ting er, hvornår og hvordan den bruges, men jeg har ingen erfaring med at bruge den. Og intervieweren så ikke ud til at kunne lide det. Så bad de mig skrive noget kode. Ja, når du udvikler en applikation, skal du straks skrive kode. Igen Android-kode på tavlen. Det viste sig igen skræmmende.
Frokost
En anden person skulle komme, men det gjorde han ikke. Og Google laver fejl. Som et resultat gik jeg til frokost med den tidligere interviewer, hendes kollega, og lidt senere kom den næste interviewer med. Frokost var ganske anstændigt. Igen, da dette ikke er hovedkontoret i Zürich, så spisestuen ganske almindelig ud, selvom den var meget flot.
Interview nummer fire
Endelig algoritmer i deres reneste form. Jeg løste det første problem ret hurtigt og øjeblikkeligt effektivt, selvom jeg gik glip af en kant-case, men på interviewerens opfordring (han gav netop denne kant-case) fandt jeg problemet og rettede det. Selvfølgelig skulle jeg skrive koden på tavlen. Så blev der givet en lignende opgave, men sværere. Til den fandt jeg et par ikke-optimale løsninger og fandt næsten den optimale, 5-10 minutter var ikke nok til at gøre tanken færdig. Nå, jeg havde ikke tid til at skrive koden til det.
Interview nummer fem
Og igen Android-interview. Jeg spekulerer på, hvorfor jeg studerede algoritmer hele året?
Først var der et par simple spørgsmål. Derefter skrev intervieweren kode på tavlen og bad om at finde problemer i den. Fandt det, forklarede det, rettede det. Diskuteret. Og så begyndte nogle uventede spørgsmål i ånden af "hvad gør metode Y i klasse X", "hvad er inde i metode Y", "hvad gør klasse Z". Selvfølgelig svarede jeg noget, men så sagde jeg, at jeg ikke er stødt på dette i mit arbejde for nylig, og jeg husker naturligvis ikke, hvem der gør hvad og hvordan i detaljer. Derefter spurgte intervieweren, hvad jeg lavede nu. Og spørgsmålene gik på dette emne. Jeg har allerede svaret meget bedre her.
Efter afslutningen af det sidste interview tog de mit pas, ønskede mig held og lykke og sendte mig af sted. Jeg gik lidt rundt i byen, spiste aftensmad og gik til hotellet, hvor jeg gik i seng, da flyveturen igen var tidligt om morgenen. Dagen efter ankom jeg sikkert til Cypern. Efter anmodning fra rekruttereren skrev jeg feedback på interviewet og udfyldte en formular i en særlig tjeneste for at returnere de brugte penge. Af alle udgifter betaler Google direkte kun for billetter. Hotel, mad og rejser betales af kandidaten. Så udfylder vi formularen, vedlægger kvitteringerne og sender den til et særligt kontor. De behandler dette og overfører penge til kontoen ret hurtigt.
Det tog halvanden uge at behandle interviewresultaterne. Hvorefter jeg blev informeret om, at jeg var "lidt under baren." Det vil sige, jeg kom lidt til kort. Mere specifikt gik 2 interviews godt, 2 lidt knap så godt, og System Design ikke særlig godt. Nu, hvis mindst 3 var gået godt, så havde vi været i stand til at konkurrere, ellers er der ingen chance. De tilbød at komme tilbage om endnu et år.
I starten var jeg selvfølgelig ked af det, for der var brugt mange kræfter på forberedelsen, og da interviewet fandt sted, tænkte jeg allerede på at forlade Cypern. At slutte sig til Google og flytte til Schweiz virkede som en god mulighed.
Konklusion
Og her kommer vi til den sidste del af artiklen. Ja, jeg mislykkedes i Google-interviewet to gange. Det er trist. Det ville nok være interessant at arbejde der. Men man kan se sagen fra den anden side.
- På halvandet år lærte jeg en enorm mængde ting relateret til softwareudvikling.
- Jeg havde det meget sjovt med at deltage i programmeringskonkurrencer.
- Jeg tog til Zürich i et par dage. Hvornår tager jeg dertil igen?
- Jeg havde en interessant interviewoplevelse hos en af de største it-virksomheder i verden.
Alt, hvad der skete i løbet af disse halvandet år, kan således simpelthen betragtes som træning eller træning. Og resultaterne af denne træning gjorde sig gældende. Min idé om at forlade Cypern modnedes (på grund af nogle familiemæssige omstændigheder), jeg bestod flere interviews med et andet velkendt firma og flyttede efter 8 måneder. Men det er en helt anden historie. Jeg synes dog, at jeg stadig skal takke Google både for det halvandet år, jeg selv har arbejdet på, og for 2 interessante dage i Zürich.
Hvad kan jeg sige til sidst? Arbejder du inden for IT, så forbered dig på samtaler hos Google (Amazon, Microsoft, Apple osv.). Måske vil du en dag tage dertil for at komme dertil. Selv hvis du ikke vil, tro mig, sådan forberedelse vil ikke gøre dig værre. I det øjeblik du indser, at du (selvom kun med held) kan få et interview med en af disse virksomheder, vil mange flere veje være åbne for dig, end før du begyndte din forberedelse. Og alt hvad du behøver undervejs er formål, vedholdenhed og tid. Jeg ønsker dig succes :)
Kilde: www.habr.com