Hvordan ikke mislykkes på et teknisk intervju hos et IT-selskap. Bestå det tekniske intervjuet

Visninger: 805

Mye smerte strømmer ut på Internett om mislykkede intervjuer. Noen likte ikke intervjuernes spørsmål, andre ble fornærmet av latterliggjøring, andre ble dømt basert på deres VKontakte-side. Intervjuerne holder tritt med søkerne og banner på hvor dårlig bemanningssituasjonen er i disse dager, og hvilke dumme svar uerfarne programmerere gir på de vanskelige spørsmålene deres. tekniske problemer.

Dessverre er det ingen universelle regler for å bestå og gjennomføre intervjuer, og kan ikke være det, fordi ansatte velges ikke bare ut fra sine tekniske ferdigheter og personlige egenskaper, men også ved å matche en eller annen (ofte implisitt og veldig subjektiv) "profil", som ifølge til intervjuere, passer inn i deres team eller bedrift. Når det gjelder guidene fra serien "hvordan sende intervjuer riktig", forårsaker de vanligvis ikke mindre smerte i kommentarene, fordi de er veldig subjektive og vil garantert berøre noens smertepunkter.

I løpet av min yrkeskarriere har jeg vært på begge sider av gjerdet, selv om jeg nok har måttet ta litt flere tekniske intervjuer enn å bestå dem. Men i løpet av denne tiden har jeg akkumulert en rekke "kjepp" som skremmer meg vekk under et teknisk intervju og umiddelbart i tankene mine satte en stopper for videre samtale. Det var dette jeg ville snakke om – fra intervjuerens og søkerens perspektiv. Jeg vil umiddelbart ta forbehold om at artikkelen gjenspeiler mine personlige subjektive inntrykk og ikke gir seg ut for å være en «guide til intervjuer». På den annen side er dette ikke et øyeblikks raseriutbrudd fra et mislykket intervju, men et langvektet sett med kriterier som, om enn på et negativt grunnlag, lar meg luke ut alternativer, eller ikke skremme bort en potensielt egnet søker meg selv.

Hva irriterer eller stresser deg under intervjuer? Del i kommentarene.

Intervju fra søkerens perspektiv

Hver gang en programmerer ser etter en jobb, må han gjennom mange tekniske intervjuer. Han går rundt på kontorer eller snakker på Skype, løser problemer eller tar tester, svarer på vanskelige tekniske spørsmål, prøver å demonstrere seg selv med den beste siden. Men selv vurderer han også personene som intervjuer og tester ham, og tenker at i morgen må han potensielt jobbe med disse menneskene. Og det er mange måter å tekniske intervjuer er å skremme bort søkeren fra en interessant stilling. Jeg skal fortelle deg om hva som alltid har skremt meg personlig, og hva jeg prøver å unngå som intervjuer.
1. «Hva annet teknisk intervju?»
Det første og viktigste som alltid har skremt meg med et teknisk intervju er fraværet. Det hender at hele samtalen med tekniske spesialister - potensielt fremtidige kolleger - er basert på spørsmål angående yrkeserfaring: hvor han jobbet, hvilke prosjekter han jobbet med, hvilken funksjon han utførte i dem. Om teknologi eller kunnskap - spørsmål på nivået "hvilken farge er læreboken." Vet du hva en meldingsmegler er? Flott, vi tar deg!

Denne tilnærmingen til intervju har alltid vendt meg skarpt mot en potensiell arbeidsgiver. De stilte meg ikke et eneste spørsmål for å sjekke at jeg virkelig kunne min virksomhet. Det ser ut som om personene som intervjuer meg enten ikke forstår noe om emnet selv og leter etter minst én person som forstår, eller rett og slett er desperate og klare til å ta tak i hvem som helst. Jeg ville i alle fall neppe ønske å jobbe i et team rekruttert på denne måten.

2. "Vel, hva gjorde du der i det..."
Det er overraskende hvor ofte avvisende holdninger til søkere oppstår under tekniske intervjuer. Ja, kanskje du er en streng og erfaren programmerer med en haug med prosjekter under beltet, du ble revet bort fra ekstremt viktig arbeid på grunn av noen unødvendige intervjuer med folk, hvorav de fleste, etter din mening, er fullstendig inkompetente. Men ikke glem at du for øyeblikket representerer din bedrift og ditt team, og en person vil definitivt foreta en vurdering basert på din oppførsel om klimaet i teamet og hvordan de vil bli behandlet i dette teamet. Vær høflig og respektfull overfor søkeren, selv om du fra de første fem minuttene innså at han ikke skulle få lov i nærheten av din dyrebare kode.
3. "Ditt fornavn/etternavn/patronymnavn er skrevet feil på CV-en din!"
Dette er slett ikke teknisk, men likevel et vanlig problem selv i tekniske intervjuer. Heldigvis har jeg et ganske enkelt og vanlig navn, og slike problemer har ikke skjedd meg. Imidlertid vet jeg at det er overraskende mange mennesker som tror bestemt at visse navn og til og med patronymer rett og slett ikke eksisterer. De vil overbevise deg om at det riktige navnet ikke er "Danila", men "Daniil", eller at det ikke er noe navn "Alena", men bare "Elena". De vil tilby å korrigere og skrive "riktig" i dokumentene sine. Personer med sjeldne eller uvanlige navn, og tro meg, det er utrolig irriterende. Så det er en enkel regel: det er ingen slike navn som ikke eksisterer. Skriv riktig som skrevet i passet. Vis respekt for søkeren og ikke betrakt ham som så dum at han ikke klarer å kopiere fra passet til CV-en fornavn. Selv om du mistenker en feil, kan du avklare dette på en mer taktfull måte.
4. "Hvor mange golfballer ville det ta for å rengjøre alle de runde vinduene på en skolebuss som krympet til størrelsen på et nikkel under evakueringen av San Francisco, med ikke mer enn 3 veiinger?"
Ingen artikkel om intervjuer ville være komplett uten å nevne kumlokk. Du kan betrakte dette som mitt personlige særpreg knyttet til manglende evne til raskt og under press å løse ikke-standardiserte problemer. Men jeg er sikker på at hjernetrim er helt ubrukelig under intervjuer. Eller rettere sagt, det er det flott måte rekruttere en full avdeling av hjernevidunder med hjerneolympiaden, som vil utveksle nye hjernetrim hele dagen i stedet for å jobbe. Ekte programmerer i naturlige omgivelser livet, selv når han har å gjøre med veldig kule og ikke-standardoppgaver, koder han fortsatt sjelden under press, og bruker mesteparten av dagen på å sitte og tenke i en relativt rolig atmosfære på hvordan han vakkert kan klippe koden i metoder. Han bruker aldri "hjernemusklene" sine til å løse vanskelige problemer i denne prosessen.
5. «Feil. Lengre."
Det er selvsagt ikke intervjuerens jobb å lære opp folk som kommer til intervju. Men hvis søkeren ikke kunne svare på spørsmålet, men fortsatt er interessert, er det et spørsmål å spørre eller i det minste peke ham til den riktige løsningen før han går videre til neste spørsmål profesjonell etikk, og demonstrerer at hvis noe skjer, vil de hjelpe ham, lære ham og ikke la ham være alene med tekniske problemer. Fortell ham i det minste noen få ord, hva han skal google, hva han skal lese. Tross alt, interesse for riktig avgjørelse oppgavene ligger i seg selv positiv kvalitet en teknisk spesialist, og du bør ikke demotivere en slik person ved å nedverdige hans feil eller unøyaktigheter.

