Programmører, gå til interviews

Billedet er taget fra en video fra kanalen "Militante ametyster»

Jeg arbejdede som systemprogrammør for Linux i omkring 10 år. Det er kernemoduler (kernerum), forskellige dæmoner og arbejde med hardware fra brugerplads (brugerplads), forskellige bootloadere (u-boot osv.), controller-firmware og meget mere. Selv nogle gange skete det for at skære i webgrænsefladen. Men oftere skete det, at jeg skulle sidde med en loddekolbe og interagere med printkortdesignere. Et af problemerne ved sådan et arbejde er, at det er ret svært at vurdere niveauet af din kompetence, da du måske kender én opgave meget dybt, men måske slet ikke kender en anden. Den eneste tilstrækkelige måde at forstå, hvor man skal hen, og hvilke strømninger der er nu, er at gå til interviews.

I denne artikel vil jeg gerne opsummere min erfaring med at interviewe til en ledig stilling som Linux-systemprogrammør, detaljerne i interviewet, jobbet, og hvordan du vurderer dit personlige vidensniveau ved at kommunikere med en fremtidig arbejdsgiver, og hvad du ikke bør forvente af det.

Artiklen vil indeholde en lille konkurrence med præmier.

Egenskaber af erhvervet

En systemprogrammør inden for det specifikke felt, hvor jeg arbejdede, er en komplet generalist: Jeg skulle både skrive kode og fejlfinde hardware. Og ofte var der behov for selv at lodde noget. Fra tid til anden skete det, at mine justeringer af hardwaren så blev overført til udviklerne. For at arbejde inden for dette område har du derfor brug for en ret god vidensbase, både inden for digitale kredsløb og programmering. På grund af dette ligner interviews til en systemprogrammørstilling ofte en søgning efter en elektronikspecialist.

En typisk arbejdsstation for en systemprogrammør.

Billedet ovenfor viser min typiske arbejdsplads ved fejlfinding af drivere. Den logiske analysator viser rigtigheden af ​​de transmitterede meddelelser, oscilloskopet overvåger formen af ​​signalkanterne. Desuden var jtag-debuggeren ikke inkluderet i rammen, som bruges, når standardfejlfindingsværktøjer ikke længere kan klare det. Og du skal kunne arbejde med alt dette udstyr.

Det sker ofte, at det er hurtigere og nemmere selv at omlodde nogle elementer og rette topologifejl end at tage produktet til en installatør. Og så tager en loddestation også bolig på din arbejdsplads.

Et andet træk ved udvikling på driver- og hardwareniveau er, at Google ikke hjælper. Ofte skal du lede efter information om dit problem, og der er tre links, hvoraf to er dine egne spørgsmål på et eller andet forum. Eller endnu værre, når du støder på et spørgsmål fra den samme stakkels fyr, der stillede det for 5 år siden på kernel-mailinglisten og aldrig modtog et svar. I dette arbejde støder man udover fejl i design af både hardware og software ofte på dokumentationsfejl – det er nok de mest alvorlige og ubehagelige problemer. Nogle gange er registre beskrevet forkert, eller der er slet ingen beskrivelse af dem. Sådanne problemer kan kun løses ved videnskabeligt at stikke tilfældige tal ind i bestemte registre (en slags omvendt). Det sker ofte, at processoren indeholder en eller anden funktionalitet, men ingen undtagen dig implementerede denne funktionalitet (især hvis processoren er ny). Og det betyder at gå over marken med en rive, hvoraf 70 % er til børn. Men når der er dokumentation, selv med fejl, er dette allerede fremskridt. Ganske ofte sker det, at der slet ikke er nogen dokumentation, og det er, når gang gennem minefelter begynder, når jernet brænder. Og ja, jeg har også med succes løst sådanne problemer.

Interviews

Min mening er, at du skal gå til samtaler mindst en gang hvert halve år, selvom du elsker dit job og ikke vil ændre det. Et interview giver dig mulighed for at forstå dit niveau som specialist. Jeg tror, ​​at de mest værdifulde interviews er dem, der mislykkes. Det er dem, der mest præcist viser, hvilke flaskehalse i din viden, der skal forbedres.

En anden interessant funktion er kvaliteten af ​​interviews. Dette er min observation, og det er ikke sandheden, jeg indrømmer, at jeg bare var heldig. Hvis interviewet går efter scenariet:

• Fortæl os om dig selv;
• Sådanne opgaver har vi;
• Du kan lide?

