Programmerere, gå til intervjuer

Bildet er tatt fra en video fra kanalen "Militante ametyster»

Jeg jobbet som systemprogrammerer for Linux i omtrent 10 år. Dette er kjernemoduler (kjerneplass), ulike demoner og arbeid med maskinvare fra brukerplass (brukerplass), ulike oppstartslastere (u-boot, etc.), kontrollerfastvare og mye mer. Selv noen ganger skjedde det for å kutte nettgrensesnittet. Men oftere hendte det at jeg måtte sitte med en loddebolt og samhandle med kretskortdesignere. Et av problemene med slikt arbeid er at det er ganske vanskelig å vurdere nivået på kompetansen din, siden du kanskje kjenner en oppgave veldig dypt, men kanskje ikke kjenner en annen i det hele tatt. Den eneste tilstrekkelige måten å forstå hvor du skal gå og hvilke strømninger det er nå, er å gå for intervjuer.

I denne artikkelen vil jeg gjerne oppsummere min erfaring med å intervjue for en ledig stilling som Linux-systemprogrammerer, detaljene for intervjuet, jobben og hvordan du kan vurdere ditt personlige kunnskapsnivå ved å kommunisere med en fremtidig arbeidsgiver og hva du ikke bør forvente av det.

Artikkelen vil inneholde en liten konkurranse med premier.

Egenskaper av yrket

En systemprogrammerer, i det spesifikke feltet jeg jobbet i, er en fullstendig generalist: Jeg måtte både skrive kode og feilsøke maskinvare. Og ofte var det behov for å lodde noe selv. Fra tid til annen hendte det at mine justeringer av maskinvaren så ble overført til utviklerne. Derfor trenger du en ganske god kunnskapsbase for å jobbe innenfor dette området, både innen digitale kretser og programmering. På grunn av dette ser intervjuer for en systemprogrammererstilling ofte ut som et søk etter en elektronikkspesialist.

En typisk arbeidsstasjon for en systemprogrammerer.

Bildet ovenfor viser min typiske arbeidsplass når jeg feilsøker drivere. Den logiske analysatoren viser riktigheten av de overførte meldingene, oscilloskopet overvåker formen på signalkantene. Dessuten var ikke jtag-debuggeren inkludert i rammen, som brukes når standard feilsøkingsverktøy ikke lenger takler. Og du må kunne jobbe med alt dette utstyret.

Det hender ofte at det er raskere og enklere å lodde noen elementer på nytt og rette topologifeil selv enn å ta produktet til en installatør. Og da tar også en loddestasjon bolig på din arbeidsplass.

En annen funksjon i utviklingen på driver- og maskinvarenivå er at Google ikke hjelper. Ofte må du lete etter informasjon om problemet ditt, og det er tre lenker, hvorav to er dine egne spørsmål på et eller annet forum. Eller enda verre, når du kommer over et spørsmål fra den samme stakkaren som stilte det for 5 år siden på kjernepostlisten og aldri fikk svar. I dette arbeidet, i tillegg til feil i design av både maskinvare og programvare, støter man ofte på dokumentasjonsfeil – dette er nok de mest alvorlige og ubehagelige problemene. Noen ganger beskrives registre feil, eller det er ingen beskrivelse for dem i det hele tatt. Slike problemer kan bare løses ved å vitenskapelig stikke tilfeldige tall inn i visse registre (en slags omvendt). Det hender ofte at prosessoren inneholder noe funksjonalitet, men ingen bortsett fra du implementerte denne funksjonaliteten (spesielt hvis prosessoren er ny). Og dette betyr å gå over feltet med en rive, hvorav 70 % er for barn. Men når det er dokumentasjon, selv med feil, er dette allerede fremgang. Ganske ofte hender det at det ikke er noen dokumentasjon i det hele tatt, og det er når vandringen gjennom minefelt begynner når jernet brenner. Og ja, jeg løste også slike problemer med hell.

Intervjuer

Min mening er at du bør gå til intervju minst en gang hver sjette måned, selv om du elsker jobben din og ikke vil endre den. Et intervju lar deg forstå nivået ditt som spesialist. Jeg tror de mest verdifulle intervjuene er de som mislykkes. Det er de som mest nøyaktig viser hvilke flaskehalser i kunnskapen din som må forbedres.

En annen interessant funksjon er kvaliteten på intervjuene. Dette er min observasjon, og det er ikke sannheten, jeg innrømmer at jeg bare var heldig. Hvis intervjuet går i henhold til scenariet:

