Ting jeg har lært fra intervjuer med programmering av par

Noen selskaper foretrekker å koble program med kandidater for å få en følelse av å jobbe med dem mens de måler ferdighetene sine. Jeg har vært i et par av disse selskapene, og oftere enn ikke var en av oppgavene mine å være paret i intervjuene.

I min forrige jobb med et konsulentselskap hadde vi team for hvert prosjekt. Noen prosjekter hadde NDA, og som sådan måtte alle som ble med i teamet logge på. Dette førte til vanskeligheter med å bruke disse kodebasene når de ble parret med potensielle ansatte. Som et resultat parret vi hovedsakelig på enten interne prosjekter eller på prosjekter der klienten var ok med å vise kode til kandidater.

Jeg var vanligvis på lag uten NDA, så når vi hadde kandidater, var jeg hovedparet. Å være i det selskapet i fem år, kan du bare forestille deg hvor mange kandidater det var. Det var tider da jeg i løpet av arbeidsuken min parret med en annen person hver dag!

Vi gjør også pareprogrammering i mitt nåværende selskap. Siden jeg har trent på parprogrammering siden 2010, har det blitt naturlig for meg.

Men den ene tingen å huske på disse intervjuene er at det går begge veier : intervjueren lærer om intervjuobjektets ferdigheter og personlighet, mens intervjuobjektet lærer om hvem de skal jobbe med og hvordan en typisk arbeidsdag ser ut.

Så her er leksjonene jeg lærte fra parprogrammeringsintervjuer, både som intervjuobjekt og intervjuer. Forhåpentligvis vil dette hjelpe deg med å få en bedre ide til ditt neste intervju.

Vær forberedt

Hvis det er en ting du kan ta bort fra dette, vær så snill å la det være denne. Det kan virke åpenbart at du, som i ethvert intervju, være forberedt - men jeg følte bare at jeg trengte å understreke dette poenget.

Som intervjuer , se gjennom kandidatens CV, CV eller kildekode hvis de har sendt den inn. Dette vil hjelpe deg med å sette dine egne forventninger til ferdighetsnivå og personlighet, noe som vil hjelpe når du kommuniserer med dem. Å vite at du har de samme hobbyene kan være en god isbryter!

Som intervjuobjekt , gå til selskapets nettside og les / klikk gjennom. Jeg har vært i en situasjon der jeg søkte som webutvikler, og det første spørsmålet som ble kastet mot meg var: “Så, har du sett nettstedet vårt? Hva tror du kan du gjøre for å forbedre det? ” Det er tilstrekkelig å si at jeg slo til det intervjuet. Så vær så snill, i det minste, ta en titt på nettsiden deres. Gjennomgå koden din hvis du sendte den og dobbeltsjekk alt.

Slapp av og vær deg selv.

Dette kan høres ut som generelle råd, men det er mye viktigere for en parprogrammeringsøkt sammenlignet med et generelt eller teknisk intervju. Hvorfor? Rett og slett fordi en HR-person i noen generelle intervjuer snakker med deg og måler personligheten din for hele tiden. Mens du vil være i samme selskap som de er, vil du ikke jobbe direkte med dem hver dag.

I løpet av en parprogrammeringsøkt, hvis selskapet allikevel parer programmering mesteparten av tiden, vil du sannsynligvis jobbe tett med intervjueren din som en del av jobben din. Det er hovedforskjellen.

Dette fungerer både for intervjueren og intervjuobjektet. Som i ethvert forhold er det vanskelig å ha et langsiktig forhold hvis du bygger det bare basert på en del av bildet. Fundamentet ditt vil være et skjelvende grunnlag for usikkerhet, og før eller siden vil det komme ut og kan føre til noen problemer.

Stille spørsmål!

Som intervjuer , vær oppmerksom på at kandidaten mesteparten av tiden vil være nervøs. Selv om det å stille for mange spørsmål potensielt kan skremme dem bort, vil du ikke stille spørsmål i mørket og kaste bort paringsdagen din.

Jeg har lært å liste opp et sett med spørsmål som jeg får stille i løpet av paringsdagen. Listen trenger ikke å være i orden, og du trenger ikke å spørre dem alle på en gang. De fleste spørsmålene vil dukke opp mens du parrer, men det er best å ha dem skrevet ned i tilfelle.

Som intervjuobjekt , husk at noen intervjuere FORVENTER deg å stille spørsmål. Å ikke spørre betyr at du ikke er interessert (hvorfor søker du allikevel?) Eller at du vet alt (som du ikke gjør).

Hver gang jeg kobler sammen med noen, legger jeg merke til når de stiller et spørsmål og hvor ofte. Spørsmål kan variere fra enkle syntaksspørsmål som "Hva var det første argumentet for each_with_indexigjen?" til arbeidsrelaterte spørsmål som "Parrer du vanligvis hver dag?"

Det er ingen riktige eller gale løsninger

For meg er det bare å få jobben gjort. Selv om jeg forventer at kandidater skal være på sitt beste, forstår jeg at de vil være nervøse, noe som kan påvirke deres tenkning litt.

Jeg mener å ha mentale blokkeringer under et intervju er ganske vanlig (i det minste for meg). Jeg har paret med en rekke mennesker fra nye grader, til juniorer, utviklere på mellomnivå og til og med eldre, og jeg selv blir svart noen ganger.

Eksempel: da jeg ble intervjuet for den nåværende jobben min (jeg hadde allerede mer enn seks års Ruby-erfaring på det tidspunktet), slo jeg meg sammen med en enkel øvelse, og jeg glemte helt hvordan jeg skulle lage en Hash. Som jeg bare gikk, "Um. Vent hvordan gjør jeg det igjen? Kan jeg Google noe? " Ganske pinlig, men da jeg spurte, ble paret mitt bare tømt, så vi begge googlet det sammen. Morsomme tider.

