Jak wygląda rozmowa o pracę front-end?

Cześć. Robię w c#, głównie backend, w ramach rozwoju chciałbym się w wolnym czasie zacząć uczyć reacta by mieć większe pole manewru na rynku pracy. Rozmowy techniczne z backendu kojarzę, teoria / jakbyś coś zaprogramował / zadanko w stylu "jaki otrzymamy wynik" / czy coś tam o technologiach, frameworkach.

Zastanawiam się, jak w takim razie wygląda rozmowa na front-end? Czy ocenia się kandydatów po ich portfolio i typuje kto ma postawioną lepszą stronkę na github porównując UI? Pyta się o teorie? Bo jak tu niby pytać - ktoś mi zada pytanie "jakby pan napisał stronę logowania" - i mam recytować z pamięci "div / div / potem h1, potem logo svg, potem znowu div i w środku label" - bezsensu :D
Czy w takim razie na front-end też pytają z teorii, np. jak działa jakaś funkcja w react, jakby pan pobrał dane i omówić fetch, albo gdzie można trzymać token, że np. w local storage albo cookies? Bardzo mnie to ciekawi, bo będę się uczył reacta od 0, fajnie umieć coś napisać, ale jak to potem przenieść na rozmowę kwalifikacyjną?

Raczej te drugie pytania, które zadałeś.
Jak rekrutowałem się na fullstacka z angularem rok temu, to z angulara pytania o framework: opisać change detection, observable hot vs cold, pipy, cykle życia komponentów, zarządzanie stanem aplikacji. Z frontu ogólne pytania o responsywność, wcag.
Jak poszukasz w internecie top 50 interview questions na reacta i na frontend, to styknie.

JunDev napisał(a):

Zastanawiam się, jak w takim razie wygląda rozmowa na front-end?

Często pytają o asynchroniczność w JavaScript (czy to teoretycznie, czy zadają pytania wymagające wiedzy o asynchroniczności np. co się uruchomi po kolei - console.log, Promise.resolve().then, setTimeout i dlaczego).

No i często jest live coding (zwykle masz linka do jakiejś piaskownicy online, wchodzisz tam i piszesz, szerujesz okno).

np. jak działa jakaś funkcja w react, jakby pan pobrał dane i omówić fetch, albo gdzie można trzymać token, że np. w local storage albo cookies?

Na przykład. Albo gdzie byś trzymał taki i taki stan itp. Z jakimi bibliotekami pomocniczymi miałeś do czynienia itp. Bardziej koncepcyjnie.

Ale też może być live coding i masz np. zmodyfikować jakiś komponent, żeby coś robił.

Też mogą pytać o hooki i inne szczegółowe rzeczy z Reacta.

LukeJL napisał(a):

Często pytają o asynchroniczność w JavaScript (czy to teoretycznie, czy zadają pytania wymagające wiedzy o asynchroniczności np. co się uruchomi po kolei - console.log, Promise.resolve().then, setTimeout i dlaczego).

Do czego to się może przydać w pisaniu aplikacji w react/angular/svelte? Jestem zaznajomiony z zadaniami na micro/macro w wersji kolejność wypisywanych logów, ale nie potrafię sobie wymyślić przykładu kiedy to się przydaje w pracy.

Oskarlesk napisał(a):

LukeJL napisał(a):

Często pytają o asynchroniczność w JavaScript (czy to teoretycznie, czy zadają pytania wymagające wiedzy o asynchroniczności np. co się uruchomi po kolei - console.log, Promise.resolve().then, setTimeout i dlaczego).

Do czego to się może przydać w pisaniu aplikacji w react/angular/svelte? Jestem zaznajomiony z zadaniami na micro/macro w wersji kolejność wypisywanych logów, ale nie potrafię sobie wymyślić przykładu kiedy to się przydaje w pracy.

No np. jak ktoś nie wie, jak działają mikrotaski, to się zdziwi, kiedy mu program wpadnie w wieczną pętlę mikrotasków https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide#microtasks ). A tak może się stać, jak piszesz kod asynchroniczny (którego pisze się pełno w apkach reactowych akurat). Pisząc taki kod powinno się mieć pojęcie, jak to działa. Bo o ile można coś przekopiować i napisać funkcję asynchroniczną, która działa, to jednak wystarczy, że kod nie będzie działać tak, jak chcemy, i nie będziemy w stanie go zdebugować czy zmodyfikować.

Plus ludzie, którzy nie rozumieją tego czy innego aspektu asynchroniczności mają tendencję mylenia kodu synchronicznego z asynchronicznym, czyli chcą używać czegoś, co jeszcze nie jest zainicjalizowane itp. to wcześniej czy później skończy się bugami.

Inna rzecz, że to typowe pytanie rekrutacyjne (bo już na iluś rekrutacjach się z tym spotkałem), które bada tylko pewien aspekt asynchroniczności + ktoś może wykuć odpowiedź. Więc też nie wiem, na ile to pytanie skutecznie filtruje ludzi. No ale o asynchroniczności ogólnie lubią pytać. Tutaj też można się wkopać. Ja za dużo staram się powiedzieć o tym i zaczynam omawiać różne rodzaje asynchroniczności w JS i historię, jak to wchodziło do języka. A czasem ktoś oczekuje zwięzłej wypowiedzi. Na jednej rekrutacji mnie przez to odrzucili, bo uznali, że mam trudności z klarownym wyjaśnianiem zagadnień technicznych. "Klarownym" czyli zakładam, że krótko i dokonując uproszczeń. No ale myślę, że mógłbym książkę o tym napisać, to tam bym mógł to opisać dłużej, a nie na rekrutacjach.

Na rozmowie na front-end mogą pytać o różne rzeczy, zwłaszcza związane z asynchronicznością w JavaScript, ale to już wyżej wyjaśnili inni. Przygotuj się na pytania o Promisy, async/await i różnice między nimi a callbackami. Mogą też być pytania o obsługę błędów w kodzie asynchronicznym albo jak działa event loop w JS .

Warto wiedzieć o takich rzeczach jak ARIA i czytniki ekranu, bo to coraz częściej poruszany temat. Oprócz tego, CSS vs JS w animacjach – np. które są bardziej wydajne i kiedy lepiej użyć którego rozwiązania. CORS to też częsty temat – wiedza o tym, jakie problemy rozwiązuje, może się przydać .

Powodzenia Michał