Dziękuję za możliwość sprawdzenia się :) Wartościowe, choć stresujące, doświadczenie :) Kilka tygodni po nagraniu rozmowy miałem rozmowę rekrutacyjną w software housie, przeszedłem całość pozytywnie i od grudnia zaczynam jako junior frontend dev. Informacyjnie: w mojej rekrutacji miałem mało pytań technicznych, polegała ona głównie na luźnej rozmowie o technologiach, w czym pisałem i na ile rozumiem dane biblioteki lub język ogólnie. Mam wrażenie, że umiejętności miękkie były kluczowe, bo na nieznane mi zagadnienia słyszałem, że "nie ma problemu, to się douczysz / poznasz w trakcie".
Wartość domyślna dla position to static i nie można ustalać top, left, right ani bottom. Jakby 'by default' było relative to by można było zawsze ustalać te właściowości. Jak to możliwe że taki doswiadczony programista tego nie wie?
Hej, dzięki za wyjaśnienie i komentarz ;) nie wiem/nie pamiętam takich rzeczy z prostego powodu, mianowicie pozycji static użyłem może z 2 razy w życiu. Wiem mniej więcej jak to działa, a jak będę potrzebował tego użyć to sprawdzę dokumentację. Programiści nie są maszynami, nikt normalny nie pamięta wszystkiego a ja nie specjalizuje się w CSS tylko w architekturze. Co prawda wiem jak zrobić jakieś proste rzeczy, ale jak potrzebuję coś bardziej skomplikowanego to uderzam do osoby która w tym siedzi ;) Tutaj w rozmowie pytałem o takie rzeczy, gdyż chciałem mieć ogólny ogląd mocnych i słabych stron kandydata - tak też robię podczas rozmów, które przeprowadzam. I nie służy to pokazaniu czego dana osoba nie umie, tylko wyłapaniu co jej dobrze wychodzi, co lubi robić i gdzie ma braki, tak aby było można dobrać jej odpowiedni projekt. Może się okazać, że ktoś będzie miał braki w ja, ale za to świetnie ogarnia CSS i lubi to robić. I o wiele lepiej jest taką osobę wrzucić do takiego projektu niż do takiego gdzie będzie super zaawansowana architektura, ale może to ją przytłoczyć. I w drugą stronę, są osoby takie jak ja które CSS robią z doskoku, ale za to specjalizują się w innych zagadnieniach. Aktualnie nawet frontend jest na tyle szeroki, że powoli zaczynają się robić specjalizacje ;)
Ten "useProject" hook w 1:10:00 powoduje nie potrzebne przerenderowanie. Po wyrenderowaniu sie komonentu ktory posiada "useProject", setter setProject w useEffecie spowoduje kolejne przerenderowanie sie komponentu zaraz po jego wyrenderowaniu. To samo stanie sie gdy jedno z deps sie zmieni. Wiadomo nie wpływa to znacznie na performance ale gdy buduje się jakieś API pod reacta to na takie rzeczy się patrzy. Dobrze ze trwają prace nad React Compiler ;)
Szacunek do Pawła za te pytania do Marcina, bardzo trafne i dużo info dla rekrutujących się osób. W ogóle to jesteśmy w tej samej sytuacji, też skończyłem budownictwo i bardzo fajnie, że zadałeś to pytanie jeśli chodzi o studia. Jestem inżynierem od 5 lat i tak naprawdę to myślenie techniczne to gamechanger jeśli chodzi o programowanie. No rozmowa petarda, lepszy klient Ci się Marcin nie mógł trafić :D
Hej, mogę tyle trwać, aczkolwiek dużo tu zależy od firmy - w niektórych rekrutacje mogą trwać nawet cały dzień (z tego co kojarzę to Google tak robi). Ale myślę, ze w większości jednak powinieneś się zamknąć w 2h, szczególnie na stanowisko juniorskie. Normalnie taką rozmowę skróciłbym do 1,5-2h, ale w nagraniu chciałem poruszyć więcej tematów stąd też dłuższa rozmowa. Ale zdarzało mi się przeprowadzać rozmowy i ponad 3h, dużo tutaj zależy od doświadczenia, i samej osoby, tj czasem po kilku pytaniach wiesz że ktoś coś umie i pomijasz podstawy, ale zdarzają się też osoby pomiędzy i wtedy trzeba dopytać zarówno o zagadnienia bardziej i mniej zaawansowane ;) Ogólnie to sama rekrutacja jest bardzo subiektywna, zależy na kogo trafisz, czy ta osoba Cię polubiła, do jakiej firmy aplikujesz (jakie mają procesy/wymagania).
Mega przydatny materiał - powinieneś mieć dużo więcej subów :) Kanał Twój odnalazłem dzięki Twojemu wczorajszego wystąpieniu na Meet Up'ie we Wro :) Pozdrawiam!
Jak oceniasz tego kandydata pod względem innych kandydatów entry level? Wiedzy masa, ja z 5 latami głównie na froncie jestem zaskoczony poziomem pytań. Choć widzę, że zostały dobrze zadane i prowadzone, więc dobry kandydat jakoś się uratuje nawet gdy nie wie. Nie oglądałem jeszcze całości kanału, ale jak wyglądają pytania na mida i dalej? Więcej o ogóle, architekturze, pracy w projekcie czy pytacie ich o jakieś szczegóły które użyłem 2 razy w życiu i po prostu sięgam do dokumentacji gdy nie wiem?
hej, dzieki za komentarz i ciekawe pytanie ;) to tak: 1. to byla moja pierwsza rekrutacja na entry/junior, zazyczaj przeprowadzam rekrutacje regular+. Przygotowujac musialem sie w ogole zastanowic jak sprawdzic kogos na poziomie entry stad pytania o algorytmy i czym jest programowanie. Na wyzszych pozycjach o takie rzeczy nie pytam, wychodze z zalozenia ze jak ktos pracuje w IT kilka lat to takie rzeczy wie, a nie ma tez czasu przepytac wszystkiego ;) 2. rekrutacja na mid/senior roznilaby sie poziomem pytan, tj zakres bylby podobny, ale mocniejszy nacisk na zrozumienie co i dlaczego sie dzieje. Dodatkowo procesy biznesowe, roznice miedzy waterfall a scrum/kanban, ci/cd, mocniejszy nacisk na testowanie, architektura, skalowanie projektu, bezpieczenstwo, praca w zespole, konflikty. Zazwyczaj w przypadku regular+ nie pytam tez az tyle o css, jedynie box model, aby wiedziec czy ktos ma podstawowa wiedze z css 3. czesc pytan byla z poziomu regular/senior, np te o mechanizm event loop czy to jak dzialaja hooki w react W rekrutacji nie chodzi tez, aby kandydat odpowiedzial na wszystkie pytania poprawnie, chcesz sprawdzic ogolna wiedze kandydata. Ja zadaje wiele pytan z roznych obszarow, tak aby miec ogolny poglad co kandydat umie, z czego jest mocny, gdzie ma braki. Wtedy moge w podsumowaniu to opisac i mozemy dobrac mu lepszy projekt, a takze osoba z nim pracujaca bedzie wiedziala np w czym taka osoba jest mocna, a gdzie ma braki. Jezeli nie wiesz czegos bo to sprawdzasz w dokumentacji to jest to ok, czesto ktos o to pyta to mowie ze moze sobie normalnie to sprawdzic. Chodzi o to, aby wiedzial jak tego uzywac, a nie znal dokumentacje na pamiec ;)
@@frontendarchitecture Dzięki, cieszy mnie, jako osobe dbającą o umiejętności miękkie, że jest to cenione. Po paru latach w IT, uważam, że z przeciętnym skillem technicznym i dobrą gadką można zyskać - od rozmowy, po relacje w projekcie, kontakt z klientem i radzenie sobie z problemami w pracy :)
hej różnie. Nie ma jednej reguły ile to rozmowa będzie trwała. Im większe doświadczenie tym więcej obszarów do sprawdzenia i tym dłuższa rozmowa może być. Różne rozmowy będą także wyglądały inaczej w różnych firmach, tj inaczej będzie wyglądała rekrutacja do software house (w którym pracuje), inaczej do fb czy google (tam proces ma kilka etapów), a jeszcze inaczej do startupu. Aczkolwiek na stanowisko trainee/junior myślę, że większość rozmów zamknie się w 1,5h, max 2h. Jakbym miał się zmieścić czasowo w 1,5-2h to pewnie mniej czasu spędziłbym na luźnej rozmowie (m.in dopytywaniu o analogie w budownictwie) i tłumaczeniu dlaczego. Możliwe też że przeszedłbym przez niektóre punkty bardziej pobieżnie (np w testach nie dopytywałbym o problem z użyciem tej samej zmiennej, tylko bym zadał prostsze pytanie). Natomiast sam zakres zostawiłbym ten sam, tj sprawdziłbym przynajmniej pobieżnie wiedzę z różnych obszarów, aby mieć ogólne pojęcie w których obszarach kandydat jest mocny, a w których ma braki.
Hej, jeszcze pomyślę, ale nie planowałem. Na Spotify będę wrzucał jedynie wywiady/odcinki, gdzie nie jest nic pokazywane. Tutaj jednak spora cześć rozmowy wymaga obrazu (review cody, zadania) i wydaje mi się, że byłoby sporo momentów których by się nie zrozumiało
Dziękuję za możliwość sprawdzenia się :) Wartościowe, choć stresujące, doświadczenie :) Kilka tygodni po nagraniu rozmowy miałem rozmowę rekrutacyjną w software housie, przeszedłem całość pozytywnie i od grudnia zaczynam jako junior frontend dev.
Informacyjnie: w mojej rekrutacji miałem mało pytań technicznych, polegała ona głównie na luźnej rozmowie o technologiach, w czym pisałem i na ile rozumiem dane biblioteki lub język ogólnie. Mam wrażenie, że umiejętności miękkie były kluczowe, bo na nieznane mi zagadnienia słyszałem, że "nie ma problemu, to się douczysz / poznasz w trakcie".
Gratuluje nowej pracy! Powodzenia :)
Wartość domyślna dla position to static i nie można ustalać top, left, right ani bottom. Jakby 'by default' było relative to by można było zawsze ustalać te właściowości. Jak to możliwe że taki doswiadczony programista tego nie wie?
Hej, dzięki za wyjaśnienie i komentarz ;) nie wiem/nie pamiętam takich rzeczy z prostego powodu, mianowicie pozycji static użyłem może z 2 razy w życiu. Wiem mniej więcej jak to działa, a jak będę potrzebował tego użyć to sprawdzę dokumentację. Programiści nie są maszynami, nikt normalny nie pamięta wszystkiego a ja nie specjalizuje się w CSS tylko w architekturze. Co prawda wiem jak zrobić jakieś proste rzeczy, ale jak potrzebuję coś bardziej skomplikowanego to uderzam do osoby która w tym siedzi ;)
Tutaj w rozmowie pytałem o takie rzeczy, gdyż chciałem mieć ogólny ogląd mocnych i słabych stron kandydata - tak też robię podczas rozmów, które przeprowadzam. I nie służy to pokazaniu czego dana osoba nie umie, tylko wyłapaniu co jej dobrze wychodzi, co lubi robić i gdzie ma braki, tak aby było można dobrać jej odpowiedni projekt. Może się okazać, że ktoś będzie miał braki w ja, ale za to świetnie ogarnia CSS i lubi to robić. I o wiele lepiej jest taką osobę wrzucić do takiego projektu niż do takiego gdzie będzie super zaawansowana architektura, ale może to ją przytłoczyć. I w drugą stronę, są osoby takie jak ja które CSS robią z doskoku, ale za to specjalizują się w innych zagadnieniach. Aktualnie nawet frontend jest na tyle szeroki, że powoli zaczynają się robić specjalizacje ;)
Ten "useProject" hook w 1:10:00 powoduje nie potrzebne przerenderowanie. Po wyrenderowaniu sie komonentu ktory posiada "useProject", setter setProject w useEffecie spowoduje kolejne przerenderowanie sie komponentu zaraz po jego wyrenderowaniu. To samo stanie sie gdy jedno z deps sie zmieni.
Wiadomo nie wpływa to znacznie na performance ale gdy buduje się jakieś API pod reacta to na takie rzeczy się patrzy. Dobrze ze trwają prace nad React Compiler ;)
Kozackie jest to, że chcesz najpierw kogoś poznać i zrozumieć jego mindset :D
Szacunek do Pawła za te pytania do Marcina, bardzo trafne i dużo info dla rekrutujących się osób. W ogóle to jesteśmy w tej samej sytuacji, też skończyłem budownictwo i bardzo fajnie, że zadałeś to pytanie jeśli chodzi o studia. Jestem inżynierem od 5 lat i tak naprawdę to myślenie techniczne to gamechanger jeśli chodzi o programowanie. No rozmowa petarda, lepszy klient Ci się Marcin nie mógł trafić :D
Rozmowy naprawde tyle trwają czy tylko na potrzeby odcinka aby jak najwiecej wiedzy w nim zawrzeć?
Hej, mogę tyle trwać, aczkolwiek dużo tu zależy od firmy - w niektórych rekrutacje mogą trwać nawet cały dzień (z tego co kojarzę to Google tak robi). Ale myślę, ze w większości jednak powinieneś się zamknąć w 2h, szczególnie na stanowisko juniorskie. Normalnie taką rozmowę skróciłbym do 1,5-2h, ale w nagraniu chciałem poruszyć więcej tematów stąd też dłuższa rozmowa. Ale zdarzało mi się przeprowadzać rozmowy i ponad 3h, dużo tutaj zależy od doświadczenia, i samej osoby, tj czasem po kilku pytaniach wiesz że ktoś coś umie i pomijasz podstawy, ale zdarzają się też osoby pomiędzy i wtedy trzeba dopytać zarówno o zagadnienia bardziej i mniej zaawansowane ;)
Ogólnie to sama rekrutacja jest bardzo subiektywna, zależy na kogo trafisz, czy ta osoba Cię polubiła, do jakiej firmy aplikujesz (jakie mają procesy/wymagania).
@pixel13PL ale mówisz tutaj o rozmowie technicznej czy np z liniowym/managerem? O co pytasz podczas takiej rozmowy i jak taka rozmowa wygląda?
Mega przydatny materiał - powinieneś mieć dużo więcej subów :)
Kanał Twój odnalazłem dzięki Twojemu wczorajszego wystąpieniu na Meet Up'ie we Wro :)
Pozdrawiam!
Dla nastepnikow - symbolu nie tworzy sie przez konstruktor z new, to jest operacja nielegalna natomiast jest to czywiscie wartosc prosta, a nie obiekt
Jak oceniasz tego kandydata pod względem innych kandydatów entry level?
Wiedzy masa, ja z 5 latami głównie na froncie jestem zaskoczony poziomem pytań. Choć widzę, że zostały dobrze zadane i prowadzone, więc dobry kandydat jakoś się uratuje nawet gdy nie wie.
Nie oglądałem jeszcze całości kanału, ale jak wyglądają pytania na mida i dalej? Więcej o ogóle, architekturze, pracy w projekcie czy pytacie ich o jakieś szczegóły które użyłem 2 razy w życiu i po prostu sięgam do dokumentacji gdy nie wiem?
hej, dzieki za komentarz i ciekawe pytanie ;)
to tak:
1. to byla moja pierwsza rekrutacja na entry/junior, zazyczaj przeprowadzam rekrutacje regular+. Przygotowujac musialem sie w ogole zastanowic jak sprawdzic kogos na poziomie entry stad pytania o algorytmy i czym jest programowanie. Na wyzszych pozycjach o takie rzeczy nie pytam, wychodze z zalozenia ze jak ktos pracuje w IT kilka lat to takie rzeczy wie, a nie ma tez czasu przepytac wszystkiego ;)
2. rekrutacja na mid/senior roznilaby sie poziomem pytan, tj zakres bylby podobny, ale mocniejszy nacisk na zrozumienie co i dlaczego sie dzieje. Dodatkowo procesy biznesowe, roznice miedzy waterfall a scrum/kanban, ci/cd, mocniejszy nacisk na testowanie, architektura, skalowanie projektu, bezpieczenstwo, praca w zespole, konflikty. Zazwyczaj w przypadku regular+ nie pytam tez az tyle o css, jedynie box model, aby wiedziec czy ktos ma podstawowa wiedze z css
3. czesc pytan byla z poziomu regular/senior, np te o mechanizm event loop czy to jak dzialaja hooki w react
W rekrutacji nie chodzi tez, aby kandydat odpowiedzial na wszystkie pytania poprawnie, chcesz sprawdzic ogolna wiedze kandydata. Ja zadaje wiele pytan z roznych obszarow, tak aby miec ogolny poglad co kandydat umie, z czego jest mocny, gdzie ma braki. Wtedy moge w podsumowaniu to opisac i mozemy dobrac mu lepszy projekt, a takze osoba z nim pracujaca bedzie wiedziala np w czym taka osoba jest mocna, a gdzie ma braki. Jezeli nie wiesz czegos bo to sprawdzasz w dokumentacji to jest to ok, czesto ktos o to pyta to mowie ze moze sobie normalnie to sprawdzic. Chodzi o to, aby wiedzial jak tego uzywac, a nie znal dokumentacje na pamiec ;)
@@frontendarchitecture Dzięki, cieszy mnie, jako osobe dbającą o umiejętności miękkie, że jest to cenione. Po paru latach w IT, uważam, że z przeciętnym skillem technicznym i dobrą gadką można zyskać - od rozmowy, po relacje w projekcie, kontakt z klientem i radzenie sobie z problemami w pracy :)
Paweł, Marcin ma dużo racji w uczeniu się przez budowanie własnych projektów zamiast iść w freelance na 100%.
rozmowy faktycznie potrafia az 3 godziny trwac, czy to po prostu tak polecieliscie dla contentu?
hej
różnie. Nie ma jednej reguły ile to rozmowa będzie trwała. Im większe doświadczenie tym więcej obszarów do sprawdzenia i tym dłuższa rozmowa może być. Różne rozmowy będą także wyglądały inaczej w różnych firmach, tj inaczej będzie wyglądała rekrutacja do software house (w którym pracuje), inaczej do fb czy google (tam proces ma kilka etapów), a jeszcze inaczej do startupu. Aczkolwiek na stanowisko trainee/junior myślę, że większość rozmów zamknie się w 1,5h, max 2h. Jakbym miał się zmieścić czasowo w 1,5-2h to pewnie mniej czasu spędziłbym na luźnej rozmowie (m.in dopytywaniu o analogie w budownictwie) i tłumaczeniu dlaczego. Możliwe też że przeszedłbym przez niektóre punkty bardziej pobieżnie (np w testach nie dopytywałbym o problem z użyciem tej samej zmiennej, tylko bym zadał prostsze pytanie). Natomiast sam zakres zostawiłbym ten sam, tj sprawdziłbym przynajmniej pobieżnie wiedzę z różnych obszarów, aby mieć ogólne pojęcie w których obszarach kandydat jest mocny, a w których ma braki.
czy rozmowa zostanie dodana również na spotify?
Hej, jeszcze pomyślę, ale nie planowałem. Na Spotify będę wrzucał jedynie wywiady/odcinki, gdzie nie jest nic pokazywane. Tutaj jednak spora cześć rozmowy wymaga obrazu (review cody, zadania) i wydaje mi się, że byłoby sporo momentów których by się nie zrozumiało