Som intervjuer må du ikke holde deg til forestillingen om din egen løsning på et problem. Det er 11287398173 måter å skrive FizzBuzz på, og løsningen din er (sannsynligvis) ikke den beste som finnes. I stedet må du være mer åpen for andre løsninger og bedømme dem så godt du kan.

Når jeg gjør paringsintervjuer, har jeg vanligvis et svar i tankene når jeg stiller et spørsmål, men jeg lytter og ser hva intervjuobjektets svar er, for det er nesten aldri det samme svaret som mitt. Du vil bli overrasket over hvor kreative folk kan bli!

Som en intervjuobjekt , vær oppmerksom på dette faktum og bare gjør tingene dine. Ikke sett deg fast og bekymre deg for at du ikke vil være effektiv (med mindre det var intervjuspørsmålet!), Men vær samtidig ikke slurvete. Hvis du kommer til en sammenkoblingsøkt for et selskap som gjør TDD / BDD, for din skyld, start med tester først! De vil se etter det (jeg gjør det!), Og du kan havne nederst i haugen hvis du bare knuser ting ut.

Behandle dette som en vanlig sammenkoblingsdag

Basert på min første erfaring, behandlet jeg det som et teknisk intervju. Jeg satt ved siden av kandidaten og tok notater mens de skrev tankene sine.

Men det er IKKE slik jeg pleier å koble sammen, og da jeg skjønte det, forandret jeg meg. Når noen satt fast, ville jeg dytte dem sammen uten å gi svaret akkurat. Jeg vil stille noen sonderende spørsmål som "Hva er feilmeldingen?" eller "Hva tror du er problemet?" eller "Hva kan du gjøre for å fikse det?"

Som intervjuer , la kandidaten din kjøre 90% av tiden - men aldri 100%. Det gir inntrykk av at det er et strengere teknisk intervju (du er bare ved siden av dem og ser på hver eneste bevegelse - noe som faktisk gjør konsentrasjonen vanskeligere). Prøv litt med tastaturet og la dem snakke deg gjennom løsningen. Dette vil gi dem ro.

Som intervjuobjekt , ikke bare begynn å skrive det øyeblikket tastaturet blir gitt til deg. Begynn å diskutere løsningen først. Spør partneren din om de vil ha tastaturet mens du gir dem beskjed om tankene dine. Påminn deg selv om at dette mer er en sammenkobling av "testkjøring" i stedet for et teknisk intervju. Som bringer meg til neste punkt ...

Snakk med partneren din

Dette er det første jeg sjekker når jeg gjør paringsintervjuer. I mitt forrige selskap startet jeg vanligvis dagen med å forklare hva appen vi jobber med, hva funksjonen jeg jobber med, og hva vi skal gjøre. Jeg begynte da å skrive ut spesifikasjonene mine og la kandidaten få regjering.

Jeg ville være oppmerksom på å se hva de gjorde: Noen ganger fortsatte de bare og begynte å skrive, andre tenkte de først stille, og igjen andre ville rett opp stille spørsmål om problemet eller fortelle meg om løsningene deres.

I mitt nåværende selskap fokuserer parøkten vanligvis på et gitt problem. Jeg gir kandidaten problemet å lese, og så venter jeg. Hvis de begynner å skrive uten å si noe, er det allerede et rødt flagg for meg. Jeg gir poeng til folk som får penn og papir og begynner å forklare løsningen for meg med diagrammer.

Som intervjuer er det viktig å holde samtalen i gang for å la kandidaten føle at det er en sammenkoblingsøkt. På dette tidspunktet er dere to en enhet. Dere skal begge kunne kommunisere godt med hverandre og sprette ideer frem og tilbake.

Selvfølgelig vil det være tider at kandidaten din trenger å tenke alene, så la dem få det også. Finn balansen mellom å holde opp samtalen og la dem fokusere og løse problemet.

Som intervjuobjekt , fortell alltid partneren din hva du planlegger å gjøre og hva løsningen din er. Dette lar dem få vite at du gjenkjenner det faktum at dette er en sammenkoblingsøkt, og at du kan kommunisere ideene dine godt. Dette gir dem også følelsen av at du planlegger ting nøye, i stedet for å gå YOLO.

Det er greit å ta et øyeblikk å tenke

I motsetning til utsagnet ovenfor, bør du også kunne ha tid til å tenke stille. Det er helt ok å ha død luft. Du er ikke i en radiostasjon tross alt.

Som intervjuer trenger du sjelden å gjøre dette. Men hvis du er i min situasjon, hvor du kobler sammen med en kandidat på en funksjon du faktisk implementerer, trenger du også tid til å tenke. Bare gi partneren din beskjed om dette, så skal det være greit.

Som intervjuobjekt kan du fortelle partneren din at du trenger litt tid til å tenke og at du vil fortelle dem løsningen din etter. Dette viser at du anerkjenner deres tilstedeværelse og at du vil kommunisere tankene dine etter at du har behandlet dem. Kommunikasjon er nøkkelen!

Siste tanker

Dette er bare noen ting jeg lærte. Forhåpentligvis kan de hjelpe deg i ditt neste intervju. Selv om dette ikke er en omfattende liste om hvordan man kan få et paringsintervju, tror jeg at det kan hjelpe kandidater (og første gangs intervjuere også!) I intervjuene sine.

Lykke til! Og husk også at uansett hva som skjer, vil du komme ut av intervjuet etter å ha lært noe - og det er det som betyr noe.