🥇Programmerare, gå till intervjuer

Bilden är tagen från en video från kanalen "Militanta ametister»

Jag arbetade som systemprogrammerare för Linux i cirka 10 år. Dessa är kärnmoduler (kärnutrymme), olika demoner och att arbeta med hårdvara från användarutrymmet (användarutrymme), olika bootloaders (u-boot, etc.), styrenhetsfirmware och mycket mer. Till och med ibland råkade det klippa ner webbgränssnittet. Men oftare hände det att jag fick sitta med en lödkolv och interagera med kretskortsdesigners. Ett av problemen med ett sådant arbete är att det är ganska svårt att bedöma nivån på din kompetens, eftersom du kan en uppgift mycket djupt, men du kanske inte kan en annan alls. Det enda adekvata sättet att förstå vart man ska gå och vilka strömningar det finns nu är att gå på intervjuer.

I den här artikeln skulle jag vilja sammanfatta min erfarenhet av att intervjua för en ledig tjänst som Linux-systemprogrammerare, detaljerna kring intervjun, jobbet och hur man bedömer din personliga kunskapsnivå genom att kommunicera med en framtida arbetsgivare och vad du inte bör förvänta sig av det.

Artikeln kommer att innehålla en liten tävling med priser.

Egenskaper av yrket

En systemprogrammerare, inom det specifika område där jag arbetade, är en fullständig generalist: jag var tvungen att både skriva kod och felsöka hårdvara. Och ofta fanns det ett behov av att löda något själv. Då och då hände det att mina justeringar av hårdvaran sedan överfördes till utvecklarna. För att arbeta inom detta område behöver du därför en ganska bra kunskapsbas, både inom området digitala kretsar och inom programmering. På grund av detta ser intervjuer för en systemprogrammerare ofta ut som ett sökande efter en elektronikspecialist.

En typisk arbetsstation för en systemprogrammerare.

Bilden ovan visar min typiska arbetsplats vid felsökning av drivrutiner. Den logiska analysatorn visar korrektheten av de överförda meddelandena, oscilloskopet övervakar formen på signalkanterna. Dessutom ingick inte jtag-debuggern i ramen, som används när vanliga felsökningsverktyg inte längre klarar av. Och du måste kunna arbeta med all denna utrustning.

Det händer ofta att det är snabbare och lättare att själv löda om vissa element och rätta topologifel än att ta produkten till en installatör. Och då tar även en lödstation bostad på din arbetsplats.

En annan funktion i utvecklingen på drivrutins- och hårdvarunivå är att Google inte hjälper. Ofta måste du leta efter information om ditt problem, och det finns tre länkar, varav två är dina egna frågor på något forum. Eller ännu värre, när du stöter på en fråga från samma stackars kille som ställde den för 5 år sedan på kärnans e-postlista och aldrig fick något svar. I detta arbete stöter man, förutom fel i designen av både hårdvara och mjukvara, ofta på dokumentationsfel – det är förmodligen de allvarligaste och mest obehagliga problemen. Ibland beskrivs register felaktigt, eller så finns det ingen beskrivning av dem alls. Sådana problem kan bara lösas genom att vetenskapligt peta in slumptal i vissa register (ett slags omvänd). Det händer ofta att processorn innehåller någon funktionalitet, men ingen förutom du implementerade denna funktionalitet (speciellt om processorn är ny). Och det innebär att gå över fältet med en kratta, varav 70 % är för barn. Men när det finns dokumentation, även med fel, är detta redan framsteg. Ganska ofta händer det att det inte finns någon dokumentation alls, och det är när promenader genom minfält börjar när järnet brinner. Och ja, jag har också framgångsrikt löst sådana problem.

Intervjuer

Min åsikt är att du ska gå på intervjuer minst en gång var sjätte månad, även om du älskar ditt jobb och inte vill ändra det. En intervju låter dig förstå din nivå som specialist. Jag tror att de mest värdefulla intervjuerna är de som misslyckas. Det är de som mest exakt visar vilka flaskhalsar i din kunskap som behöver förbättras.

En annan intressant egenskap är kvaliteten på intervjuerna. Detta är min observation, och det är inte sanningen, jag erkänner att jag bara hade tur. Om intervjun går enligt scenariot:

