Virker det ikke mærkeligt for dig, at når du skal skifte job, og behovet opstår for at bestå en samtale, er det første du tænker "du skal forberede dig til samtalen." Løs problemer på HackerRank, læs Knæk kodningsinterviewet, husk, hvordan ArrayList fungerer, og hvordan det adskiller sig fra LinkedList. Åh ja, de spørger måske også om sortering, og det ville naturligvis være uprofessionelt at sige, at hurtig sortering højst sandsynligt ville være det bedste valg.
Men vent, du programmerer 8 timer om dagen, løser interessante og ikke-trivielle problemer, og på dit nye job vil du gøre det samme, plus eller minus. Men ikke desto mindre, for at bestå en samtale, skal du på en eller anden måde yderligere forberede dig, ikke engang finpudse dine daglige færdigheder, men lære noget, som du ikke havde brug for på dit nuværende job, og som du sandsynligvis ikke får brug for på dit næste job. Til dine indvendinger om, at datalogi er os i blodet, og hvis du vækker os midt om natten, er vi forpligtet til at skrive med lukkede øjne på et pudebetræk en tur rundt i et træs bredde uden overhovedet at komme til bevidsthed, vil svare, at hvis jeg får et job i cirkus, og mit primære trick ville være netop dette - så er det måske ja, jeg er enig. Denne færdighed skal testes.
Men hvorfor teste færdigheder, der er irrelevante for dit nuværende job? Bare fordi det blev moderne? Fordi Google gør dette? Eller fordi din fremtidige teamleder skulle lære alle sorteringsmetoderne før interviewet, og nu mener han, at "enhver god programmør skal kende implementeringen af at finde et palindrom i en streng udenad."
Nå, du er ikke Google (c). Hvad Google har råd til, kan almindelige virksomheder ikke. Google, efter at have analyseret sine medarbejderes data, kom til den konklusion, at ingeniører med en Olympiade-baggrund er gode til at håndtere sine specifikke opgaver. Desuden har de ved at designe deres udvælgelsesproces råd til at tage risikoen for, at de måske ikke ansætter et par gode ingeniører, fordi de ikke nemt kan løse matematiske problemer. Men det er ikke et problem for dem, der er mange mennesker, der gerne vil arbejde hos Google, stillingen vil blive lukket.
Lad os nu se ud af vinduet, og hvis de ingeniører, der vil arbejde for dig foran dit kontor, endnu ikke har oprettet en teltlejr, og dine udviklere oftere kigger på stackoverflow efter, hvad næste forårsannotering skal installeres, i stedet for forviklingerne ved rangeringsalgoritmer, så er det tilsyneladende på tide, at du tænker over, om du skal kopiere Google.
Nå, hvis Google denne gang fejlede og ikke gav et svar, hvad skal du så gøre? Tjek præcis, hvad udvikleren vil gøre på arbejdet. Hvad værdsætter du hos udviklere?
Lav kriterier for, hvem du vil ansætte og udvikle tests, der tester netop disse færdigheder.
ThoughtWorks
Hvad har ThoughtWorks med dette at gøre? Det var her, jeg fandt et eksempel på et eksemplarisk interview til mig selv. Hvem er ThoughtWorks? Kort sagt er der tale om et High-End konsulentfirma med kontorer over hele verden, fra Kina, Singapore til de amerikanske kontinenter, som har rådgivet inden for udvikling i omkring 25 år, har sin egen Science division, ledet af Martin Fowler. Hvis du leder efter en liste med 10 must-read bøger for en softwareingeniør, så vil måske 2-3 af dem være skrevet af gutterne fra ThoughtWorks, såsom Refactoring af Martin Fowler og Building Microservices: Designing Fine-Grained Systems af Sam Newman eller Building Evolutionary Architectures
af Patrick Kua, Rebecca Parsons, Neal Ford.
Virksomhedens forretning bygger på at levere ret dyre ydelser, men kunden betaler for fænomenal kvalitet, som består af ekspertise, interne standarder og selvfølgelig mennesker. Derfor er det afgørende her at ansætte de rigtige mennesker.
Hvilken slags mennesker har ret? Selvfølgelig er der forskellige for alle. ThoughtWorks har fastslået, at de vigtigste kriterier for deres udviklerforretningsmodel er:
- Evne til at udvikle sig i par. Det er evner, ikke erfaring eller dygtighed. Ingen forventer, at der kommer folk, der har praktiseret parprogrammering i 5 år. Men at være modtagelig for andres meninger og at kunne lytte er en nødvendig færdighed.
- Evne til at skrive test, og ideelt set øve TDD
- Forstå SOLID og OOP og kunne anvende dem.
- Fremlæg din mening. Som konsulent skal man arbejde sammen med kundens udviklere, med andre konsulenter, og der er ikke den store fordel, hvis en person ved, hvordan man gør noget godt, men er fuldstændig ude af stand til at formidle det til resten af teamet.
Nu er det vigtigt at evaluere disse særlige færdigheder hos kandidaten. Og her vil jeg fortælle om min oplevelse med at interviewe hos ThoughtWorks. Jeg vil med det samme sige, at jeg tog til Singapore og bestod, men rekrutteringsprocessen er samlet og vil ikke variere meget fra land til land.
Trin 0. HR
Som det ofte sker, et 20-minutters interview med HR. Jeg vil ikke dvæle ved det, jeg vil bare sige, at jeg aldrig har mødt en HR-person, der kunne tale i 15 minutter om udviklingskulturen i virksomheden, hvorfor de bruger TDD, hvorfor parprogrammering. Normalt vil HR'ere gå i stå med dette spørgsmål og sige, at deres proces er normal: udviklere udvikler, testere tester, ledere kører.
Fase 1. Hvor god er du til OOP, TDD?
1.5 time før interviewets start fik jeg tilsendt en opgave om at lave en Mars Rover simulator.
Mars rover missionEt hold robotrovere skal landes af NASA på et plateau på Mars. Dette plateau, som er mærkeligt rektangulært, skal navigeres af roverne, så deres kameraer ombord kan få et komplet overblik over det omkringliggende terræn for at sende tilbage til Jorden. En rovers position og placering er repræsenteret af en kombination af x- og y-koordinater og et bogstav, der repræsenterer et af de fire kardinalkompaspunkter. Plateauet er delt op i et gitter for at forenkle navigationen. Et eksempel på position kan være 0, 0, N, hvilket betyder, at roveren er i nederste venstre hjørne og vender mod nord. For at styre en rover sender NASA en simpel række af bogstaver. De mulige bogstaver er 'L', 'R' og 'M'. 'L' og 'R' får roveren til at dreje henholdsvis 90 grader til venstre eller højre uden at flytte sig fra dets nuværende sted. 'M' betyder at gå et gitterpunkt frem og bevare den samme kurs.
Antag, at kvadratet direkte nord fra (x, y) er (x, y+1).
INPUT:
Den første linje af input er de øverste højre koordinater af plateauet, de nederste venstre koordinater antages at være 0,0.
Resten af inputtet er information vedrørende de rovere, der er blevet indsat. Hver rover har to inputlinjer. Den første linje angiver roverens position, og den anden linje er en række instruktioner, der fortæller roveren, hvordan han skal udforske plateauet. Positionen består af to heltal og et bogstav adskilt af mellemrum, svarende til x- og y-koordinaterne og roverens orientering.
Hver rover vil blive færdig sekventielt, hvilket betyder, at den anden rover ikke begynder at bevæge sig, før den første er færdig med at bevæge sig.
PRODUKTION:
Outputtet for hver rover bør være dens endelige koordinater og kurs.
NB:
Du skal blot implementere ovenstående krav og bevise, at en støvsuger virker ved at skrive enhedstests for den.
Oprettelse af enhver form for brugergrænseflade er uden for rækkevidde.
Løsning af problemet ved at følge en TDD (Test Driven Development) tilgang vil være at foretrække.
På den korte tid, der er til rådighed, er vi mere optaget af kvalitet end fuldstændighed.
*Jeg kan ikke poste den opgave, der er sendt til mig, det er en gammel opgave, der blev givet for flere år siden. Men tro mig, grundlæggende forbliver alt det samme.
Jeg vil især gerne henlede opmærksomheden på evalueringskriterierne. Hvor mange gange er du stødt på en situation, hvor ting, der er vigtige for en kandidat, er fuldstændig ligegyldige under revisionen og omvendt. Ikke alle tænker på samme måde som dig, men mange kan acceptere og følge dine værdier, hvis de står klart. Så ud fra evalueringskriterierne er det umiddelbart klart, at de vigtigste færdigheder på dette stadium er
- TDD;
- Evne til at bruge OOP og skrive vedligeholdelsesvenlig kode;
- parre programmeringsevner
Så jeg blev advaret om at bruge de 1.5 timer på at tænke på, hvordan jeg skulle udføre opgaven, i stedet for at skrive kode. Vi skriver koden sammen.
Da vi tog telefonen, fortalte fyrene os kort, hvem de er, og hvad de laver og tilbød at starte udviklingen.
Under hele interviewet havde jeg aldrig en eneste gang følelsen af, at jeg blev interviewet. Der er en følelse af, at man udvikler kode i et team. Hvis du går i stå et eller andet sted, hjælper de, rådgiver, diskuterer, endda diskuterer med hinanden, hvordan de bedst gør det. Ved interviewet glemte jeg, hvordan man tjekker i JUnit 5, at en metode giver en undtagelse - de tilbød at fortsætte med at skrive testen, mens en af dem googlede, hvordan man gjorde det.
Bogstaveligt talt et par timer efter interviewet fik jeg konstruktiv feedback - hvad jeg kunne lide, og hvad jeg ikke kunne. I mit tilfælde fik jeg ros for at bruge Sealed-klasser som et alternativ til null-objektet; for, at jeg inden jeg skrev koden, skrev i pseudokode, hvordan jeg gerne ville styre roveren, og fik dermed en skitse af klasserne, i hvert fald dem, der er involveret i robottens API.
Trin 2: Fortæl os det
En uge før interviewet blev jeg bedt om at forberede en præsentation om ethvert emne, der interesserede mig. Formatet er enkelt og velkendt: 15 minutters præsentation, 15 minutter besvarelse af spørgsmål.
Jeg valgte Clean Architecture af onkel Bob. Og igen blev jeg interviewet af et par mennesker. Dette var min første oplevelse med at præsentere på engelsk, og hvis jeg havde været i en stresset situation, ville jeg måske ikke have været i stand til at klare det. Men igen, jeg havde aldrig en eneste gang følelsen af, at jeg var til et interview. Alt er som det plejer – jeg fortæller dem, de lytter godt efter. Selv den traditionelle spørgsmål og svar-session var ikke som et interview; det var tydeligt, at spørgsmålene ikke blev stillet for at "synke", men dem, der virkelig interesserede dem i min præsentation.
Et par timer efter interviewet fik jeg feedback - præsentationen var meget nyttig, og de nød virkelig at lytte.
Trin 3. Produktionskvalitetskode
Efter at have advaret om, at dette var sidste fase af tekniske interviews, blev jeg bedt om at bringe koden derhjemme til en produktionsklar tilstand, derefter sende koden til gennemgang og planlægge interviews, hvor kravene til opgaven ville ændre sig, og koden ville kræver modifikation. Når jeg ser fremad, kan jeg sige, at kodegennemgangen udføres i blinde, anmelderne kender ikke den stilling, kandidaten søger, de ser ikke hans CV, de ser ikke engang hans navn.
Telefonen ringede, og igen var der et par fyre på den anden side af skærmen. Alt er det samme som ved det første interview: det vigtigste er ikke at glemme TDD, fortæl hvad du gør og hvorfor. Hvis du ikke har praktiseret TDD før, så anbefaler jeg, at du begynder at gøre det med det samme, ikke fordi det er nødvendigt i virksomheder, men fordi det forenkler dit liv markant, reducerer dit stressniveau, hvis du vil. Kan du huske, hvordan du febrilsk skulle søge med en debugger efter en fejl, der kun kan gengives gennem browseren, men du ikke kan gengive den med test? Forestil dig nu, at du bliver nødt til at fange sådan en fejl under et interview - du er garanteret et par grå hår. Hvad får vi med TDD? Vi ændrede koden og indså uventet, at nu er testene røde, men hvad er fejlen, vi ikke kan finde ud af første gang? Okay, vi siger "Ups" til interviewerne, trykker på Ctrl-Z og begynder at tage små skridt fremad. Og ja, du skal udvikle evnen til at udvikle dig ved at bruge TDD i dig selv, evnen til at gå mod målet, så dine tests er permanent grønne og ikke røde i en halv dag, fordi "du har en masse refactoring." Dette er nøjagtig den samme færdighed som at skrive vedligeholdelsesvenlig kode eller skrive produktiv kode.
Så hvor godt din kode kan ændres afhænger af hvilket design du har i tankerne til at begynde med, hvor enkelt det er, og hvor gode dine tests er.
Efter interviewet fik jeg tilbagemelding inden for få timer. På dette tidspunkt indså jeg, at jeg næsten var færdig, og der var meget lidt tilbage, indtil jeg "mødte Fowler."
Etape 4. Finale. Nok tekniske spørgsmål. Vi vil gerne vide, hvem du er!
For at være ærlig var jeg noget forundret over denne formulering af spørgsmålet. Hvordan kan du forstå, hvilken slags person jeg er i en times samtale? Og endnu mere, hvordan kan du forstå det, når jeg taler et sprog, der ikke er mit modersmål, og ærligt talt meget elendigt og tungebundet. I tidligere interviews var det lettere for mig personligt at tale frem for at svare på spørgsmål, og accenten var skylden. Mindst én af interviewerne var asiatisk – og deres accent, ja, lad os bare sige, er noget specifik for det europæiske øre. Derfor besluttede jeg at tage en proaktiv tilgang – udarbejde et oplæg om mig selv og tilbyde i starten af interviewet at tale om mig selv med dette oplæg. Hvis de er enige, så vil der i det mindste være færre spørgsmål til mig; hvis de afviser tilbuddet, ja, 3 timer af mit liv brugt på en præsentation er ikke så høj en pris. Men hvad skal du skrive i din præsentation? Biografi - Født der, på det tidspunkt, gik i skole, dimitterede fra universitetet - men hvem bekymrer sig?
Hvis du Googler lidt om Thoughtworks-kulturen, finder du en artikel af Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], som beskriver de 3 søjler: Sustainable Business, Software Excellence, and Social Justice.
Lad os antage, at Software Excellence allerede er blevet kontrolleret for mig. Det er tilbage at vise bæredygtig virksomhed og social retfærdighed.
Desuden besluttede jeg at fokusere på det sidste.
Til at begynde med fortalte jeg ham, hvorfor ThoughtWorks - jeg læste Martin Fowlers blog tilbage på college, deraf min kærlighed til ren kode.
Projekter kan også præsenteres fra forskellige vinkler. Han udviklede også software til medicin, der forenklede patienternes liv, og endda, ifølge rygter, reddede et liv. Jeg udviklede også software til banker, som også gjorde livet lettere for borgerne. Især hvis denne bank bruges af 70 % af landets befolkning. Det handler ikke om Sberbank og ikke engang om Rusland.
Vil du vide noget om mig? OKAY. Min hobby er fotografering, på en eller anden måde har jeg holdt et kamera i hænderne i omkring 10 år, der er fotografier, som jeg ikke er for flov til at vise. På et tidspunkt hjalp jeg også et katteinternat: Jeg fotograferede katte, der havde brug for et permanent hjem. Og med gode fotografier er det meget nemmere at placere en kat. Jeg har sikkert fotograferet hundrede katte :)
Til sidst var 80 % af min præsentation fyldt med katte.
Umiddelbart efter præsentationen skrev HR til mig, at han endnu ikke kendte resultatet af interviewet, men hele kontoret var allerede imponeret over kattene.
I sidste ende ventede jeg på feedback - jeg tilfredsstillede alle som person.
Men under den sidste samtale sagde HR taktfuldt, at Social Retfærdighed er meget god og nødvendig, men ikke alle projekter er sådan. Og han spurgte, om det skræmte mig. Generelt gik jeg lidt overbord med Social Retfærdighed, det sker :)
Total
Som et resultat heraf har jeg arbejdet i Singapore hos Thoughtworks i flere måneder nu, og jeg kan se, at her er alt for mange virksomheder ved at tage "bedste interviewpraksis" fra Google ved at bruge blade og Whiteboard til kodning, på trods af at de har mere viden end Spring, Symfony, RubyOnRails ( Understreg det nødvendige) er ikke påkrævet i arbejdet. Ingeniører tager en uges fri før et interview for at "forberede sig."
Hos Thoughtworks er, udover tilstrækkelige krav til kandidaten, følgende principper i højsædet:
Glæde ved at interviewe. Desuden for begge sider. Hvis du vil have det bedste personale (og hvem gør ikke?), så er et interview ikke et marked, hvor slaver vælges, men et show, hvor både arbejdsgiveren og kandidaten evaluerer hinanden. Og hvis en kandidat forbinder behagelige følelser med en virksomhed, er det sandsynligt, at han vil vælge netop denne virksomhed
Flere interviewere for at afbøde bias. Hos Thoughtworks er parprogrammering de facto-standarden. Og hvis denne praksis kan anvendes på andre områder, forsøger TW at gøre det. På hvert trin udføres interviewet af 2 personer. Hver person bliver således vurderet af mindst 8 personer, og TW forsøger at udvælge interviewere med forskellig baggrund, forskellige retninger (ikke kun teknikere) og køn.
I sidste ende vil ansættelsesbeslutningen blive truffet på baggrund af udtalelser fra mindst 8 personer, og ingen har en afgørende stemme.
Attributbaseret ansættelse I stedet for at træffe en beslutning baseret på en kandidats kan lide eller ikke lide, udvikles en formular for hver rolle og hvert trin, der inkluderer de egenskaber, der vurderes. Samtidig, når man vurderer, anbefales det stærkt at vurdere ikke erfaring med en bestemt færdighed, men evnen til at anvende den. Således, hvis en kandidat ikke var i stand til at anvende nogen færdigheder, såsom TDD, men alligevel forsøger at anvende dem, lytter til råd om, hvordan man bruger dem korrekt, har han alle muligheder for at bestå samtalen.
Uddannelsesbeviser er ikke påkrævet TW kræver ingen certificering eller uddannelse i datalogi. Kun færdigheder vurderes.
Det er det første interview, jeg har haft med udenlandske virksomheder, som jeg ikke skulle forberede mig til. Efter hvert trin følte jeg mig ikke udmattet, men tværtimod var jeg glad for, at jeg kunne anvende den bedste praksis, at folk på den anden side af skærmen satte pris på det og anvendte dem hver dag.
Efter flere måneder kan jeg sige, at mine forventninger blev fuldt ud indfriet. Hvordan adskiller ThoughtWorks sig fra en almindelig virksomhed? I et almindeligt firma kan du finde gode udviklere og søde mennesker, men i TW er deres koncentration ude af hitlisterne.
Hvis du er interesseret i at blive medlem af ThoughtWorks, kan du se vores ledige stillinger
Jeg foreslår også at være opmærksom på interessante ledige stillinger:
Ledende softwareingeniør: , , ,
Senior softwareingeniør: , , ,
Software ingeniør: , ,
Senior dataingeniør:
Kvalitetsanalytiker:
Infrastruktur: , ,
(Jeg vil gerne ærligt advare dig om, at linket er et henvisningslink, hvis du går til TW, vil jeg modtage en fin bonus). Vælg et kontor du kan lide, du behøver ikke at begrænse dig til Europa, trods alt vil TW hvert andet år med glæde flytte dig til et andet land, fordi... dette er en del af ThoughtWorks-politikken, så kulturen spredes og homogeniseres.
Stil gerne spørgsmål i kommentarerne eller spørg mig om anbefalinger.
Hvis emnet virker interessant, vil jeg skrive om, hvordan det er at arbejde hos ThoughtWorks, og hvordan livet er i Singapore.
Kilde: www.habr.com