Intervju fra intervjuerens perspektiv

Hver gang en ny ledig stilling åpner, må en ledende spesialist eller avdelingsleder gjennomføre mange tekniske intervjuer. Personer med ulik teknisk erfaring, treningsnivåer og forventninger kommer til intervjuer. For å gjennomføre intervjuer må du tenke gjennom en samtaleplan, lage en liste med spørsmål, og deretter prøve å forstå ut fra svarene på disse spørsmålene om personen er egnet for stillingen eller ikke. Og noen ganger sier søkere under intervjuer slike ting at det umiddelbart blir klart - nei, du kan ikke jobbe sammen med denne personen. Her er et utvalg nøkkelfraser fra søkere som skremmer meg personlig.
1. «Noen av spørsmålene dine er teoretiske. Jeg er ikke sterk i teorien, jeg er rutinert i praksis! La oss ta en bedre test!"
Ordet "teoretisk" uttales vanligvis med en avvisende konnotasjon, som om det var noe dårlig. Men det er ikke engang problemet. Tror du denne setningen ble innledet av intervjuerens forespørsel om å bevise Cauchys teorem? Gi presis definisjon tredje normalform? Ikke i det hele tatt. Jeg hørte slike utrop som svar på følgende spørsmål:

  • Hvordan er sammenligning med == forskjellig fra sammenligning med likeverdige i Java?

  • fortell oss hvordan hash-kartet fungerer.

  • Forklar med dine egne ord hva REST er.

  • Hva er transaksjoner og hvorfor trengs de?

Ja, fra et visst synspunkt er ethvert programmeringsspørsmål teoretisk hvis det ikke krever at du skriver en kodelinje her og nå. Men jeg er sikker på at en person med tilstrekkelig lang erfaring innen et bestemt felt bør kunne forklare de mest grunnleggende tingene med egne ord, eller i det minste ikke late som om uvitenhet om dem er normal og naturlig.
2. «Jeg forventet ikke den spanske inkvisisjonen her! Det er akkurat som å ta en eksamen på instituttet. Vanligvis spør de bare hvor han jobbet og hva han gjorde.»
Du har kommet for et teknisk intervju. I et teknisk intervju vil du bli stilt tekniske spørsmål for å teste dine tekniske ferdigheter. Overlat testmetoden og valg av spørsmål til intervjuerens samvittighet – spørsmålene virker kanskje ikke alltid tilstrekkelige for deg, men intervjueren vet nøyaktig hvilken informasjon han ønsker å få om deg ved å analysere svarene dine. Mange spørsmål trengs ikke for å teste kunnskapen din, men for å tvinge deg til å tenke og se på tankerekken din. Husk også at ikke alle spørsmål krever et helt nøyaktig svar, og hvis du svarer tydelig på minst halvparten av det de spurte deg om, vil dette allerede gjøre et godt inntrykk.
3. "Jeg trenger ikke å vite det, jeg spesialiserer meg på oppgaver på høyere nivå!"
Ikke forveksle spesialisering med uvitenhet om det grunnleggende innen programmering. Fra utviklerne mobilapplikasjoner Jeg har hørt lignende ting om TCP/IP-stabelprotokollene fra front-end-programmerere - som svar på spørsmål om sorterings- og søkealgoritmer. "Hvorfor skulle jeg vite dette, alt er i standardbiblioteket, jeg jobber på et høyere nivå." Som svar på slike uttalelser kom jeg for lenge siden med et par små problemer med snikskjulte algoritmer - i håp om å vise at en "naiv" løsning, utstedt av uvitenhet om algoritmer, ikke tåler kritikk, og til kl. minst oppmuntre til selvutdanning. Dessuten er dette ikke noen kunstig konstruerte oppgaver, men ting som skjer i utviklingen hver dag. Enhver kode er en algoritme. Å forstå grunnleggende algoritmer og datastrukturer er viktig for enhver programmerer, og Internett-protokoller er en base, uten kunnskap som det er umulig å kompetent skrive noe som går utover grensene til en datamaskin.
4. «Og du selv! / Vis meg koden din! / Men jeg gikk til GitHub-en din, og der er dette..."
Det siste en intervjuer ønsker er å ansette en person og deretter lytte til ham som kritiserer kodebasen hans. Ja, hun er mest sannsynlig ufullkommen. Ja, teknisk gjeld er overalt og alle har det. I enhver kode er det noe å kritisere. Men hvis du virkelig anser deg selv som så kul at du ser åpenbare problemer i koden til dine potensielle arbeidsgivere, oversett dette til et konstruktivt positivt: Jeg vet hvordan jeg kan forbedre meg, jeg har erfaring med dette emnet, jeg kan være til nytte for deg.
5. "Du tar feil!"
Alt kan selvfølgelig skje, men det er bedre å beholde din mening om intervjueren tar feil eller tviler på kompetansen sin til slutten av intervjuet. Så Google det og finn ut hvem av dere som hadde rett. Et teknisk intervju er ikke et sted for diskusjon eller selvhevdelse, og spørsmålene her er først og fremst stilt til deg. Intervjueren vil ikke spørre om noe han selv ikke forstår.

Konklusjon

Vet du hva det hyggeligste jeg hørte fra søkere under intervjuer? «Jeg svarte egentlig ikke, gjorde jeg? Kan du gi meg et stykke papir? Jeg skal skrive ned spørsmålene dine og finne ut av det hjemme, selv om du ikke ansetter meg, så vet jeg det nå.» Stolthetstårer velter opp i øynene dine - det var ikke forgjeves at du brukte en og en halv time på en person, han lærte selv noe av dette intervjuet. Selv om han nå er for svak for denne stillingen, vil kanskje dette oppmuntre ham til å utdanne seg, og om et år eller to kommer han igjen, viser seg fra sin beste side og får jobb – slik det skjedde en gang i min egen karriere.
Hvordan det skjer

I de fleste tilfeller inviteres en annen spesialist med høy grad av teknisk kompetanse til å foreta vurderingen, som som regel ikke forstår noe om personalspørsmål og metodikk for innhenting av informasjon om en persons personlighet, og et frontalt avhør av «hvem vet mer» begynner ganske enkelt. Noen intervjuere har rett og slett en sjekkliste med spørsmål. Mange bruker også praksisen med en testoppgave, som må fullføres før man planlegger et personlig intervju. Generelt, den som kan gjøre det beste løser problemet.

