Hvordan man ikke fejler en teknisk samtale hos en it-virksomhed. Bestå det tekniske interview

Visninger: 805

Der hældes meget smerte ud på internettet om mislykkede interviews. Nogle kunne ikke lide interviewernes spørgsmål, andre blev stødt af latterliggørelse, andre blev bedømt ud fra deres VKontakte-side. Interviewerne følger med ansøgerne og bander over, hvor dårlig personalesituationen er i disse dage, og hvilke dumme svar uerfarne programmører giver på deres vanskelige spørgsmål. tekniske problemer.

Desværre er der ingen universelle regler for beståelse og afholdelse af samtaler, og det kan det ikke være, fordi medarbejderne ikke kun udvælges ud fra deres tekniske færdigheder og personlige egenskaber, men også ved at matche nogle (ofte implicitte og meget subjektive) "profiler", som iflg. til interviewere, passer ind i deres team eller virksomhed. Hvad angår guiderne fra serien "hvordan man passerer interviews korrekt", forårsager de normalt ikke mindre smerte i kommentarerne, fordi de er meget subjektive og er sikre på at røre ved nogens smertepunkter.

I løbet af min professionelle karriere har jeg været på begge sider af hegnet, selvom jeg nok har været nødt til at lave lidt flere tekniske interviews end at bestå dem. Men i løbet af denne tid har jeg akkumuleret en række "fadser", der skræmmer mig væk under et teknisk interview og straks i mit sind sætter en stopper for den videre samtale. Det var det, jeg ville tale om - set fra interviewerens og ansøgerens perspektiv. Jeg vil straks tage forbehold for, at artiklen afspejler mine personlige subjektive indtryk og ikke foregiver at være en "guide til interviews." På den anden side er dette ikke et kortvarigt raseriudbrud fra et mislykket interview, men et langvægtet sæt af kriterier, der, omend på et negativt grundlag, giver mig mulighed for at luge ud i muligheder eller ikke at skræmme en potentielt egnet ansøger væk. mig selv.

Hvad irriterer eller stresser dig under interviews? Del i kommentarerne.

Interview fra ansøgers perspektiv

Hver gang en programmør leder efter et job, skal han igennem mange tekniske interviews. Han går rundt på kontorer eller taler på Skype, løser problemer eller tager test, svarer på vanskelige tekniske spørgsmål, prøver at demonstrere sig selv med den bedste side. Han vurderer dog også selv de personer, der interviewer og tester ham, og tænker, at han i morgen potentielt skal arbejde sammen med disse mennesker. Og der er mange måder at gøre det på tekniske interviews for at skræmme ansøgeren væk fra en interessant stilling. Jeg vil fortælle dig om, hvad der altid har skræmt mig personligt, og hvad jeg forsøger at undgå som interviewer.
1. "Hvad ellers teknisk interview?»
Den første og vigtigste ting, der altid har alarmeret mig ved et teknisk interview, er dets fravær. Det sker, at hele samtalen med tekniske specialister - potentielt fremtidige kolleger - er baseret på spørgsmål vedrørende professionel erfaring: hvor han arbejdede, hvilke projekter han arbejdede på, hvilken funktion han udførte i dem. Med hensyn til teknologi eller viden - spørgsmål på niveauet "hvilken farve er lærebogen." Ved du, hvad en Message Broker er? Super, vi tager dig!

Denne tilgang til interview har altid vendt mig skarpt mod en potentiel arbejdsgiver. De stillede mig ikke et eneste spørgsmål for at kontrollere, at jeg virkelig kendte min virksomhed. Det ser ud som om de personer, der interviewer mig, enten ikke selv forstår noget om emnet og leder efter mindst én person, der forstår, eller simpelthen er desperate og klar til at tage imod nogen. Jeg ville i hvert fald næppe have lyst til at arbejde i et team rekrutteret på denne måde.

2. "Nå, hvad lavede du der i det..."
Det er overraskende, hvor ofte afvisende holdninger til ansøgere forekommer under tekniske samtaler. Ja, måske er du en streng og erfaren programmør med en masse projekter under bæltet, du blev revet væk fra ekstremt vigtigt arbejde af hensyn til nogle unødvendige interviews med folk, hvoraf de fleste efter din mening er fuldstændig inkompetente. Men glem ikke, at du i øjeblikket repræsenterer din virksomhed og dit team, og en person vil helt sikkert foretage en vurdering baseret på din adfærd om klimaet i teamet, og hvordan de vil blive behandlet i dette team. Vær høflig og respektfuld over for ansøgeren, selvom du fra de første fem minutter indså, at han ikke skulle have lov i nærheden af ​​din dyrebare kode.
3. "Dit fornavn/efternavn/patronymnavn er skrevet forkert på dit CV!"
Dette er slet ikke teknisk, men ikke desto mindre er det et almindeligt problem selv i tekniske interviews. Heldigvis har jeg et ret simpelt og almindeligt navn, og sådanne problemer er ikke sket for mig. Jeg ved dog, at der er overraskende mange mennesker, der fuldt ud tror på, at visse navne og endda patronymer simpelthen ikke eksisterer. De vil overbevise dig om, at det korrekte navn ikke er "Danila", men "Daniil", eller at der ikke er noget navn "Alena", men kun "Elena". De vil tilbyde at rette og skrive "korrekt" i deres dokumenter. Mennesker med sjældne eller usædvanlige navne, og tro mig, det er utroligt irriterende. Så der er en simpel regel: der er ingen sådanne navne, der ikke eksisterer. Skriv rigtigt som skrevet i passet. Vis respekt over for ansøgeren og opfatt ham ikke så dum, at han ikke er i stand til at kopiere fra passet til CV'et fornavn. Selvom du har mistanke om en fejl, kan du afklare dette på en mere taktfuld måde.
4. "Hvor mange golfbolde ville der kræves for at rense alle de runde vinduer på en skolebus, der blev krympet til størrelsen af ​​et nikkel under evakueringen af ​​San Francisco og ikke brugt mere end 3 vejninger?"
Ingen artikel om interviews ville være komplet uden at nævne brønddæksler. Du kan betragte dette som min personlige pointe relateret til manglende evne til hurtigt og under pres at løse ikke-standardiserede problemer. Men jeg er sikker på, at hjernevridere er absolut ubrugelige under interviews. Eller rettere, det er det fantastisk måde rekruttere en fuld afdeling af hjernevidundere med hjerneolympiaden, som vil udveksle friske hjernevridere hele dagen lang i stedet for at arbejde. Rigtig programmør i naturlige miljø livet, selv når han beskæftiger sig med meget fede og ikke-standardiserede opgaver, koder han stadig sjældent under pres, og bruger det meste af dagen på at sidde og roligt tænke i en forholdsvis rolig atmosfære over, hvordan han smukt kan skære koden i metoder. Han bruger aldrig sine "hjernemuskler" til at løse vanskelige problemer i denne proces.
5. “Forkert. Længere."
Det er naturligvis ikke interviewerens opgave at træne folk, der kommer til samtale. Men hvis ansøgeren ikke kunne besvare spørgsmålet, men stadig er interesseret, så er det et spørgsmål at tilskynde eller i det mindste pege ham på den rigtige løsning, før han går videre til det næste spørgsmål professionel etik, en demonstration af, at hvis der sker noget, vil de hjælpe ham, lære ham og ikke lade ham være alene med tekniske problemer. Fortæl ham i det mindste et par ord, hvad han skal google, hvad han skal læse. Når alt kommer til alt, interesse for den rigtige beslutning opgaverne ligger i sig selv positiv kvalitet en teknisk specialist, og du bør ikke demotivere en sådan person ved at nedgøre hans fejl eller unøjagtigheder.