• Fortell oss om deg selv;
• Vi har slike oppgaver;
• du liker?

Og hvis du etter denne dialogen liker hverandre, går på jobb, så viser selskapet og oppgavene seg som regel veldig hyggelige og tilstrekkelige. Hvis et intervju minner om å gå gjennom 12 helvetesirkler: det første intervjuet med HR, deretter et intervju med en gruppe programmerere, deretter direktøren, mer lekser osv., så var dette som regel mislykkede organisasjoner der jeg ikke jobbet i veldig lenge. Igjen er dette en personlig observasjon, men som regel viser for mye byråkrati og en utstrakt ansettelsesprosess at de nøyaktige samme prosessene foregår innad i bedriften. Beslutninger tas sakte og ineffektivt. Det var også motsatte situasjoner, da det var sirkler av intervjuhelvete, og selskapet viste seg å være flott, og når selskapet etter et slag på håndleddet viste seg å være en sump, men disse er sjeldne.

Hvis du tror at scenariet: møtt, fortalt om deg selv og blitt ansatt, bare eksisterer i små selskaper, så nei. Jeg har sett dette i veldig store selskaper som sysselsetter mer enn hundrevis av mennesker og er representert på verdensmarkedene. Dette er en normal mekanisme, spesielt hvis du har en rik merittliste og har mulighet til å ringe dine tidligere arbeidsgivere og spørre om deg.

For meg er det en veldig god indikator på et selskap når de ber om å vise eksempler på prosjekter og kode. Opplæringsnivået til søkeren vises umiddelbart. Og for meg er dette den mest effektive metoden for utvelgelse enn utstillingsintervjuer fra synspunktet om å velge kandidater. Faktisk kan du mislykkes på et intervju av spenning, eller tvert imot, komme deg ut på adrenalin. Men i ekte arbeid kan du ikke takle virkelige oppgaver. Og dette møtte jeg også da jeg intervjuet folk selv. En spesialist kommer, viser seg å være utmerket, jeg likte ham, han likte oss. Og jeg slet med det enkleste problemet i en måned, og som et resultat løste en annen programmerer det på et par dager. Jeg måtte skille meg med den programmereren.

Jeg verdsetter spesielt programmeringsoppgaver i intervjuer. Og de som må løses rett under møtet, under stress og lekser. Den første viser hvor klar du er til å raskt og nøyaktig løse problemer i en stressende situasjon og nødsituasjon. Den andre viser ditt kompetansenivå og evne til å søke etter informasjon og løse aktuelle problemer.

De mest interessante jobbene jeg hadde var i forsvarskomplekset i landet vårt. I prosessen med arbeidet måtte jeg løse rett og slett fantastiske problemer som kommersielle programmerere aldri hadde drømt om. Superdatamaskiner, design av rutere, forskjellige nodekampsystemer - dette er utrolig spennende. Når du under paraden ser et kompleks som lagrer koden din, er det veldig hyggelig. Merkelig nok er intervjuer med slike selskaper vanligvis veldig enkle, bokstavelig talt kommer, liker det, akseptert (sannsynligvis spesifikasjonene til militæret, som ikke liker å snakke for mye), er lagt over hverandre. Utfordringene jeg møtte der var virkelig interessante og utfordrende. Med erfaring viste det seg at de er gode til å lære å være en systemprogrammerer av høy kvalitet. Det er også ulemper, og dette er ikke engang lav lønn. For øyeblikket er lønnen i forsvarskomplekset ganske grei, med bonuser og goder. Som regel er det mye byråkrati, lang arbeidstid, endeløse rushjobber, og arbeid under stort stress. I visse tilfeller kan hemmelighold ikke utelukkes, noe som gir visse problemer for utenlandsreiser. Pluss, selvfølgelig, sjefens tyranni, og dette skjer dessverre også. Selv om min erfaring med å jobbe med en kunderepresentant er svært hyggelig. Dette er et samlet inntrykk av tre ulike forskningsinstitutter og selskaper knyttet til statlige forsvarsordrer.

Intervjuoppgaver

For å unngå misforståelser og for ikke å avsløre selskapene jeg intervjuet med, vil jeg ikke friste skjebnen og angi detaljene deres. Men jeg er takknemlig for hvert intervju, for tiden folk brukte på meg, for muligheten til å se på meg selv utenfra. Jeg kan bare si at oppgavene var for store internasjonale selskaper representert i ulike land.

