Hvor mange tekniske samtaler har du haft i dit liv?
I løbet af de seneste fem år har jeg deltaget i 35 tekniske interviews af enhver tænkelig type og specificitet – fra kasakhiske startups til kollektivt indkøb af kød til vinteren til tyske og amerikanske fintech-tjenester og banker; med fokus på programmering, levering og ledelse; fjernbetjening og på kontoret; begrænset og ubegrænset i tid; stressende og afslappet, på forskellige sprog.
Dette, sammenholdt med de ~20 interviews, som jeg selv gennemførte som arbejdsgiver - et tilstrækkeligt antal til, at jeg kan blive kongen af interviews til at gøre følgende observation (i første omgang helt uoplagt) og etablere mig i den: Jeg er overbevist om, at en stor del takket være så mange interviews begynder det at ligne en marginal vane, jeg studerede min stak på professionelt niveau og blev en konkurrencedygtig specialist, på trods af at jeg allerede havde arbejdet med webudvikling i 10 år.
Denne artikel henvender sig til programmører, der er i begyndelsen af deres rejse og endnu ikke har opbrugt dybden af deres viden. Heri vil jeg uddybe specialet om de kolossale pædagogiske fordele ved testopgaver og tekniske spørgsmål stillet i interviews - og invitere alle til min nyskrevne telegrambot , hvor du efter min plan kan tage en teknisk samtale mindst hver dag, indtil de slutter. Og for at de ikke slutter, kan du også dele en interessant teknisk opgave, spørgsmål eller en nyttig/sjov situation oplevet under et interview.
Jeg vil fortælle dig mere om botten nedenfor, lad os først finde ud af, hvorfor det er så vigtigt at kende og forstå svarene på disse tekniske spørgsmål og opgaver, selvom du med succes har kørt freelanceprojekter i årevis.
Hvorfor lader kvaliteten af vores grundlæggende viden meget tilbage at ønske?
Tekniske samtaler, hvis du endnu ikke er blevet kongen af samtaler, er en alvorlig stress for kroppen, ligesom søgen efter et job generelt er - uanset om du er nybegynder specialist, skifter eller udvikler, der har arbejdet i en. sted i lang tid (og i vores tid kan "lang" betragtes som et år).
I mange interviews er der en menneskelig faktor, der forværrer denne stress. Din interviewer er måske ikke Alena Vladimirskaya, men en almindelig programmør-som-du-fundet, fra hvem det er svært at forvente tilstrækkelige opgaver og deres evaluering, eller en hardcore teamleder, der vil vente på det øjeblik for at nedbringe al hans alvor i hans øjne på dig og stiller spørgsmålet: Hvad er for dig adræt!?
En dag, uden at give det nødvendige, men, som du forstår, uforudsigelige svar på dette spørgsmål, stod jeg uden et tilbud, hvilket jeg var utrolig glad for.
Ved at forsøge at undgå denne stress og unødvendige bevægelser generelt, tager vi afstand ikke kun fra den højlydte eksponering af vores uvidenhed om nogle grundlæggende træk ved sproget, men også fra at reducere denne uvidenhed i det mindste en smule.
Problemet er, at der i praksis er få steder, hvor vi kan få denne klasse af problemer.
Enhver udvikler, der har været nødt til at arbejde flere steder, vil bekræfte, at de grundlæggende eller kreative problemer, der stilles i interviews, sjældent har noget at gøre med, hvad en programmør beskæftiger sig med i det virkelige liv - ingen rekursioner, grafer og asynkrone elevatorkontrolsystemer på planeten med negative tyngdekraften i en anden arm af galaksen. Desværre.
I forhold til mit oprindelige JavaScript er der et godt eksempel - hvis React.JS ikke var dukket op, ville 98% af JavaScript-programmører med succes fortsætte med at leve i lyksalig uvidenhed om, hvad bind er - mere end 20 år efter dets fremkomst - og ville fortsætte at blive forvirret, modtage spørgsmål om det ved interviews, og kun dem, der opfinder alle disse meget abstrakte biblioteker, rammer og moduler, ville fortsætte med at arbejde med det. I dag er dette tal, takket være reaktionen, blevet reduceret til, hvad der føles som 97%.
Når man ser "isolationen fra virkeligheden" af disse opgaver, ignorerer mange udviklere dem eller spilder tid på at fordybe sig i dem - og fortsætter med at gå i gang med deres daglige rutine, det vil sige billedligt talt at gå gennem minefeltet af udvikling til produktion, ikke kun uden minedetektor, men også uden at vide, at de befinder sig i et minefelt.
Hvad er konsekvenserne af manglende grundlæggende viden om et sprog?
Svaret på dette spørgsmål virker banalt, men af en eller anden grund er det menneskets natur altid at skubbe sin løsning ind i det fjerne hjørne - og dette spiller en trist rolle i livet for junior- og mellemprogrammører, hvilket forlænger deres vej til højderne (og dybderne) ) af sprogkundskaber med et par år.
Den applikationskode, der bruger rammer og biblioteker, som de er vant til at skrive hver dag, kan ikke betragtes som pålidelig, hvis de skriver den uden tilstrækkelig forståelse af de forskellige aspekter af dens implementering. En god illustration af dette fra JavaScript-verdenen er skæbnen for JQuery-biblioteket, som engang var fremskridtsmotoren og i dag, som er et selvstændigt indelukket vidensfelt, skilt fra resten af sproget, indtager sin naturlige plads i markedet - semi-professionelle manuskripter skrevet i hast og arbejde efter behov som en gave til det samme hurtige layout på bootstrap fra billige freelancere.
Fremtiden for projekter udviklet med en så uansvarlig tilgang, omend af uvidenhed, er prosaisk og kortvarig: betydelige tab af tid ud af det blå, fiaskoer, økonomiske tab og omdømmetab og som følge heraf et fald i entusiasme for fortsat samarbejde.
På den anden side, for en person, der har valgt en programmørs vej, kan lidt måle sig med glæden ved at forstå, hvad han laver. Forståelse for, at han ligesom Baron Munchausen suser gennem et minefelt på hesteryg. Det er overflødigt at sige, at en anstændig arbejdsgiver tydeligt kan se folk gå hensynsløst gennem et minefelt og folk, der er frosset i ubeslutsomhed til at tage et skridt i en situation, hvor de kan løbe og hoppe uden at tænke over noget?
ActualizeBot
Efter at have set fordelene ved interviews og også indset, at det ikke er helt etisk at gå til blanke interviews, tænkte jeg, at det ville være fantastisk at skabe en bot, hvor en begynder eller en udvikler, der transplanterer til et andet sprog, kunne deltage i uddannelse uden at ty til rigtige interviews i den grad , hvor det skete for mig. Og da jeg huskede, hvordan programmører elsker at diskutere og sammenligne problemer, som de skulle løse - især hvis det var noget ikke-trivielt - indså jeg, at alt passer, afviste al tvivl og voila.
Botten har i øjeblikket 3 simple funktioner:
- Abonnement på et bestemt sprog/framework for at modtage nye opgaver til det. Du tilmelder dig og efterhånden som opgaverne kommer, modtager du dem i det daglige nyhedsbrev
- Udgivelse af en opgave eller testopgave – I min bog siger de, at deling er omsorg
- En fremragende navnegenerator, hvormed du kan vælge den optimale signatur til teksten til den opgave, du udgiver, inklusive feminine ordbøger, ikke uden feminister
I øjeblikket er følgende sprog tilgængelige at vælge imellem: JavaScript, Java, Python, PHP, MySQL. Udvalget er noget begrænset på grund af grænserne for min forståelse. Jeg håber at kunne tilføje til denne liste med hjælp fra habra-samfundet.
Botten lanceres i et rent rock and roll-format; betaling for noget forventes ikke.
Du kan gå til det ved at bruge dette link:
Kort om teknisk implementering
Denne bot er et af flere små projekter, hvor jeg bringer den første offentlige version af mit open source miniframework til udvikling af bots med en kompleks struktur, kærligt navngivet Hobot og tilgængelig i NPM for hardcore mennesker.
Rammerne er bygget på basis af Telegraf.JS og TypeScript, dens nul-nul-første version, udstyret med et eksempel på brug, kan ses på og prøv det med det samme. Snart vil jeg uploade version 0.0.2, udvidet og kæmmet til en person udefra, og vil afsætte en separat artikel til det (stammen). Jeg vil blive glad, hvis det viser sig at være lige så relevant for nogen, som det er for mig.
Så hvor mange interviews skulle du deltage i?
Jeg er sikker på, du har noget at fortælle!
Kilde: www.habr.com