Interview fra interviewerens perspektiv

Hver gang en ny ledig stilling åbner, skal en førende specialist eller afdelingsleder gennemføre mange tekniske samtaler. Folk kommer til interviews med forskellig teknisk erfaring, uddannelsesniveauer og forventninger. For at gennemføre interviews skal du gennemtænke en samtaleplan, udarbejde en liste med spørgsmål og derefter forsøge at forstå ud fra svarene på disse spørgsmål, om personen er egnet til stillingen eller ej. Og nogle gange siger ansøgere under samtaler sådan nogle ting, at det med det samme står klart - nej, man kan ikke arbejde sammen med denne person. Her er et udvalg af nøglesætninger fra ansøgere, der skræmmer mig personligt.
1. “Nogle af dine spørgsmål er teoretiske. Jeg er ikke stærk i teorien, jeg er rutineret i praksis! Lad os lave en bedre test!"
Ordet "teoretisk" udtales normalt med en afvisende konnotation, som om det var noget dårligt. Men det er ikke engang problemet. Tror du, at denne sætning blev indledt af interviewerens anmodning om at bevise Cauchys sætning? Give præcis definition tredje normalform? Slet ikke. Jeg hørte sådanne udråb som svar på følgende spørgsmål:

  • Hvordan er sammenligning med == forskellig fra sammenligning med ligemænd i Java?

  • fortæl os, hvordan hash-kortet fungerer.

  • Forklar med dine egne ord, hvad REST er.

  • Hvad er transaktioner, og hvorfor er de nødvendige?

Ja, fra et bestemt synspunkt er ethvert programmeringsspørgsmål teoretisk, hvis det ikke kræver, at du skriver en kodelinje lige her og nu. Men jeg er sikker på, at en person med tilstrækkelig stor erfaring inden for et bestemt felt burde være i stand til at forklare de mest basale ting med egne ord, eller i det mindste ikke lade som om, at uvidenhed om dem er normal og naturlig.
2. "Jeg havde ikke forventet den spanske inkvisition her! Det er ligesom at tage en eksamen på instituttet. Normalt spørger de bare, hvor han arbejdede, og hvad han lavede."
Du er kommet til en teknisk samtale. I et teknisk interview vil du blive stillet tekniske spørgsmål for at teste dine tekniske færdigheder. Overlad testmetoden og valg af spørgsmål til interviewerens samvittighed – spørgsmålene virker måske ikke altid fyldestgørende for dig, men intervieweren ved præcis, hvilken information han ønsker at få om dig ved at analysere dine svar. Mange spørgsmål er nødvendige for ikke at teste din viden, men for at tvinge dig til at tænke og se på din tankegang. Husk også, at ikke alle spørgsmål kræver et helt præcist svar, og hvis du klart svarer på mindst halvdelen af ​​det, de spurgte dig, vil dette allerede gøre et godt indtryk.
3. "Det behøver jeg ikke at vide, jeg er specialiseret i opgaver på højere niveau!"
Forveksle ikke specialisering med uvidenhed om det grundlæggende i programmering. Fra udviklerne mobile applikationer Jeg har hørt lignende ting om TCP/IP-stackprotokollerne fra frontend-programmører - som svar på spørgsmål om sorterings- og søgealgoritmer. "Hvorfor skulle jeg vide det, alt er i standardbiblioteket, jeg arbejder på et højere niveau." Som svar på sådanne udsagn kom jeg for længe siden med et par små problemer med snigende skjulte algoritmer - i håbet om at vise, at en "naiv" løsning, udstedt af uvidenhed om algoritmer, ikke tåler kritik, og at kl. mindst tilskynde til selvuddannelse. Desuden er det ikke nogle kunstigt konstruerede opgaver, men ting der sker i udvikling hver dag. Enhver kode er en algoritme. Forståelse af grundlæggende algoritmer og datastrukturer er vigtigt for enhver programmør, og internetprotokoller er en base, uden viden om hvilken det er umuligt at skrive noget kompetent, der går ud over grænserne for en computer.
4. “Og du selv! / Vis mig din kode! / Men jeg gik til din GitHub, og der er dette..."
Det sidste, en interviewer ønsker, er at ansætte en person og så skal lytte til ham, der kritiserer sin kodebase. Ja, hun er højst sandsynligt ufuldkommen. Ja, teknisk gæld er overalt, og alle har det. I enhver kode er der noget at kritisere. Men hvis du virkelig anser dig selv for så sej, at du ser åbenlyse problemer i dine potentielle arbejdsgiveres kode, så oversæt dette til et konstruktivt positivt: Jeg ved, hvordan jeg kan forbedre mig, jeg har erfaring med dette emne, jeg kan være til gavn for dig.
5. "Du tager fejl!"
Alt kan selvfølgelig ske, men det er bedre at bevare din mening om, hvorvidt intervieweren tager fejl eller tvivler på sin kompetence, indtil interviewet er slut. Så Google det og find ud af, hvem af jer der havde ret. Et teknisk interview er ikke et sted for diskussion eller selvhævdelse, og spørgsmålene her er primært stillet til dig. Intervieweren vil ikke spørge om noget, han ikke selv forstår.

Konklusion

Ved du, hvad det bedste, jeg hørte fra ansøgere under samtaler? "Jeg svarede ikke rigtig, gjorde jeg? Kan du give mig et stykke papir? Jeg vil skrive dine spørgsmål ned og finde ud af det derhjemme, selvom du ikke ansætter mig, så ved jeg det i det mindste nu." Stolthedstårerne vælter frem i dine øjne - det var ikke forgæves, at du brugte halvanden time på en person, han lærte selv noget af dette interview. Selvom han nu er for svag til denne stilling, vil det måske tilskynde ham til at uddanne sig, og om et år eller to kommer han igen, viser sig fra sin bedste side og får et job - som det skete en gang i min egen karriere.
Hvordan det sker

I de fleste tilfælde inviteres en anden specialist med en høj grad af teknisk kompetence til at foretage vurderingen, som som udgangspunkt ikke forstår noget om personalespørgsmål og metoder til indsamling af oplysninger om en persons personlighed, og en frontal afhøring af ”hvem ved mere” begynder simpelthen. Nogle interviewere har simpelthen en tjekliste med spørgsmål. Mange bruger også praksis med en testopgave, som skal udføres før planlægning af en personlig samtale. Generelt løser den, der kan gøre det bedst, problemet.

