Frontend

Milliseid teisi kriteeriume te võiksite nimetada heaks raamatukogukomponendiks?

Saite õppima Reacti, ja React on populaarsem ning selle jaoks on rohkem tööpakkumisi. Miks lõpuks läksite Angulari?

Räägi mulle üheühiktestide kirjutamisest: millal, sinu arvates, peaks test ebaõnnestuma? Mida täpselt peaks kontrollima üheühiktest, mis on testitud Londoni kooli meetodit järgides (kõik sõltuvused on mock-itud)?

Võrrelge sõltuvuste sisestamist konstruktoriparameetrite kaudu ja inject-funktsiooni kaudu: millised on iga lähenemise plussid ja miinused?

Selle lähenemise analüüs vastutuse segamise vaatenurgast: mis siin valesti tehti ja kuidas seda seletaksite arhitektuuriprintsiipide (eriti Ühe vastutuse printsiibi ja esitamise ning mudeli eraldamise) vaatenurgast?

Kas saaksite loetleda kõiki selle probleemi tehnilisi lahendusi (välja arvatud välja asendamine signaaliga)?

Rääkige meile rohkem async pipe'i ja käsitsi tellimise kasutamisest: mida täpselt tuleb teha, et väärtus õigesti kuvatakse mallil (sealhulgas töö tellimisega ja selle tühistamisega takeUntilDestroy või ngOnDestroy kaudu)?

Kui mall ei tea, et väärtus on muutunud, miks async pipe lisamine mallile lahendab reaktiivsuse probleemi? Kuidas see töötab kapoti all?

Kas teil on praktiliselt põhinevad kriteeriumid, kus pärimine on sobiv ja kus mitte?

Kas saaksite anda konkreetset näidet raamatukogust, mis takistas Angulari uuendamisel (näiteks versioonile 16) ehituse lõpetamist? Mis täpselt oli probleem ja kuidas te selle lahendasite?

Teie elulookirjelduses on märgitud, et uuendasite Angulari versioonilt 14 kuni 20. Rääkige mõnest probleemist, mis tekkis Angulari uuendamisel projektis - praktiline lugu.

Miks on OOP-is pärimine üldse vajalik? Esitage põhjendus, miks seda kasutatakse, kui loogika taaskasutamise ülesannet saab lahendada ka teistmoodi (näiteks DI kaudu).

Miks signaali kasutamisel ja set meetodi kutsumisel uuendatakse väärtus mallis, kuid lihtsa omistamisega nagu this.token = string, mitte? Selgitage seda muutuste tuvastamise tasemel.

Kas tead UML-klassidiagrammidest? Kas olete tegelenud selliste seoste tüüpidega nagu assotsiatsioon, koostamine, agregatsioon, üldistamine?

Sa ütlesite, et kirjutasite testid närvivõrgu abil. Kui närvivõrk on genereerinud testid, mis ebaõnnestuvad iga klassi koodi muutmisel, saavutavad need testid oma eesmärgi? Kas need on kasulikud?

Kui teil oleks vaja loendada koodiridade arvu projektis, kuidas te selle ülesande juurde läheksite? Kuidas te sõnastaksite päringu lahenduse või närvivõrgu otsimiseks?

Miks te valisite just veebiarenduse ja Angular, mitte näiteks mobiilse arenduse?

Eelmisel töökohal ütlesite, et frontend osa on suhteliselt väike, kuid sellega tegeleb 6 frontend arendajat. Kust täpselt pärineb see 6-liikmeline meeskond ja kuidas see on seotud ettevõtte üldise frontend-meeskonnaga?

Kujutage ette stsenaariumi: kogenum suurem arendaja saab nojunioriga ülesandeks luua Angular-komponendi, millel on väli tokeni kuvamiseks ja nupp 'loo token'. Nupule klõpsates saadetakse serverile päring, saadakse token ja noor kirjutab this.token = saadud stringi, kuid väärtus ei kuvata ning leht ei uuesti joonistata. Mida soovitaksite selle probleemi lahendamiseks ja millised on üldised lähenemised selle parandamiseks?

Rääkige meile, kuidas te sattusite arendusvaldkonda: kuidas õppisite, kuidas leidsite oma esimese töö, arvestades, et teie CV-s on märgitud mitte-tehniline eriala?