Live coding na rozmowie rekrutacyjnej

0

@rysiek81: jakie mechanizmy?

2
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.

0

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.

0

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.

1

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ą.

1
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:

  • było w miarę rozwiązywalne
  • dało się "naprowadzić" kandydata

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.

1

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.

2

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.

3

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.

1

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0