Generelt kan denne tilgang være effektiv, men den har en række ulemper:
1. Der er mulighed for, at den samtalende tekniske specialist kan opfatte uoverensstemmelsen mellem ansøgerens erfaring og hans egen som en manglende erfaring overhovedet. For eksempel kan de specificeres ret snævert praktiske spørgsmål, som ansøgeren ikke er stødt på i praksis, hvilket kan tolkes som "Hvordan kan du ikke vide det, det er så enkelt." Men en personalespecialist vil aldrig være i stand til at genkende dette på grund af kontekstens særlige forhold.
2. Selvom der stilles åbne spørgsmål som "Hvilke problemer har du skullet løse?", kan uoverensstemmelsen i erfaring igen tolkes som "Han er ikke egnet til os, fordi han ikke har gjort det, vi har gjort i flere år ."
3. Nogle tekniske specialister, især dem, der allerede har ret meget erfaring, ved ikke meget om, at uvidenhed om specifikke værktøjer ofte ikke er en stor hindring. For eksempel, hvis en person ikke har arbejdet med GIT, men kender CVS godt, reducerer dette markant barrieren for adgang til at eje værktøjet.
4. Der kan også være et problem, når ansøgeren har stor praktisk erfaring og svarer godt på spørgsmål specifikke løsninger, men da han bliver ansat, viser det sig pludselig, at han laver ret typiske fejl på områder, som han ikke har arbejdet med før. Man får det indtryk af sådanne mennesker, at de "er dumme ud af det blå" eller "aktivt kopierer og indsætter kode" fra deres tidligere projekter.
5. Nogle gange støder du på en specialist, der giver indtryk af en nybegynder, og hans CV viser lidt praktisk erfaring, men det er vigtigt at forstå, om han vil lykkes. For hvis det virker, kan du få en god “stjerne” til holdet med en lille investering. Og det er ikke klart, hvordan man genkender dette så præcist som muligt.

Dette er blot nogle få af de scenarier, der regelmæssigt støder på, når man rekrutterer nye teknikere. At interviewe en tekniker er som en opgave, hvor du har et kæmpe maleri gemt bag roterende firkanter, som du vender om en efter en. Og din opgave er at gætte hele billedet, forudsat at din tid er begrænset og antallet af mulige billeder er enormt.
For at være mere tilbøjelige til at bortfiltrere disse negative scenarier, samt at gennemføre interviews af tekniske specialister mere effektivt, kan du bruge en speciel informationsindsamlingsmodel.

Klassificering af viden

Først skal du beslutte dig for klassificeringen af ​​viden. For at gøre dette skal de opdeles i 3 typer:
1. Fundamental- Det her grundlæggende viden i et bestemt område. For eksempel kan dette være spørgsmålet "Hvilke grundlæggende typer forespørgsler i SQL kender du?"
2. Anvendt er en færdighed til at løse specifikke problemer. Det kan fx være opgaver på korrekt stavning SQL-forespørgsler til specifikke eksempler.
3. Medvirkende er viden om, hvordan man bruger specifikke værktøjer. Hvad er for eksempel forskellen mellem innodb og myisam butikker?

Grundlæggende viden er nødvendig for at bruge den til at forstå, hvordan man bedst løser praktiske problemer. Praktiske opgaver danner anvendt viden, det vil sige en forståelse af hvordan og hvad der er bedst at gøre. Med forståelsen af, at individuelle problemer bedst løses ved hjælp af specifikke værktøjer, udvikles instrumentel viden også. Ofte starter en person med en lille øvelse, studerer derefter "hvorfor det virker på denne måde", forsøger derefter at gøre noget lignende og finpudser derefter sine færdigheder ved hjælp af værktøjer.
For eksempel udvikler en person sprogfærdigheder på nøjagtig samme måde: Først prøver han simpelthen at gentage efter sine forældre individuelle ord; så lærer han alfabetet; derefter skriver essays, artikler eller forretningsbreve; og bruger nogle gange opslagsbøger og ordbøger til dette.

Når noget gik galt

Da "akademisk uddannelse" inden for IT stadig er ret svag, er de fleste specialister stort set selvlærte. Dette skaber visse afvigelser, som godt kan forstås på denne model, hvis et af vidensområderne er hypertrofieret. Her er de klassiske portrætter af kandidater og deres forklaring:
1. Ved-det-alt– har en betydelig mængde grundlæggende viden, fx erhvervet gennem nogle kurser og læsning af bøger/artikler, dog har han ikke praktiske færdigheder i at anvende dem, hvilket ikke generer ham på nogen måde. Selvom du begynder at stille ham nogle praktiske problemer, vil du altid høre en masse viden om, hvordan det egentlig skal fungere, hvordan de enkelte dele er indrettet, men det vil være ret svært for sådan en kandidat at sætte alt sammen for at løse problemet uden dine tips. En ret almindelig situation, hvis du spørger en kandidat om lidt brugte OOP-mønstre: du vil høre en beskrivelse af mønsteret, når det bruges i et akademisk eksempel, men integrationen i en live-opgave vil være vanskelig.
2. Stackoverflow udvikler- normalt taler sådanne udviklere ret aktivt om deres oplevelse, om hvilke problemer og hvordan de formåede at løse, men når de forsøger at besvare spørgsmålet "Hvordan gør man...?" fra et praktisk område ukendt for dem, vil du enten høre et forsøg på at "trække i ørerne" en anden løsning, eller et svar i stil med "Ja, det her kan Googles på 5 minutter, jeg har allerede set dette et sted. ” Sådanne udviklere forsøger ofte at trække nogle færdige løsninger ind, som de allerede har lavet, og argumenterer som "Hvorfor gør det 2 gange?", eller de kopierer og indsætter simpelthen kode fra internettet og andre projekter. Når du spørger "Hvorfor fungerer det sådan?" eller "Hvordan kan dette gøres anderledes?" kan ofte fare vild og forsøge at oversætte emnet.
3. Tools&Frameworks udvikler. Spise gammel vittighed: “Hvordan begynder man at lave en hjemmeside i 1995? Åbn notesblok og begynd at skrive kode. Hvordan begynder man at lave en hjemmeside i 2015? Download og installer composer, framework, cms-extension, bootstrap, jquery, bower, less, installer IDE, start med at skrive kode." Dette er omtrent det samme for denne slags specialister. Det meste af den anvendte erfaring fra sådanne specialister er udelukkende relateret til et specifikt værktøj. Begrebet "hjernebitrix" karakteriserer ganske specifikt denne sag. For sådanne kandidater er det meget vanskeligt at give opgaver ved hjælp af "native" kode, fordi uden et værktøj er det en næsten umulig opgave for dem.
Disse eksempler er givet for tilfælde, hvor et af videnområderne indtager en ledende position, og da følelsen af ​​"overlegenhed" på dette område giver anledning til en følelse af ens egen "storhed", forsøger specialisten at holde fast i det med alle. hans magt ("alle vil være seje"). For eksempel vil en Stackoverflow-udvikler, når han forsøger at finde ud af grundlæggende viden, argumentere til det sidste, at "Jeg behøver ikke at vide dette, jeg har allerede gjort dette hundrede gange, og alt fungerede."

Hvordan effektiv udvikling fungerer

Det mest effektive scenarie for udvikling af viden er netop balancen mellem områder. Du kan nå det på forskellige måder, men det er umuligt at tillade "forvrængning". For eksempel ville du lave en startside og forstår ikke noget om det (alle startede med dette): du downloadede wordpress (tog "værktøjet"); Googlede hvordan man sætter alt op og lavede vores første blog med flere artikler (erhvervet anvendt viden); find nu ud af hvordan og hvorfor det virker, for eksempel hvordan databasen og cachen er opbygget, hvad motorarkitekturen er osv. (få grundlæggende viden). Så kan du se på hvilke andre værktøjer og hvordan de kan løse dette problem, eller skrive dit eget værktøj. Hvis du kun stopper ved det første eller andet trin, kan du nemt falde ind under en af ​​kategorierne af specialister ovenfor, og jeg er sikker på, at du tydeligvis ikke ønsker dette :)