Generelt kan denne tilnærmingen være effektiv, men den har en rekke ulemper:
1. Det er en mulighet for at den intervjuende tekniske spesialist kan oppfatte avviket mellom søkerens erfaring og hans egen som mangel på erfaring i det hele tatt. For eksempel kan de spesifiseres ganske snevert praktiske spørsmål, som søkeren ikke har vært borti i praksis, som kan tolkes som "Hvordan kan du ikke vite dette, det er så enkelt." Og en personalspesialist vil aldri kunne gjenkjenne dette på grunn av kontekstens spesifikasjoner.
2. Selv om det stilles åpne spørsmål som "Hvilke problemer har du måttet løse?", igjen, kan avviket i erfaring tolkes som "Han er ikke egnet for oss fordi han ikke har gjort det vi har gjort på flere år ."
3. Noen tekniske spesialister, spesielt de som allerede har ganske mye erfaring, erkjenner lite at uvitenhet om spesifikke verktøy ofte ikke er en stor hindring. For eksempel, hvis en person ikke har jobbet med GIT, men kjenner CVS godt, reduserer dette betraktelig adgangsbarrieren til å eie verktøyet.
4. Det kan også være et problem når søkeren har lang praktisk erfaring og svarer godt på spørsmål spesifikke løsninger, men når han blir ansatt, viser det seg plutselig at han gjør ganske typiske feil på områder som han ikke har jobbet med før. Man får inntrykk av slike mennesker at de «er dumme ut av det blå» eller «kopier-limer aktivt kode» fra sine tidligere prosjekter.
5. Noen ganger kommer du over en spesialist som gir inntrykk av en nybegynner og hans CV viser lite praktisk erfaring, men det er viktig å forstå om han vil lykkes. For hvis det fungerer, kan du få en god "stjerne" for laget med en liten investering. Og det er ikke klart hvordan man gjenkjenner dette så nøyaktig som mulig.

Dette er bare noen av scenariene som ofte oppstår ved rekruttering av nye teknikere. Å intervjue en tekniker er som en oppgave hvor du har et digert maleri skjult bak roterende firkanter som du snur en etter en. Og oppgaven din er å gjette hele bildet, forutsatt at tiden din er begrenset og antallet mulige bilder er enormt.
For å være mer sannsynlig å filtrere ut disse negative scenariene, samt å gjennomføre intervjuer av tekniske spesialister mer effektivt, kan du bruke en spesiell informasjonsinnsamlingsmodell.

Klassifisering av kunnskap

Først må du bestemme deg for klassifiseringen av kunnskap. For å gjøre dette må de deles inn i 3 typer:
1. Fundamental- Dette grunnleggende kunnskap i et bestemt område. For eksempel kan dette være spørsmålet "Hvilke grunnleggende typer spørringer i SQL kjenner du?"
2. Anvendt er en ferdighet for å løse spesifikke problemer. Dette kan for eksempel være oppgaver på riktig skriving SQL-spørringer for spesifikke eksempler.
3. Instrumental er kunnskap om hvordan man bruker spesifikke verktøy. Hva er for eksempel forskjellen mellom innodb og myisam butikker?

Grunnleggende kunnskap er nødvendig for å bruke den til å forstå hvordan man best kan løse praktiske problemer. Praktiske oppgaver danner anvendt kunnskap, det vil si en forståelse av hvordan og hva som er best å gjøre. Med forståelse for at individuelle problemer løses best ved hjelp av spesifikke verktøy, utvikles også instrumentell kunnskap. Ofte begynner en person med litt øvelse, deretter studerer "hvorfor det fungerer på denne måten", prøver deretter å gjøre noe lignende, og så finpusser ferdighetene sine ved hjelp av verktøy.
For eksempel utvikler en person språkferdigheter på nøyaktig samme måte: først prøver han bare å gjenta etter foreldrene sine individuelle ord; så lærer han alfabetet; skriver deretter essays, artikler eller forretningsbrev; og bruker noen ganger oppslagsverk og ordbøker for dette.

Når noe gikk galt

Siden "akademisk utdanning" innen IT fortsatt er ganske svak, er de fleste spesialister i stor grad selvlærte. Dette skaper visse avvik, som kan forstås godt på denne modellen dersom et av kunnskapsområdene er hypertrofiert. Her er de klassiske portrettene av kandidater og deres forklaring:
1. Vet alt– har en betydelig mengde grunnleggende kunnskap, for eksempel ervervet gjennom enkelte kurs og lesing av bøker/artikler, men han har ikke praktiske ferdigheter i å anvende dem, noe som ikke plager ham i det hele tatt. Selv om du begynner å stille ham noen praktiske problemer, vil du alltid høre mye kunnskap om hvordan det faktisk skal fungere, hvordan de enkelte delene er ordnet, men det vil være ganske vanskelig for en slik kandidat å sette alt sammen for å løse problemet , uten dine tips. En ganske vanlig situasjon hvis du spør en kandidat om lite brukte OOP-mønstre: du vil høre en beskrivelse av mønsteret når det brukes i et akademisk eksempel, men integreringen i en live-oppgave vil være vanskelig.
2. Stackoverflow-utvikler- vanligvis snakker slike utviklere ganske aktivt om deres erfaring, om hvilke problemer og hvordan de klarte å løse, men når de prøver å svare på spørsmålet "Hvordan gjøre ...?" fra et praktisk område ukjent for dem, vil du enten høre et forsøk på å "trekke etter ørene" en annen løsning, eller et svar i stil med "Ja, dette kan Googles på 5 minutter, jeg har allerede sett dette et sted. ” Slike utviklere prøver ofte å trekke inn noen ferdige løsninger som de allerede har laget, og argumenterer som "Hvorfor gjøre det 2 ganger?", eller de kopierer og limer inn kode fra Internett og andre prosjekter. Når du spør "Hvorfor fungerer det slik?" eller "Hvordan kan dette gjøres annerledes?" kan ofte gå seg vill og prøve å oversette emnet.
3. Tools&Frameworks-utvikler. Spise gammel vits: «Hvordan begynne å lage en nettside i 1995? Åpne notisblokk og begynn å skrive kode. Hvordan begynne å lage en nettside i 2015? Last ned og installer composer, framework, cms-extension, bootstrap, jquery, bower, less, installer IDE, begynn å skrive kode." Dette er omtrent det samme for denne typen spesialister. Det meste av den anvendte erfaringen til slike spesialister er utelukkende relatert til et spesifikt verktøy. Konseptet "hjernebitrix" karakteriserer ganske spesifikt denne saken. For slike kandidater er det veldig vanskelig å gi oppgaver ved å bruke "native" kode, fordi uten et verktøy er det en nesten umulig oppgave for dem.
Disse eksemplene er gitt for tilfeller der et av kunnskapsområdene inntar en ledende posisjon, og siden følelsen av "overlegenhet" på dette området gir opphav til en følelse av ens egen "storhet", prøver spesialisten å holde fast ved det med alle. hans makt ("alle vil være kule"). For eksempel vil en Stackoverflow-utvikler, når han prøver å finne ut grunnleggende kunnskap, argumentere til det siste at "Jeg trenger ikke å vite dette, jeg har allerede gjort dette hundre ganger og alt fungerte."

Hvordan effektiv utvikling fungerer

Det mest effektive scenariet for utvikling av kunnskap er nettopp balansen mellom områder. Du kan oppnå det forskjellige måter, men det er umulig å tillate "forvrengning". For eksempel, du ønsket å lage en hjemmeside og forstår ikke noe om det (alle begynte med dette): du lastet ned wordpress (tok "verktøyet"); Googlet hvordan du setter opp alt og laget vår første blogg med flere artikler (ervervet anvendt kunnskap); Finn ut hvordan og hvorfor det fungerer, for eksempel hvordan databasen og hurtigbufferen er strukturert, hva motorarkitekturen er osv. (få grunnleggende kunnskap). Deretter kan du se på hvilke andre verktøy og hvordan de kan løse dette problemet, eller skrive ditt eget verktøy. Hvis du bare stopper på det første eller andre trinnet, kan du enkelt falle inn i en av kategoriene spesialister gitt ovenfor, og jeg er sikker på at du tydeligvis ikke vil ha dette :)