berätta för oss om dig själv;
Vi har sådana uppgifter;
du gillar?

Och om ni efter den här dialogen gillar varandra, går till jobbet, så visar sig företaget och uppgifterna som regel vara mycket trevliga och adekvata. Om en intervju påminner om att gå igenom 12 helvetescirklar: den första intervjun med HR, sedan en intervju med en grupp programmerare, sedan regissören, mer läxor etc., så var det i regel misslyckade organisationer där jag inte arbetade väldigt länge. Återigen är detta en personlig observation, men som regel visar för mycket byråkrati och en utdragen anställningsprocess att exakt samma processer äger rum inom företaget. Beslut fattas långsamt och ineffektivt. Det fanns också motsatta situationer, när det fanns cirklar av intervjuhelvete, och företaget visade sig vara fantastiskt, och när företaget efter en smäll på handleden visade sig vara ett träsk, men dessa är sällsynta.

Om du tror att scenariot: träffats, berättat om dig själv och blivit anställd, bara finns i små företag, så nej. Jag har sett detta i mycket stora företag som sysselsätter mer än hundratals personer och är representerade på världsmarknaderna. Detta är en normal mekanism, särskilt om du har en rik meritlista och har möjlighet att ringa dina tidigare arbetsgivare och fråga om dig.

För mig är det en mycket bra indikator på ett företag när de ber att få visa exempel på sina projekt och kod. Den sökandes utbildningsnivå visas omedelbart. Och för mig, ur synvinkeln att välja ut kandidater, är detta den mest effektiva metoden för urval än showintervjuer. Faktum är att du kan misslyckas på en intervju av spänning, eller tvärtom, komma ut på adrenalin. Men i verkligt arbete kan du inte klara av riktiga uppgifter. Och det stötte jag också på när jag själv intervjuade folk. En specialist kommer, visar sig vara utmärkt, jag gillade honom, han gillade oss. Och jag kämpade med det enklaste problemet i en månad, och som ett resultat löste en annan programmerare det på ett par dagar. Jag var tvungen att skilja mig från den programmeraren.

Jag värdesätter särskilt programmeringsuppgifter i intervjuer. Och de som måste lösas direkt under mötet, under stress och läxor. Den första visar hur redo du är att snabbt och exakt lösa problem i en stressig situation och nödsituation. Den andra visar din kompetensnivå och förmåga att söka information och lösa aktuella problem.

De mest intressanta jobben jag hade var i vårt lands försvarskomplex. Under arbetets gång var jag tvungen att lösa helt enkelt fantastiska problem som kommersiella programmerare aldrig ens hade drömt om. Superdatorer, design av routrar, olika nodstridssystem - det här är otroligt spännande. När du under paraden ser ett komplex som lagrar din kod är det riktigt trevligt. Märkligt nog är intervjuer med sådana företag vanligtvis mycket enkla, bokstavligen kommer, gillar det, accepterade (förmodligen detaljerna för militären, som inte gillar att prata för mycket), överlagras. Utmaningarna jag mötte där var verkligen intressanta och utmanande. Med erfarenhet visade det sig att de är bra för att lära sig att vara en högkvalitativ systemprogrammerare. Det finns också nackdelar, och det är inte ens låga löner. För tillfället är lönen i försvarskomplexet ganska anständig, med bonusar och förmåner. Som regel är det mycket byråkrati, långa arbetstider, oändliga brådska jobb och arbete under stor stress. I vissa fall kan sekretess inte uteslutas, vilket tillför vissa problem för utlandsresor. Plus, naturligtvis, chefernas tyranni, och detta händer tyvärr också. Även om min erfarenhet av att arbeta med en kundrepresentant är oerhört trevlig. Detta är ett samlat intryck av tre olika forskningsinstitut och företag med anknytning till statliga försvarsorder.

Intervjuuppgifter

För att undvika missförstånd och för att inte avslöja företagen jag intervjuat med kommer jag inte att fresta ödet och ange deras detaljer. Men jag är tacksam för varje intervju, för den tid som folk lagt ner på mig, för möjligheten att se mig själv utifrån. Jag kan bara säga att uppgifterna var för stora internationella företag representerade i olika länder.