Hvordan man vurderer viden

Baseret på denne model er det også muligt, og ganske nemt, at "sondere" tekniske specialister med hensyn til deres læringsstrategi og i hvor høj grad deres nuværende viden giver dem mulighed for effektivt at løse problemer. Interviewstrategien er som følger: efter at have stillet et spørgsmål om et teknisk område af interesse til dig inden for ethvert vidensområde, bevæg dig ikke "vandret" inden for vidensområdet, men "lodret" ind i en tilstødende type af viden.
De spurgte om grundlæggende viden, så spørger de, hvilke problemer personen løste ved at bruge den, eller stiller et praktisk problem, hvor denne viden ville være påkrævet, og spørger derefter, hvilke værktøjer der er tilgængelige til at bruge denne viden og bedre løse praktiske problemer.

For eksempel: Hvad er sammensatte b-træ-indekser, og hvordan fungerer de? Kan du give et eksempel på, hvornår sådanne indekser kan være nødvendige, eller hvornår de tværtimod ville være uhensigtsmæssige? Hvordan kan du forstå, at disse indekser fungerer effektivt, og hvad kan bruges til dette?

Hvis du hører omfattende svar på alle disse spørgsmål, betyder det, at specialisten virkelig har forsøgt at udvikle solid viden på dette område og erhverve alle niveauer af viden. Nu skal vi drage de rigtige konklusioner af dette. Dette vil enten indikere, at specialisten havde en enorm bunke af opgaver relateret til indekser, eller at han har en god læringsstrategi (som ikke udelukker den første). For at afgøre, om denne strategi eksisterer, er det nok at undersøge nogle flere områder, hvor kandidaten måske ikke er så kyndig, hvilket ofte kan ses på CV'et.

Stærke og lovende kandidater viser, at selv i mangel af viden forstår de, hvad de mangler og vælger effektiv tilgang at kompensere for manglende viden. Hvis du tjekker flere områder på denne måde, bemærker du, at kandidaten har effektiv strategi træning, så skal du blot tjekke den grundlæggende viden, der kræves for dig. Når alt kommer til alt, at have dem og den rigtige læringsstrategi, vil kandidaten med en høj grad af sandsynlighed være i stand til at løse nye problemer så effektivt som muligt.
En effektiv læringsstrategi er en strategi til at genopbygge viden inden for ethvert område af alle typer (fundamentalt, anvendt, instrumentelt): prøv noget, forstå hvordan og hvorfor det virker, gør noget lignende, lær værktøjer til at gøre det endnu bedre.

Typiske fejl i vurderingen

Mange har en tendens til at overvurdere vigtigheden af ​​anvendt viden i forhold til andre områder, nemlig at personer med mere erfaring i at udføre opgaver er gode specialister, men det er absolut ikke tilfældet. Hvis praksis ikke er understøttet af grundlæggende viden, eller specialisten aldrig har udvidet sine værktøjer, så kan effektiviteten af ​​en sådan specialist være meget lav. Se efter dem, der kan udvikle hvert område. De er de bedste, selvom de ikke har masser af erfaring bag sig.

Du kan ofte finde testopgaver, der kun er snævert fokuseret på grundlæggende spørgsmål, såsom sprogkonstruktioner, typiske fejl ved brug af "ikke-intuitiv adfærd", spørgsmål om OOP-mønstre osv. Som du allerede kan forstå ud fra ovenstående model, vil du ikke identificere "teoretikere" på denne måde, og desuden er grundlæggende viden perfekt googlebar. Så effektiviteten af ​​sådanne tests er relativt lav.

Der er også en almindelig tro på, at det er vigtigt at "forstå, hvordan en person tænker." Dette er utvivlsomt en "smuk" sætning, men den er meget subjektiv, og som følge heraf er det svært at være sikker på resultatet baseret på sådanne vurderinger. Derudover kan du her falde i fælden med en subjektiv vurdering: "han tænker ikke som mig." Men hvis du ser, at en person ved, hvordan man effektivt formulerer sin viden og løser problemer, så er det ligegyldigt, hvordan han præcist gør det, fordi det vigtigste er resultatet.

Giver du attraktive samarbejdsvilkår, og strømmen af ​​kandidater er høj nok, så træk op test opgave. Inkluder flere spørgsmål, ikke fra én type viden, men fra forskellige. Ud fra svarene på disse spørgsmål kan du få et groft billede af, hvad kandidatens styrker og svagheder er.

Hvad skal man kigge efter

Der er flere punkter, som du også bør være opmærksom på under samtalen. De forholder sig mere til personalekomponenten, dog optræder de specifikt under den tekniske samtale.

Nysgerrighed i sindet. Hvor hårdt prøver en kandidat at løse et problem, hvis han ikke kender løsningen med det samme? Er han på udkig efter alternative veje, analyserer spor, spørger og analyserer den foreslåede løsning. Svage kandidater "springer over" alt, hvad de ikke kunne forstå.
Sund selvtillid. I hvilket omfang indrømmer kandidaten, at han måske ikke ved noget? På grund af deres opvækst har folk nogle gange komplekser med hensyn til deres egen viden (“ærede diplomstuderende” osv.). Nogle gange træffer sådanne mennesker beslutninger på en skarpt kategorisk måde og genkender ikke alternative meninger, hvis de indikerer manglende viden fra kandidatens side.
Ønsket om selvudvikling. De bedste kandidater er dem, der stræber efter at udvikle sig som specialister, eller som stræber efter at "gøre verden til et bedre sted" ved at skabe en form for fordel. Svage kandidater mener, at de allerede er "ved loftet af deres viden" og blot ønsker at tjene så meget som muligt på dette. Der er også kandidater, der mener, at arbejdsgiveren skal udvikle dem, og ikke dem selv, fordi det er arbejdsgiveren, der stiller opgaverne.

Samtalestrategi

Inden samtalen skal du lave en liste over nøgleområder, hvor du har brug for erfaring fra en specialist. Det er godt, hvis der er mindst 10 af dem. For eksempel: PHP + OOP-mønstre. SQL + forespørgselsoptimering; arkitektur af højbelastningsprojekter; arbejde med cache osv.
I hvert nøgleområde skal du oprette mindst 5 spørgsmål for hver type viden, for i alt mindst 15 spørgsmål for hvert område. Dette gøres bedst for ikke at komme med spørgsmål i farten. Det er ønskeligt, at sådanne problemer giver vertikal forbindelse indbyrdes.

For eksempel:
Område: arkitektur af højbelastningsprojekter.
Grundlæggende spørgsmål: Hvilke hovedparametre er vigtige at overveje, når man designer højbelastningssystemer? Hvilke typiske arkitektoniske løsninger kender du? Hvad er forskellen mellem vandret og lodret skalering?
Ansøgningsspørgsmål: Hvis brugere kan uploade filer, hvad er så den bedste måde at løse problemet med horisontal skalering til returnering? Hvis du har en side med en høj RPM, og en informationsblok, der har lang tid generation, hvordan kan du fremskynde sidegengivelsen? Hvis en enkelt database er blevet en flaskehals i et projekt på grund af øget arbejdsbyrde, hvad er den bedste måde at gribe dette problem an?
Instrumentelle spørgsmål: Hvilke værktøjer kan bruges til at load balance HTTP-trafik? Hvilke caching-servere kender du, og hvad er deres forskelle? Hvordan kan du måle applikationsydelse under store belastninger?