Hvordan vurdere kunnskap

Basert på denne modellen er det også mulig, og ganske enkelt, å "undersøke" tekniske spesialister angående deres læringsstrategi og i hvilken grad deres nåværende kunnskap tillater dem å effektivt løse problemer. Intervjustrategien er som følger: etter å ha stilt et spørsmål om et teknisk område av interesse til deg i et hvilket som helst kunnskapsområde, flytt ikke "horisontalt" innenfor kunnskapsområdet, men "vertikalt" inn i en tilstøtende type av kunnskap.
De spurte om grunnleggende kunnskap, spør deretter hvilke problemer personen løste ved å bruke den, eller stiller et praktisk problem der denne kunnskapen ville være nødvendig, og spør deretter hvilke verktøy som er tilgjengelige for å bruke denne kunnskapen og bedre løse praktiske problemer.

For eksempel: Hva er sammensatte b-tre-indekser og hvordan fungerer de? Kan du gi et eksempel når slike indekser kan være påkrevd, eller når de tvert imot ville være upassende? Hvordan kan du forstå at disse indeksene fungerer effektivt og hva kan brukes til dette?

Hvis du hører omfattende svar på alle disse spørsmålene, betyr det at spesialisten virkelig har prøvd å utvikle solid kunnskap på dette området og tilegne seg alle nivåer av kunnskap. Nå må vi trekke de riktige konklusjonene fra dette. Dette vil enten tyde på at spesialisten har hatt en enorm haug med oppgaver knyttet til indekser, eller at han har en god læringsstrategi (som ikke utelukker den første). For å finne ut om denne strategien eksisterer, er det nok å undersøke noen flere områder der kandidaten kanskje ikke er så kunnskapsrik, dette kan ofte ses fra CV-en.

Sterke og lovende kandidater viser at selv i mangel på kunnskap forstår de hva de mangler og velger effektiv tilnærming for å kompensere for manglende kunnskap. Hvis du sjekker flere områder på denne måten merker du at kandidaten har effektiv strategi trening, så er alt du trenger å gjøre å sjekke den grunnleggende kunnskapen som kreves for deg. Når alt kommer til alt, med dem og riktig læringsstrategi, vil kandidaten med høy grad av sannsynlighet kunne løse nye problemer så effektivt som mulig.
En effektiv læringsstrategi er en strategi for å fylle på kunnskap på ethvert område av alle typer (grunnleggende, anvendt, instrumentell): prøv noe, forstå hvordan og hvorfor det fungerer, gjør noe lignende, lær verktøy for å gjøre det enda bedre.

Typiske feil ved vurdering

Mange har en tendens til å overvurdere betydningen av anvendt kunnskap i forhold til andre områder, nemlig at personer med mer erfaring i å utføre oppgaver er gode spesialister, men dette er absolutt ikke tilfelle. Hvis praksisen ikke støttes av grunnleggende kunnskap, eller spesialisten aldri har utvidet verktøyene sine, kan effektiviteten til en slik spesialist være svært lav. Se etter de som kan utvikle hvert område. De er de beste, selv om de ikke har massevis av erfaring bak seg.

Du kan ofte finne testoppgaver som kun er snevert fokusert på grunnleggende spørsmål, for eksempel språkkonstruksjoner, typiske feil ved bruk av "ikke-intuitiv atferd", spørsmål om OOP-mønstre osv. Som du allerede kan forstå fra modellen ovenfor, vil du ikke identifisere "teoretikere" på denne måten, og dessuten er grunnleggende kunnskap perfekt googlebar. Så effektiviteten av slike tester er relativt lav.

Det er også en vanlig oppfatning at det er viktig å "forstå hvordan en person tenker." Dette er utvilsomt en "vakker" setning, men den er veldig subjektiv, og som et resultat er det vanskelig å være trygg på resultatet basert på slike vurderinger. I tillegg kan du her falle i fellen med en subjektiv vurdering: "han tenker ikke som meg." Imidlertid, hvis du ser at en person vet hvordan man effektivt formulerer kunnskapen sin og løser problemer, spiller det ingen rolle hvordan han gjør det, fordi det viktigste er resultatet.

Hvis du tilbyr attraktive samarbeidsvilkår og strømmen av kandidater er høy nok, så legg opp test. Inkluder flere spørsmål, ikke fra én type kunnskap, men fra forskjellige. Basert på svarene på disse spørsmålene kan du få et grovt bilde av hva kandidatens styrker og svakheter er.

Hva du skal se etter

Det er flere punkter du også bør være oppmerksom på under intervjuet. De forholder seg mer til personalkomponenten, men de dukker opp spesifikt under det tekniske intervjuet.

Nysgjerrighet i sinnet. Hvor hardt prøver en kandidat å løse et problem hvis han ikke vet løsningen med en gang? Er han ute etter alternative veier, analyserer ledetråder, spør og analyserer den foreslåtte løsningen. Svake kandidater "hopper over" alt de ikke kunne forstå.
Sunn selvtillit. I hvilken grad innrømmer kandidaten at han kanskje ikke vet noe? På grunn av sin oppvekst har folk noen ganger komplekser angående egen kunnskap ("ærede diplomstudenter", etc.). Noen ganger tar slike mennesker beslutninger på en skarp kategorisk måte og gjenkjenner ikke alternative meninger hvis de indikerer mangel på kunnskap hos kandidaten.
Ønsket om selvutvikling. De beste kandidatene er de som streber etter å utvikle seg som spesialister, eller som streber etter å "gjøre verden til et bedre sted" ved å skape en slags fordel. Svake kandidater tror at de allerede er "i taket av kunnskapen" og ønsker rett og slett å tjene så mye som mulig på dette. Det er også kandidater som mener at arbeidsgiver bør utvikle dem, og ikke seg selv, fordi det er arbeidsgiver som setter oppgavene.

Intervjustrategi

Før intervjuet, lag en liste over nøkkelområder der du trenger erfaring fra en spesialist. Det er bra hvis det er minst 10 av dem. For eksempel: PHP + OOP-mønstre. SQL + spørringsoptimalisering; arkitektur av høybelastningsprosjekter; jobber med cache osv.
I hvert nøkkelområde, lag minst 5 spørsmål for hver type kunnskap, for totalt minst 15 spørsmål for hvert område. Dette gjøres best for ikke å komme med spørsmål i farten. Det er ønskelig at slike problemer gir vertikal tilkobling seg imellom.

For eksempel:
Region: arkitektur av høybelastningsprosjekter.
Grunnleggende spørsmål: Hvilke hovedparametere er viktige å vurdere når man designer høylastsystemer? Hvilke typiske arkitektoniske løsninger kjenner du til? Hva er forskjellen mellom horisontal og vertikal skalering?
Søknadsspørsmål: Hvis brukere kan laste opp filer, hva er da den beste måten å løse problemet med horisontal skalering for retur? Hvis du har en side med høy RPM, og en informasjonsblokk som har lang tid generasjon, hvordan kan du øke hastigheten på sidegjengivelsen? Hvis en enkelt database har blitt en flaskehals i et prosjekt på grunn av økt arbeidsmengde, hva er den beste måten å nærme seg dette problemet på?
Instrumentelle spørsmål: Hvilke verktøy kan brukes til å lastebalanse HTTP-trafikk? Hvilke caching-servere kjenner du og hva er forskjellene deres? Hvordan kan du måle applikasjonsytelsen under store belastninger?

