Tekniske interviews er kendt for deres puslespil. Uanset om du bliver bedt om at skrive et binært træ ud på en tavle, forklare en sorteringsalgoritme eller implementere FizzBuzz på 10 linjer eller mindre, skal du forberede dig til tekniske programmeringsspørgsmål i det gennemsnitlige interview.
Men det er ikke det eneste, du skal være forberedt på.
Virkeligheden er, at mange udviklere vil være i stand til at løse almindelige spørgsmål til programmeringssamtale med lidt afvigelse mellem svarene. Så hvad gør dig anderledes end den næste kandidat? Det er præcis, hvad vi vil fokusere på i disse fem tip.
1. Tal din begrundelse og problemløsning
Det værste, du kan gøre, når du stilles et hårdt spørgsmål er at gå helt målløs. Desværre er det meget let at gøre dette ved en ulykke. Når du støder på et problem, der kræver betydelig mental energi og fokus, er det sandsynligt, at din første tilbøjelighed er at trække sig tilbage i dit sind. Selvom dette er naturligt, er det heller ikke særlig nyttigt for intervieweren.
Pointen med tekniske spørgsmål er til dels at afsløre, hvordan du tænker på at løse problemer. Hvad er din proces? Hvordan nedbryder du de forskellige komponenter? Hvordan kommer du frem til en løsning? Hvordan reagerer du, når du prøver noget, der ikke fungerer? Er du bedre til at eksperimentere med kode eller til at tegne noget ud på en tavle?
Forklar hvad der sker i dit hoved, når du løser problemet. Handle som om du optager din stemme for at offentliggøre online for at lære andre, hvordan du løser dette problem. Selv hvis dine interviewere giver dig plads til at tænke roligt, kan du drage fordel af at forklare din tankeproces, uden at de beder dig om at gøre det. Dette hjælper dem ikke kun med at forstå dine evner og kritisk tænkning mere grundigt, men det gør dig også mere mindeværdig.
2. Hvad er bedre end at løse et problem i et teknisk interview? Løsning to gange
Meget få problemer har kun én løsning, og alle problemer har uendelige forkerte løsninger. Så hvis du kun fokuserer på en måde at løse et problem, mangler du en større mulighed for at bevise din fleksibilitet og dine evner.
I stedet for blot at gå med en velkendt løsning eller arbejde på et enkelt sprog, skal du åbne diskussionen om det særlige problem og løse det for forskellige scenarier. For eksempel, hvis du bliver bedt om at programmere FizzBuzz, kan du muligvis tilbyde at gøre det på to sprog, eller ved at anvende to forskellige paradigmer, eller måske ved at tage nogle præstationsbegrænsninger for en løsning og æstetiske begrænsninger for en anden.
Ved at validere, at problemet kan have flere løsninger, viser du din tilpasningsevne, fleksibilitet og opmærksomhed, som alle giver din interviewere tillid til, at du kan vælge den rigtige løsning blandt mange muligheder.
Gå selvfølgelig ikke over bord - der er en kunst at læse, når besvarelse af et spørgsmål med flere løsninger overdrives eller glædes velkommen. Hvis du er i tvivl, skal du ikke være bange for at spørge dine interviewere, hvis de har noget imod, hvis du tager noget tid på at udvide din løsning med en sekundær mulighed.
3. Vær ikke bange for at dele dine meninger, når det er relevant
Nogle gange, når du arbejder igennem problemer, vil du tage beslutninger, der helt er baseret på din egen smag og mening. Og det er OK - arbejdsgivere er interesserede i din mening! Den måde, du tænker og reagerer på situationer på, gør en stor forskel for en virksomheds kultur. At have en mening er også et tegn på lederskab og teknisk modenhed som udvikler. At have en diskussion om dine meninger kræver, at du har evalueret andre holdninger til et givet emne.
Husk dog, at udtalelser kan holdes meget tæt. Hvis du er uenig med din interviewer om et givet emne, skal du trætte let, når du deler disse oplysninger. Selvom det er godt at have et synspunkt, er det også vigtigt at bemærke, at det ikke altid er nødvendigt at dele det, og vide, hvordan man vælger dine slag. En god tommelfingerregel: Del ikke din mening, medmindre du bliver spurgt.
4. Afslut aldrig et svar med "Jeg ved ikke"
Medmindre du står over for et "Kobayashi Maru" -scenarie, skal du aldrig afslutte et interviewspørgsmål med "Jeg ved ikke." Det er ikke en mulighed på jobbet, så det bør ikke være en mulighed i interviewet.
Selvfølgelig siger jeg ikke, at du skal vide alt. Det er umuligt! Men du skal vise, at du har en strategi for at lære, hvad du har brug for at vide for at få arbejdet gjort. Prøv at svare med ”Jeg ved ikke, hvordan man gør det, men her er, hvordan jeg ville finde ud af det.” Dette svar skulle gå videre end bare at sige “Jeg ville Google det” også. Du er bedre til at forklare den mest sandsynlige retning, du ville undersøge.
Skam dig mest af alt! Læring er i vid udstrækning processen med at finde ud af de ting, du ikke kender. Din arbejdsgiver forventer ikke, at du skal være perfekt, men de forventer, at du skal være flittig og intelligent og aldrig slutte med et problem.
5. Spil altid for holdet
Medmindre du er freelanceudvikler, vil dit job altid blive sat inden for rammerne af et team, og holdets succes er altid vigtigst for din egen. Så dit interview skal afspejle, at du ikke bare er optaget af at løse dine problemer på en given dag, men snarere at du er fokuseret på at gøre, hvad der er nødvendigt for, at teamet skal få succes.
Så hvordan kan du kommunikere dette i et interview?
Diskuter aldrig problemer, som om de er i vakuum
Næsten ethvert projekt har praktisk taget ressourcebehov og -grænser, så vis din opmærksomhed på problemets kontekst. Et problem, der løses godt, men er gået over budgettet, er ikke virkelig den største løsning.
Vis din opmærksomhed om ekspertise på det eksisterende team
Undertiden er det bedste svar på et spørgsmål at bede andre på dit team om at samarbejde med dig, og du kan muligvis henvise disse mennesker til de tekniske spørgsmål: ”Hvis jeg blev præsenteret dette problem i forbindelse med vores team, ville jeg sandsynligvis bede om at gennemgå min løsning også. ”Dette viser, at du er villig til at stole på andres ekspertise, og at dit mål er at nå frem til den bedste løsning.
Kommuniker dit team Drevne værdier eksplicit
Dette er et vigtigt nok spørgsmål, så du skal komme lige ud og sige det. Du vil sikre dig, at dine arbejdsgivere er fuldt ud klar over, at dit mål er at hjælpe virksomheden med at få succes, ikke bare at sidde ved dit skrivebord og kode hele dagen.
I sidste ende er dit job som udvikler ikke kun at kode. Det er at være en holdspiller, en leder og nogen, der aldrig er villig til at stoppe med et problem. Mulighederne i et teknisk interview er ikke kun at vise, at du kan opfylde mål eller skrive algoritmer, men også at sætte dig selv over konkurrencen og vise den værdi, du tilføjer til en arbejdsgiver.