Start med et hvilket som helst af spørgsmålene efter eget valg. Stil konsekvent spørgsmål fra hver videnstype i det valgte område (lodret). Hvis du kan se, at kandidaten har en sikker beherskelse af teori, praksis og værktøjer, så kan du være ret sikker på, at han også trygt vil kunne løse relaterede praktiske problemer.

Når du besvarer spørgsmålene, bevæger du dig gennem områderne, vil du danne dig et billede af, hvordan kandidatens viden er fordelt. For eksempel kan du indse en betydelig mangel på teoretisk viden eller huller i viden om værktøjer. Ud fra dette kan du drage en konklusion om, hvor effektiv kandidatens træningsstrategi og hans nuværende viden generelt er. Som regel er læringsstrategien den samme for alle områder, det vil sige, at det er meget sjældent at finde kandidater, der kender teorien rigtig godt på et område, men på et andet kun løste praktiske problemer og ikke engang forsøgte at stille spørgsmålet "Hvordan fungerer det?"

Nå, så, afhængigt af kravene til den ledige stilling, vil det være meget nemmere for dig at træffe en beslutning. Leder du efter en junior? Sørg for, at du ikke kun forsøger at løse praktiske problemer, men også genopbygger grundlæggende viden og også leder efter og lærer nye værktøjer. Leder du efter en mellemting? Sørg for, at hans færdigheder er forankret i hver type viden, og at han forstår, hvor han skal gå hen for at udfylde hullerne. Leder du efter en senior? Sørg for, at han har fremragende grundlæggende viden og effektivt kan "samle" ethvert praktisk problem med grundlæggende begrundelser og passende værktøjer.

Hvis du bemærker huller i den nødvendige viden, og de ikke er grundlæggende for dig, men stadig vigtige, så sørg for at skrive det ned og arbejde videre med det prøvetid en plan for at udfylde disse huller ved at bruge dette under certificering. Dette vil give dig mulighed for at øge dine medarbejderes produktivitet på en metodisk og bevidst måde. Spørgsmålet om uddannelse og udvikling af medarbejdere er dog en helt anden og meget stor historie.

Hvor kan man ellers bruge modellen?

Den givne model kan faktisk bruges ikke kun til tekniske specialister, men til ethvert erhverv generelt. Den eneste forskel vil være i, hvor fuldt ud visse typer viden realiseres på disse områder. Tag for eksempel en pedel: Hvilke kriterier for renlighed kender du? Hvis du skal rense 10 huse på én dag, hvad er den bedste måde at gøre det på? Hvilke rengøringsmidler er bedst at bruge til hvilke overflader?

Som en konklusion

Jeg besluttede for nylig at samle mine noter om interviewspørgsmål til PHP-udviklere og sende dem videre åben adgang(projektet er "på knæet", så bebrejde mig ikke). Selvfølgelig er alt ikke der, men det er nok til at samle dine tanker og gøre dig klar til samtalen. Du kan se spørgsmålene på linket:
pagerton.com/hr/question/all
Hvis der kommer positive tilbagemeldinger, vil jeg udvikle projektet så meget som muligt, jeg vil også gerne sende links til gode kurser for udviklere, så jeg vil være taknemmelig for feedback.
Jeg håber, at denne model også kan være nyttig for dig. Ikke kun som interviewperson, men også som interviewperson, fordi at forstå dine styrker og svagheder vil hjælpe dig med at udvikle dig mere effektivt.
Jeg ønsker dig at være den bedste og arbejde med de bedste.

Hej alle sammen, Javarashites! Det skete, at jeg for nylig havde en samtale og gerne ville fortælle dig, hvilke spørgsmål jeg blev stillet, forudsat at jeg søgte Junior++-stillingen. Dem. Ikke en midterste endnu, men heller ikke en grøn junior. Så interviewet forløb efter denne plan

  1. JavaCore
  2. Databaser.
  3. De værktøjer du bruger.

