Mythbusting konkurrencedygtig programmering - Du behøver ikke lære det

Nu hvor jeg har fået din opmærksomhed med posttitlen, lad mig gå i dybden med mine synspunkter om konkurrencedygtig programmering.

Hvad er konkurrencedygtig programmering?

Konkurrenceprogrammering er en sport. Du skal løse et problem med kode, der er hurtig, bruger den mindste mængde hukommelse og ofte er praktisk ulæselige.

Det er super populært blandt universitetsstuderende og dem, der prøver at komme ind i store virksomheder, primært fordi det hjælper dem med at blive placeret i disse virksomheder. Desværre ansættes millioner af mennesker på grund af en vis viden, som de aldrig ville bruge i deres job.

Systemet er brudt

Her er et andet eksempel fra Hen-Wen:

Der er mange eksempler derude, jeg kan tænke på.

Skaberen af ​​homebrew - en pakkehåndtering, der bruges af næsten alle, der kører macOS? Afvist. Skaberen af ​​WhatsApp? Afvist af Facebook og Twitter.

Så hvad sker der her? Er disse mennesker ikke kvalificerede nok til at arbejde i disse MNC'er?

Nej, svaret er, at disse fyre kan udvikle nyttige værktøjer og skrive god software med førsteklasses kodekvalitet, men de undlader sandsynligvis ikke at (gen) opfinde en algoritme til at invertere et binært træ inden for en 30-minutters frist.

Noget af den bedste kode, der nogensinde er skrevet, blev ikke skrevet på 30 minutter. Nogle af de bedste algoritmer skrevet i Linux-kerne, der blev brugt selv i dag, blev ikke skrevet på 30 minutter af Linus. Nogle af de bedste brugergrænseflader som Stripe blev ikke designet på 30 minutter.

Så hvordan kan en tilfældig HR-person i et tilfældigt firma bestemme dit værd på 30 minutter?

Dette er, hvordan virksomheder bedømmer din "gennemførlighed" - ved at se, om du kan løse et legetøjsproblem, der ikke er relateret til noget arbejde, du måske har gjort tidligere, eller du måske gør i fremtiden.

Kan dette løses?

Jeg ved ikke. Jeg kan klage og råbe alt, hvad jeg vil, men jeg ved ærligt talt ikke, hvordan virksomheder hurtigt og korrekt kan vurdere en person, der ansøger om et job.

Hvis du vil have hurtigt, mister du mange gode kandidater som dem, der er nævnt ovenfor. Hvis du ikke vil miste nogen gode kandidater, kan interviewet vare alt for længe - meget længere end virksomheden har råd til.

Konkurrencedygtig programmering! == Real World programmering

Interviews for virksomheder er mere af en eksamen, hvor du bliver nødt til at huske og lære om ting, du ikke bruger, efter du har fået jobbet.

Du tror, ​​du måske har brug for at lære Dijkstras algoritme til at arbejde på Google Maps, men seriøst, tror du, at Google vil aflevere et af deres kerneprodukter til en ny til virksomheden? Tror du, at du overhovedet ikke får hjælp fra dine jævnaldrende?

Du vil sandsynligvis arbejde på grænsefladen til produktet eller distribuerede systemer i stedet for at arbejde på en af ​​Googles koralgoritmer. Dette betyder, at al din "konkurrenceprogrammerende" viden ikke er til nogen nytte.

Du finder næsten ingen brug for konkurrencedygtig programmering i den virkelige verden. Ingen algoritme, der kører på produktions Microsoft-servere, er skrevet i uleselig kode med korte og meningsløse variabelnavne, udokumenteret og kun optimeret til hastighed og ikke læsbarhed eller vedligeholdelse.

Minificering og forbedring af ydeevnen kommer senere med automatiske værktøjer meget tid. Chancerne er, at hvis du er en konkurrencekoder, udviklede du den dårlige vane med at skrive grim kode.

Alle kan skrive kode til maskiner. Spørgsmålet er, kan du skrive kode til mennesker?

Men der er håb

At sidde til interviews som denne og håbe, at du kan løse et legetøjsspørgsmål, du har forberedt i 3-5 måneder, bare lære DSA og konkurrencedygtig programmering er en måde.

Der er en anden måde - det vil arbejde med færre virksomheder og mennesker, men du vil nyde det og lære en masse virkelige ting undervejs. Du vil også være mere nyttig end de mennesker, der kun lærer "konkurrencedygtig kodning" af hensyn til det.

