programmering,

Nettsideutvikling

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 for tekniske intervjuere å skremme kandidater bort 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. "Hvilket 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. Når det gjelder 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.

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 i 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 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. Pepper 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 utviklingstilnærming, 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

En mening om deg kan bli bortskjemt av et uforsiktig svar på spørsmålet "Hvorfor forlot du et slikt og slikt selskap?", desorganisering, å komme for sent til et intervju uten varsel, nekte å bestemme seg test.

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 kolleger 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

Se intervjuet som en mulighet til å lære noe nytt og vinne tilbakemelding. Dette vil være gunstig selv om du ikke mottar et jobbtilbud.

Alexander Kaganovsky, bensinstasjon

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. Hva fem deler skal 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:

Siraj Rawal, utvikler, skribent og vlogger, deler hvordan du klarer ethvert teknisk intervju i 5 trinn.

Jeg har gått gjennom denne prosessen et dusin ganger i forskjellige IT-selskaper i minnet mitt. stort antall både avslag og tilbud. Og her er leksjonene jeg har lært av det. Intervju krever arbeid: ikke tro de som sier at det skal være enkelt. Dette er feil. Folk snakker bare om deres suksesser og aldri om deres fiaskoer.

Jeg har skissert flere trinn som lar deg unngå mange feil og bestå ethvert teknisk intervju.

Trinn 1. Forberedelsesplan

Lære. Selv før du har den lyse ideen om å prøve å få en jobb et sted, bør du konsentrere deg om å oppgradere dine tekniske ferdigheter.

Ansettelsesprosessen for en utviklerstilling ser ganske lik ut hos mange store selskaper. Som regel foregår det i to etapper. Først kommuniserer rekruttereren med søkeren på telefon for å forstå hvor interessert han er i selskapet deres. Etter vellykket gjennomføring av første etappe, etterfølges det av 1-2 tekniske samtaler med spesialister, hvor han blir stilt vanskelige spørsmål og problemer som han må løse på brettet. Han må vise sin tankeprosess for å løse et problem, finne en passende løsning, og så vil han bli ansatt.

Den eneste måten å lære dette på er øvelse. Alle vennene mine som jobber i kule selskaper gjør mye arbeid. Poenget her er ikke å ha ekstraordinær intelligens, men å jobbe hardt og gjennomtenkt.

Spørsmålet oppstår: hva skal du egentlig øve på? Du vil ikke bli testet på dine kunnskaper om syntaksen til noe språk. Hvis du vil, kan du lære det grunnleggende om Ruby-syntaks over natten. Men det natten ikke er nok til, er grunnleggende datavitenskap. Men på intervjuet vil de teste kunnskapen din om datastrukturer og algoritmer.

Start med å ta to kurs:
introduksjon til datastrukturer (My Code School)
Introduksjon til algoritmer (MIT Open Courseware)
Begge er med åpen tilgang og er ideelle for å få grunnleggende kunnskap for disse seksjonene.

Etter dette kan du konsolidere den ervervede kunnskapen om HackerRank og HackerEarth. Disse ressursene inneholder et stort antall problemer for å finpusse programmeringsferdighetene dine.

Etter å ha løst et par dusin gåter fra begge nettstedene, les bøkene "Technical Interviews as They Are" og "Breaking the Technical Interview." De vil lede deg gjennom mange spesifikke oppgaver fra ekte intervjuer, fra systemdesignproblemer til spørsmål om tid og kompleksitet.

Etter å ha fullført alle ritualene ovenfor, begynn å øve på et intervju med en av vennene dine. Be ham stille deg spørsmål og svare på dem, bare bruk en markør og en hvit tavle og forklar tankene dine høyt. Jeg anbefaler å gjøre dette i to til tre måneder, to til tre timer om dagen.

Trinn 2: Finn selskaper som interesserer deg

