JUNIOR, REGULAR czy SENIOR? Rozmowa rekrutacyjna na frontend developera 

Bardzo fajny kanał i ciekawa rozmowa rekrutacyjna. Oczywiście gratuluje Adamowi odwagi i jednak odpowiadanie pod presją stresu i czasu które często pokazują że myślimy/działamy trochę mniej przemyślanie lub nie możemy czegoś wydobyć z naszego "umysłu" jeśli nie to jeszcze dla nas naturalne (wiele razy przetworzone, wyrobione w praktyce a nie tylko teoria lub spróbowanie tego raz lub 2 w ramach zabawy), chodzi tu głównie o różne problemy, wyzwania które się mogą pojawić. Jak dla mnie Adam sumarycznie to pomiędzy 2/5 a 3/5 (w skali od 1 do 5, możliwe) regular developer biorąc pod uwagę że ma podejście i szeroko otwarty wnikliwy umysł do osiągnięcia pozycji seniorskiej w raz z większym nabyciem doświadczenia i rozwiązaniem wielu powtarzalnych problemów technicznych i biznesowych. W przypadku tych technicznych problemów to pozwoli nabyć większego zrozumienia pewnych mechanizmów "w tle", jak działa JS itd. oraz różnych zagadnień stosowanych przy konkretnych problemach. Chociaż bardzo na plus wysokie umiejętności miękkie i nastawienie na klienta, dbanie o produkt co mogło sprawić wrażenie rozmowy z osobą seniorską i na pewno powoduje większą przychylność do takiej osoby. Co do wychwyconych błędów wyłapanych w trakcie rozmowy: Cześć Javascript: 1) Event Loop, tam jedynie długo błądził(zgoniłbym na stres), natomiast to co sam Marcin powiedziałeś (micro-taski, ich kolejka ma priorytet przed kolejką macro-tasków). Microtaski są zarządzanie bezpośrednio przez OS, a macro-taski nie, dlatego są wolniejsze), czyli mamy execution context (synchroniczne operacje, linijka po linijce) -> microtaski (jeśli execution context jest czysty) -> return control to event loop -> macrotaski. Tutaj lepiej wyjaśnione: www.codingninjas.com/codestudio/library/microtask-and-macrotask-in-javascript 2) Co do "this", generalnie tam jest 3 zasady bodajże: Najwyżej jest funkcja bind (która "trzyma" referencje this w miejscu którym jest tworzona), potem są funkcje call/apply do których też możemy podać obiekt do którego this będzie trzymać referencje cały czas, dopóki inny fragment kodu tego nie zmieni), potem już jest zawsze miejsce że this ma wartość aktualnego kontekstu wykonawczego(funkcji), najczęściej wskazuje na obiekt przed operatorem dostępu "." do metody. A funkcja strzałkowa, generalnie nie tworzy własnego kontekstu wykonawczego (execution context) tylko korzysta z nadrzędnego. Także jeśli nie tworzysz nowego obiektu, to this w funkcjach zawsze będą wskazywać na obecny execution context czyli (window jak w przeglądarce lub global jako w NodeJS, poza przeglądarką). Tutaj wyjaśnione: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this 3) Co do ostatniego, sam ostatnio miałem takie pytanie i się pomyliłem z "4" a nie "5". Jednak mechanizm za to jest taki że var ma zasięg funkcji(czyli globalnej funkcji, głównego kontekstu) więc inkrementacja w pętli będzie zwiększała zmienną i , cały czas tą samą co jest w pętli a let ma zasięg blokowy, więc w każdej etapie pętli będzie nowa zmienna i tworzona która będzie przekazana do setTimeout callbacku, ale nie do końca rozumiem "działania" pod spodem bo to by znaczyło przekazanie przez referencję a nie przez wartość(ale mamy typ prosty number). Co zastosowania IIFE, to powinno być: (function(i){ setTimeout(function() { console.log(i) }, i* 1000) })(i) I tylko tak ponieważ setTimeout przyjmuje referencje funkcji jako 1 parametr(callback) by to wywołać później a nie wywołanie od razu funkcji jako 1 parametr, więc nie może być setTimeout(function(){}(), i * 1000); Ponadto te przekazanie przez referencje i wywołanie funkcji, to nie prawda, w sensie przez zmianą własności obiektu, kontekst funkcji będzie zawierał "dotychczasowa" własność tego obiektu, bo interpreter nie wykonał jeszcze linijki przypisania po wywołaniu funkcji. Co do części z zadaniem/architektura to ja bym zastosował foldery modules lub domains(lepiej to jeszcze pokazuje co się pod znajduje) ale jeśli mamy shareowalny kod to będzie on na zew. i będzie importowany, to jest trudne i bardzo zależne od wielkości projektu, stopień złożoności branży, ilość encji i zależności oraz powiązań między encjami. Podział per feature jest fajny, ale na pewno jakieś logiczne i solidne granice tzw. ograniczonego kontekstu/ów danego modułu (jak często się komunikujesz się backendem o dane i jak często są potrzebne.). BFF też fajne, i fakt jak potrzeba danych z różnych mikroserwisów to lepiej jak backend to połączy i zwróci niż frontend by to robił. Co do części ReactJS hooki wpinają/pozwalają napisać nam kod który ma się wywołać w określonym cyklu życia komponentu lub w odpowiedzi na inne zdarzenie, logikę wbudowaną w ReactJS by obsługiwać komponent. Hook useContext używa mechanizmu/wzorca "Dependency Injection" by uzyskać dostęp do danych w dowolnym miejscu w kodzie bez znaczenia gdzie w hierarchii się znajduje. Co do testów to pewnie, warto testować przede wszystkim Acceptance criteria/biznesowe wymagania i scenariusze biznesowych transakcji/zdarzeń. Co do mockowania czy testowania nie mockowanego komponentu to jest chyba dość dyskusyjny temat, i oczywiście odp. brzmi zależy. Co do testów integracji, to miejsce gdzie komponenty/części systemu komunikują się ze sobą i jaki efekt/wpływ mają na siebie. Nie wiem czy dobrze zrozumiałem z dziedziczeniem, że w przypadku normalnego po utworzeniu instancji klasy dziecka(która dziedziczy z bazowej) nie mamy dostępu do zmian wprowadzony później w klasie bazowej ? Co do Javascript part2 czyli hoistingu, to bardziej jest tak że Javascript runtime ma 2 etapy, pierwsze fazy tworzenia(statyczna/kompilowania) gdzie javascript zbiera tylko deklaracje funkcji i zmienne var i umieszcza w pamięci, żeby potem 2 etapie (wykonywania/interpretowania) były te zmienne lub deklaracje funkcji już dostępne(najlepsze rozw. dla deklaracji funkcji, bo one mają body przechowywane pamięci wraz ze swoją nazwa a var tak nie ma, przypisanie w etapie wykonawczym dopiero). Potocznie jednak mówi się "że wynosi" się var i deklaracje funkcji na początku w obecnej funkcji. Co do css, to z tym centrowaniem to chodziło może o display: inline-block lub table-cell(wewnątrz display: table) i vertical align: middle, by go wycentrować w innym divie ?, a może coś z display: table ? Co do pozycji absolute to wtedy najbliższy możliwy element w drzewku html z pozycją relative. Co do gitflow to chyba jeszcze warto dodać że feature remote branche muszę istnieć by dopiero z nich robić merge do developa a także pewnie cherry-pick do developa jeśli coś poprawimy w release branch z hotfixami, mogę się mylić. Mimo wszystko Adam jak na ponad 2 lata doświadczenia to esktra, ja mam obecnie ponad 6,5 roku ale po 2 latach myślę że nie byłem tak "ogarnięty" biznesowo i projektowo głównie skupiałem się na technologii. Dzięki Marcin za tak świetną dawkę wiedzy i rozmowę a nie "odpytywanie i wytykanie".