Jag ska berätta det mest intressanta: vilka uppgifter som ges under intervjuer. I allmänhet är de vanligaste frågorna för den lediga tjänsten för en systemprogrammerare och mikrokontrollerprogrammerare bitoperationer, i alla möjliga variationer. Förbered dig därför bäst på detta område.

Det näst mest polariserande ämnet är vägvisare, det här borde verkligen hoppa ur tänderna. Så att de väcker dig mitt i natten och du kan berätta och visa allt.

Jag stal frågor från flera intervjuer i mitt huvud, och jag kommer att presentera dem här, eftersom jag tycker att de är ganska intressanta. Jag ger medvetet inga svar på dessa frågor så att läsarna själva kan svara på dessa frågor i kommentarerna och ha lite krut när de går igenom en riktig intervju.

Frågor nr 1

I. Kunskaper om SI. Vad betyder följande poster:
const char * str;

char const * str;

const * char str;

char * const str;

const char const * str;
Är alla inmatningar korrekta?

II. Varför kommer det här programmet att skapa ett segmenteringsfel?
int main ()
{
       fprintf(0,"hellon");
       fork();
       return(0);
}
III. Att vara smart.

Det finns en pinne som är en meter lång. Tio myror faller slumpmässigt på henne och kryper åt olika håll. En myras rörelsehastighet är 1 m/s. Om en myra stöter på en annan myra vänder den sig om och kryper åt motsatt håll. Vad är den maximala tiden du behöver vänta på att alla myror ska ramla av pinnen?

Nästa intervju var ett misslyckande för mig, och jag anser att den är den mest användbara i min programmeringsövning. Det visade djupet av min inkompetens. Före den här intervjun var jag bekant med var och en av dessa frågor och de kom ständigt upp i min praktik, men på något sätt lade jag inte så stor vikt vid dem, och därför förstod jag dem inte så bra. Därför misslyckades jag på detta prov på skam. Och jag är mycket tacksam för att ett sådant misslyckande inträffade, det hade den mest nyktra effekten på mig. Du tror att du är en cool specialist, du kan kretsdesign, gränssnitt och att arbeta med kärnan. Och så har du riktiga frågor och du flyter. Så låt oss se.

Intervjufrågor #2

Hårdvaruproblem.

Hur linux-systemanrop ordnas i assemblerspråk på en ARM-processor, på x86. Vad är skillnaden?

Vilka synkroniseringsverktyg finns det? Vilka synkroniseringsverktyg kan användas i ett avbrottssammanhang, vilka kan inte, och varför?

Vad är skillnaden mellan i2c bus och spi bus?

Varför finns det terminatorer på i2c-bussen och vad är deras värde?

Kan RS-232-gränssnittet ENDAST fungera på två ledningar: RX och TX? Här kommer jag att ge svaret: Det visar sig att det är dåligt, på 9600, men det kan det!!!

Och nu den andra frågan: varför?

Vad är det bästa sättet att ordna signalledningar och ström i flerskiktskort och varför? Kraft inuti lagren, eller signallinjer inuti lagren? (Frågan handlar i allmänhet enbart om kretsdesign).

Varför har differentiallinjer spår som går ihop överallt?

RS-485 buss. Vanligtvis finns det terminatorer på en sådan linje. Däremot har vi en stjärnkrets, med ett varierande antal plug-in moduler. Vilka medel för att undvika kollisioner och störningar bör användas?

Vad är röda och binära träd?

Hur arbetar man med cmake?

Frågor om att bygga yocto Linux.

Mål för denna intervju:

1. Skriv en funktion som inverterar till uint32_t alla bitarna. (att arbeta med bitar är väldigt populärt vid intervjuer, jag rekommenderar det)
2.
int32_t a = -200;
uint32_t b = 200;
return *(uint32_t) * (&a)) > b;
Vad kommer denna funktion att returnera? (lösning på papper, utan dator)

3. Funktion för att beräkna det aritmetiska medelvärdet av två tal int32_t.

4. Vilka är utdatametoderna i program, inkl. in i en ström av fel.

Det tredje urvalet var relativt nyligen, och jag skulle inte bli förvånad om det fortfarande finns ett sådant frågeformulär där, så jag kommer inte att avslöja företaget för att inte avslöja dem... Men i allmänna termer ska jag ge ett exempel av möjliga frågor, och om du känner igen dina frågor, då säger jag hej :).

Intervjufrågor #3