Og hvis man efter denne dialog kan lide hinanden, går på arbejde, så viser virksomheden og opgaverne sig som regel at være meget behagelige og fyldestgørende. Hvis et interview ligner at gå gennem 12 helvedes cirkler: det første interview med HR, derefter et interview med en gruppe programmører, så direktøren, flere lektier osv., så var det som regel fejlslagne organisationer, hvor jeg ikke arbejdede. meget længe. Igen er der tale om en personlig observation, men som regel viser for meget bureaukrati og en langstrakt ansættelsesproces, at de nøjagtige samme processer foregår i virksomheden. Beslutninger træffes langsomt og ineffektivt. Der var også de modsatte situationer, hvor der var kredse af interviewhelvede, og selskabet viste sig at være fantastisk, og når selskabet efter et slag på hånden viste sig at være en sump, men disse er sjældne.

Hvis du tror, ​​at scenariet: mødtes, fortalte om dig selv og blev ansat, kun eksisterer i små virksomheder, så nej. Det har jeg set i meget store virksomheder, der beskæftiger mere end hundredvis af mennesker og er repræsenteret på verdensmarkederne. Dette er en normal mekanisme, især hvis du har en rig track record og har mulighed for at ringe til dine tidligere arbejdsgivere og spørge om dig.

For mig er det en meget god indikator for en virksomhed, når de beder om at vise eksempler på deres projekter og kode. Ansøgerens uddannelsesniveau vises straks. Og for mig er dette den mest effektive metode til udvælgelse af udvælgelse af kandidater end show-interviews. Faktisk kan du fejle ved et interview af spænding, eller tværtimod komme ud på adrenalin. Men i rigtigt arbejde kan du ikke klare rigtige opgaver. Og det stødte jeg også på, da jeg selv interviewede folk. En specialist kommer, viser sig at være fremragende, jeg kunne lide ham, han kunne lide os. Og jeg kæmpede med det enkleste problem i en måned, og som et resultat løste en anden programmør det på et par dage. Jeg var nødt til at skille mig af med den programmør.

Jeg værdsætter især programmeringsopgaver i interviews. Og dem der skal løses lige under mødet, under stress og lektier. Den første viser, hvor klar du er til hurtigt og præcist at løse problemer i en stresset situation og nødsituation. Den anden viser dit niveau af kompetence og evne til at søge information og løse aktuelle problemer.

De mest interessante arbejdssteder, jeg havde, var i vores lands forsvarskompleks. I løbet af arbejdet skulle jeg løse simpelthen fantastiske problemer, som kommercielle programmører aldrig selv havde drømt om. Supercomputere, design af routere, forskellige node-kampsystemer - det er utrolig spændende. Når du under paraden ser et kompleks, der gemmer din kode, er det virkelig rart. Mærkeligt nok er interviews med sådanne virksomheder som regel meget enkle, bogstaveligt talt kommer, kan lide det, accepteret (sandsynligvis de særlige forhold ved militæret, som ikke kan lide at tale for meget), er overlejret. De udfordringer, jeg stod over for der, var virkelig interessante og udfordrende. Med erfaring viste det sig, at de er gode til at lære at være en systemprogrammør af høj kvalitet. Der er også ulemper, og det er ikke engang lave lønninger. I øjeblikket er lønnen i forsvarskomplekset ganske anstændig, med bonusser og goder. Som regel er der meget bureaukrati, lange arbejdstider, endeløse travle jobs og arbejde under stor stress. I visse tilfælde kan hemmeligholdelse ikke udelukkes, hvilket tilføjer visse problemer ved udlandsrejser. Plus, selvfølgelig, chefernes tyranni, og dette sker desværre også. Selvom min erfaring med at arbejde med en kunderepræsentant er yderst behagelig. Dette er et samlet indtryk af tre forskellige forskningsinstitutter og virksomheder relateret til statens forsvarsordrer.

Interview opgaver

For at undgå misforståelser og for ikke at afsløre de virksomheder, jeg har interviewet med, vil jeg ikke friste skæbnen og angive deres detaljer. Men jeg er taknemmelig for hvert interview, for den tid, folk brugte på mig, for muligheden for at se mig selv udefra. Jeg kan kun sige, at opgaverne var for store internationale virksomheder repræsenteret i forskellige lande.