Jeg skal fortelle deg det mest interessante: hvilke oppgaver som gis under intervjuer. Generelt er de vanligste spørsmålene for den ledige stillingen til en systemprogrammerer og mikrokontrollerprogrammerer bitoperasjoner, i alle mulige varianter. Forbered deg derfor best på dette området.

Det nest mest polariserende temaet er veivisere, dette burde virkelig hoppe av tennene. Slik at de vekker deg midt på natten og du kan fortelle og vise alt.

Jeg stjal spørsmål fra flere intervjuer i hodet mitt, og jeg vil presentere dem her, siden jeg synes de er ganske interessante. Jeg gir bevisst ikke svar på disse spørsmålene slik at leserne kan svare på disse spørsmålene selv i kommentarfeltet og ha litt krutt når de skal gjennom et ekte intervju.

Spørsmål nr. 1

I. Kunnskap om SI. Hva betyr følgende oppføringer:

const char * str;

char const * str;

const * char str;

char * const str;

const char const * str;

Er alle oppføringer korrekte?

II. Hvorfor vil dette programmet gi en segmenteringsfeil?

int main ()
{
       fprintf(0,"hellon");
       fork();
       return(0);
}

III. Å være smart.

Det er en pinne som er en meter lang. Ti maur faller tilfeldig på henne og kryper i forskjellige retninger. Bevegelseshastigheten til en maur er 1 m/s. Hvis en maur møter en annen maur, snur den seg og kryper i motsatt retning. Hva er den maksimale tiden du trenger for å vente på at alle maurene faller av pinnen?

Det neste intervjuet var en fiasko for meg, og jeg anser det som det mest nyttige i min programmeringspraksis. Det viste dybden i min inkompetanse. Før dette intervjuet var jeg kjent med hvert av disse spørsmålene, og de dukket stadig opp i min praksis, men på en eller annen måte la jeg dem ikke særlig vekt, og derfor forsto jeg dem ikke godt. Derfor strøk jeg på denne eksamenen i skam. Og jeg er veldig takknemlig for at en slik fiasko skjedde, den hadde den mest nøkterne effekten på meg. Du tror at du er en kul spesialist, du kjenner kretsdesign, grensesnitt og arbeider med kjernen. Og så har du virkelige spørsmål og du flyter. Så la oss se.

Intervjuspørsmål #2

Maskinvareproblemer.

• Hvordan linux-systemanrop er ordnet i assemblerspråk på en ARM-prosessor, på x86. Hva er forskjellen?
• Hvilke synkroniseringsverktøy finnes det? Hvilke synkroniseringsverktøy kan brukes i en avbruddskontekst, hvilke kan ikke, og hvorfor?
• Hva er forskjellen mellom i2c buss og spi buss?
• Hvorfor er det terminatorer på i2c-bussen og hva er verdien deres?
• Kan RS-232-grensesnittet KUN fungere på to ledninger: RX og TX? Her vil jeg gi svaret: Det viser seg at det er dårlig, på 9600, men det kan!!!
• Og nå det andre spørsmålet: hvorfor?
• Hva er den beste måten å ordne signallinjer og strøm i flerlagskort og hvorfor? Strøm inne i lagene, eller signallinjer inne i lagene? (Spørsmålet er generelt utelukkende om kretsdesign).
• Hvorfor har differensiallinjer spor som går sammen overalt?
• RS-485 buss. Vanligvis er det terminatorer på en slik linje. Vi har imidlertid en stjernekrets, med et variabelt antall plug-in moduler. Hvilke midler for å unngå kollisjoner og forstyrrelser bør brukes?
• Hva er røde og binære trær?
• Hvordan jobbe med cmake?
• Spørsmål om å bygge yocto Linux.

Mål for dette intervjuet:

1. Skriv en funksjon som inverterer til uint32_t alle bitene. (å jobbe med biter er veldig populært på intervjuer, jeg anbefaler det)
2.

int32_t a = -200;
uint32_t b = 200;
return *(uint32_t) * (&a)) > b;

Hva vil denne funksjonen returnere? (løsning på papir, uten datamaskin)

3. Funksjon for å beregne det aritmetiske gjennomsnittet av to tall int32_t.

4. Hva er utdatametodene i programmer, inkl. inn i en strøm av feil.

Det tredje utvalget var relativt nylig, og jeg ville ikke bli overrasket om det fortsatt er et slikt spørreskjema der, så jeg vil ikke avsløre selskapet for ikke å avsløre dem... Men generelt sett skal jeg gi et eksempel av mulige spørsmål, og hvis du kjenner igjen spørsmålene dine, så sier jeg hei :).

Intervjuspørsmål #3

