Sådan knækkes Javascript fuldstack udviklersamtale

Jeg har kodet stort set i JavaScript siden sidste 6 år og arbejdede også meget med Java, databaser og mange andre programmeringssprog.

På grund af min viden inden for både Frontend- og Backend-teknologier, havde jeg mange muligheder, da jeg ledte efter jobskifte. Jeg kunne ansøge om en fuld stack-udviklerrolle (Java, node.js og databaser) eller webudvikler (JavaScript, HTML og CSS).

Senere indså jeg, at det er vanskeligt at rydde fuld stack-udviklerinterview, når du ikke har arbejdet med design og skalerbarhed af applikationen. Da jeg også ønskede at lære skalerbarhed og design i processen, gav jeg flere full-stack-interviews også.

Så her vil jeg diskutere, hvordan forberedte jeg mig på webudviklingssamtale og fuld stack-interviews separat.

JavaScript-udviklerinterview: JavaScript er den vigtigste ting at lære, mens man forbereder sig til webudviklingssamtale. Hver virksomhed har forskellige interviewprocesser. Få store virksomheder som Flipkart og Amazon fokuserer på vanilje JavaScript, mens mindre virksomheder også fokuserer på JavaScript-biblioteker (React and Angular). Så der kræves separat planlægning til samtale med hver virksomhed.

Her er nogle af ressourcerne, jeg henviste til:

Objektorienteret Javascript Stoyan Stefanov: Denne bog dækker grundlæggende JavaScript meget godt. Det dækker ikke ES6, men stadig er dette en af ​​de bedste bøger til at lære grundlæggende om JavaScript.

33 JS-koncepter: Det er virkelig god ressource at revidere alt grundlæggende JavaScript-koncept.

Blogs: John resig er opfinder af JQuery, og jeg fandt hans blog meget nyttig til at rydde nogle af de grundlæggende begreber i JavaScript.

Toptal har også meget godt sæt spørgsmål til JavaScript.

ES6: Stephen Grider er topskribent i JavaScript på Udemy, og jeg fandt, at alle kurserne var meget nyttige, mens jeg forberedte mig til interviews.

Designmønstre: Addy Osmanis blog dækker omfattende mønstre i JavaScript.

React and Redux: Nogle af virksomhederne beder det grundlæggende om React og Redux. Stephen Griders kursus er meget nyttige i den henseende.

CSS: Interviewere dømmer også engang kandidater, hvis de er gode i CSS.

CSS-tricks er virkelig god ressource, og det har også en god samling af interviewspørgsmål:

30 sekunder af CSS har god samling af CSS-komponenter til at øve:

Min essens: Baseret på mine interviews, har jeg også oprettet en kernedækning af nogle af de avancerede spørgsmål om JavaScript:

I hvert JavaScript-interview justerer intervieweren stort set spørgsmål til følgende emner:

1. Arv

2. Lukning

3. Begivenheder

4. Design mønstre

5. Omfang

Bygningskomponenter: Erfaren udvikler bliver generelt bedt om at designe og kode en UI-komponent ved hjælp af OOJS. Udvikler skal vise deres design og JavaScript-viden her. Det er bedre at udvikle nogle af dine komponenter inden din samtale. For eksempel: Auto-forslag, karrusel, timer, trækomponent osv. En af de mest almindelige fejludviklere gør er at starte kodning uden at stille de rigtige spørgsmål. Så vi er nødt til at være klar over de anvendelsessager, denne komponent løser.

Vi er nødt til at overveje få sager for at designe komponenten:

  1. Kantsager: Komponenten skal fungere, hvis klienten ikke leverer nogen parameter
  2. Undtagelseshåndtering: Komponent skal kaste undtagelse, når der er bestået forkerte params eller andre kanttilfælde
  3. Designmønster: Show case konstruktør, afslørende modul, singleton mønster osv.
  4. Understøtter flere komponenter på siden
  5. Begivenhedsdelegering: Vis sag, hvor skal du håndtere begivenheder, og hvad er fordelene
  6. MVC-mønster: Vis sagmodel, visning og controller, hvis nogen i komponenten
  7. DOM Manipulation og maling: Nogle af de almindelige fejl, folk begår, er at læse fra dom. Det er bedre at undgå det. Vis også tilfældet, hvordan gengivelse er hurtigere i din komponent.

Jeg har oprettet en grundlæggende komponent, der er nyttig til at opbygge enhver anden komponent:

Full stack-udvikler Interview:

Jeg bemærkede, at betydningen af ​​Full stack-udvikler i industrien er lidt forkert. De fleste af virksomhederne betragter Full stack-udvikleren som Backend-udvikler, der kender lidt frontend. Kun få virksomheder fokuserer mere på frontend end backend, mens de leder efter fuld stack-udvikler. Så kandidaten skal være forberedt på en sådan samtale og bør stille spørgsmål til HR om dette før samtalen.

Så jeg vil diskutere, hvordan forberedte jeg mig på backend-interviews, selvom jeg ikke er ekspert på dette område.

1. Github-lager:

Jeg fandt github-depot af John Washam, mens jeg forberedte et interview. Og det dækker næsten alle de vigtige ressourcer til at forberede sig til samtale. Det er meget vanskeligt at udfylde alle de ressourcer, der leveres i dette arkiv. Jeg har primært fokuseret på design, algoritmer og ressource til datastruktur fra dette arkiv.

2. Forberedelse af algoritme og datastruktur:

Jeg henviste til 'datastrukturer og algoritmer gjort let' af Narasimha Karumanchi. Denne bog dækker næsten alle de vigtige emner til interviews. Løst problemer med Geeksforgeeks, leetcode og hackerrank.

Siden løste jeg problemer fra forskellige kilder, alle de vigtige algoritmer var meget tydelige for mig. Jeg kunne skrive disse algoritmer meget hurtigt på papir.

2. Online-dommer: For at skrive kode hurtigt deltog jeg i forskellige udfordringer med Top-coder- og kodekræfter. Jeg løste også problemer fra spoj og projekt euler.

3. Øv på papir / whiteboard / google doc:

Det er meget vigtigt ikke at bruge IDE først. Da virksomheder bruger sammenbrud, google-doc eller whiteboard i interview, øvede jeg på papir eller whiteboard eller google-doc først, så kodede jeg på IDE for at få mere tillid.

4. Designproblemer: Interviewbit designproblemer er gode at starte. Derudover fulgte jeg mine ressourcer:

Få andre tip:

Her er nogle andre interviewtips, der kan være nyttige:

  • At stille rigtige spørgsmål i stedet for at antage
  • Forklaring af løsningen klart
  • Brug lidt tid på at forberede dig på dine projekter.
  • Brug ikke debugger, brug dit sind i stedet :)
  • Hvis du forklarer ethvert problem, du har løst, skal du være klar til ethvert tværgående spørgsmål