JavaCore

    Først blev jeg bedt om at tegne hierarkiet af grænseflader til samlinger (det var ikke svært, der er kun få af dem (Samling, Liste, Sæt, Kø, Kort).

    Hvad er forskellen mellem ArrayList og LinkedList (dette er et af de mest afslørede spørgsmål og svar på internettet, bare mørke).

    Vi diskuterede hastigheden for udførelse af forespørgsler i dem, og hvad forskellen er mellem arkene.

    Spørgsmål om klassen Objekt. Hvad er hans metoder, hvad gør de?

    Afspejling. Hvad getClass()-metoden gør. Meget interessant spørgsmål, skiller det ad. Især om hvordan man får alt om en klasse, selvom den indeholder private metoder eller variabler.

    De spurgte om multithreading. Det er svagt, synes jeg, at fortælle dig, hvordan du forstår, hvad multithreading er. Hvad skal der til for at starte en ny tråd. Realistisk set, hvis du er niveau 20+, så vil disse spørgsmål virke sjove for dig.

    Hvad kan du sige om Stream. Det handler ikke om Java 8. Det handler om input og output streams. Ligesom grundlæggende grænseflader, hvad de er (tegn og byte). For forståelsen, ingen detaljer.

  • Undtagelser. Her blev vi igen bedt om at tegne et hierarki af undtagelser, hvilke typer der er, hvilke der er markeret og hvilke der ikke er markeret. Hvad skal man gøre med Runtime-undtagelser. Navngiv den oftest stødte på (NullPointerException).

    • Spørgsmålet er, hvad der skal gøres med kontrollerede undtagelser (fremsend videre eller proces - begge er tydelige).

OOP

    Hvad er OOP i en nøddeskal?

    Hvilke andre programmeringsparadigmer findes der? Hvordan adskiller de sig fra OOP?

    Hvad er de grundlæggende principper for OOP (arv, polymorfi og indkapsling)? Fortæl os om hver af dem. Indtil videre er alt abstrakt, ikke bundet til noget sprog.

    Systemdesign forståelsesopgave: der er en hest og en fugl. Vi skal have Pegasus. princippet "har en" og "er en"

HVILE

    Hvad er REST. Wikipedia taler meget køligt om dette. Faktisk er en artikel fra Wikipedia nok at stifte bekendtskab med.

    HTTP. Der er også generelle sætninger her. Hans metoder, hvad hver af dem er til.

    HTTP-statuskoder. Hvilke fem dele skal deles op i Fortæl os om de mest berømte (200,204,404,500,501). Hvorfor gør de det? De spurgte også om 401 og 403. Men jeg kendte dem ikke. De sagde, at de var vigtige.

Databaser

Her fortalte jeg dig, at jeg kender MySQL. Fortalte om tre normale former. Jeg talte om Joins, hvad de er, og tegnede krydset mellem områder, hvor forskellige joins bruges. Jeg talte om, hvordan jeg forstår en relationel database. Jeg har heller ikke glemt MongoDB - dette er en NoSQL-database , det vil jeg også skrive om.

Andre værktøjer

Her gennemgik vi mit CV. Det blev skrevet at jeg bruger Maven/Gradle til montering, jeg bruger JIRA til opgaver, git, Docker, Swagger. Til kontinuerlig integration - Stash, Bambus, Puppet. Til test af JUnit, Mockito, JMeter. Jeg har måske glemt noget, så hvis du er interesseret - spørg i kommentarerne Jeg vil prøve at svare. Dette var første del af interviewet. Nu venter jeg på resultaterne, og hvis det er tilfældet, vil der være en anden del. Jeg vil skrive om det hurtigst muligt. Enhver, der kunne lide artiklen og fandt den nyttig - sæt "+". Skriv i kommentarerne. Se også mine andre artikler:

Der er meget materiale på internettet dedikeret til interviews med HR-chefer, men næsten intet siges om forviklingerne ved interviews med tekniske specialister. Denne artikel er afsat til, hvilke kvaliteter og færdigheder en kandidat skal have for at bestå denne fase og modtage et tilbud i en IT-virksomhed.

Dialog fra livet:

Kandidat: Vi skal udføre operation "A", indtil betingelse "B" er opfyldt.
Mig: Fantastisk plan. Lad os implementere det.

Kandidaten skriver et for hver sløjfe. Selvom det er indlysende. Hvis en kandidat har bestået dette niveau, vil han før eller siden blive en god programmør. Men 70 % af ansøgerne fejler her.

Bogdan Gusev, tankstation

Lad os rette denne irriterende misforståelse.

while (bool tilbud == falsk)(

Regel 0

Skal du til samtale til rollen som Java-udvikler, skal du have et godt kendskab til Java og relaterede teknologier

//Ingen kommentarer.

Regel 1

Forbered dig til samtalen på forhånd

Få på forhånd ud af alle mulige detaljer om projektet hos rekruttereren.

Google-søgning efter spørgsmål, der ofte stilles i interviews. Nogle af dem vil helt sikkert støde på.

Alexander Pitz, projektleder

Regel 2

Lyv ikke på dit CV

At forsøge at bedrage ved at overdrive din viden er spild af din tid og virksomhedens tid. Du bør være i stand til at besvare spørgsmål om alle teknologier, der er anført på dit CV.

Et CV fyldt med søgeord, som du ikke har en ordentlig forståelse for, ødelægger dine chancer for at modtage et tilbud.

Regel 3

Afstem dine værdier med virksomhedens værdier

Hver virksomhed har sine egne værdier. Et hold værdsætter dedikation og fokus på resultater og foragter som et resultat ikke overarbejde. Den anden er innovativ på arbejdspladsen og er villig til at lære og anvende innovationer hvert par måneder. Den tredje er pålidelighed og stabilitet: gennemprøvede teknologier, dedikerede mennesker, der ikke forlader virksomheden, hvis cookies pludselig forsvinder.

Der er en acceptabel grænse for uoverensstemmelse mellem værdier, hvis overskridelse vil virksomheden højst sandsynligt beslutte ikke at afgive tilbud, selvom kandidaten har den nødvendige erfaring og den nødvendige tekniske viden.

Regel 4

Udvikle kommunikationsevner

Jeg ønsker, at ansøgeren har bedre kommunikationsevner højt niveau end den grundlæggende. I vores tidsalder med fuldstændig agile kommer denne kvalitet frem blandt de nødvendige færdigheder. Kandidaten bør ikke have svært ved at kommunikere med HR- og tekniske specialister samt med kunder.

Regel 5

Forbedre dit engelsk

I modsætning til ukritiske fejl i viden om enhver teknologi, vil du ikke være i stand til at forbedre dine sprogfærdigheder i løbet af et par måneder. Det tager år her. Derfor er et utilstrækkeligt niveau i engelsk i de fleste tilfælde en tilstrækkelig grund til afslag.

En lille motivation: niveauet af engelsk og lønnen for Kyiv Java og .NET mellem- og seniorer med 3-5 års erfaring svarer.

Regel 6

Vis din passion for dit fag

Ifølge Bogdan Gusev kan det faktum, at du nyder dit arbejde, indikeres af tilstedeværelsen af ​​Open Source-projekter, deltagelse i tematiske konferencer og beherskelse af tekstredigerings- eller IDE-funktioner. Og selvfølgelig interesse for detaljer videre arbejde. Programmører, der er ligeglade med deres arbejde, er ikke i høj efterspørgsel blandt arbejdsgivere.

Regel 7

Vis intelligens og abstrakt tænkning

Kandidaten skal:
- kunne løse problemer svarende til hans stilling;
- kende det nødvendige programmeringssprog og rammer;
- navigere i teknologierne i det projekt, han bliver interviewet til.

Hvis stillingen er dårligt defineret, testes generel lærdom og intelligens, samt evnen til at tænke strukturelt og finde løsninger.

Det er meget vigtigt at demonstrere evnen til at bruge din viden. Hvis du kender tilgange og metoder til at løse problemer og ved, hvordan du indhenter manglende information, så vil du være i stand til at klare de opgaver, du får.

Regel 8

Demonstrere et ønske om at få ny viden

Nogle gange vil en kandidat sige: "Jeg har studeret teknologi X, og jeg vil kun arbejde med det. Hvorfor skulle jeg studere teknologi Y, hvis jeg kender X?" Chancerne for at en sådan kandidat får et tilbud er stærkt reduceret. Teknologier er bare værktøjer. Efter noget tid vil X blive irrelevant, og med det specialisten selv, som kun ved det.

Maxim Kovtun, løsningsarkitekt

Regel 9

Vis resultatorientering

jeg vurderer:
- evnen til at gå på kompromis med ens "religiøse overbevisninger" (for eksempel, hvis en udgivelse kræver det, brug et "hot fix" i stedet for at nærme sig løsningen grundlæggende);
- evnen til at insistere på egen hånd, når det er nødvendigt;
- og endnu vigtigere - evnen til at opretholde den rette balance mellem de to punkter ovenfor.

Andrey Mudry, projektleder

Regel 10

Sig ikke "jeg ved det ikke"

Undtagelse: hvis du aldrig har arbejdet med denne teknologi, og den ikke står på dit CV. I dette tilfælde er det bedre at være ærlig og bede intervieweren om at forklare dig det rigtige svar.

Hvis du ikke forstår, hvad vi taler om, så stil et opklarende spørgsmål.

Hvis spørgsmålet er specifikt, og du ikke er sikker på svaret, så bør du indrømme det og være sikker på at gøre antagelser baseret på dine erfaringer. Forklar din tankeproces. Hvis spørgsmålet er åbent, er der ikke et enkelt korrekt svar.

Det værste svar er stilhed eller "Jeg ved det ikke." Du skal prøve at løse problemet, uanset hvor dum din løsning kan virke. Selv det mest naive svar er bedre end ingenting. To eller tre svarmuligheder er generelt gode. Peber disse svar med overvejelser om deres anvendelighed og yderligere spørgsmål for at afklare problemet – og det vil være fantastisk.

Alexey Kolupaev, tankstation

Regel 11

Vær ikke genert for at lære selv under et interview.

Det er umuligt at vide alt. Jeg arbejdede engang på et projekt, der krævede viden om en ret specifik teknologistak og kartografi. Erfaring har vist, at få programmører kan konvertere den klassiske koordinatnotation fra WGS84 til decimalnotation. I sådanne tilfælde synes jeg, at et godt svar i et interview er spørgsmålet: "Kan jeg kigge på Google?"

Artem Polyukhovich, CTO

Regel 12

Tænk over, hvad du siger som svar

Du behøver ikke lade som om du er mentalt aktiv i et minut, men prøv at tænke på problemet så bredt som muligt. Desuden er der under interviews ofte trickspørgsmål.

Det er godt, hvis kandidaten forsøger at "udlede" det rigtige svar på spørgsmålet. Han gætter ikke, men bruger sin eksisterende viden, samt logik, intelligens, opfindsomhed og evnen til hurtigt at træffe beslutninger under pres. Denne kvalitet er meget nyttig i en fleksibel tilgang til udvikling, når kunden har brug for det hurtig løsning problemer, nogle gange endda under en onlinekonference.

Sergey Chirkov, projektleder

Regel 13

Indrøm fejl du har lavet

Evnen til at analysere og indrømme dine fejl indikerer, at du vil være interesseret i både din egen faglige udvikling og resultatet af et specifikt job.

Regel 14

Ødelæg ikke dit omdømme

Et skødesløst svar på spørgsmålet "Hvorfor forlod du sådan og sådan en virksomhed?", desorganisering, at komme for sent til et interview uden varsel eller et afslag på at udføre en testopgave kan ødelægge en mening om dig.

Regel 15

Opbyg et partnerskab med intervieweren

Det forekommer mig, at i udtrykket "arbejdsforhold" fokuserer mange mennesker på "arbejde", men de burde lægge mere vægt på "relationer". I denne forstand ligner et interview en date: I ser begge nærmere på hinanden, finder ud af, om I vil have det godt sammen. Og når nogen prøver hårdt på at virke bedre, end de er, kan det være irriterende. Nogle gange kan en kandidat være så fængslende, at det er let at vende det blinde øje til selv alvorlige mangler.

Alexey Kolupaev, tankstation

Regel 16

Opfør dig ordentligt

"Korrekt" betyder høfligt, respektfuldt. Arrogance, inderlighed eller smiger over for intervieweren vil kun ødelægge indtrykket. Humor er heller ikke altid passende.

Flere fejlslagne adfærdsmønstre kan identificeres:
  • Ven- flytter samtalen til et uformelt niveau for at undgå specifikke svar på specifikke spørgsmål.
  • erobrer- tager initiativet i egen hånd, taler højt og meget og lader ikke stille spørgsmål.
  • doven- efter en times interview viser han, at han oplever reel pine - sådan en person vil næppe være i stand til at arbejde intensivt mere end 1 time om dagen.
  • arkitekt- opretter et stort antal ubrugelige klasser, inden der skitseres en løsningsplan. Som følge heraf kan den ikke selv drage fordel af sin egen "arkitektur".
  • teoretiker- den farligste type, klar til at kommunikere om ethvert emne, så længe han ikke er tvunget til at vise praktisk viden. Kan nemt beskrive en løsningsalgoritme, men er ikke i stand til at programmere den.

Sidstnævnte kan let bestemmes af følgende dialog:
Mig: Tag din bærbare computer med til interviewet
Kandidat: Hvorfor?

Efter sådan en dialog står det umiddelbart klart, at kandidaten mener, at hovedsagen ved at være programmør er at tale om fede teknologier i køkkenet. Han ved ikke, at programmering på et velkendt tastatur er meget nemmere end på et udenlandsk. Derfor bruger han lidt tid på det. Jeg spekulerer på, hvordan det går med hans arbejdsdag?

Bogdan Gusev, tankstation

Regel 17

Vær tilstrækkelig :)

Tilstrækkelighed er et ret bredt begreb. Først og fremmest omfatter det en reaktion på svære situationer. Hvad gør en person, når han står over for et uforståeligt stykke kode eller en kompleks algoritme? Hvordan vil han opføre sig over for kolleger, når han har brug for noget fra dem (eller har brug for dem)? Hvad gør han, hvis der opstår en interessekonflikt? Hvad hvis han får en umulig eller vanskelig opgave?

Artem Polyukhovich, CTO

Regel 18

Vær optimistisk

Positiv indstilling - meget brugbar kvalitet. Det er meget mere behageligt at arbejde med en person, der ved, hvordan man bemærker positive øjeblikke i livet, på arbejdet, i alt.

Regel 19

Føl dig fri

Et interview er en diskussion mellem to ligeværdige specialister. Dermed er stivhed mere et minus end et plus. Det vil forhindre dig i at udtrykke dig på det rigtige niveau.

Men for meget selvtillid er også et minus. En monolog i 20 minutter uden stop kan tjene som grund til afslag.

Opfør dig naturligt, vær ikke genert. Hvis du for eksempel har lettere ved at behandle information visuelt, skal du ikke være bange for at bede om papir og pen.

Regel 20

Hvis du fejler, så lær af dine fejl

Tænk på interviewet som en mulighed for at lære noget nyt og få feedback. Dette vil være en fordel, selvom du ikke modtager et jobtilbud.

Alexander Kaganovsky, tankstation

Interviews rangerer højt på listen over de fleste menneskers største frygt, sammen med offentlige taler. Du optræder ikke kun foran nogen, men du bliver også konstant evalueret hele tiden... brrrr!

Selvfølgelig er vi langt fra at forsøge at forstå og overvinde dine psykologiske barrierer, men det er absolut bedst at se interviews som en chance for at vise alle de fede ting, du har skabt, og alle de interessante nye færdigheder, du har lært. Bedste interviews- det er entusiastiske samtaler med et teknisk overblik.

Det første skridt før alt dette er forberedelse. Du får lyst til at tænke over de mulige spørgsmål (og de mest almindelige svar, der fremhæver din glans) og undersøge ansættelsesfirmaet. Din viden om virksomheden vil hjælpe dig med at præsentere dig selv på en måde, der passer til deres behov, og vil også give dig mulighed for at stille smarte spørgsmål om deres produkter og teknologier, når tiden kommer. Endnu en gang, se Happy Bears artikel for praktiske tips.

Hvad er hele denne proces?

Bare et hurtigt kig på den proces, som den gennemsnitlige teknologivirksomhed gennemgår, når de ansætter udviklere:

  1. Indledende samtale på telefon (telefonskærm)
  2. Teknisk interview
  3. Testkommissorium
  4. Opfølgningssamtaler for at sikre, at du passer godt (Fit Interviews)
  5. Jobtilbud
  6. Diskussion af tilbudsvilkår (tilbudsforhandling)
  7. Tilbudsaccept

Foreløbig telefoninterview

Tillykke! Dit CV viste sig ikke at være det mest katastrofale, og du blev inviteret til et telefoninterview (bemærk, at nogle gange laver du en testopgave først). Det egentlige formål med dette trin, som ofte involverer en halv times samtale med en person i HR (i stedet for beslutningstageren om ansættelse), er at sikre, at du har en god chance for at komme igennem resten af ​​interviewprocessen. Så tænk på det som en lettere version af de andre trin.

Du vil sandsynligvis blive spurgt om nogle af de tekniske ting, du sætter på dit CV, men gå ikke for dybt (selvom nogle arbejdsgivere stiller nogle ret vanskelige spørgsmål), og du vil sandsynligvis blive stillet nogle "blødere" spørgsmål om hvorfor du valgte dette job, og hvad du gjorde før. Telefoninterviews kan variere meget fra virksomhed til virksomhed. Hovedtaktikken her er slet ikke en taktik, bare vær ærlig, energisk og åben. Og vær ikke bange for at øve dig i at tale om dig selv foran spejlet.

EN ENDELIG BEMÆRK - Dette er ikke en metode, der passer til alle, og mange virksomheder springer den over til fordel for at dykke direkte ned i dybden af ​​et teknisk interview, så du skal forberede dig for en sikkerheds skyld. Linket nedenfor til Coding Horror er det mest illustrative af denne sag.

  • Opnå fremragende telefoninterview med Monster
  • 7 trin til at opnå fremragende kvalitet i telefoninterview

Teknisk interview

Det tekniske interview er normalt den mest skræmmende del af udvælgelsesprocessen. Det er her de vil vurdere, om du har de nødvendige tekniske færdigheder. Det betyder, at de ikke kun vil spørge dig meget detaljeret om dit arbejde, men også bede dig om at bestemme logiske problemer eller skriv kode lige der eller skitser et diagram over nogle nye komponenter.

Faktisk er et af formålene med sådan et interview at bringe dig til kanten af ​​dine evner, bare for at se, hvordan du reagerer på ukendte ting. Hvis du laver en øvelse for let, vil de gå videre til noget meget sværere. Der vil altid være steder at snuble, især for begyndere. Dit største aktiv er din ærlighed og nysgerrighed.

Når du løser et problem, skal du sørge for at gøre det på en klar og logisk måde, og forklare højt, hvorfor du udfører et bestemt trin. Tal igennem alle de forhindringer, du stødte på, og giv eksempler på, hvordan du ville løse det i " virkelige verden". Ofte er svaret at "Google" nogle specifik funktion. Sig det! De ved, at du ikke er en Ruby-ekspert, men de skal også vide, at du kan komme med løsninger på de problemer, du uundgåeligt vil støde på på jobbet.

Det er også helt normalt, hvis du bruger brute force - en ineffektiv metode - til at løse et kodningsproblem. Dette er ofte det bedste udgangspunkt for at få en ordentlig fornemmelse af problemet. Mest sandsynligt vil du blive spurgt, hvordan løsningen kan forbedres, men det er meget bedre end at prøve at finde den perfekte løsning og ikke have tid til at skrive noget til sidst. Endnu en gang er dit job ikke at være en fremtrædende kandidat, men at vise, at du er omstillingsparat og robust, når du står over for udfordringer.

Og hvis du ikke ved noget, er det bedre at sige det ærligt og prøve at tænke det igennem med intervieweren. Tro mig, de vil have dig til at lykkes lige så meget, som du gør, for der er ikke noget værre for en interviewer end at se en, der stille forsøger at løse et problem, blive mere og mere fast uden at bede om hjælp og ikke lade nogen vide, hvad han var. tænker.

Du bliver nødt til at læse om store mængder ting, der ikke blev lagt vægt på i tidligere kurser, for eksempel datastrukturer og algoritmer, simpelthen fordi det er meget populære spørgsmål om dem i interviews. De afspejler ikke altid programmeringsfærdigheder godt, men det sker bare, at du svarer på spørgsmål, der falder ind under et mere akademisk område af computerviden.

Links

  • Lad os se på interviewet for programmører: SKAL LÆSE MATERIALE hvem bliver din bedste ven. Det tager et omfattende kig på alle typer udfordringer, du vil møde i et interview. Det går ud over, hvad vi allerede har dækket i dette kursus og berører ting, der er gode at vide, fordi du sandsynligvis vil støde på dem. Tag dig tid til at lære så mange at kende som muligt et stort antal materiale.
  • Interviewing.io giver dig chancen for at øve anonymt og online tekniske interviews.
  • Sådan får du en perfekt score i et teknisk interview
  • Sådan skiller du dig ud i dit næste webudviklerjobinterview
  • Læs 40 vigtige computervidenskabelige begreber forklaret i et letforståeligt sprog
  • Googles guide til tekniske færdigheder(for avancerede)

Programmeringstestopgaver:

  • 8 dronninger er et klassisk problem.
  • Programmering til interviews: Ved, at standardbibliotekerne kan være overkill for en begynder, men det skader aldrig, hvis du tager dig tid til at gøre det.
  • På Project Euler finder du mere generelle og komplekse problemer, der skal løses effektivt (de kan kræve en masse beregning).
  • Øvelsesspørgsmål til Java og Python udgives på Coding Bat.

Algoritmetræning:

  • Algoritmekursus fra Udacity (ikke synkroniseret)
  • Algoritmekursus fra Coursera (delvist synkroniseret)

Arkitektur:

Teknisk testopgave

Prøve lektier kan forekomme enten før eller efter en personlig samtale, afhængigt af virksomheden. Du får en opgave, der vil kræve en hel dag at fuldføre, når som helst, der passer dig. Eksempler på en sådan opgave kan være at lave et eksempel på en webapplikation med tests eller at løse et komplekst algoritmisk problem med at skrive kode.

Evalueringen vil være baseret på fuldstændigheden af ​​løsningen og kvaliteten af ​​din kode. Hvis dette sker før den tekniske samtale, så er det det god metode tjek din interesse (op til halvdelen af ​​ansøgerne vender ikke engang tilbage med en løsning).

Afsluttende interview ("Fit")

Det sidste trin, inden du træffer en beslutning, er normalt at lære teamet og kontorerne at kende i et par timer. Du kan blive testet teknisk, men hovedmålet er at sikre, at du bliver en god kollega. Hvis et andet teammedlem siger, at du ikke vil arbejde godt, vil de højst sandsynligt ikke ansætte dig. Råd? Ingen grund til at være mærkelig eller akavet, selvom du er hjemme :)