Jeg vil fortælle dig det mest interessante: Hvilke opgaver gives under interviews. Generelt er de mest almindelige spørgsmål til den ledige stilling for en systemprogrammør og mikrocontrollerprogrammør bitoperationer i alle mulige variationer. Forbered dig derfor bedst på dette område.

Det næstmest polariserende emne er vejvisere, dette burde virkelig springe fra tænderne. Så de vækker dig midt om natten, og du kan fortælle og vise alt.

Jeg stjal spørgsmål fra flere interviews i mit hoved, og jeg vil præsentere dem her, da jeg finder dem ret interessante. Jeg giver bevidst ikke svar på disse spørgsmål, så læserne selv kan svare på disse spørgsmål i kommentarerne og have lidt krudt, når de skal igennem et rigtigt interview.

Spørgsmål nr. 1

I. Kendskab til SI. Hvad betyder følgende poster:

const char * str;

char const * str;

const * char str;

char * const str;

const char const * str;

Er alle indtastninger korrekte?

II. Hvorfor vil dette program give en segmenteringsfejl?

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

III. At være smart.

Der er en pind på en meter lang. Ti myrer falder tilfældigt på hende og kravler i forskellige retninger. En myres bevægelseshastighed er 1 m/s. Hvis en myre støder på en anden myre, vender den sig om og kravler i den modsatte retning. Hvad er den maksimale tid, du skal vente på, at alle myrerne falder af pinden?

Det næste interview var en fiasko for mig, og jeg betragter det som det mest nyttige i min programmeringspraksis. Det viste dybden af ​​min inkompetence. Før dette interview var jeg bekendt med hvert af disse spørgsmål, og de dukkede konstant op i min praksis, men på en eller anden måde tillagde jeg dem ikke den store betydning, og derfor forstod jeg dem ikke godt. Derfor bestod jeg denne eksamen i skændsel. Og jeg er meget taknemmelig for, at sådan en fiasko skete; det havde den mest nøgterne virkning på mig. Du synes, at du er en sej specialist, du kender kredsløbsdesign, grænseflader og at arbejde med kernen. Og så har du rigtige spørgsmål, og du flyder. Så lad os se.

Interviewspørgsmål #2

Hardware problemer.

• Hvordan linux-systemopkald arrangeres i assemblersprog på en ARM-processor på x86. Hvad er forskellen?
• Hvilke synkroniseringsværktøjer findes der? Hvilke synkroniseringsværktøjer kan bruges i en interrupt-kontekst, hvilke kan ikke, og hvorfor?
• Hvad er forskellen mellem i2c bus og spi bus?
• Hvorfor er der terminatorer på i2c-bussen, og hvad er deres værdi?
• Kan RS-232-grænsefladen KUN fungere på to ledninger: RX og TX? Her vil jeg give svaret: Det viser sig, at det er dårligt, på 9600, men det kan!!!
• Og nu det andet spørgsmål: hvorfor?
• Hvad er den bedste måde at arrangere signallinjer og strøm i flerlagstavler og hvorfor? Strøm inde i lagene, eller signallinjer inde i lagene? (Spørgsmålet handler generelt udelukkende om kredsløbsdesign).
• Hvorfor har differentiallinjer spor, der går sammen overalt?
• RS-485 bus. Normalt er der terminatorer på sådan en linje. Vi har dog et stjernekredsløb, med et variabelt antal plug-in moduler. Hvilke midler til at undgå kollisioner og interferens bør anvendes?
• Hvad er røde og binære træer?
• Hvordan arbejder man med cmake?
• Spørgsmål om at bygge yocto Linux.

Mål for dette interview:

1. Skriv en funktion, der inverterer til uint32_t alle stumperne. (at arbejde med bits er meget populært ved interviews, jeg anbefaler det)
2.

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

Hvad vil denne funktion returnere? (løsning på papir, uden computer)

3. Funktion til beregning af det aritmetiske middelværdi af to tal int32_t.

4. Hvad er outputmetoderne i programmer, inkl. ind i en strøm af fejl.

Den tredje udvælgelse var forholdsvis ny, og jeg ville ikke blive overrasket, hvis der stadig er sådan et spørgeskema der, så jeg vil ikke afsløre virksomheden for ikke at afsløre dem... Men generelt vil jeg give et eksempel af mulige spørgsmål, og hvis du genkender dine spørgsmål, så siger jeg hej :).

Interviewspørgsmål #3

