Witam,
Co sądzicie o live codingu na rozmowie rekrutacyjnej? Ostatnio cos takiego mialem na rozmowie i miałem coś zakodowac wykorzystujac pewne mechanizmy, ktorych wczesniej nigdy nie uzywalem przez co bardzo kiepsko mi to poszlo. Sama roznowa techniczna poszla mi dobrze, natomiast ten live coding mocno mi ja zepsuł. Mam wrazenie, ze tak jednym zadaniem zaprzepaścilem wtedy mozliwosc pracy w danej firmie. Nie przyjeli mnie tam.
@rysiek81: Skoro miałeś wykazać się znajomością tych mechanizmów, których nie znałeś to co za różnica czy Cię o nie zapytają czy kodujesz? I dla mnie takie rzeczy to tylko na własnym kompie albo na kartce mają sens.
Uważam, że to jeden z lepszych sposób sprawdzania kandydatów.
Nie przejmuj się.
Rozmowa kwalifikacyjna w IT dzisiaj to błazenada.
Change my mind.
prostokąty i cylindry już jak najbardziej. Czego nie rozumiesz?
Dhuum napisał(a):
Nie przejmuj się.
Rozmowa kwalifikacyjna w IT dzisiaj to błazenada.
Change my mind.
jakim typem zwierzęcia jesteś - źleprostokąty i cylindry - źleTak czytając wypowiedzi różnych ludzi na forum - praktycznie każda forma rekrutacji jest zła. Teraz okazuje się, że live coding też. Jaka forma rozmowy kwalifikacyjnej NIE jest zatem błazenadą?
kropka - kreska - kropka - kreska - pusta strzałka vs kreska - długa kreska - kreska - kreska - długa kreska - pełna strzałka z kółkiem albo narysować prostokąty, cylindry, strzałki i podpisać o co chodzi.
Wolę kodować na tablicy niż live coding, bo na tablicy łatwiej być kozakiem i robić skróty myślowe, a w live codingu to musi być działający program, więc od razu widać, jak się jest słabym xD
Co sądzę? Ale ogólnie czy o konkretnych modelach jej prowadzenia?
Zależy co się koduje.
Zależy gdzie.
Zależy czego chcą.
Jak rekrutacja do czegoś "okołowebdev" i oczekują coś pokroju autoryzacji jakimś tokenem i połączenia z bazą danych którą pierwszy raz na oczy widzisz,ale masz dostęp do dokumentacji i gdzie oczekują że obsłużysz błędy to co innego niż coś kalibru idziesz na rozmowę do firmy piszącej renderery na zamówienie i każą zakodować na żywo raytracer od zera z palca bez dostępu do jakiejkolwiek dokumentacji czy bibliotek bo oczekują że pisałeś tego typu rzeczy tyle razy, że wzory na rzutowanie wektora na wektor i podobne zabawy z algebry recytujesz obudzony w środku nocy a strukturę plików png pamiętasz lepiej niż swój pesel. Graf sceny moż być zadany z góry. Może być oczekiwana dyskusja o tym jaką strukturę najlepiej wykorzystać do grafu.I tak dalej i tak dalej.
Satanistyczny Awatar napisał(a):
idziesz na rozmowę do firmy piszącej renderery na zamówienie i każą zakodować na żywo raytracer od zera z palca bez dostępu do jakiejkolwiek dokumentacji czy bibliotek
Są takie firmy? Myślałem, że takie coś to zabawa dla hobbystów ;)
Tak czytając wypowiedzi różnych ludzi na forum - praktycznie każda forma rekrutacji jest zła. Teraz okazuje się, że live coding też. Jaka forma rozmowy kwalifikacyjnej NIE jest zatem błazenadą?
nie no, nie odkrywajmy świata na nowo xd
oczywiście że każda z form rekrutacji jest zła, ale dla danych osób (wątpię że na każdą z tych form narzeka ta sama osoba)
Kto będzie bardziej skłonny narzekać na długie zadania - singiel czy ktoś mający dwójkę dzieci?
i tak samo do każdego innego
Lubię rozwiązywanie zadań na tablicy (w postaci pseudokodu), które sprawdzają myślenie. Nie lubię zadań, które muszą się od razu kompilować (jeszcze jak ktoś chce, aby pisać w google docsach, a on to sobie skopiuje do IDE i sprawdzi czy się skompiluje). Takie zadania imo nie sprawdzają nic sensownego. W codziennej pracy nie muszę pamiętać o średniku, bo IDE mi przypomni więc nie zawracam sobie glowy bzdetami - no chyba, że robi się jakieś zmiany w vimie na serwerze to wtedy faktycznie się to przydaje, ale to scenariusz dość rzadki. :P
Trochę rozmów przeszedłem i najbardziej spodobała mi się forma zadań w stylu: Mamy problem X - jak byś go rozwiązał? Przykładowo: w dzialającej aplikacji, której nikt nie ruszał od roku, klienci zaczęli się skarżyć, że bardzo długo czekaja na odpowiedź. Co byś zrobił, aby zdiagnozować problem? Sprawdzenie logów, połączenia z serwerami, sprawdzenie puli wątków na bazie itd.
Albo zadania typowo około architektury - Zaproponuj obsłużenie komunikacji w momencie gdy [tutaj wpisz różne wymagania tej komunikacji]
innym, w tym tym którzy nie lubią Vim
Po tym jak zobaczyłem trzech wymiataczy z rzędu którzy nie potrafili zrobić fizz buzza zostałem 100% fanem live codingu.
this albo domknięć w JS i stąd ten problem, że jak ktoś nie ogarnia podstaw języka to i framework nie pomoże.
Za często nie prowadzę rozmów rekrutacyjnych. Ale ostatnio właśnie ten peer coding "ocalił" pewnego juniora bo jeśli chodzi o teorię chłopak leżał, ale kodowanie udowodnił mi, że potrafi myśleć a to najważniejsze dzięki czemu przyjęto go na okres próbny a potem normalnie i chłopak sobie radzi. Wg. mnie musisz zwyczajnie poćwiczyć.
Wielu programistów jest szybkich w łojeniu kandydatów którzy nie radzą sobie z zadaniami na rozmowie, ale druga strona medalu jest taka że mało który programista jest w stanie wymyślić zadanie które ma jakiś związek z realnymi zadaniami w pracy, zamiast czegoś co związku nie ma i tak na prawdę nic nie sprawdza. Zresztą mam ogólne wrażenie że ze względu na przesycenie rynku kandydatami rozmowy rekrutacyjne w IT zmieniły się w festiwal spierd**enia, podobnie jak na początku lat 90 w innych zawodach, tak że nie chodzi już o to żeby przede wszystkim znaleźć kompetentnego pracownika, tylko uwalić nieperfekcyjnego kandydata i potem kręcić z tego bekę na kawie.
Dopóki zadanie jest proste sprawdzajace czy kandydat umie logicznie myśleć to nie mam nic przeciwko.
Jeśli jednak rekruter wyskakuje z zadaniem zaimplementowania jakiegoś algorytmu Pierdziochowa-Srakowicza to kończę rozmowę i małpy do cyrku szukają gdzie indziej. Nie zamierzam się uczyć tysiąca algorytmów na pamięć, bo zgooglanie ich zajmuje łącznie 30 sekund z implementacją.w docelowym języku
w sumie spoko, taka rozmowa bardzo szybko wybije osoby niby z kilkuletnim doswiadczeniem ale kompletnie bez umiejetnosci bo przesiedzieli jakims cudem pare lat w jednej firmie nie robiac zbyt wiele
Mam nadzieje, że jak ktos aplikuje na kierownika budowy to mu każą budować dom z klocków lego zanim zacznie robote
Według mnie większość sposobów rekrutacji opierające rozwiązywania krótkich zadań/algorytmów czy nawet ten livecoding są tyle warte co rekrutacja żeby zadowolić wytyczne dotyczące diversity.
Jest masa stron, płatnych kursów pokroju leetcode, geeksforgeeks, które za gruby hajs uczą hindusów jak rozwiązywać zadania algorytmiczne po to tylko zeby dostać sie do faang'a a później wyrwać vise pracowniczą, i co później z tego wychodzi ? Masz "chłopa" z indii pracującego w facebooku, który jest w trakcie zmiany płci, a z programowaniem ma tyle wspolnego, że jest w stanie zbalansować BST stojąc na głowie. A później powstaje taki nowy messenger/facebook który działa jak działa...
Co do samego live codingu, każdy człowiek reaguje inaczej. Znam ludzi co są dużo bardziej efektywni jak ktoś im patrzy na ręce, inni z kolei się denerwują i wszystko im się sypie.
Patologią w IT jest to, że żeby dostać pracę nie jest nie wystarczy, że sie na tym znasz i jesteś w tym dobry ale też musisz być dobry w przechodzeniu rozmów rekrutacyjnych. Nie bez powodu powstaly ksiązki typu "cracking coding interview" i wiele innych. Sama autorka o tym pisze.
Potencjalny kandydat może być przeciętnym programistą albo w ogole ledwo co programować, ale bedąc dobrym w algosach i przechodzeniu rozmów rekrutacyjnych jest w stanie dorwać robote za 100k$ +. Co jak na Polskie warunki dosyć dużo.
Miałem okazję pracować z i supportować kod ludzi, których głownym atutem w życiu było to, że pracowali w google lub facebooku.
Byli dobrzy w pisaniu algorytmów na przeszukanie grafów albo rozwiązywanie jakiś karkołonych przypadków z dziedziczenia tak jak @Shalom wspomniał i na tym ich zajebistość sie kończyła.
I później przychodzi taki i ci pisze command patter do czegoś co można zrobic 2-if'ami bo on wielki ex-google engineer. I wiele innych kwiatków.
Z innym typem ludzi, z którymi miałem przyjemność pracować to chłop, który nie ma pojecia jak działa merge sort, albo dijstra, ale był topką w tym co robił, super przyjemnie sie z nim pracowało (nie to co z buffonami z faanga) i mega dużo można było się nauczyć.
Rzeczywistość zweryfikowała, ex-faang-cymbały miały wjazd do firm uznawanych za topowe w niektórych kręgach (typu Qulatrics, Alledrogo, Codewise, Revolut itp).
Z kolei ci kumaci mieli problem bo na twarz dostawali od razu pytanie o drzewo binarne, albo co sie wyświetli pierwsze jeżeli A extends B implements C..
Nie miałem jeszcze live codingu, ale rozmowy z HR są dobijające- pytania typu jak się czujesz jak coś robisz...
Algorytmy to tylko pewna działka i najwyraźniej kogoś od nich szukają, przynajmniej takie odniosłem wrażenie w jednej firmie, gdzie dostałem z nich zadanie do rozwiązania na za kilka dni. (Szkoda, że nie odbierali emaili ani telefonów - był wtedy pogrzeb mojego dziadka)
Algorytmy? Obecnie bym zaczynał od sprawdzenia czy kandydat po dostaniu do ręki dokumentacji funkcji umie ją wykorzystać i czy koduje obsługę błędów. Piszę to po doświadczeniu jako admin z dziesiątkami jak nie setkami "webdeveloperów" którzy uważają sprawdzenie wartości zwracanej za niepotrzebny wysiłek a wyjątki łapią na zasadzie "catch any, do nothing", a potem ci w razie wykrzaczenia się kodu piszą do supportu, że serwery są źle skonfigurowane bo im kod się nie wykrzacza na ich lokalnych maszynach. Oczywiście dzięki brakowi obsługi błędów we własnym kodzie nie są w stanie przedstawić dowodów na poparcie tezy o błędnej konfiguracji, nie mówiąc już o wiedzy co konkretnie za błąd ma miejsce. No ale "oni wiedzą bo pracują już X lat".
Jeśli praca wymaga żonglowania algorytmami i strukturami danych - pytanie z nich ma sens. Jeśli nie ma takiego typu rzeczy w realnie prowadzonych projektach nawet na poziomie biernego czytania kodu - to mija się z celem. Tutaj jednak bym się skupił na składaniu ze sobą kilku różnych struktur danych i algorytmów niż na weryfikowaniu czy pamięta kandydat jak się balansowało drzewa czerwono-czarne. Skupił na zasadzie czy kandydat umie uzasadnić wybór takich a takich rozwiązań. Nie zakładając z góry klucza odpowiedzi, gdzie istnieje tylko jedna słuszna metoda rozwiązania. Czy live coding jednak by to miał testować to już uważam za dyskusyjną kwestię.
Z tym, że jeśli ktoś nie ogarnia takich podstaw jak co to jest tablica hashująca czy hasło graf w sensie struktur danych mu nic nie mówi to coś jest zdecydowanie nie tak. W dowolnej formule sprawdzania kandydata.
Inna sprawa to jak sensownie sprawdzić przejrzystość kodu czy zdolność wyszukiwania błędów i ich naprawy tak by mieć jakiś wartościowy obraz w realistycznej sytuacji bo to już materiał na minimum kilkaset linii kodu. A tego już niekoniecznie da się spawdzić poniżej bitych kilku godzin (gdy pracowałem w embedded trafiała się masa dość głupich błędów ale nawet seniorzy w skrajnych przypadkach mogli się szczaić o co chodzi dopiero po ładnych paru tygodniach drążenia tematu i mówię tu o ludziach, którzy spokojnie mogli ci pisać od zera funkcjonalne kernele na zlecenie), a tyle raczej nikt na live coding nie poświęca.
Shalom napisał(a):
@rysiek81 hmm no ale jak to sobie wyobrażasz? Bo skoro nie umiałeś na rozmowie, to w pracy też byś nie umiał. Dostajesz podobnego taska i co wtedy? ;)
Wg mnie taki live coding to średnia metoda rekrutacyjna. Co innego jest zrobić jakieś zadanie w pracy, a co innego na takim live codingu. W pracy siedzisz sobie spokojnie, pijesz kawkę, pracujesz na skonfigurowanym pod siebie sprzęcie i możesz sobie spokojnie rozwiązać problem, który prawdopodobnie został parę dni wcześniej przegadany na jakimś backlog refinemencie lub planowaniu i wiesz, co co tam chodzi.
Raz dostałem zadanie na rekrutacji na zasadzie masz tu laptopa, jakiś edytor w przeglądarce i ścianę tekstu z opisem zadania bez słowa wyjaśnienia ze strony rekruterów. No i miałem 30 minut na analizę i zrozumienie tego, o co im tam chodzi, rozwiązanie zadania, zakodowanie i sprawdzenie, czy działa poprawnie i w tym samym czasie 3 osoby patrzyły mi na ręce. Była to dość stresująca sytuacja i normalnie nie pracuje się w takich warunkach. Co ciekawe, rozwiązałem to zadanie poprawnie, ale nie pasowało im, że rozwiązałem je inaczej, niż oni by to zrobili, a niestety w tak krótkim czasie nie ma możliwości dopracowania swojego rozwiązania.
Tak, czy inaczej, jeśli chcemy się dostać do firmy, która organizuje coś takiego podczas rekrutacji, to niestety musimy się do tego dopasować, czy nam się to podoba, czy nie i grać w tę "grę". Można się tego nauczyć. Na szczęście nie każda firma próbuje robić rekrutację w stylu google.
Live coding - o ile przeprowadzony poprawnie - jest IMO najlepszą formą weryfikacji umiejętności. Warto na wstępie poprosić kandydata, żeby opowiadał o tym co robi - wtedy bardzo fajnie wychodzi czy rozumie co robi oraz czy jest w stanie zrozumiale komunikować co się dzieje.
Live coding to tylko dla jakichś prostych zadań typu fizzbuzz albo wyszukiwanie liczb parzystych w tablicy. Kiedyś dodałem zadanie "zaimplementuj swój malloc() i free()`", oczywiście nie zrobiłem tego, IMO to jest za trudne zadanie. Są też kwestie praktyczne - mój edytor, Emacs, pisze ze mnie dużo kodu, podkreśla errory, automatycznie robi wcięcia, w dowolnej chwili mogę ten kod skompilować i zobaczyć czy są warningi albo czy się uruchamia, ma inne keybindingi niż browserowe edytorki np. Control-w usuwa cały poprzedni wyraz (tak jak defaultowo w Bash) a w Firefox to zamyka taba.
Powiem tak, że chyba najlepiej to rokującemu kandydatowi dać po prostu 3 miesiące okresu próbnego :) Na rozmowie kwalifikacyjnej można tylko odsiać ludzi, którzy naprawdę nie potrafią nic, a zostawić tych, którzy rokują.
Raz rekrutowałem gościa, który był świetny z teorii, w teście (manager wymusił programowanie na kartce, bo co to za herezja live coding), ale kompletnie sobie w robocie nie radził. W konsekwencji jego pracę w 2 tygodnie byłem w stanie zrobić w 30 minut po jego roku pracy.
Osobiście ostatnio mam dość oryginalny sposób na przechodzenie rozmów kwalifikacyjnych. W sumie to opowiadam o swoich błędach, rzeczach, które chciałem wdrożyć, elementach, które bym poprawił. Dlaczego używałem technologii X i dlaczego ma ona swoje wady. Po takiej rozmowie mam poczucie, że opowiadam bardziej o swoich przegranych niż sukcesach, ale chyba działa bo ostatnią pracę dostałem w jakimś rekordowym czasie po 33 minutach rozmowy 2 godziny później dostałem telefon z ofertą.
wiciu napisał(a):
Wg mnie taki live coding to średnia metoda rekrutacyjna. Co innego jest zrobić jakieś zadanie w pracy, a co innego na takim live codingu. W pracy siedzisz sobie spokojnie, pijesz kawkę, pracujesz na skonfigurowanym pod siebie sprzęcie i możesz sobie spokojnie rozwiązać problem, który prawdopodobnie został parę dni wcześniej przegadany na jakimś backlog refinemencie lub planowaniu i wiesz, co co tam chodzi.
Właśnie o to chodzi, że trzeba dobrać zadanie tak, żeby:
Dobry live coding nie wygląda tak, że dostajesz jakiś duży problem do rozwiązania w dwie godziny, a osoby rekrutujące siedzą przez ten czas, milczą i notują co robisz źle. Musi być komunikacja - trzeba spytać kandydata, jak coś by rozwiązał, jeśli gdzieś się machnie to trzeba wskazać, że jednak gdzieś tam jest problem żeby mógł się poprawić itp. itd. To nie jest łatwa sprawa dobrze to ogarnąć - ale jeśli się to zrobi dobrze to pay-off jest bardzo duży.
Ogólnie jak ktos ma sprawdzić cie na szybko to jest to trudne, wszystko ma swoje minusy i plusy, inaczej się niestety nie da.
Powiedziałbym raczej, ze prócz umiejętności i doświadczenia ważne jest szczescie.
Dobry git i to czy się polubisz z gościem, czasem cos nie pyka po prostu.
Edit: tak pomyślałem, to podczas live codingu jest ważne by rozmawiać, potraktuj to może jako formę dalszej rozmowy tylko, ze teraz patrzycie w kod.
To nie polega na cichym pisaniu z pełnymi gaciami, a właśnie na głośnym myśleniu.
Np : Tutaj można zrobić walidacje tego co dostajemy za pomocą monady, ale skoro jest juz w klasie metoda to mogę z niej skorzystać..
Tutaj zależy jaki cel bizenesowy..
Tu warto pamiętać o tym, ze w transakcji mamy dirty checking i encja jest już w cyklu persist, wiec nie trzeba save...
Tak wiec kod to dalsza rozmowa, trzeba się nie bać, mówić pomysły. Nawet nie rozwiązując czegoś idealnie można być bardzo dobrze odebranym.
Jednym z lepszych live codingów które miałem to była rozmowa gdzie dostałem jakiś wycinek aplikacji i miałem zrobić code review + zaklepać jakąś małą rzecz. Generalnie w kodzie było sporo błędów różnego rodzaju (od niespójnego formatowania przez jakieś nieobsłużone przypadki, N+1, jakieś bezsensowne calle do zewnętrznych API po w ogóle dziwną architekturę). 90% czasu zajęło gadanie o tym co i jak można poprawić, jak to testować, co zacznie się pierniczyć pierwsze jak się to zdeployuje, a faktyczne klepanie kodu to tak naprawdę był refactor żeby obsłużyć nowy (słabo opisany, trzeba było się dopytywać) scenariusz walidacji. Rozmowa trwała ponad 2 godziny ale najbardziej odzwierciedlała codzienną pracę z tych wszystkich na których byłem.
Jak do tej pory tylko raz brałem udział w live coding. Ciekawe doświadczenie, ale raczej źle mi się w ten sposób kodowało. W moim przypadku zadania były dość proste - raczej taki przyczynek do rozmowy. Bardziej niż na rozwiązaniu zadania skupiałem się na walce z przeglądarką - zero kolorowania składni, wcięć, podpowiadania, kolorowania błędów, wyuczonych skrótów klawiaturowych, podpowiadania kolejności parametrów. Po wszystkim zauważyłem, że jedno z zadań mogłem rozwiązać znacznie lepiej, niż to zrobiłem bo dużo pary w gwizdek szlo aby chociaż dojść do tego, że kod działa bez błędów. Pracę dostałem, oceny niby bardzo wysokie ze względu na zachowanie komunikatywności w trakcie rozwiązywania zadań i tłumaczenia czemu co robię etc.
Myślę, że nie ma idealnego sposobu na prowadzenie rekrutacji. Po prostu każdemu co innego podejdzie. Kiedyś miałem zadanie zaprojektowania i zakodowania całego systemu w 4h. Chodziło głównie o architekturę i POC. Po 1h walki z edytorem, którego nie znałem i konfiguracją środowiska, która też była trochę nienaturalna stwierdziłem, że to nie ma sensu i wyszedłem. Ktoś kto nie przywiązuje się za bardzo do środowiska i nawet w Vimie klepnie większy kawałek kodu pewnie by sobie z tym poradził - mi już ciśnienie skaczę jak siadam na IDE, które ma domyślnie skróty klawiaturowe zamiast moich.
Najlepiej wypadam na rekrutacjach, gdzie jest rozmowa techniczna w dużej mierze dlatego, że potrafię bronić swoich poglądów nie idąc przy tym w konflikt z kimś kto uważa inaczej (nie dotyczy dyskusji w internecie ;-) ). Zazwyczaj łatwo łapię kontakt z ludźmi i większość takich rekrutacji przekształca się w luźną rozmowę przy kawie i bardziej wymianę opinii niż "egzamin".
Każdy typ rekrutacji ma tak, że promuje pewne umiejętności, a zmniejsza znaczenie innych, wiec różnym osobom będą podchodziły inne typy rekrutacji.
Zależy od zadania, live coding w słabych firmach to klepanie w frameworkach i sprawdzanie, czy małpa umie into framework. Brałem udział w 2 rekrutacjach z live codingiem w "lepszych" firmach, jedna firma sprawdzała moje podejście z narzędziem, które nie używałem od bardzo długiego czasu, a druga miała zadanie w plain javie - oczywiście wszystko miało być przetestowane. Doświadczenie bardzo fajne, bo jak nie masz abstrakcji frameworków, to okazuje się, że jednak napisanie kodu, który da się łatwo testować oraz jest czytelny, to zadanie trudniejsze niż się większości "programistów" wydaje.
transactional z metody która miała transactional, jak się to propaguje i co się stanie jak poleci wyjątek ;) o kwiatkach z attached/detached object w JPA to nawet nie będę pisać :D
Shalom