Dette er også en mulighed for dig. Hvis du er nået så langt for at komme til dette trin, er der en god chance for, at du generelt er kvalificeret. Du skal overveje, om du vil arbejde for denne virksomhed, så lav en liste med spørgsmål og få svar på dem.

Lidt om løn

Ikke. Udtal det. Dine. Lønninger. Forventninger.

Du vil altid blive spurgt "hvor meget vil du gerne modtage?" Dit svar? "Jeg vil gerne blive betalt til den gennemsnitlige markedsrente" (medmindre du er så arrogant at spørge over markedsprisen. Lad os se, hvordan det virker for dig). Du vinder ikke noget ved at nævne dit ønskede lønniveau. Hvis det viser sig at være lavere end det, de ønskede at tilbyde dig, vil de simpelthen sænke dette niveau. Og hvis det er højere, så vil de simpelthen afbryde hele processen og beslutte, at du er for dyr for dem.

Når du har modtaget et tilbud, kan du tjekke, hvordan det er sammenlignet med den gennemsnitlige markedsløn ved at spørge nogle få personer (forhåbentlig kender du allerede et par personer at spørge) eller ved at gå til Glassdoor (bare husk at du er nybegynder, hvilket betyder at du ikke modtager en "gennemsnitlig" løn). Det vigtigste er ikke at skade dig selv, når du bliver spurgt.



Relaterede artikler