Ett exempel på trädgenomgångskod ges, det är nödvändigt att berätta vad som görs i denna kod och påpeka fel.

Skriv ett exempel på ls-verktyget. Med det enklaste alternativet "-l".

Ge ett exempel på hur man gör statisk och dynamisk länkning. Vad är skillnaden?

Hur fungerar RS-232? Vad är skillnaden mellan RS-485 och RS-232? Vad är skillnaden mellan RS-232 och RS-485 från en programmerares synvinkel?

Hur fungerar USB (ur en programmerares synvinkel)?

Översättning av teknisk text från ryska till engelska.

En framgångsrik intervju är ingen garanti för framgångsrikt arbete

Det här kapitlet är förmodligen inte ens för programmerare (men för dem också), utan mer för HR. De mest adekvata företagen tittar inte noggrant på resultaten av intervjuer. Det är normalt att göra misstag; oftast tittar de på hur en person vet hur man löser problem och resonerar.

Ett av nyckelproblemen är att en kandidat framgångsrikt löser problem under intervjuer, visar sig vara en utmärkt specialist, men misslyckas med den första riktiga uppgiften. Jag ska inte ljuga, det här hände mig också. Jag gick framgångsrikt igenom alla helvetets cirklar, löste alla testuppgifter, men under verkliga förhållanden visade sig arbetet vara för tufft på grund av enkel oerfarenhet. Att komma ombord är inte den svåraste uppgiften. Det svåraste är att stanna ombord på det här företaget.

Därför litar jag på fler företag som gör enkla intervjuer med kandidaten och säger: efter första månadens arbete kommer det att framgå om du är lämplig för oss eller inte. Detta är det mest adekvata tillvägagångssättet, ja, kanske lite dyrt, men det är direkt klart vem som är vem.

Det finns ett annat alternativ för intervjuer: när du klarar det, men baserat på resultaten av intervjun förstår du att arbetsgivaren är helt otillräcklig. Jag vägrar omedelbart arbete om jag erbjuds att arbeta som enskild företagare och lovar stora inkomster. Detta är en form av skatteflykt för en driftorganisation, och varför ska arbetsgivarens problem oroa mig som programmerare? Ett annat alternativ är olika statliga myndigheter. Jag hade en intervju, som ett resultat av vilken jag erbjöds en bra lön, men de sa att den förra programmeraren slutade, blev sjuk, dog, gick på en hetta på grund av arbetsbelastningen och din arbetsdag börjar klockan 8 på morgonen . Från ett sådant ställe sprang han också så att hälarna gnistrade. Ja, HR, observera att programmerare är redo att tacka nej till även det mest läckra jobb om arbetsdagen måste börja tidigt på morgonen.

I slutet kommer jag att ge en utmärkt video om val av programmerare, en skärmdump av vilken ges i början av den här artikeln. Jag har också haft en sådan intervju mer än en gång. Om du ser tyranni i frågestadiet, respektera dig själv, res dig upp, ta dina saker och lämna - det här är normalt. Om HR och chefen hävdar sig på din bekostnad under intervjun tyder det på att företaget är giftigt och du ska inte jobba där om du inte gillar otillräckliga chefer.

Resultat

Programmerare, gå på intervjuer! Och försök alltid att bli befordrad. Låt oss säga att om du får N pengar, gå på en intervju för minst N*1,2, eller bättre N*1,5. Även om du inte tar den här lediga tjänsten direkt, kommer du att förstå vad som krävs för denna lönenivå.
Mina observationer har visat att goda kunskaper i engelska språket, tillräckligt rik erfarenhet av branschen och självförtroende avgör. Det senare är huvudegenskapen, som överallt i livet. Som regel kan en mer självsäker kandidat prestera bättre i en intervju, även med fler misstag, än en utmärkt, men mer blyg och proaktiv sökande. Lycka till med dina intervjuer!

P/S-tävling

Om du har intressanta exempel på problem som HR har laddat dig med, välkommen i kommentarerna. Vi har förberett en liten tävling - förutsättningarna är enkla: du skriver den mest ovanliga uppgiften som du hade under en intervju, läsarna utvärderar den (plus), och efter en vecka summerar vi resultaten och belönar vinnaren med roliga godsaker.

Källa: will.com

Programmerare, gå på intervjuer