Hvis prosessen med å forberede hvert intervju tar to til tre måneder, så vil du naturligvis ikke kaste bort denne dyrebare tiden på selskaper som ikke imponerer deg.

Å holde oversikt over bedrifters intervjuforberedelse og intervjuprosess kan være ganske stressende, men prøv å holde deg organisert. Lag en liste over selskaper som interesserer deg og noter hvilket stadium forholdet ditt til hver av dem er på. Angel.co og Hacker News er gode ressurser for dette.

Det er noe overnaturlig ved dette. Du må anstrenge all din styrke psykiske evner, for å forstå hvordan du best kan bruke ferdighetene dine på ønsket felt og finne selskaper som lar deg gjøre det.

Trinn 3. Lag en portefølje

Store selskaper mottar hundrevis av CV-er om dagen, så de trenger rett og slett å luke ut mye middelmådighet som ikke er interessant for dem. Hvordan skille seg ut fra denne grå massen? Sørg for at alle ordene i CV-en passer på én side, og at den er kortfattet, men til poenget. Lys den mest opp viktig arbeid gjort av deg.

Det er lurt å ha flere CVer: en for hver spesialitet eller for hver bedrift der du prøver å få jobb. I porteføljen din, separate personlige prosjekter, prosjekter fra hackathons, bidrag til åpen kildekode-prosjekter.

GitHub er et flott sted ikke bare å lagre koden din, men også som en annen portefølje som kan tjene deg godt.

Gjør ditt beste nettprosjekt til ditt eget CV-nettsted. Prøv å få det til å se stilig og profesjonelt ut, slik at det kan imponere en potensiell arbeidsgiver.

Trinn 4. Få en invitasjon til et intervju

Den enkleste måten er å søke på en ledig stilling på en spesialisert nettside. Men store selskaper får mange slike svar hver dag, og det er veldig lett å gå seg vill blant dem. Et godt alternativ- send en e-post til selskapets rekrutterer, gjør den kort og konsist. Inkluder det kort anmeldelse om hvem du er og hva du vil gjøre, en lenke til et lett tilgjengelig og relevant prosjekt, og uttrykke ønske og vilje til å lære og oppleve nye ting.

Det er på tide å gå videre til...

Trinn 5. Bestå intervjuet

Noen ganger kan intervjueren være mer nervøs enn du er, og det er greit. Bare smil, vær høflig, gjør det klart at du forstår ham og er villig til å samarbeide for å oppnå felles mål.

Når du løser tekniske problemer, ikke vær redd for å tenke høyt. Husk at det er akkurat dette de vil ha fra deg: det riktige svaret er ikke like viktig som det riktige tanken din. Når en jobbsøker kommer med den første løsningen, ber rekruttereren ham ofte finne bedre alternativer. Det er her din informatikkkunnskap kommer inn i bildet.

Og ikke vær sjenert for å stille spørsmål. Intervjueren er der for å hjelpe deg. Og til tross for at hovedmålet hans er å evaluere ferdighetene dine, er det også viktig for ham å prøve å finne et forhold til deg. gjensidig språk, samarbeide med deg og hjelpe deg å nå et felles mål. Så hvis du kommer forberedt, vil alt gå bra.

Konklusjon

Å forberede og bestå et intervju er en ansvarlig og tidkrevende prosess. Aldri, aldri, ALDRI la avvisning få deg ned. Å bestå et intervju er også flott opplevelse, selv om du ikke ble ansatt. Derfor vil du over tid oppnå den høyeste ferdigheten og være i stand til å bestå ethvert teknisk intervju. Hovedsaken er å trene, tro på deg selv og holde deg motivert.

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 liten oversikt over prosessen gjennomsnittet går gjennom teknologiselskap når du 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 løsningen kan forbedres, 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).
• Publisert på Coding Bat praktiske spørsmål for Java og Python.

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 jobbe 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 for å komme 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 få betalt til gjennomsnittlig markedsrente" (med mindre du er så arrogant å spørre 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 det 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.