1. Et eksempel på trægennemløbskode er givet; det er nødvendigt at fortælle, hvad der bliver gjort i denne kode og påpege fejl.
2. Skriv et eksempel på ls-værktøjet. Med den enkleste mulighed "-l".
3. Giv et eksempel på, hvordan man laver statisk og dynamisk linking. Hvad er forskellen?
4. Hvordan virker RS-232? Hvad er forskellen mellem RS-485 og RS-232? Hvad er forskellen mellem RS-232 og RS-485 fra en programmørs synspunkt?
5. Hvordan fungerer USB (fra en programmørs synspunkt)?
6. Oversættelse af teknisk tekst fra russisk til engelsk.

Et vellykket interview er ikke en garanti for et vellykket arbejde

Dette kapitel er nok ikke engang for programmører (selvom også for dem), men mere for HR. De mest passende virksomheder ser ikke omhyggeligt på resultaterne af interviews. Det er normalt at lave fejl; oftest ser de på, hvordan en person ved, hvordan man løser problemer og ræsonnerer.

Et af nøgleproblemerne er, at en kandidat med succes løser problemer under interviews, viser sig at være en fremragende specialist, men fejler ved den første rigtige opgave. Jeg vil ikke lyve, det skete også for mig. Jeg gik med succes igennem alle helvedes cirkler, løste alle testopgaverne, men under virkelige forhold viste arbejdet sig at være for hårdt på grund af simpel uerfarenhed. At komme ombord er ikke den sværeste opgave. Det sværeste er at blive ombord i dette selskab.

Derfor stoler jeg på flere virksomheder, der laver simple samtaler med kandidaten og siger: efter den første måneds arbejde vil det stå klart, om du er egnet til os eller ej. Dette er den mest passende tilgang, ja, måske lidt dyr, men det er umiddelbart klart, hvem der er hvem.

Der er en anden mulighed for interviews: når du har bestået det, men baseret på resultaterne af interviewet forstår du, at arbejdsgiveren er fuldstændig utilstrækkelig. Jeg nægter straks arbejde, hvis jeg bliver tilbudt at arbejde som individuel iværksætter og lover store indkomster. Dette er en form for skatteunddragelse for en driftsorganisation, og hvorfor skulle arbejdsgiverens problemer bekymre mig som programmør? En anden mulighed er forskellige offentlige myndigheder. Jeg havde en samtale, som resulterede i, at jeg blev tilbudt en god løn, men de sagde, at den tidligere programmør sagde op, blev syg, døde, gik på en binge på grund af arbejdsbyrden, og din arbejdsdag starter klokken 8 om morgenen . Fra sådan et sted løb han også, så hans hæle funklede. Ja, HR, vær opmærksom på, at programmører er klar til at takke nej til selv det lækreste job, hvis arbejdsdagen skal starte tidligt om morgenen.

Til sidst vil jeg give en fremragende video af programmørvalg, et skærmbillede af det er givet i begyndelsen af ​​denne artikel. Jeg har også haft sådan et interview mere end én gang. Hvis du ser tyranni på spørgsmålsstadiet, så respekter dig selv, rejs dig, tag dine ting og gå - det er normalt. Hvis HR og lederen hævder sig på din regning under samtalen, indikerer det, at virksomheden er giftig, og du bør ikke arbejde der, medmindre du kan lide utilstrækkelige chefer.

Fund

Programmører, gå til interviews! Og prøv altid at blive forfremmet. Lad os sige, at hvis du får N penge, så gå til et interview for mindst N*1,2 eller bedre N*1,5. Selvom du ikke tager denne ledige stilling med det samme, vil du forstå, hvad der er nødvendigt for dette lønniveau.
Mine observationer har vist, at godt kendskab til det engelske sprog, tilstrækkelig rig erfaring i branchen og selvtillid afgør. Sidstnævnte er hovedegenskaben, som overalt i livet. Som regel kan en mere selvsikker kandidat præstere bedre i et interview, selv med flere fejl, end en fremragende, men mere genert og proaktiv ansøger. Held og lykke med dine samtaler!

P/S konkurrence

Hvis du har interessante eksempler på problemer, som HR har fyldt dig med, så velkommen i kommentarerne. Vi har forberedt en lille konkurrence - betingelserne er enkle: du skriver den mest usædvanlige opgave, du havde under et interview, læserne vurderer den (plus), og efter en uge opsummerer vi resultaterne og belønner vinderen med sjove lækkerier.

Kilde: www.habr.com