Start med et av spørsmålene du ønsker. Still konsekvent spørsmål fra hver kunnskapstype i det valgte området (vertikalt). Hvis du ser at kandidaten har en sikker beherskelse av teori, praksis og verktøy, så kan du være ganske sikker på at han også selvsikkert vil kunne løse relaterte praktiske problemer.

Når du svarer på spørsmålene, beveger du deg gjennom områdene, vil du danne deg et bilde av hvordan kandidatens kunnskap er fordelt. For eksempel kan du innse en betydelig mangel på teoretisk kunnskap, eller hull i kunnskap om verktøy. Basert på dette kan du trekke en konklusjon om hvor effektiv kandidatens opplæringsstrategi og hans nåværende kunnskap generelt er. Som regel er læringsstrategien den samme for alle områder, det vil si at det er svært sjelden å finne kandidater som kjenner teorien veldig godt på ett område, men på et annet bare løste praktiske problemer og ikke en gang prøvde å stille spørsmålet "Hvordan virker det?"

Vel, da, avhengig av kravene til den ledige stillingen, vil det være mye lettere for deg å ta en avgjørelse. Ser du etter en junior? Sørg for at du ikke bare prøver å løse praktiske problemer, men også fyller på grunnleggende kunnskap, og også ser etter og lærer nye verktøy. Leter du etter en mellomting? Sørg for at ferdighetene hans er forankret i hver type kunnskap, og at han forstår hvor han skal gå videre for å fylle hullene. Ser du etter en senior? Sørg for at han har utmerket grunnleggende kunnskap og effektivt kan "sette sammen" ethvert praktisk problem med grunnleggende begrunnelser og passende verktøy.

Hvis du merker noen hull i den nødvendige kunnskapen, og de ikke er grunnleggende for deg, men likevel er viktige, må du huske å skrive det ned og jobbe med det prøvetid en plan for å fylle disse hullene ved å bruke dette under sertifiseringen. Dette vil tillate deg å øke produktiviteten til dine ansatte på en metodisk og bevisst måte. Spørsmålet om opplæring og utvikling av ansatte er imidlertid en helt annen og veldig stor historie.

Hvor ellers kan du bruke modellen?

Den gitte modellen kan faktisk brukes ikke bare for tekniske spesialister, men for ethvert yrke generelt. Den eneste forskjellen vil være i hvor fullt ut visse typer kunnskap blir realisert på disse områdene. Ta for eksempel en vaktmester: Hvilke kriterier for renslighet kjenner du til? Hvis du trenger å rengjøre 10 hus på en dag, hva er den beste måten å gjøre det på? Hvilke rengjøringsmidler er best å bruke til hvilke overflater?

Som en konklusjon

Jeg bestemte meg nylig for å samle notatene mine om intervjuspørsmål for PHP-utviklere og legge dem ut åpen tilgang(prosjektet er "på kneet", så ikke klandre meg). Selvfølgelig er ikke alt der, men det er nok til å samle tankene dine og gjøre deg klar for intervjuet. Du kan se spørsmålene på linken:
pagerton.com/hr/question/all
Dersom det kommer positive svar vil jeg utvikle prosjektet så mye som mulig, jeg vil også sende lenker til gode kurs for utviklere, så jeg er takknemlig for tilbakemelding.
Jeg håper denne modellen kan være nyttig for deg også. Ikke bare som intervjuobjekt, men også som intervjuobjekt, fordi å forstå dine styrker og svakheter vil hjelpe deg å utvikle deg mer effektivt.
Jeg ønsker at du skal være den beste og jobbe med de beste.

Hei alle sammen, Javarashites! Tilfeldigvis hadde jeg nylig et intervju og vil gjerne fortelle deg hvilke spørsmål jeg ble stilt, forutsatt at jeg søkte på Junior++-stillingen. De. Ikke en midterste ennå, men heller ikke en grønn junior. Så intervjuet gikk i henhold til denne planen

  1. JavaCore
  2. Database.
  3. Verktøyene du bruker.