Byg noget. Hvad som helst. Og bygg derefter mere oven på det. Har en stærk portefølje. Har en komplet færdighedssæt, der er nyttig for virksomheder. Få mestring med en tech stack - ejer den. Har projekter, blogs, erfaring for at vise, at du er, hvad der er i dit CV. Byg forbindelser, netværk med mennesker, bede om deres anbefalinger.

Mange steder er konkurrencedygtig kodning ikke den eneste måde at rydde et interview på - der er alle slags mennesker, der driver alle slags virksomheder. En person, der er enig med min PoV og driver en virksomhed, ville ikke ansætte folk på deres "konkurrencedygtige" viden alene.

Dit arbejde kan tage dig til steder, du ikke kunne forestille dig. Den nemmeste måde er at altid følge publikum. Men intet godt kommer let, i det mindste hvis du er ambitiøs nok. At blande den rigtige mængde ambition og mod kan gøre underværker.

Verden har brug for store programmører for at komme videre, for at komme menneskeheden fremad, ikke mennesker, der kan ansættes.

Forveks ikke DSA med konkurrencedygtig programmering

Jeg ønskede ikke at skrive dette afsnit oprindeligt, men jeg vidste for mange mennesker vil forvirre dette. DSA - Datastrukturer og algoritmer er noget andet. Bunke, kort, arrays, vektorer, sammenkædede lister, .etc, alle disse er også super nyttige i programmering fra den virkelige verden.

Den sjove del er, at du også kan udvikle den forståelse med erfaring. Jeg lærte aldrig eksplicit om "bunke" ved hjælp af et stort 50-timers DSA-kursus. Og hvis du lærer at programmere, har du ikke brug for en meget meget dyb forståelse af det også.

DSA i dybden er påkrævet, når du vil lære datalogi og ikke programmering. Forstå forskellen, datalogi er teorien - programmering er praktisk.

Vær opmærksom på ting, der findes, algoritmer, der findes, og datastrukturer, der findes. Du behøver ikke at lære eller huske dem alle. Det lyder sindssygt dumt for mig at huske eller lære noget, der sjældent bruges, når jeg kan få det med lidt hjælp fra kolleger og internettet.

Min historie

Jeg er ikke en konkurrencekoder, sandsynligvis den eneste CS-kandidat i mit universitet, der aldrig har rørt konkurrencekodning på college .

Hvorfor? Fordi jeg prøvede det for 4-5 år siden og hadede det. Hvorfor? Fordi jeg kunne se mig selv bruge 3-5 timer af min dag hver dag på at løse problemer, der ikke fik mig noget. Jeg vidste en ting eller to mere om at nærme mig det næste spørgsmål, men var det nok til at få indflydelse? Var det nok til at skille sig ud fra mængden?

Hvad godt gjorde jeg? Det føltes som om jeg spildte tid på spørgsmål, der allerede var løst. Det kan være anderledes for alle, men jeg er glad, når jeg ser andre mennesker bruge de ting, jeg programmerede (jeg startede som en webudvikler dengang).

Jeg kunne bare ikke tåle at spilde min tid på at lære noget, jeg aldrig ville bruge i den virkelige verden. Jeg deltog tidligere i Googles Code Jam og Facebooks Hacker Cup tilbage på dagen. Men snart blev jeg keder mig og frustreret over manglen på et bedre ord og kom aldrig rigtig tilbage til det. At få et job eller praktik berørte mig ikke, det gjorde det aldrig.

Jeg sad til Google-interviews en gang på campus. De havde en CV-shortlisting-runde som første runde, i modsætning til alle de andre virksomheder, hvor den første runde var, vent på den, konkurrencedygtig kodningsrunde. Nå der gik de 7 års webudvikling og systemoplevelse ned i afløbet.

Under alle omstændigheder var jeg for Google den eneste person, der kom på listen med en GPA på 7,5 (den højeste GPA er 10 i Indien). Resten af ​​de 10-15 mennesker var over 8,5 eller 9.

Jeg kom ikke forbi den konkurrenceprægede runde igen, men det lærte mig, at det var muligt at bryde ind i den første runde af et firma som Google med bare dit CV. Derfor er det vigtigt at arbejde på det.

Konklusion

TL; DR - Du behøver ikke lære konkurrencedygtig kodning for at få succes i livet. Du er nødt til at lære noget, du kan lide så meget, at du mestrer det, og du er uovervindelig inden for dit felt. Det er alt.

Har synspunkter og meninger? Opret forbindelse til mig på Twitter og Instagram, og lad os tale!