Mega odcinek! Ale jakbym miał takiego seniora w teamie to trochę był bym zdziwiony

Przede wszystkim dzięki za materiał! Mam jednak małą uwagę. Porównanie Redux do React Query jest nieco niefortunne i może być mylące/zniechęcające dla nowych developerów (2:03:20). RTK Query to jest oficjalne narzędzie Reduxa, do realizowania tych samych celów co React Query. Niestety muszę też zaprotestować przy stwierdzeniu, że "przy drobnej zmianie przerenderuje mi się cała aplikacja". W kontekście Reduxa nie jest to prawda, a tak to zabrzmiało.

W setTimeout pierwszy parametr musi być callbackiem, IIFE zwraca undefined, więc to chyba nie zadziała?

Mam pytanie co do contextu. Tworze typowa stronke pokewiki gdzie wyswietlam karty pokemonow mam tam opcje aby dodac itemek do ulubionych mam tez ododzielna podstrone gdzie wyswietlam liste uluibioonych itemek i czy powinienem dodac tablice favorites do contextu? Zeby doprecyzowac mam hook useFavorites ktory zajmuje sie dodawaniem/usuwaniem itemkow z localStorage. samej tablicy z ulubionymi itemkami zdaje sie ze musze uzywac prawie wszedzie poniewaz karty ktore sa w ulubionych musza byc oznaczone ze naleza do ulubionych. Drugie pytanie co do contextu czy taki hook jak useViewport powinien sie w nim znajdowac?