JavaCore

    Først ble jeg bedt om å tegne hierarkiet av grensesnitt for samlinger (det var ikke vanskelig, det er bare noen få av dem (Samling, Liste, Sett, Kø, Kart).

    Hva er forskjellen mellom ArrayList og LinkedList (dette er et av de mest utslitte spørsmålene og svarene på internett, bare mørke).

    Vi diskuterte hastigheten på utførelse av spørringer i dem og hva forskjellen er mellom arkene.

    Spørsmål om objektklassen. Hva er metodene hans, hva gjør de?

    Speilbilde. Hva getClass()-metoden gjør. Veldig interesse Spør, ta den fra hverandre. Spesielt om hvordan man får alt om en klasse, selv om den inneholder private metoder eller variabler.

    De spurte om multithreading. Det er svakt, synes jeg, å fortelle deg hvordan du forstår hva multithreading er. Hva skal til for å starte en ny tråd. Realistisk sett, hvis du er nivå 20+, vil disse spørsmålene virke morsomme for deg.

    Hva kan du si om Stream. Dette handler ikke om Java 8. Det handler om input- og output-strømmer. Som grunnleggende grensesnitt, hva de er (karakter og byte). For forståelse, ingen detaljer.

  • Unntak. Her ble vi igjen bedt om å tegne et hierarki av unntak, hvilke typer det finnes, hvilke som er krysset av og hvilke som ikke er krysset av. Hva du skal gjøre med Runtime-unntak. Navngi den oftest opptrådte (NullPointerException).

    • Spørsmålet er hva som skal gjøres med sjekkede unntak (fremsetter videre eller prosess – begge er klare).

OOP

    Hva er OOP i et nøtteskall?

    Hvilke andre programmeringsparadigmer finnes det? Hvordan er de forskjellige fra OOP?

    Hva er de grunnleggende prinsippene for OOP (arv, polymorfisme og innkapsling)? Fortell oss om hver av dem. Så langt er alt abstrakt, ikke knyttet til noe språk.

    Forståelsesoppgave for systemdesign: det er en hest og en fugl. Vi må få tak i Pegasus. prinsippet "har en" og "er en"

HVILE

    Hva er REST. Wikipedia snakker veldig kult om dette. En artikkel fra Wikipedia er faktisk nok å sette seg inn i.

    HTTP. Det er også generelle fraser her. Metodene hans, hva hver av dem er for.

    HTTP-statuskoder. Hvilke fem deler skal den deles inn i Fortell oss om de mest kjente (200,204,404,500,501). Hvorfor gjør de det? De spurte også om 401 og 403. Men jeg kjente dem ikke. De sa at de var viktige.

Database

Her fortalte jeg deg at jeg kan MySQL. fortalte om tre normale former. Jeg snakket om Joins, hva de er, og tegnet skjæringspunktet mellom områder der forskjellige joins brukes. Jeg snakket om hvordan jeg forstår en relasjonsdatabase. Jeg glemte heller ikke MongoDB - dette er en NoSQL-database , jeg skal skrive om det også.

Andre verktøy

Her gikk vi gjennom CV-en min. Det ble skrevet at jeg bruker Maven/Gradle til montering, jeg bruker JIRA til oppgaver, git, Docker, Swagger. For kontinuerlig integrasjon - Stash, Bamboo, Puppet. For testing av JUnit, Mockito, JMeter. Jeg har kanskje glemt noe, så hvis du er interessert - spør i kommentarfeltet Jeg skal prøve å svare. Dette var første del av intervjuet. Nå venter jeg på resultatene, og i så fall vil det være en andre del. Jeg vil skrive om det så snart som mulig. Alle som likte artikkelen og fant den nyttig - sett "+". Skriv i kommentarfeltet. Se også mine andre artikler:

Det er mye materiale på Internett dedikert til intervjuer med HR-ledere, men nesten ingenting er sagt om vanskelighetene ved intervjuer med tekniske spesialister. Denne artikkelen er viet til hvilke egenskaper og ferdigheter en kandidat må ha for å kunne bestå dette stadiet og motta et tilbud i et IT-selskap.

Dialog fra livet:

Kandidat: Vi må utføre operasjon "A" til betingelse "B" er oppfylt.
Meg: Flott plan. La oss implementere det.

Kandidaten skriver en for hver løkke. Selv om det er åpenbart. Hvis en kandidat består dette nivået, vil han før eller siden bli en god programmerer. Men 70 % av søkerne stryker her.

Bogdan Gusev, bensinstasjon

La oss rette opp denne irriterende misforståelsen.

while (bool tilbud == usant)(

Regel 0

Skal du intervjue for rollen som Java-utvikler, må du ha god kunnskap om Java og relaterte teknologier

//Ingen kommentarer.

Regel 1

Forbered deg på intervjuet på forhånd

Finn ut av rekruttereren på forhånd alle mulige detaljer om prosjektet.

Google-søk etter spørsmål som ofte stilles i intervjuer. Noen av dem vil definitivt komme over.

Alexander Pitz, prosjektleder

Regel 2

Ikke lyv på CV-en din

Å prøve å lure ved å overdrive kunnskapen din er bortkastet tid og selskapets tid. Du må kunne svare på spørsmål om alle teknologiene som er oppført på CV-en din.

Et CV fylt med søkeord, som du ikke har skikkelig forståelse for, ødelegger sjansene dine for å motta et tilbud.

Regel 3

Juster dine verdier med selskapets verdier

Hvert selskap har sine egne verdier. Ett lag verdsetter engasjement og fokus på resultater, og forakter som et resultat ikke overtidsarbeid. Den andre er innovativ på jobben, og er villig til å lære og ta i bruk innovasjoner annenhver måned. Den tredje er pålitelighet og stabilitet: velprøvde teknologier, dedikerte mennesker som ikke vil forlate selskapet hvis informasjonskapslene plutselig forsvinner.

Det er en akseptabel grense for avvik mellom verdier, ved overskridelse vil selskapet mest sannsynlig velge å ikke gi tilbud, selv om kandidaten har nødvendig erfaring og nødvendig teknisk kunnskap.

Regel 4

Utvikle kommunikasjonsevner

Jeg ønsker at søkeren skal ha bedre kommunikasjonsevner høy level enn den grunnleggende. I vår tidsalder med fullstendig smidighet kommer denne egenskapen frem blant de nødvendige ferdighetene. Kandidaten skal ikke ha problemer med å kommunisere med HR- og tekniske spesialister, samt med kunder.

Regel 5

Forbedre engelsken din

I motsetning til ukritiske feil i kunnskap om enhver teknologi, vil du ikke kunne forbedre språkkunnskapene dine på et par måneder. Det tar år her. Derfor er utilstrekkelig nivå i engelsk i de fleste tilfeller en tilstrekkelig grunn for avslag.

En liten motivasjon: nivået på engelsk og lønnen til Kyiv Java og .NET mellomstore og seniorer med 3-5 års erfaring tilsvarer.

Regel 6

Vis din lidenskap for yrket ditt

I følge Bogdan Gusev kan det faktum at du liker arbeidet ditt indikeres av tilstedeværelsen av Open Source-prosjekter, deltakelse i tematiske konferanser og mestring av tekstredigerings- eller IDE-funksjoner. Og selvfølgelig interesse for detaljer videre arbeid. Programmerere som er likegyldige til arbeidet sitt er ikke etterspurt blant arbeidsgivere.

Regel 7

Vis intelligens og abstrakt tenkning

Kandidaten må:
- kunne løse problemer som tilsvarer hans stilling;
- kjenne nødvendig programmeringsspråk og rammeverk;
- navigere i teknologiene til prosjektet han blir intervjuet for.

Hvis stillingen er dårlig definert, testes generell lærdom og intelligens, samt evnen til å tenke strukturelt og finne løsninger.

Det er svært viktig å demonstrere evnen til å bruke kunnskapen din. Hvis du kjenner tilnærminger og metoder for å løse problemer og vet hvordan du kan innhente manglende informasjon, så vil du være i stand til å takle oppgavene du får.

Regel 8

Vis et ønske om å få ny kunnskap

Noen ganger vil en kandidat si: «Jeg har studert teknologi X og jeg vil bare jobbe med den. Hvorfor skal jeg studere teknologi Y hvis jeg kjenner X?» Sjansene for at en slik kandidat får et tilbud er kraftig redusert. Teknologi er bare verktøy. Etter en tid vil X bli irrelevant, og med det spesialisten selv, som bare vet det.

Maxim Kovtun, løsningsarkitekt

Regel 9

Vis resultatorientering

Jeg vurderer:
- Evnen til å gå på akkord med ens "religiøse tro" (for eksempel, hvis en utgivelse krever det, bruk en "hot fix" i stedet for å nærme seg løsningen fundamentalt);
- Evnen til å insistere på egenhånd når det er nødvendig;
- og enda viktigere - evnen til å opprettholde den rette balansen mellom de to punktene ovenfor.

Andrey Mudry, prosjektleder

Regel 10

Ikke si "jeg vet ikke"

Unntak: hvis du aldri har jobbet med denne teknologien og den ikke er oppført på CV-en din. I dette tilfellet er det bedre å være ærlig og be intervjueren forklare deg det riktige svaret.

Hvis du ikke forstår hva vi snakker om, still et oppklarende spørsmål.

Hvis spørsmålet er spesifikt og du ikke er sikker på svaret, bør du innrømme det og sørge for å gjøre antagelser basert på din erfaring. Forklar tankeprosessen din. Hvis spørsmålet er åpent, er det ikke et enkelt riktig svar.

Det verste svaret er stillhet eller "jeg vet ikke." Du må prøve å løse problemet, uansett hvor dum løsningen din kan virke. Selv det mest naive svaret er bedre enn ingenting. To eller tre svaralternativer er generelt gode. Pepp disse svarene med betraktninger om deres anvendelighet og tilleggsspørsmål for å avklare problemet - og det vil være flott.

Alexey Kolupaev, bensinstasjon

Regel 11

Ikke vær sjenert for å lære selv under et intervju.

Det er umulig å vite alt. Jeg jobbet en gang med et prosjekt som krevde kunnskap om en ganske spesifikk teknologistabel og kartografi. Erfaring har vist at få programmerere kan konvertere den klassiske koordinatnotasjonen fra WGS84 til desimalnotasjonen. I slike tilfeller tror jeg et godt svar i et intervju er spørsmålet: "Kan jeg se på Google?"

Artem Polyukhovich, CTO

Regel 12

Tenk på hva du sier som svar

Du trenger ikke late som du er mentalt aktiv et minutt, men prøv å tenke så bredt på problemet som mulig. Dessuten er det ofte lurespørsmål under intervjuer.

Det er bra om kandidaten prøver å «utlede» det riktige svaret på spørsmålet. Han gjetter ikke, men bruker sin eksisterende kunnskap, samt logikk, intelligens, oppfinnsomhet og evnen til raskt å ta beslutninger under press. Denne kvaliteten er svært nyttig i en fleksibel tilnærming til utvikling, når kunden krever det rask avgjørelse problemer, noen ganger til og med under en nettkonferanse.

Sergey Chirkov, prosjektleder

Regel 13

Innrøm feil du har gjort

Evnen til å analysere og innrømme dine feil indikerer at du vil være interessert i både din egen faglige utvikling og resultatet av en bestemt jobb.

Regel 14

Ikke ødelegg ryktet ditt

Et uforsiktig svar på spørsmålet "Hvorfor forlot du et slikt og slikt selskap?", desorganisering, å komme for sent til et intervju uten forvarsel, eller et avslag på å fullføre en testoppgave kan ødelegge en mening om deg.

Regel 15

Bygg et partnerskap med intervjueren

Det virker for meg som om i uttrykket «arbeidsforhold» fokuserer mange på «arbeid», men de bør legge mer vekt på «forhold». I denne forstand ligner et intervju på en date: dere ser begge nærmere på hverandre, finner ut om dere vil ha det bra sammen. Og når noen prøver hardt å virke bedre enn de er, kan det være irriterende. Noen ganger kan en kandidat være så fengende at det er lett å lukke øynene for alvorlige mangler.

Alexey Kolupaev, bensinstasjon

Regel 16

Oppfør deg skikkelig

"Korrekt" betyr høflig, respektfullt. Arroganse, indignelse eller smiger mot intervjueren vil bare ødelegge inntrykket. Humor er heller ikke alltid passende.

Flere mislykkede atferdsmønstre kan identifiseres:
  • Venn- flytter samtalen til et uformelt nivå for å unngå konkrete svar på spesifikke spørsmål.
  • erobrer- tar initiativet i egne hender, snakker høyt og mye, og lar ikke spørsmål.
  • lat person- etter en times intervju viser han at han opplever ekte pine - en slik person vil neppe kunne jobbe intensivt mer enn 1 time om dagen.
  • arkitekt- oppretter et stort antall ubrukelige klasser før man skisserer en løsningsplan. Som et resultat kan den ikke selv dra nytte av sin egen "arkitektur".
  • teoretiker- den farligste typen, klar til å kommunisere om ethvert emne, så lenge han ikke er tvunget til å vise praktisk kunnskap. Kan enkelt beskrive en løsningsalgoritme, men klarer ikke å programmere den.

Sistnevnte bestemmes enkelt av følgende dialog:
Meg: Ta med den bærbare datamaskinen til intervjuet
Kandidat: Hvorfor?

Etter en slik dialog er det umiddelbart klart at kandidaten mener at hovedsaken med å være programmerer er å snakke om kule teknologier på kjøkkenet. Han vet ikke at programmering på et kjent tastatur er mye enklere enn på et utenlandsk. Følgelig bruker han lite tid på det. Jeg lurer på hvordan arbeidsdagen hans går?

Bogdan Gusev, bensinstasjon

Regel 17

Vær tilstrekkelig :)

Tilstrekkelighet er et ganske vidt begrep. Først og fremst inkluderer det en reaksjon på vanskelige situasjoner. Hva gjør en person når han står overfor en uforståelig kodebit eller en kompleks algoritme? Hvordan vil han oppføre seg med kollegaer når han trenger noe fra dem (eller trenger dem)? Hva gjør han hvis det oppstår en interessekonflikt? Hva om han får en umulig eller vanskelig oppgave?

Artem Polyukhovich, CTO

Regel 18

Vær optimistisk

Positiv holdning - veldig nyttig kvalitet. Det er mye mer behagelig å jobbe med en person som vet å legge merke til positive øyeblikk i livet, i jobben, i alt.

Regel 19

Føl deg fri

Et intervju er en diskusjon mellom to likeverdige spesialister. Dermed er stivhet mer et minus enn et pluss. Det vil hindre deg i å uttrykke deg på riktig nivå.

Men for mye selvtillit er også et minus. En monolog i 20 minutter uten stopp kan tjene som grunn til avslag.

Oppfør deg naturlig, ikke vær sjenert. Hvis du for eksempel synes det er lettere å behandle informasjon visuelt, ikke vær redd for å be om papir og penn.

Regel 20

Hvis du mislykkes, lær av dine feil

Tenk på intervjuet som en mulighet til å lære noe nytt og få tilbakemeldinger. Dette vil være gunstig selv om du ikke mottar et jobbtilbud.

Alexander Kaganovsky, bensinstasjon

Intervjuer rangerer høyt på listen over de flestes største frykt, sammen med offentlige taler. Ikke bare opptrer du foran noen, men du blir også konstant evaluert hele tiden... brrrr!

Selvfølgelig er vi langt fra å prøve å forstå og overvinne dine psykologiske barrierer, men det er definitivt best å se på intervjuer som en sjanse til å vise frem alle de kule tingene du har laget og alle de interessante nye ferdighetene du har lært. Beste intervjuer– dette er entusiastiske samtaler med teknisk slagside.

Det første trinnet før alt dette er forberedelse. Du bør tenke på mulige spørsmål (og de vanligste svarene som fremhever din glans) og undersøke ansettelsesselskapet. Din kunnskap om selskapet vil hjelpe deg å presentere deg selv på en måte som passer deres behov, og vil også tillate deg å stille smarte spørsmål om deres produkter og teknologier når den tid kommer. Igjen, se Happy Bears artikkel for praktiske tips.

Hva er hele denne prosessen?

Bare en rask titt på prosessen det gjennomsnittlige teknologiselskapet går gjennom når de ansetter utviklere:

  1. Foreløpig intervju på telefon (telefonskjerm)
  2. Teknisk intervju
  3. Testmanual
  4. Oppfølgingsintervjuer for å sikre at du passer godt (Fit Interviews)
  5. Jobbtilbud
  6. Diskusjon av tilbudsvilkår (tilbudsforhandling)
  7. Tilbud aksept

Foreløpig telefonintervju

Gratulerer! CV-en din viste seg å ikke være den mest katastrofale, og du ble invitert til et telefonintervju (merk at noen ganger gjør du en testoppgave først). Den virkelige hensikten med dette trinnet, som ofte involverer en halvtimes samtale med noen i HR (i stedet for ansettende beslutningstaker), er å sørge for at du har en god sjanse til å komme deg gjennom resten av intervjuprosessen. Så tenk på det som en lettere versjon av de andre trinnene.

Du vil sannsynligvis bli spurt om noen av de tekniske tingene du legger på CV-en din, men ikke gå for dypt (selv om noen arbeidsgivere stiller noen ganske vanskelige spørsmål), og du vil sannsynligvis bli stilt noen "mykere" spørsmål om hvorfor du valgte denne jobben og hva du gjorde før. Telefonintervjuer kan variere mye fra bedrift til bedrift. Hovedtaktikken her er ikke en taktikk i det hele tatt, bare vær ærlig, energisk og åpen. Og ikke vær redd for å trene på å snakke om deg selv foran speilet.

EN AFSLUTTENDE MERKNAD - Dette er ikke en metode som passer for alle, og mange selskaper hopper over den til fordel for å dykke rett i dypet av et teknisk intervju, så du må forberede deg i tilfelle. Linken nedenfor til Coding Horror er den mest illustrerende for denne saken.

  • Oppnå fremragende telefonintervju med Monster
  • 7 trinn for å oppnå fremragende telefonintervjuer

Teknisk intervju

Det tekniske intervjuet er vanligvis den skumleste delen av utvelgelsesprosessen. Det er her de vil vurdere om du har de nødvendige tekniske ferdighetene. Dette betyr at de ikke bare vil spørre deg i detalj om arbeidet ditt, men også be deg om å bestemme logiske problemer eller skriv kode der eller skisser et diagram over noen nye komponenter.

Faktisk er en av hensiktene med et slikt intervju å ta deg helt til kanten av dine evner, bare for å se hvordan du reagerer på ukjente ting. Hvis du gjør en øvelse for lett, vil de gå videre til noe mye vanskeligere. Det vil alltid være steder å snuble, spesielt for nybegynnere. Din største ressurs er din ærlighet og nysgjerrighet.

Når du løser et problem, sørg for at du gjør det på en klar og logisk måte, og forklarer høyt hvorfor du gjør et bestemt trinn. Snakk gjennom alle hindringene du møtte og gi eksempler på hvordan du ville løse det i " virkelige verden". Ofte er svaret å "Google" noen spesifikk funksjon. Si det! De vet at du ikke er en Ruby-ekspert, men de må også vite at du kan komme opp med løsninger på problemene du uunngåelig vil møte på jobben.

Det er også helt normalt hvis du bruker brute force – en ineffektiv metode – for å løse et kodeproblem. Dette er ofte det beste utgangspunktet for å få en skikkelig følelse av problemet. Mest sannsynlig vil du bli spurt om hvordan du kan forbedre løsningen, men dette er mye bedre enn å prøve å komme opp med den perfekte løsningen og ikke ha tid til å skrive noe til slutt. Nok en gang er jobben din ikke å være en fremstående kandidat, men å vise at du er tilpasningsdyktig og robust når du møter utfordringer.

Og hvis du ikke vet noe, er det bedre å si det ærlig og prøve å tenke gjennom det med intervjueren. Tro meg, de vil at du skal lykkes like mye som du gjør, for det er ikke noe verre for en intervjuer enn å se noen i stillhet prøve å løse et problem, bli mer og mer fast uten å be om hjelp og ikke la noen få vite hva han var. tenker.

Du må lese om store mengder ting som ikke ble vektlagt i tidligere kurs, for eksempel datastrukturer og algoritmer, rett og slett fordi det er veldig populære spørsmål om dem i intervjuer. De reflekterer ikke alltid programmeringsferdigheter godt, men det hender at du må svare på spørsmål som faller inn under et mer akademisk område av datakunnskap.

Lenker

  • La oss se på intervjuet for programmerere: MÅ LESE MATERIALE hvem vil bli din bestevenn. Det tar en omfattende titt på alle typer utfordringer du vil møte i et intervju. Det går utover det vi allerede har dekket i dette kurset og berører ting som er greit å vite fordi du sannsynligvis vil møte dem. Ta deg tid til å bli kjent med så mange som mulig stort beløp materiale.
  • Interviewing.io gir deg sjansen til å øve anonymt og online tekniske intervjuer.
  • Hvordan få en perfekt poengsum i et teknisk intervju
  • Slik skiller du deg ut i ditt neste jobbintervju med webutviklere
  • Les 40 viktige datavitenskapelige konsepter forklart på et lettfattelig språk
  • Googles veiledning for tekniske ferdigheter(for viderekomne)

Programmering av testoppgaver:

  • 8 dronninger er et klassisk problem.
  • Programmering for intervjuer: Vet at standardbibliotekene kan være overkill for en nybegynner, men det skader aldri hvis du tar deg tid til det.
  • På Project Euler vil du finne mer generelle og komplekse problemer som må løses effektivt (de kan kreve mye beregning).
  • Øvingsspørsmål for Java og Python publiseres på Coding Bat.

Algoritmetrening:

  • Algoritmekurs fra Udacity (ikke synkronisert)
  • Algoritmekurs fra Coursera (delvis synkronisert)

Arkitektur:

Teknisk testoppgave

Test hjemmelekser kan skje enten før eller etter et personlig intervju, avhengig av selskapet. Du vil få en oppgave som vil kreve en hel dag å fullføre når som helst som passer deg. Eksempler på en slik oppgave kan være å lage et eksempel på en nettapplikasjon med tester eller å løse et komplekst algoritmisk problem med å skrive kode.

Evalueringen vil være basert på fullstendigheten til løsningen og kvaliteten på koden din. Hvis dette skjer før det tekniske intervjuet, så er det det god metode sjekk interessen din (opptil halvparten av søkerne kommer ikke engang tilbake med en løsning).

Avsluttende intervju ("Fit")

Det siste trinnet før du tar en beslutning er vanligvis å bli kjent med teamet og kontorene i noen timer. Du kan bli testet teknisk, men hovedmålet er å sørge for at du blir en god kollega. Hvis et annet teammedlem sier at du ikke vil fungere bra, vil de mest sannsynlig ikke ansette deg. Råd? Du trenger ikke være rar eller vanskelig, selv om du er hjemme :)

