Live coding na rozmowie rekrutacyjnej

0

@Patryk Maleszko:

Skoro nie umiesz tego dzięki codziennej pracy (rzeczy które umiesz tak po prostu to te rzeczy które naprawdę są potrzebne) to znaczy że nie są one potrzebne.

według mnie to tak nie działa.


A tak ogólnie, to ja nie przygotowuje się do rozmów, bo uważam że to trochę oszukiwanie

no chyba że do faamga

2

ale co tak nie działa? pomyśl o gościu co robi łazienki (kafelki, rury, wanny, sylikony), czy on jak idzie do nowego klienta to wkuwa normy przenikalności hydrologicznej gipsu w suchym tynku? no nie, chociaż klient mógłby go o to zapytać i sobie pomyśleć "no debil takich podstaw nie zna, nie biorę go do roboty"

5

[Bedzie kontrowersyjnie]
Ja tam zawsze lubiłem zadania domowe nawet dla sportu (jedno nawet robiłem z 10-15h, ale chyba przesadziłem z rozwiązaniem :p). W sumie zawsze wychodziłem z założenia, że skoro mam sobie wybierać pracodawcę i mierzyć wysoko, to powinienem takie zadania czy inne Codylyty wciągać nosem. Kiedyś pomimo wykształcenia odpadłem na algorytmach i zmotywowało mnie to do pracy nad sobą, a to zawsze procentuje. A tutaj jak czytam to już wiekszosc junior/mid stawia oczekiwania, że nie będzie robić żadnych testów/zadań. W mojej opinii nie doprowadzi to do znalezienia wymarzonego pracodawcy, tylko będziecie przysłowiowe krudy klepać i spowiadać się PM-owi z każdej linijki ;) a najlepsze są teksty, że firma powinna zapłacić za zadanie, bo przecież potem wdroży je na proda :D litości

1

@Charles_Ray

A tutaj jak czytam to już wiekszosc junior/mid stawia oczekiwania, że nie będzie robił żadnych testów/zadań. W mojej opinii nie doprowadzi to do znalezienia wymarzonego pracodawcy, tylko będziecie krudy klepać ;)

(piszę o zadaniach domowych)

Proszę cię, jeżeli jestem na rekrutacji technicznej np. 2 etapy po 1-3h i to nie wystarczy aby rekruterzy potrafili mnie jakoś ocenić,
no to chyba słabo, don't ya think?

Przychodzę na rekrutacje i wtedy jest czas, niech wtedy rzucą zadanko i zrobię to z nimi wspólnie, oni mi dadzą swój feedback, ja im uzasadnienie.

0

Live coding jest stresujące i często nie wiadomo o co chodzi rekrutującym. Dostaję banalne zadanie typu fizbuzz i zastanawiam się o co chodzi, bo przecież nie może być tak, że ktoś mi każe zakodować coś delikatnie bardziej złożonego niż hello world. Zdarzało mi się też dostać proste zagadnienie algorytmiczne, typu znalezienie najmniejszego fragmentu kolekcji zawierającego wszystkie wskazane elementy i chociaż to również banał, poległem, bo zamiast myśleć o sposobach rozwiązania problemu, myślałem o tym jak wypadnę i ile czasu wypada myśleć nad problemem. Tuż po rozmowie rozwiązanie było dla mnie jasne, więc chociaż zadanie było dla mnie banalne, w trakcie rozmowy nie byłem w stanie się wykazać.

Z drugiej strony lady, urządzamy live coding, własny komputer, własne IDE, pobranie projektu z wskazanego repozytorium, poprawa najprostszego możliwego algo jakie przyszło nam do głowy. Chcieliśmy zwyczajnie zobaczyć, czy ktoś potrafi tego git'a pobrać, otworzyć projekt, dostrzec problem widoczny na pierwszy rzut oka i coś z nim zrobić, poprawnie nazywać zmienne, może wpaść na pomysł dopisania testów. Ewidentnie widać, że niektórzy ludzie się spalają z podobnych powodów co ja, ale widać również to o co nam chodziło - sposób podejścia do problemu, sprawność posługiwania się narzędziami. Nie jest to oczywiście ani jedyna, ani nawet decydująca część rekrutacji.

0
kevin_sam_w_domu napisał(a):

Kucie na blachę algorytmów przez około rok, dwa lata do niektórych firm to moim zdaniem zjawisko psychologiczne, które ma na celu wymuszenie pewnych rzeczy.

Jesli rekrutacja jest przeprowadzona poprawnie to z reguly celem nie jest sprawdzenie czy ktos zna jakies zaawansowane algorytmy, ale sprawdzenie czy jest zdolny do samodzielnego zrobienia czegokolwiek. W takich zadaniach bardzo czesto najbardziej zaawansowany algorytm to sortowanie, a najbardziej zaawansowana struktura to vector. I zdecydowana wiekszosc programistow sobie z tym nie radzi, co sie przeklada na realne zadania w pracy - albo kod dziala wielokrotnie wolniej niz powinien, albo sie sypie dla czegokolwiek poza happy path, albo np. jesli programista trafi na problem ktorego wczesniej nie mial, to po prostu bedzie sie wgapial w monitor i nie zadnych szans zeby cokolwiek zrobil.

13

Wątek ma 1,5 roku, więc postanowiłem wnieść do niego nieco świeżości. Tak się składa, że przeprowadzono badania na ten temat:

https://www.sciencedaily.com/releases/2020/07/200714101228.htm