1. Et eksempel på trekryssningskode er gitt; det er nødvendig å fortelle hva som gjøres i denne koden og påpeke feil.
2. Skriv et eksempel på ls-verktøyet. Med det enkleste alternativet "-l".
3. Gi et eksempel på hvordan du gjør statisk og dynamisk kobling. Hva er forskjellen?
4. Hvordan fungerer RS-232? Hva er forskjellen mellom RS-485 og RS-232? Hva er forskjellen mellom RS-232 og RS-485 fra en programmerers synspunkt?
5. Hvordan fungerer USB (fra en programmerers synspunkt)?
6. Oversettelse av teknisk tekst fra russisk til engelsk.

Et vellykket intervju er ingen garanti for vellykket arbeid

Dette kapittelet er nok ikke engang for programmerere (men for dem også), men mer for HR. De mest adekvate selskapene ser ikke nøye på resultatene av intervjuer. Det er normalt å gjøre feil; oftest ser de på hvordan en person vet hvordan man løser problemer og resonnerer.

Et av hovedproblemene er at en kandidat lykkes med å løse problemer under intervjuer, viser seg å være en utmerket spesialist, men mislykkes i den første virkelige oppgaven. Jeg vil ikke lyve, dette skjedde med meg også. Jeg gikk med hell gjennom alle helvetes sirkler, løste alle testoppgavene, men under reelle forhold viste arbeidet seg å være for tøft på grunn av enkel uerfarenhet. Å komme om bord er ikke den vanskeligste oppgaven. Det vanskeligste er å bli om bord i dette selskapet.

Derfor stoler jeg på flere bedrifter som gjennomfører enkle intervjuer med kandidaten og sier: etter første måneds arbeid vil det være klart om du passer for oss eller ikke. Dette er den mest passende tilnærmingen, ja, kanskje litt dyr, men det er umiddelbart klart hvem som er hvem.

Det er et annet alternativ for intervjuer: når du har bestått det, men basert på resultatene av intervjuet forstår du at arbeidsgiveren er helt utilstrekkelig. Jeg nekter umiddelbart å jobbe hvis jeg blir tilbudt å jobbe som individuell gründer, og lover store inntekter. Dette er en form for skatteunndragelse for en driftsorganisasjon, og hvorfor skal arbeidsgivers problemer bekymre meg som programmerer? Et annet alternativ er ulike offentlige etater. Jeg hadde et intervju, som et resultat av at jeg ble tilbudt en god lønn, men de sa at den forrige programmereren sluttet, ble syk, døde, gikk på en fyllesyke på grunn av arbeidsbelastningen, og arbeidsdagen din starter klokken 8 om morgenen . Fra et slikt sted løp han også så hælene gnistret. Ja, HR, vær oppmerksom på at programmerere er klare til å takke nei til selv den deiligste jobben hvis arbeidsdagen må starte tidlig om morgenen.

På slutten vil jeg gi en utmerket video av programmeringsvalg, et skjermbilde av dette er gitt i begynnelsen av denne artikkelen. Jeg har også hatt et slikt intervju mer enn en gang. Hvis du ser tyranni på spørsmålsstadiet, respekter deg selv, stå opp, ta tingene dine og gå - dette er normalt. Hvis HR og lederen hevder seg på din bekostning under intervjuet, indikerer dette at selskapet er giftig og du ikke bør jobbe der med mindre du liker utilstrekkelige sjefer.

Funn

Programmerere, gå til intervjuer! Og prøv alltid å bli forfremmet. La oss si at hvis du får N penger, så gå på et intervju for minst N*1,2, eller bedre N*1,5. Selv om du ikke tar denne stillingen med en gang, vil du forstå hva som trengs for dette lønnsnivået.
Mine observasjoner har vist at gode kunnskaper i engelsk språk, tilstrekkelig rik erfaring i bransjen og selvtillit avgjør. Sistnevnte er hovedkvaliteten, som overalt i livet. Som regel kan en mer selvsikker kandidat prestere bedre i et intervju, selv med flere feil, enn en utmerket, men mer sjenert og proaktiv søker. Lykke til med intervjuene!

P/S-konkurranse

Hvis du har interessante eksempler på problemer som HR har lastet deg med, velkommen i kommentarfeltet. Vi har utarbeidet en liten konkurranse - betingelsene er enkle: du skriver den mest uvanlige oppgaven du hadde under et intervju, leserne vurderer den (pluss), og etter en uke summerer vi opp resultatene og belønner vinneren med morsomme godsaker.

Kilde: www.habr.com