Dette er også en mulighet for deg. Hvis du har kommet så langt at du har kommet til dette trinnet, er det en god sjanse for at du generelt er kvalifisert. Du må vurdere om du vil jobbe for dette selskapet, så lag en liste med spørsmål og få svar på dem.

Litt om lønn

Ikke. Stem det ut. Ditt. Lønn. Forventninger.

Du vil alltid bli spurt "hvor mye vil du motta?" Ditt svar? "Jeg vil gjerne bli betalt til gjennomsnittlig markedspris" (med mindre du er så arrogant at du spør over markedsprisen. La oss se hvordan det fungerer for deg). Du vil ikke tjene noe ved å angi ønsket lønnsnivå. Hvis det viser seg å være lavere enn det de ønsket å tilby deg, vil de ganske enkelt senke dette nivået. Og hvis den er høyere, vil de ganske enkelt avbryte hele prosessen og bestemme at du er for dyr for dem.

Når du får et tilbud, kan du sjekke hvordan det er sammenlignet med gjennomsnittlig markedslønn ved å spørre noen få personer (forhåpentligvis kjenner du allerede noen få personer å spørre) eller ved å gå til Glassdoor (bare husk at du er nybegynner, noe som betyr at du vil ikke motta en "gjennomsnittlig" lønn). Det viktigste er å ikke skade deg selv når du blir spurt.



Lignende artikler