Wynika z nich, że live coding nie sprawdza umiejętności kandydata, a jedynie poziom stresu :] Nie dość, że kandydaci pod obserwacją osiągali o połowę gorsze wyniki niż bez obserwacji to jeszcze w badanej grupie presja na live codingu wyeliminowała wszystkie kobiety (gdy nie były obserwowane to poradziły sobie dobrze). Każdy kto kiedykolwiek zajmował się badaniami wie, że to praktycznie dyskwalifikujący wynik dla takiej metody rekrutacyjnej.

Zatem wszystkim mądralom, którzy twierdzą, że live coding "to jeden z lepszych sposób sprawdzania kandydatów" albo że "widać jak jest się słabym" - macie na to jakieś dowody czy tak wam się tylko wydaje?

Ogólnie proponuję trochę pokory. Zanim następnym razem stwierdzicie "ten człowiek z 5 latami doświadczenia nie potrafił napisać poprawnie jednej linijki kodu!", pomyślcie, czy to wy sami go nie zestresowaliście :] W IT jest sporo introwertyków, więc za dużo bodźców może ich przerastać. Takie osoby z lekką dozą paranoi mogą jednak produkować lepszej jakości kod - częściej będą do niego wracać, poprawiać go, testować więcej warunków brzegowych itd.

Wiem, że FAANG organizuje rekrutacje z live coding (tak, na pewno nie mogą się mylić, podobnie jak korporacje nie mogły się mylić organizując open space dla pracy wymagającej skupienia albo twierdząc, że przy pracy zdalnej spadnie efektywność ;] ). Wróćmy jednak do tego, jakie są konsekwencje live codingu? Po pierwsze, duża ilość false negative (czyli odrzucenia dobrego kandydata), ale FAANG może sobie na to pozwolić - oni mają wystarczająco dużo chętnych. Krótko mówiąc: nawet jak odrzucą kogoś dobrego to i tak zatrudnią innego dobrego. Po drugie, oni są trendsetterami, więc pisanie odkrywczych algorytmów może tam mieć trochę większe znaczenie niż w przeciętnej firmie tworzącej jakieś API czy webserwis, której z kolei przydałby się bardziej kandydat z umiejętnościami DevOps czy sprawnie poruszający się w obiektówce.

Możecie powiedzieć: "ja nie chcę kandydata, który nie radzi sobie ze stresem". Problem w tym, że to jest zupełnie inny stres niż ten, którego będzie doświadczał w twojej pracy. Tak po prostu się nie pracuje. Jak coś się wysypie na produkcji to menedżer zazwyczaj nie stoi ci nad głową patrząc jak naprawiasz błąd. Presja czasu oczywiście istnieje, ale zazwyczaj masz czas, żeby coś sprawdzić czy przetestować. Rozmowa rekrutacyjna to zupełnie inna stawka. Znacie osoby, które są super otwarte, odważne, radzą sobie doskonale pod presją, a idąc na randkę z dziewczyną z trudnością składają zdanie? No właśnie. Inna sytuacja, inna reakcja, inny poziom stresu.

Z tego co widzę, pozytywne opinie o live coding'u wypowiadają głównie... rekruterzy. Szczególnie tacy, którzy sami nie musieli uczesniczyć w żadnym procesie rekrutacyjnym od ładnych kilku lat ;] Sam fakt, że opinie różnią się głównie od tego, po której stronie biurka się siedzi, powinien zapalić czerwoną lampkę. Dla rekrutera ta metoda jest łatwa i przyjemna: dajesz kandydatowi zadanie i obserwujesz show, od czasu do czasu coś podpowiadając. Super. Jednak pomyśl, czy rekrutację organizujesz dla siebie czy dla kandydata? Czy na pewno pozwalasz mu się pokazać z najlepszej strony?

Ostatnie pytanie: co zamiast? Widzę kilka możliwości:

  1. Dać kandydatowi wybór: live coding czy zadanie domowe z odpytaniem na rozmowie. Zdarzają się ludzie, którym live coding nie przeszkadza. Są również tacy, którzy nie mają czasu/możliwości poświęcić paru godzin na zadanie domowe.
  2. Na rozmowie skupić się na wiedzy, sposobie myślenia, na tym czego nie można wygoogle'ować w 2 minuty. Podesłać kod, spytać gdzie jest błąd, jak kandydat by dany kod zoptymalizował. To dużo lepsze rozwiązanie, bo kod czyta się trudniej niż pisze się własny. Jak ktoś umie przeczytać to będzie też umiał napisać.
  3. Przeanalizować portfolio kandydata i odpytać go z jego projektu.
  4. Wreszcie, jeśli już musicie zorganizować live coding, warto zrobić to z głową. Po pierwsze uprzedzić, nie zaskakiwać. Na samej rozmowie sprawdzić się może programowanie w parach, na istniejącym kodzie, wspólne rozwiązanie problemu, z możliwością używania Google (warunki bardziej zbliżone do pracy). Po pierwsze, kandydat ma punkt odniesienia, może zacząć działać na istniejącym kodzie, nawet jak ze stresu ma pustkę w głowie. Po drugie, nie ma takiego poczucia, że jest obserwowany i oceniany przez rekrutera, w końcu razem rozwiązujecie ten problem, jak w prawdziwej pracy.

Pewnie są jeszcze inne możliwości, ale jesteście tacy kreatywni to na pewno wymyślicie ;]

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