Dobra rozmowa techniczna i przeciętny live coding

Witam wszystkich,

Mam takie pytanie jak oceniacie kandydata, który dosyć dobrze wypadł podczas rozmowy technicznej (pytania techniczne), ale dosyć mocno wyłożył się na live codingu? Czy ktoś taki zazwyczaj wtedy jest już traktowany jako junior?

Ostatnio sam kandydowałem na pewne stanowisko i rozmowa techniczna poszła mi dobrze. Oczywiście nie wiedziałem wszystkiego, ale tak na oko odpowiedziałem na 75% pytań. Natomiast przy live codingu wyłożyłem się. Nie były to trudne zadania, ale jakoś mi nie poszło. W normalnych warunkach raczej bym nie miał z nimi problemu. Za live coding dałbym sobie ocenę 3/10.

Czy firmy zazwyczaj takich kadnydatów już skreślają? Jednak praktyka jest dosyć ważna w tym zawodzie. Może ktoś z was jest rekruterem i może wypowiedzieć się od strony rekrutera jak taki potencjalny kandydat jest wtedy traktowany?

Nawet jeśli Cię nie skreślą, to i tak dostaniesz pewnie słabszą kasę. Więc nawet dla Ciebie lepiej byłoby próbować i szukać dalej.

A jak sądzisz - co jest ważniejsze/bardziej przydatne dla firmy:

• ktoś, kto zna teorię, ale nie umie jej zastosować i zwyczajnie kiepsko mu idzie kodowanie
• osoba, która kiepsko wypadła na pytaniach teoretycznych (które często sprawdzają jakieś rzeczy z czapy albo poziom wykucia definicji, ewentualnie starają się zagiąć kandydata na jakichś haczykach/meandrach, których w życiu się później nie spotka - coś jak ten słynny facet z podręczników do matematyki, który miał 168 jabłek, ale 73 z nich wymienił na 29 gruszek :D) ale za to sobie całkiem nieźle radzi z pracą/tworzy w miarę szybko dość dobry kod

https://joemonster.org/art/47894

Ja mam wrażenie, że w live codingu ważne jest bardziej to, co obie strony mówią, niż to, co się pisze. Czyli ogólnie czy jest chemia. Czy sprawiasz wrażenie gościa, który ogarnia i czy ten drugi programista rezonuje z tobą, czy może odpytuje cię od niechcenia albo ma już swoją odpowiedź na wszystko.

I tak - o ile możesz się nauczyć podstaw i typowych zadań live codingowych, żeby nie odpaść na pierdołach, to już nie masz wpływu na to, czy będzie cię pytać programista, z którym się dogadasz, czy może jakiś random (np. gość, który nie korzysta z technologii, z której cię przepytuje) albo burek (np. osoby, które się śmieją, jak komuś coś nie wyjdzie na tablicy*).

*(przez live coding rozumiem tu zarówno tu kodowanie na sucho (na tablicy, na kartce, w dokumencie tekstowym online) jak i w IDE/z faktycznym odpalaniem).

kandydata (...) Czy ktoś taki zazwyczaj wtedy jest już traktowany jako junior?
...
Czy firmy zazwyczaj takich kadnydatów już skreślają?

Czemu w jedną stronę? Przecież po tej drugiej stronie też są ludzie. Programista, który cię będzie rekrutować, też nie musi być jakimś wymiataczem i sam może nie znać odpowiedzi na pytania, o które cię będzie pytać. Taki programista sam by odpadł.

ale dosyć mocno wyłożył się na live codingu?

Zależy.
Było tak, że prawie nic nie umiałem w live codingu na algorytmy (musieli mi sami potem podpowiadać) i się dostałem.
Ale było też tak, że miałem zrobić HelloWorld w technologii, którą znałem, ale zapomniałem, jak się stawia w tej technologii nowe projekty od zera (bo robiłem w tej technologii dłuższy projekt, a nie stawiałem ciągle nowych) i później uznali, że nie mam w niej doświadczenia xD