Koleś nie odpowiada na pytania ,nie potrafi w prosty , czyli najskuteczniejszy sposób przekazać informacji . Komunikacja z taką osobą byłaby baaaardzo trudna

Super seria, fajnie byłoby jakby ta seria była regularnie dodawana, np. raz na dwa tygodnie, nawet lista pytań rekrutacyjnych raz na 2 tyg. :)

Z tym seniorem to trochę przesada. Raczej mocny junior. To co najbardziej zapadło to sposób odpowiadania, tak jak przedmówcy pisali - opowiada dookoła, po czym stawia pytanie na poparcie swojej okrężnej odpowiedzi. W pierwszym screeningu CV brakowało pytań o to dlaczego tak często zmieniał pracę, plus ma dziwne okresy pracy zwłaszcza w pierwszych dwóch firmach, które się zazębiają datowo. Niby fajnie że myśli w kontekście biznesu jednak chyba j est to normalna kwestia w pracy programisty, gdzie mamy jakiegoś klienta który ma oczekiwania. Zmiany które były co kilka dni w pierwszej pracy są dla mnie informacja że po prostu nikt nie potrafił zebrać wymagań, a nie że się coś zmienia tak drastycznie se co tydzień mamy rewrite ficzerow.

A ja napiszę tak : uczę sie od dluższego czasu frontendu i aktualnie przerabiam reacta, z lepszym a czasem gorszym skutkiem. Cel jest prosty : własny duży projekt i tutaj, ew. Jeśli by nie wyszło (rynek nie zaakceptuje etc) to dobry projekt do portfolio. No i tak bylo do dzis, az nie odpalilem tego wideo 😅🙄 . Jak dla mnie macie duzo wiedzy, której mi brak i aż to trochę przeraża ile rzeczy trzeba znac, umieć i pamiętać.

Dopiero przesłuchałem niecałe 2h, ale już nasuwa mi się wniosek, że obecne wymagania na staż/juniora są kosmicznie wysokie. Nie mam jeszcze żadnego doświadczenia, a jestem w stanie dyskutować na usłyszane już zagadnienia. Mam stack React ,TS, Next i różne libki cssowe, pracy będę szukał dopiero za pół roku, bo nadal nie czuję się gotowy i piszę solidne portfolio. Mimo wszystko impostor syndrom ciśnie mnie na maxa albo jestem skażony narzekaniem na wszystkich grupach jak to ciężko o pracę.

gratuluję Adamowi odwagi, ale do osobiście uważam, że na seniora za mało :P

To centrowanie w pionie - to był trick z display: table i table-cell na dzieci . Wtedy dzialal vertical-align:middle na divy ;d Troche z czapy dzisiaj pytanie, ale rozumiem ze daje swiadomosc czy ktos zna CSS sprzed flexboxa gdzie CSS to byla rzecz na ktorej trzeba bylo sie chwile zastanowic :D

Po tej rozmowie nabrałem dużego szacunku dla osób rekrutujących. Nie umiałbym zachować powagi podczas takiej rozmowy gdy padają różnego typu absurdy, albo po prostu lanie wody. Co z perspektywy rekrutowanego jest oczywiste i zrozumiałe - mówisz co wiesz / to co ci przychodzi do głowy - ale jednak znając odpowiedź ciężko się powstrzymać przed facepalmem czy nawet uśmieszkiem :P

A jak dla mnie, to gość się nasłuchał kilku doświadczonych gości i powtarza bez zrozumienia. Podzielam zdanie poprzedników mocny junior z aspiracjami na mida jak uzupełni podstawową wiedzę. Imho przy kodowaniu czegoś by wyszło. Teraz już wiem dlaczego nie szukają nigdzie juniorów - nagle każdy jest seniorem. WOW

"Drużyna była rozbita" i "PM mnie obsługiwał" , zapamiętam na długo

Może ja na seniora powinienem pójść jak Adam jest "MID"

Ten gościu jest mentorem? on najwżniejszych rzeczy z JSa nie ogarnia nawet :D