Hur många tekniska intervjuer har du haft i ditt liv?
Under de senaste fem åren har jag deltagit i 35 tekniska intervjuer av alla tänkbara typer och specificiteter – från kazakiska startups för kollektiva inköp av kött för vintern till tyska och amerikanska fintechtjänster och banker; med fokus på programmering, leverans och förvaltning; fjärrkontroll och på kontoret; begränsad och obegränsad i tid; stressande och avslappnad, på olika språk.
Detta, i kombination med de ~20 intervjuerna som jag själv genomförde som arbetsgivare - ett tillräckligt antal för att jag skulle bli kungen av intervjuer för att göra följande observation (till en början helt omöjlig) och etablera mig i den: Jag är övertygad om att till stor del tack vare så många intervjuer börjar det se ut som en marginell vana, jag studerade min stack på professionell nivå och blev en konkurrenskraftig specialist, trots att jag redan jobbat med webbutveckling i 10 år.
Den här artikeln riktar sig till programmerare som är i början av sin resa och ännu inte har uttömt djupet av sina kunskaper. I den vill jag utöka uppsatsen om de kolossala pedagogiska fördelarna med testuppgifter och tekniska frågor som ställs i intervjuer – och bjuda in alla till min nyskrivna telegrambot , där du enligt min plan kan ta en teknisk intervju minst varje dag tills de tar slut. Och så att de inte tar slut kan du också dela med dig av en intressant teknisk uppgift, fråga eller en användbar/rolig situation som du upplevt under en intervju.
Jag ska berätta mer om boten nedan, låt oss först ta reda på varför det är så viktigt att veta och förstå svaren på dessa tekniska frågor och uppgifter, även om du framgångsrikt har drivit frilansprojekt i flera år.
Varför lämnar kvaliteten på vår grundläggande kunskap mycket övrigt att önska?
Tekniska intervjuer, om du ännu inte har blivit kungen av intervjuer, är en allvarlig påfrestning för kroppen, liksom sökandet efter ett jobb i allmänhet - oavsett om du är en nybörjarspecialist, en växlare eller en utvecklare som har arbetat i en. plats under lång tid (och i vår tid kan "lång" betraktas som ett år).
I många intervjuer finns det en mänsklig faktor som förvärrar denna stress. Din intervjuare kanske inte är Alena Vladimirskaya, utan en vanlig programmerare-som-du-hittat, från vilken det är svårt att förvänta sig adekvata uppgifter och deras utvärdering, eller en hardcore-teamledare som väntar för ögonblicket för att få ner all hans svårighetsgrad i hans ögon på dig och ställer frågan: Vad är för dig smidig!?
En dag, utan att ge det nödvändiga, men, som ni förstår, oförutsägbara svar på denna fråga, blev jag utan ett erbjudande, vilket jag blev otroligt glad över.
Genom att försöka undvika denna stress och onödiga rörelser i allmänhet, tar vi avstånd inte bara från den högljudda exponeringen av vår okunnighet om vissa grundläggande drag i språket, utan också från att minska denna okunnighet åtminstone en aning.
Problemet är att det i praktiken är få ställen där vi kan få denna klass av problem.
Varje utvecklare som har varit tvungen att arbeta på flera ställen kommer att bekräfta att de grundläggande eller kreativa problem som ställs i intervjuer sällan har något att göra med vad en programmerare sysslar med i verkligheten - inga rekursioner, grafer och asynkrona hisskontrollsystem på planeten med negativa gravitationen i en annan arm av galaxen. Tyvärr.
I förhållande till mitt inhemska JavaScript finns det ett bra exempel - om React.JS inte hade dykt upp skulle 98% av JavaScript-programmerare framgångsrikt fortsätta leva i lycksalig okunnighet om vad bind är - mer än 20 år efter dess uppkomst - och skulle fortsätta att bli förbryllad, få frågor om det vid intervjuer, och bara de som uppfinner alla dessa mycket abstrakta bibliotek, ramverk och moduler skulle fortsätta att arbeta med det. Idag, tack vare reaktionen, har denna siffra minskat till vad som känns som 97%.
Uppenbarligen, när de ser "isoleringen från verkligheten" av dessa uppgifter, ignorerar många utvecklare dem eller slösar tid på att fördjupa sig i dem - och fortsätter att arbeta med sin dagliga rutin, det vill säga bildligt talat, gå igenom minfältet av utveckling för produktion, inte bara utan mindetektor, men också utan att veta att de befinner sig i ett minfält.
Vilka är konsekvenserna av bristande grundläggande kunskaper i ett språk?
Svaret på denna fråga verkar banalt, men av någon anledning ligger det i den mänskliga naturen att alltid skjuta sin lösning in i det bortre hörnet - och detta spelar en sorglig roll i junior- och mellanprogrammerares liv, vilket förlänger deras väg till höjderna (och djupet) ) av språkkunskaper med ett par år år.
Applikationskoden som använder ramverk och bibliotek som de är vana vid att skriva varje dag kan inte anses tillförlitlig om de skriver den utan tillräcklig förståelse för de olika aspekterna av dess utförande. En bra illustration av detta från JavaScripts värld är ödet för JQuery-biblioteket, som en gång var motorn för framsteg och som idag, som är ett självslutet kunskapsområde, skilt från resten av språket, tar sin naturliga plats i marknaden - semiprofessionella manus hastigt skrivna och arbetade efter behov som en gåva till samma snabba layout på bootstrap från billiga frilansare.
Framtiden för projekt som utvecklats med ett så oansvarigt tillvägagångssätt, om än av okunnighet, är prosaisk och kortlivad: betydande tidsförluster, misslyckanden, ekonomiska förluster och förluster av rykte och, som ett resultat, en minskning av entusiasmen för fortsatt samarbete.
Å andra sidan, för en person som har valt en programmerares väg, kan lite jämföras med nöjet att förstå vad han gör. Att förstå att han, precis som Baron Munchausen, sprattlar genom ett minfält till häst. Onödigt att säga att en anständig arbetsgivare tydligt kan se människor som går hänsynslöst genom ett minfält och människor som är frusna i obeslutsamhet att ta ett steg i en situation där de kan springa och hoppa utan att tänka på någonting?
AktiveraBot
Efter att ha sett fördelarna med intervjuer, och även insett att det inte är helt etiskt att gå på tomma intervjuer, tänkte jag att det skulle vara bra att skapa en bot där en nybörjare eller en utvecklare som transplanterar till ett annat språk kan delta i pedagogisk träning utan att ta till riktiga intervjuer i den mån, där det hände mig. Och när jag kom ihåg hur programmerare älskar att diskutera och jämföra problem som de var tvungna att lösa - speciellt om det var något icke-trivialt - insåg jag att allt passar, förkastade alla tvivel och voila.
Boten har för närvarande 3 enkla funktioner:
- Prenumerera på ett visst språk/ramverk för att få nya uppgifter för det. Du prenumererar och när uppgifter kommer in får du dem i det dagliga nyhetsbrevet
- Publicera en uppgift eller testuppgift – I min bok säger de att dela är att bry sig
- En utmärkt namngenerator med vilken du kan välja den optimala signaturen för texten i uppgiften du publicerar, inklusive feminina ordböcker, inte utan feminister
För närvarande finns följande språk att välja mellan: JavaScript, Java, Python, PHP, MySQL. Urvalet är något begränsat på grund av gränserna för min förståelse. Jag hoppas kunna lägga till den här listan med hjälp av habra-gemenskapen.
Boten lanseras i ett rent rock and roll-format, betalning för något förväntas inte.
Du kan gå till den via denna länk:
Kort om teknisk implementering
Den här boten är ett av flera små projekt där jag tar med den första offentliga versionen av mitt miniframework med öppen källkod för att utveckla botar med en komplex struktur, med kärleksfullt namn Hobot och tillgänglig i NPM för hardcore människor.
Ramverket är byggt på basis av Telegraf.JS och TypeScript, dess noll-noll-första version, utrustad med ett exempel på användning, kan ses på och prova det direkt. Snart kommer jag att ladda upp version 0.0.2, utökad och kammad för en person utifrån, och kommer att ägna en separat artikel åt det (stammen). Jag blir glad om det visar sig vara lika relevant för någon som det är för mig.
Så, hur många intervjuer behövde du gå på?
Jag är säker på att du har något att berätta!
Källa: will.com