W obecnej pracy skopałem live coding. O ile rozmowa techniczna poszła mi ok to zestresowałem się przy najprostszych zadaniach a mimo to prace otrzymałem. Po 3 miesiącach miałem rozmowę z menago, który stwierdził, że dostałem solidny (pozytywny) feedback od klienta + jestem jedną z bardziej aktywnych/ogarniętych osób w teamie.

Można mieć gorszy dzień i zwyczajnie skopać prostą rzecz. LC o niczym nie świadczy, bo równie dobrze może pójść w drugą stronę. Komuś pójdzie dobrze na LC (bo np zadania rodem z 100 most popular interview tasks... :D) a w projekcie się wyłoży. Kwestia firmy i podejścia. Niemniej jeśli CI poszło słabo a dostaniesz się, to warto przycisnąć okres próbny i pokazać, że nie jesteś palcem robiony ;) Potem jest zwyczajnie luźniej/łatwiej + ludzie inaczej na Ciebie patrzą.

Sprawdzenie skilla podczas godzinnego, dwugodzinnego live codingu to mega trudna sprawa, wręcz niemożliwa. Co najwyżej można sprawdzić pewne cechy kandydata i czy jest chemia pomiędzy dwoma stronami.

Poza tym pewne cechy w stylu:

• myślenie w stresującej sytuacji, pod presją czasu
• efektywność produkcji kodu (Skróty klawiszowe, nawigacja po IDE, etc.)
• umiejętność współpracy

Koniec końców potem i tak wszystko wychodzi w praniu.

Live Coding ma na celu sprawdzić czy ktoś umie programować i jak podchodzi do problemu, a nie koniecznie czy umie w 20 minut rozwiązać jakiś złożony problem. Pytanie więc co znaczy że się wyłożyłeś? Okazało sie ze nie znasz składni języka? Nie potrafisz korzystać z narzędzi? Nie umiesz napisać testu do kawałka kodu który pisaliście? Nie umiesz dopytać o szczegóły zadania/wymagania/przypadki brzegowe?

Zazwyczaj skreślają, ja sam jestem giga słaby jeżeli chodzi o LC, szczególnie jeżeli chodzi o jakieś nietypowe zadania. Algorytmy i LC? Proste REST API? spoko, jakoś napisze, ale jeżeli ktoś mi daje gotowy kod i np. pada pytanie co jest źle to bez przedebugowania się, jeżeli nie jest to trywialne, to no sorry, wróżką nie jestem. Albo jak ktoś chce żebym mu zaimplementował coś w jeden określony sposób, najlepiej bez użycia metod wbudowanych w język, bo koniecznie trzeba koło na nowo tworzyć, to dla mnie mogą spadać na drzewo. Jestem typem człowieka który woli sobie na spokojnie z herbatą przy biurku usiąść i rozkminić problem zamiast pisać na czas, i póki co z takim podejściem odbiłem się tylko od paru drzwi, a pensja i tak leci w górę :P

U mnie na rekrutacjach staramy sie unikac zadan typu napisz funkcje, ktora zrobi x (np. odwroc elementy w array)
Uwazam, ze tego typu zadania nie do konca odzwierciedlaja prawdziwych umiejetnosci kandydata.
Natomiast czesto dajemy wycinki prawdziwego kodu, np. z obecnego projektu, nad ktorym pracujemy. I tutaj nastepuje otwarta rozmowa dotyczaca np. problemow w tym kodzie, albo dajemy opis taska, ktory trzeba bylo wykonac na tym wycinku i rozmawiamy sobie o mozliwosciach wykonania tego.
To sa czesto taski, ktore wykonujemy na co dzien.
Szybko wychodzi jak bardzo osoba jest ogarnieta. Tutaj tez dajemy czesto szanse kandydatowi sie wykazac, poprzez dodatkowe pytania, ktore albo wchodza w glab rozwiazania/technologi, albo tez staramy sie znalezc braki kandydata. Zawsze po takiej rozmowie dajemy konstruktywny feedback.