React szakmai interjús élményem

Posted by Annual-Bad-3265@reddit | programmingHungary | View on Reddit | 16 comments

Szeretném megosztani egy friss React szakmai interjúélményemet, főleg azért, mert kíváncsi vagyok, ti hogyan készülnétek fel egy ilyen típusú feladatra.

Online interjú volt. A szakmai részben képernyőmegosztáson keresztül mutattak egy kb. 150 soros React komponenst, amit elemezni kellett. A feladat az volt, hogy mondjam el, milyen problémákat látok benne, mit javítanék, mire figyelnék code review során.

A komponens viszont közel sem fért ki egy képernyőre, ezért folyamatosan nekem kellett mondanom, hogy görgessünk feljebb/lejjebb, nézzük meg hol van használva egy változó, hol van deklarálva egy prop, stb. Emiatt elég nehéz volt átlátni a flow-t. Még nem volt olyan helyzetem, ahol így kellett volna code review-t csinálnom, hogy nem én navigálok a kódban, nincs saját IDE-m, nem tudok keresni, jumpolni, hoverelni, gyorsan visszanézni dolgokat.

A lint / IDE segítségek ki voltak kapcsolva. Ezt valamilyen szinten értem, mert nyilván azt akarták látni, hogy én magamtól mit veszek észre, de közben nekem ez eléggé életszerűtlennek tűnt. Valós PR review-ban pont használom a TypeScriptet, ESLintet, IDE navigációt, keresést, warningokat, mert ezek segítenek kiszűrni a mechanikus hibákat, és több figyelmem marad a valódi logikai, architekturális vagy üzleti problémákra. Ennyi erővel akár papírra is kaphattam volna a feladatot.

A kód tele volt különböző anti-patternekkel és hibákkal, például:
- hibás async / fetch kezelés, hiányzó await
- API response és a UI által várt adatstruktúra nem passzolt, nem volt interface stb
- furcsa / hibás prop átadás és destructuring
- useRef használata olyan adatra, aminek a UI-ban frissülnie kellett volna
- lista renderelésnél hiányzó key
- render közbeni ref létrehozás listaelemeknél

Kb ezekre emlékszem amik csak utólag átgondolva estek le nekem, hogy mennyire gáz, hogy nem vettem észre. Interjún a 20 perc nagyon kevésnek érződött, főleg úgy, hogy közben nekem kellett irányítanom a görgetést és fejben tartani, hogy mi hol volt. Nem volt olyan sor amibe ne lett volna valami hiba én pedig teljesen túlterhelődtem, lefagytam alig tudtam valamit mondani.

Ami külön zavaró volt, hogy sokszor nem mertem azonnal kimondani, hogy "ez szerintem rossz megoldás", mert annyira furán volt megírva hogy először azt hittem lehet valami olyan React pattern vagy optimalizálási próbálkozás, amit én nem ismerek. Utólag inkább azt látom, hogy nem valami advanced megoldás volt, hanem szándékosan összekuszált, hibákkal teli review feladat.

Valós pull requestben szerintem egy ilyen kódnál nem az lenne a reális reakció, hogy soronként javítgatjuk, hanem inkább az, hogy az egészet előlről, és először tisztázni kellene az adatmodellt, az API-szerződést, a komponens felelősségeit és az egész adatfolyamot.

Nem klasszikus live coding volt, nem algoritmus, nem is egy kicsi snippet, hanem egy szándékosan rosszul megírt, több hibakategóriát tartalmazó komponens. Én eddig főleg normálisabb kódrészletek review-zására, hookokra, API kezelésre, state-re, error handling-re készültem, de ilyen "chaos review" helyzettel még nem találkoztam.