W nawiązaniu do wątków, które ostatnio pojawiają się na forum o tym jak to źli pracodawcy ciemiężą kandydatów na rozmowach każąc im odpowiadać na za trudne/za proste pytania itp. chciałbym pogadać jak wg Was powinna wyglądać dobra rozmowa techniczna. W komentarzach pokazałem jakie sam stosuję pytania i zostałem mocno zjechany, że pytania bez sensu, programista praktyk nie umiałby na nie odpowiedzieć itp.

jak wygląda proces od strony HR

Na początek opiszę trochę wymagania do procesu rekrutacyjnego, z których osoby komentujące mogą sobie nie zdawać nawet sprawy. Zazwyczaj osoba techniczna przed prowadzeniem rekrutacji dostaje podstawowe info o kandydacie + ewentualnie wskazanie pozycji na jaką by miała go rekrutować (chyba, że rekrutacja ogólna). HR w rezultacie rozmowy oczekuje:

• odpowiedzi w skali 1-5 jaki jest poziom kandydata pod względem technicznym
• odpowiedzi w w skali 1-5 jakie wrażenie robi kandydat (tj. czy wpasuje się w zespół, czy nie jest kłótliwy, czy umie rozmawiać, jak reaguje na wskazanie błędu itp)
• do tego często jest lista skilli typu API, bazy danych, software design itp. - w każdym z tych tematów trzeba napisać kilka słów o poziomie kandydata.

Nawet jak kandydat nie zostanie zatrudniony na stanowisko to przez X miesięcy taki wpis leży sobie w systemi HR i osoby w firmie, które mają potrzebę "na zasób" zamiast rozpisywać rekrutację mogą przejrzeć osoby, które się przewinęły i ewentualnie odświeżyć kontakt. Sam HR też co jakiś czas wraca do kandydatów, którzy dobrze wypadli w rozmowach, ale np. nie przyjęli oferty i ich co 6-12 miesięcy pinguje, aby odświeżyć kontakt.

rekrutacja techniczna

Sama rozmowa zazwyczaj zależy w dużej mierze od osoby ja przeprowadzającej - są ludzie, którzy preferują code review, live coding albo luźną rozmowę. Ja jestem w tej ostatniej grupie. Mój skrypt na rozmowę (1,5-2h) polega mniej wiecej na:

wprowadzenie

Temat dowolny - zazwyczaj rozmowa o doświadczeniu kandydata. Tu wiele osób powie "przecież to jest w CV". Odpowiem, że robię to bo wielu kandydatów się stresuje i źle wypada w rozmowie. Jak zaczniemy od neutralnego tematu to kandydat ma szansę "wejść w rozmowę" na luzie. Dla mnie też jest istotne co kandydat robił, jakiej skali projekty ogarnial itp.

rozmowa techniczna.

Tu wiele osób zrzyma się, że część pytań jest za prosta i na przykład nie ma sensu pytać o SOLID osób z 5 letnim doświadczeniem i studiami. Sam pytam o SOLID bo:

• dobre praktyki/jakość kodu są na liście rzeczy, które muszę ocenić
• wbrew pozorom wiele osób sobie nie radzi z tymi tematami i jedyne co umie powiedzieć to sucha regułka.

Dla przykłądu u mnie pytanie o SOLID wygląda np.

• co to jest OCP
• podaj jakiś przykład w jaki zastosowałeś ostatnio OCP w praktyce (nie interesują mnie przykłady na poziomie tutoriali Dog/Animal)
• opisz jakieś mechanizmy z frameworka w którym pracujesz, a które wykorzystują OCP

Tu znowu podając ten przykład spotkałem się z krytyką, że na przykład wymagam znajomości kodu frameworka... Dla mnie zupełnie bez sensu stwierdzenie. Raz, że uważam, że trzeba znać narzędzie, w którym się pracuje a dwa, że przecież w ciemno można powiedzieć (bo praktycznie każdy framework to oferuje), że np. framework posiada eventy, które można subskrybować, posiada jakąś formę middleware, posiada konfigurację itp. Często widzę, że kandydat ma na początku problem ze wskazaniem to naprowadzam go np. podając jeden element.

Inny przykład pytania to scenki sytuacyjne, które zaczynam od prostego pytania i potem drążę. Np. wybobraź sobie, że jesteś na spotkaniu technicznym, gdzie pracujecie nad problemem z API. W pewnym momencie kolega z zespołu proponuję aby w zapytaniu typu GET dane przesłać przez body.

• pytanie 1 - czy w zapytaniu GET można przesyłać dane w body
• pytanie 2 - co byś odpowiedział na taką propozycję kolegi - uważasz, że to sensowne rozwiązanie?
• pytanie 3 - jakie problemy mogą wystąpić jeśli skorzystamy z tego rozwiązania

Ogólnie pytania staram się osadzać w jakimś kontekście, tak aby trzeba połączyć wiedzę teoretyczna z jakimiś konrketymi sytuacjami. Równie mocno patrzę na odpowiedzi jak i na proces dochodzenia do nich przez kandydata/sposób myślenia.

podsumowanie

Tutaj daję przestrzeń na zadanie pytań + daję feedback z rozmowy i o nim chwilę dyskutujemy.

Chętnie dowiem się od osób prowadzących rekrutacje jakie są ich patenty, a od osób rekrutowanych jak wg nich powinna wyglądać dobra rekrutacja. Zwróćcie proszę tylko uwagę, że wiele rzeczy, może się wydawać bez sensu (np. te proste pytania), ale maja one uzasadnienie np. w procedurze rekrutacyjnej czy doświadczeniu rekrutujacego na większej próbie przeprowadzonych rozmów.

Tu wiele osób zrzyma się, że część pytań jest za prosta i na przykład nie ma sensu pytać o SOLID osób z 5 letnim doświadczeniem i studiami. Sam pytam o SOLID bo:

Tylko co Ci po tym SOLIDzie. Każdy rekruter techniczny niby zna. Każdy niby Mid-Senior też niby zna. Potem idziesz do projektu i widziesz, że tam nic nie jest wg zasad SOLID i nawet jakbyś chciał wprowadzić jakieś sensowne punkty to się okazuje, że klient za takie rzeczy nie płaci, nie ma czasu, nie ma budżetu, a tam jest pożar do gaszenia bo wywaliło PRODa xD

Rekrutacja powinna być adekwatna do projektu.
Jeśli projekt faktycznie wymaga pracy z algorytmami to jest jak najbardziej sens robić jakieś zadanka codility itd.
Jeśli budujesz faktycznie nowe API, implementujesz kafki i inne cuda, to może i zasande jest by dać jakieś zadanie do domu, ale równie dobrze można to zrobić w kilkanaście minut na rozmowie.

Ja jestem przeciwny zadaniom, bo praca to nie olimpiada informatyczna czy jakiś hackton, żeby nad tym ślęczeć wieczorami i się przygotowywać jak student do egzaminu na studia.
Na koniec zawsze się okazuje, że turbo ciekawy nowatorski projekt nie wystartował i dalej lepimy i łatamy monolit legacy z kulek goowna, trzeba debbugować by naprawić buga, trzeba zrobić update wersji frameworka, trzeba na szybko wysłać patcha bo jest jakaś luka w bibliotece, omawiać z klientem coś tam, wymyślać scenariusze testowe bo nie ma sensownych testerów (bo po co? przecież developer może zrobić to samo) i tyle z tego technicznego maglowania.

To czego nie robiłeś przez ostatnie 6 miesięcy i tak pewnie zbyt dobrze nie pamiętasz i musisz sobie przypomnieć, wygooglać, dopytać Chat GPT etc.
Na rozmowie widać czy ktoś kumaty i wporzo czy ściemniacz i kombinator czy jakiś wariat, który podpali biurko by przetestować system przeciwpożarowy w biurze.

Jakby sie na tym zastanowic to nie da sie dobrze przeprowadzic rekrutacji technicznej. Stad przy seniorach niektorzy z tego rezygnuja xD, ale nie mówię, że to idealne rozwiązanie, bo sporo oszustów i zasiedziałych wysyła CV.

Wszystko zalezy od stopnia stanowiska i projektu. Imo idealna rekrutacja powinna sprawdzać czy kandydat ma wiedzę, aby móc bez przeszkód zrozumieć i pracować w projekcie do którego trafi. Pytanie o juzles teorie jak SOLID, przeładowanie operatorów dodawania, albo co robi funkcja "x" z dokumentacji to troche bullshit. Jak praca z starym softem i głównie debugging to dajecie kawałek projektu i niech pokaze jak sobie radzi z kodem.
Generalnie największa patologia IT to rekrutacje oderwane od rzeczywistości i pytanie o rzeczy całkowicie nieprzydatne. Jak juz macie to robic to pytajcie o leetcody, bo ciekawsze i mniej bezużytecznej wiedzy trzeba sie nauczyć.

No i równie ważna rzecz to jak jakiś kandydat spełni wasze wymagania to bierzcie go od razu a nie, że wypytujecie następne 20 i tracicie wszystkim czas. W mojej obecnej firmie to byłem jednym z pierwszych i jak spasowałem to oferta i koniec. Mam wrażenie, że niektóre firmy sztucznie zawyżają trudność rekrutacji licząc, że znajdą nie wiadomo kogo. Imo to kiepskie podejście i marnotrastwo czasu. Zwłaszca, że wymatacz i tak ucieknie prędzej czy później.

Ogólnie ciekawa post ale z jedną cześcią się nie zgodzę

tefu napisał(a):

Tylko co Ci po tym SOLIDzie. Każdy rekruter techniczny niby zna. Każdy niby Mid-Senior też niby zna. Potem idziesz do projektu i widziesz, że tam nic nie jest wg zasad SOLID i nawet jakbyś chciał wprowadzić jakieś sensowne punkty to się okazuje, że klient za takie rzeczy nie płaci

Dla mnie SOLID to taka trochę matrioszka/cebula. Pokrywa zarówno rzeczy duże jak cała architektura systemu, ale i zwykłe kodowanie na poziomie zlepienia kilku klas. Jak developer rozumie te zasady (a nie tylko klepie formułki) to jest szansa, że przynajmniej na poziomie wytwarzanego kodu będzie starał się je stosować, a to już i tak sporo znaczy. U devów najbardziej cenię, że potrafią łączyć kropki i wiedzę teoretyczną umieją odnieść do narzędzi w których pracują. Wbrew pozoro nie jest z tym aż tak różowo i np. SOLID wielu developerów rozumie tylko na bardzo uproszczonym poziomie w stylu pytasz o SRP to słyszysz coś w stylu "klasa musi być krótka i robić 1 rzecz", ale jak już wsadzisz to w kontekst i zadasz często nawet tak trywialne pytanie jak czy "2 metody publiczne oznaczają, że klasa łamie SRP" to się zaczynają schody i wychodzi zupełny brak zrozumienia istoty/pokazania, że się myśli przy kodowaniu.

Czitels napisał(a):

Jakby sie na tym zastanowic to nie da sie dobrze przeprowadzic rekrutacji technicznej.

Oj to prawda - trudno dogodzić wszystkim bo jedni uważają, że pytania są zbyt trudne inni, że proste pytanie ich obrażają. Live coding/zadania są złe/dobre. Chyba HR by musiał robić ankietę jaką rekrutację chce dany kandydat przejść aby wszystkim dogodzić ;-)

Co do tego, że kandydat spełni wszystkie wymagania to rzadko się zdarza aby taki się trafił. Na rozmowie (także technicznej) ocenia się nie tylko skill techniczny, ale też "fit do zespołu", sposób w jaki kandydat radzi sobie z wskazaniem błędu. Bo co z tego, że trafisz super ogarniacza, który potem twardo stoi przy każdym swoim rozwiązaniu i zawsze wie najlepiej przez co rozsadza zespół od środka. Kasa też jest dość istotna bo czasami masz kandydata, który spełnia dość dobrze wymagania (powiedzmy fit na 80%), ale chce górnych widełek, a w kolejce masz osoby podobnie rokujące, ale z mniejszymi wymaganiami. Odnosząc to do kupna auta - jak trafisz fajne auto ale na granicy Twojego budżetu to też pójdziesz do innego salonu zbadać opcje. Zresztą decyzja o zatrudnieniu nie zapada na rozmowie technicznej - w większości osoba ją prowadząca daje tylko feedback do HR, HR to wszystko owija w papierek i daje rekomendację do osoby decyzyjnej. Ja często nawet nie dostaję info o stawce jako chce kandydat a nawet na jaki level aplikuje, żeby sobie nie wyrabiać opinii przed spotkaniem.

Dobra rekrutacja techniczna - obiektywna opinia

Cheap + good enough + easygoing

hadwao napisał(a):

Dla mnie SOLID to taka trochę matrioszka/cebula. Pokrywa zarówno rzeczy duże jak cała architektura systemu, ale i zwykłe kodowanie na poziomie zlepienia kilku klas. Jak developer rozumie te zasady (a nie tylko klepie formułki) to jest szansa, że przynajmniej na poziomie wytwarzanego kodu będzie starał się je stosować, a to już i tak sporo znaczy. U devów najbardziej cenię, że potrafią łączyć kropki i wiedzę teoretyczną umieją odnieść do narzędzi w których pracują. Wbrew pozoro nie jest z tym aż tak różowo i np. SOLID wielu developerów rozumie tylko na bardzo uproszczonym poziomie w stylu pytasz o SRP to słyszysz coś w stylu "klasa musi być krótka i robić 1 rzecz", ale jak już wsadzisz to w kontekst i zadasz często nawet tak trywialne pytanie jak czy "2 metody publiczne oznaczają, że klasa łamie SRP" to się zaczynają schody i wychodzi zupełny brak zrozumienia istoty/pokazania, że się myśli przy kodowaniu.

Ale takie dyskusje jak np o wspomnianym SRP i tych metodach publicznych to rozważania quasi-filozoficzne. Można sobie o tym gdybać ale nie oparłbym decyzji o zatrudnieniu kandydata na podstawie takich rozważań techniczno-filozoficznych.
Bo to się sprowadza do tego czy masz do czynienia z bucem/zarozumialcem, który będzie foroswać swoje rozwiązanie czy z kimś, kto Ci przyzna rację lub nie i to bez spiny uargumentuje.
Krótko mówiąc, wszystko się sprowadza do tego czy można się z kimś dogadać.

hadwao napisał(a):

Inny przykład pytania to scenki sytuacyjne, które zaczynam od prostego pytania i potem drążę. Np. wybobraź sobie, że jesteś na spotkaniu technicznym, gdzie pracujecie nad problemem z API. W pewnym momencie kolega z zespołu proponuję aby w zapytaniu typu GET dane przesłać przez body.

• pytanie 1 - czy w zapytaniu GET można przesyłać dane w body
• pytanie 2 - co byś odpowiedział na taką propozycję kolegi - uważasz, że to sensowne rozwiązanie?
• pytanie 3 - jakie problemy mogą wystąpić jeśli skorzystamy z tego rozwiązania

Ogólnie pytanie ujdzie (choć przyznam, że nieoczywiste - podejrzewam, że niewielu się na to nacięło, ja bym pewnie nie wiedział, przypadkiem o tym poczytałem dawno temu jak ktoś z zespołu chciał lepsze wyszukiwanie w aplikacji zrobić).
Ale gdzie tu historyjka? Cały kontekst to "kolega pyta na spotkaniu technicznym". Nic się tutaj nie dzieje, prościej by było, jakbyś po prostu zadał to pytanie :P

Natomiast ogólnie zamysł historyjki mi się podoba. Tak jak na przykład są pytania na certach z AWS.

Mam wrażenie że w innych branżach ludzie rozumieją że uczymy się niektórych rzeczy do egzaminu i zapominamy, a później mamy zdolność szybszego przypomnienia sobie zagadnień. W IT panuje założenie że każdy ma autystyczną zdolność memoryzowania i przypominania sobie wszystkiego co w życiu przeczytał i jak nie potrafi odpowiedzieć na pytanie to znaczy że nie ma o temacie pojęcia.

hadwao napisał(a):

• pytanie 1 - czy w zapytaniu GET można przesyłać dane w body

Temat ciekawy, później sobie popiszę a w międzyczasie: https://tinyurl.com/lipna-loza-prowizoryczna

SOLID srolid, może w Javie albo C# ma sens, bo to języki typowo obiektowe, ale nie widzę sensu tego typu rozważań w innych językach. Jak już bym miał podawać jakieś przykłady wg mnie dobrych pytań na rozmowie, to byłoby to coś w tym stylu (ogólnie coś bardziej praktycznego, co sprawdzi czy kandydat miał z tym styczność):

• kiedy graphql będzie lepszym zastosowaniem niż rest api
• coś z baz danych, np kiedy lepiej zastosować sql a kiedy no-sql
• ktoś miał styczność z live streamami, to pytanie o kafkę/sqs/cokolwiek podobnego
• może jakiś prosty system design (byle nie coś w stylu zrób nam klona instagrama/tiktoka itp)
• no i sprawdzenie, czy kandydat wydaje się być ogarniętym człowiekiem a nie toksykiem bucem mitomanem

Dobra rekrutacja techniczna == krótki skan (HR) => zadanie domowe => "live coding" (ultra prosty, ew kontynuacja zadania) => dyskusja techniczna.

To doświadczenie z dwóch stron stołu.

Są ludzie, którzy ładnie przechodzą rozmowy, a potem potykają się o własne ręce -> nie chcę takich zatrudniać, jak się zatrudniam to nie chcę z takimi pracować.

A SOLID srolid - zgadzam się.

hadwao napisał(a):

Inny przykład pytania to scenki sytuacyjne, które zaczynam od prostego pytania i potem drążę. Np. wybobraź sobie, że jesteś na spotkaniu technicznym, gdzie pracujecie nad problemem z API. W pewnym momencie kolega z zespołu proponuję aby w zapytaniu typu GET dane przesłać przez body.

• pytanie 1 - czy w zapytaniu GET można przesyłać dane w body
• pytanie 2 - co byś odpowiedział na taką propozycję kolegi - uważasz, że to sensowne rozwiązanie?
• pytanie 3 - jakie problemy mogą wystąpić jeśli skorzystamy z tego rozwiązania

Bardzo dobry przykład - dokładnie to ostatnio miałem w pracy. Pracuje ponad 20 lat robiąć serwisy web, api. Bez patrzenia w internet nie potrafiłem powiedzieć co zrobić :-) Mimo, że jestem pewny, że już ze 3 razy w karierze dokładnie ten problem rozkminiałem.
Po prostu tak rzadzki przypadek, że jak się nad tym ostatnio nie siedziało to mało kto (IMO) jest pewny co powiedzieć.

korokczan napisał(a):

• no i sprawdzenie, czy kandydat wydaje się być ogarniętym człowiekiem a nie toksykiem bucem mitomanem

Mamy jakiś standard ISO do tego?

Ja już się nauczyłem że w tym zawodzie rekrutacja to jest w ogóle jakis kompletnie odrębny skill niezwiązany jakkolwiek z tym co robię od lat dzień w dzień ;)

I na odwrót, są typy co na rekrutacji wypadają wzorowo ale po miesiącu sie okazuje że sie z tymi ludzmi absolutnie nie da pracować.

hadwao napisał(a):

Temat dowolny - zazwyczaj rozmowa o doświadczeniu kandydata. Tu wiele osób powie "przecież to jest w CV". Odpowiem, że robię to bo wielu kandydatów się stresuje i źle wypada w rozmowie. Jak zaczniemy od neutralnego tematu to kandydat ma szansę "wejść w rozmowę" na luzie. Dla mnie też jest istotne co kandydat robił, jakiej skali projekty ogarnial itp.

Opowiadanie o doświadczeniu to nie jest neutralny temat, ponieważ trzeba dokonać filtracji. Jeśli się ma różnorodne doświadczenie, robiło się rzeczy z działki X, Y czy Z, to trzeba ostrożnie podchodzić, żeby wybrać takie doświadczenia, które będą pasować do profilu firmy, a resztą pominąć.

A jeśli się szuka pracy w różnych firmach (bez jakiejś konkretnej preferencji), to jest to męczące. Firmie produktowej trzeba podkreślać zaangażowanie długofalowo w produkty, software house'owi trzeba podkreślać umiejętność wchodzenia szybko w kolejne projekty pod presją czasową; firmie międzynarodowej, że się pracowało w międzynarodowym środowisku itp.

I jak człowiek używał przez lata różnych technologii, to też trzeba na rozmowie podkreślać tylko te technologie, które są używane w firmie. A jak powiesz, że technologię X znasz dobrze i się zajmowałeś nią kilka lat, jednak ostatni raz rok temu, to cię uwalą, bo szukają kogoś "ze świeżym doświadczeniem". Więc trzeba mocno lawirować, bo jedno nieuważne zdanie i potem czytasz w rejection letter, że firma wybrała kogoś z większym doświadczeniem w X

Czyli jeśli zadajesz pytania o doświadczeniu kandydata, bo wielu kandydatów się stresuje i źle wypada w rozmowie., to możesz osiągnąć skutek przeciwny do zamierzonego. Przecież to najbardziej stresująca część rozmowy, bo trzeba się domyśleć, czego ktoś oczekuje i tak przefiltrować swoje doświadczenia, żeby wyszło na to, że się nadajemy idealnie.

Dla mnie też jest istotne co kandydat robił, jakiej skali projekty ogarnial itp.

A nie lepiej odwrócić sytuację? Zamiast męczyć kandydata na temat tego, co robił (co i tak nie będzie miarodajne, ludzie też się mogą nauczyć mówić to, co ktoś chce usłyszeć), to opowiedzieć mu o tym, co wy robicie, pogadać o architekturze waszego projektu, o rozwiązaniach itp. a potem zapytać kandydata co o tym sądzi i jakie ma przemyślenia albo pytania? Albo pokazywać niezbyt udane kawałki kodu z produkcji i pytać, co tu można zrobić, jak można polepszyć? Czyli potraktować jak potencjalnego kolegę do zespołu, bo przecież na tym to ma polegać.

Zakładając, że to firma produktowa i ma własny produkt, którym może się chwalić. Bo jak to kontraktornia, to może być gorzej. Ale wtedy można by pogadać o ogólnych praktykach, podejściu jakie ma firma do projektów, tworzenia softu, pisania kodu itp.

Czyli Twoim zdaniem trzeba znać formułki typu SOLID żeby być dobrym? Ja nawet nie pamiętam rozwinięcia skrótu. Ale ja jestem jakiś dziwny i nie potrzebuję znać teorii żadnych żeby wiedzieć, że fajnie mieć czytelny kod a nie np. 100 stopni zagnieżdżeń (zgodnych z SOLID o zgrozo!)

LukeJL napisał(a):

A nie lepiej odwrócić sytuację? Zamiast męczyć kandydata na temat tego, co robił (co i tak nie będzie miarodajne, ludzie też się mogą nauczyć mówić to, co ktoś chce usłyszeć), to opowiedzieć mu o tym, co wy robicie, pogadać o architekturze waszego projektu, o rozwiązaniach itp. a potem zapytać kandydata co o tym sądzi i jakie ma przemyślenia albo pytania? Albo pokazywać niezbyt udane kawałki kodu z produkcji i pytać, co tu można zrobić, jak można polepszyć? Czyli potraktować jak potencjalnego kolegę do zespołu, bo przecież na tym to ma polegać.

O tak! Jak najbardziej.

A nie lepiej odwrócić sytuację? Zamiast męczyć kandydata na temat tego, co robił (co i tak nie będzie miarodajne, ludzie też się mogą nauczyć mówić to, co ktoś chce usłyszeć), to opowiedzieć mu o tym, co wy robicie, pogadać o architekturze waszego projektu, o rozwiązaniach itp. a potem zapytać kandydata co o tym sądzi i jakie ma przemyślenia albo pytania? Albo pokazywać niezbyt udane kawałki kodu z produkcji i pytać, co tu można zrobić, jak można polepszyć? Czyli potraktować jak potencjalnego kolegę do zespołu, bo przecież na tym to ma polegać.

Tak, google podobno ostatnio zaczął kandydatom pokazywać kod do zdebuggowania, zamiast tylko na leetcodzie się opierać, i są zadowoleni z efektów tego podejścia.

U mnie SOLID i regułki pojawiają się tylko na rozmowie z entry level, czyli osobą poniżej 6 miesięcy doświadczenia. Powyżej tego, odnośnie do SOLIDa, padają dwa pytania: jak byś zasadę pojedynczej odpowiedzialności wytłumaczył juniorowi (Sam nie znam dobrej odpowiedźi) oraz jak w swoich projektach praktycznie wykorzystywali zasadę Open-Closed. Po bloku pytań o dobre praktyki kandydat dostaje zadanie w stylu code review/dyskusji na temat zastanego kodu legacy, który trzeba zmodyfikować, ponieważ "klient będzie mocno rozwijał ten obszar". W 100% osoby, które uciekają z odpowiedźią do regułek lub błyszczą teorią, na tym zadaniu się wykładają. Natomiast mnie nie interesują regułki na rekrutacji, nie ma też idealnych rozwiązań, ani konkretnych odpowiedź które chce usłyszeć, tylko kategorie problemów, z którymi kandydaci się mierzyli w poprzednich projektach. Plus wyczucie, czy gościu nie jest dobry sprzedażowcem tylko spoko kolegą, z którym chciałbym pracować w jednym zespole.

sharper_99 napisał(a):

oraz jak w swoich projektach praktycznie wykorzystywali zasadę Open-Closed.

To więcej miałoby sensu, jakby była to odpowiedź w postaci pisemnej jako zadanie domowe (napisz co najmniej 100 słów o tym, jak w swoim projekcie praktycznie wykorzystywałeś zasadę Open-Closed). Bo jak pada na żywo, to mało czasu jest na przypominanie sobie ciekawych konkretnych przykładów i zastanowienie się, co to znaczy "praktycznie wykorzystywałeś". Open-Closed to jest część zasad pomagających pisanie utrzymywalnego kodu, ale to nie znaczy, że za każdym razem, jak tworzymy klasę wg zasady Open-Closed, to zyskujemy jakiś cudowny bonus. A tak zadane pytanie sugeruje, że pytający chce, żeby pokazać mu jakiś konkretny zysk z konkretnej implementacji, która korzystała z zasady OpenClosed. Czyli znowu - zabawa w głuchy telefon i zgadywanie, jakiej odpowiedzi oczekuje rozmówca i jednoczesne przypominanie sobie kodu, który się pisało i czy pasuje do odpowiedzi. Do takich odpowiedzi trzeba się przygotować i przećwiczyć sobie na pamięć, co mówić ew. improwizować i coś zmyślić, ubarwić.

Dobra rekrutacja to taka gdzie dostajesz na żywo do zrobienia code review kodu, w którym celowo są popełnione błędy, np. użycie IEnumerable zamiast IQueryable (w przypadku c#).

wiewiorek napisał(a):

Dobra rekrutacja to taka gdzie dostajesz na żywo do zrobienia code review kodu, w którym celowo są popełnione błędy, np. użycie IEnumerable zamiast IQueryable (w przypadku c#).

Wg mnie meh, szczególnie, że problemy w kodzie zazwyczaj leżą na dużo wyższym poziomie (niepasujące abstrakcje, overengineering), w ten sposób można sprawdzać wyczulenie na jakieś chamskie Selecty w pętli czy == vs equals. Ale to pasuje do CR, ludzie zazwyczaj przywalają się do stylu czy wcięć bracketów, a to czy kod działa czy nie to drugorzędna kwestia.

Jednym z fajniejszych zadań technicznych jakie robiłem był live debugging, dostałem zdalny dostęp do maszyny na której był VisualStudio i projekt, który nie działał jak należy, celem było znalezienie i poprawa błędu. Wg mnie tego typu zadanie daje wiele możliwości sprawdzenia kandydata - w jaki sposób porusza się po IDE, w jaki sposób myśli, czy wie w ogóle gdzie zacząć, a nawet czy umie breakpointy stawiać, mnie już nie dziwi, że nawet seniorzy potrafią polegać tylko na dupa debugging.

2 zadania z Leetcode Medium do rozwiązania plus rozmowa z frameworkow np. o Apache Kafka

To jest imo najtrudniejsze w rekrutacji: próbujemy spakować kilka lat potencjalnej współpracy do formy góra dwugodzinnej rozmowy. Nie da się wszystkiego sprawdzić, trzeba wybrać to, co najważniejsze w projekcie. Live debugging wydaje mi się spoko pomysłem, jeśli mówimy o rozwoju/utrzymaniu istniejącego kodu - fajnie.

Dokładnie to jest sedno problemu. To co (w mojej opinii) jest ważne, to że zadania tak na prawdę (nie są/nie powinny) być celem samym w sobie, tylko powinny być czymś co pozwala na obserwację kandydata i wyciąganie wniosków z jego zachowania, sposobu podchodzenia do problemów itp. Kiedyś w jednym serialu widziałem fajną rekrutację, gdzie chirurgowi w czasie rozmowy rekrutacyjnej kazano jednocześnie wykonać zadanie manualne, z którym sobie nie radził. Na końcu dowiedział się, że zadanie było niewykonalne, a chcieli po prostu zobaczyć jak reaguje w sytuacji stresowej na niepowodzenie i czy umie zachować chłodną głowę. Live debugging zaproponowany przez @Saalin ma trochę więcej sensu niż CR i w sumie ciekawy pomysł, bo sprawdza umiejętności praktyczne. Pewnie jako połowa rozmowy ma sens - całej rozmowy na pewno bym na to nie poświęcił, bo debugowanie to jednak tylko jedna z ważnych umiejętności, natomiast pełna zgoda, że przy okazji od razu widać wiele innych rzeczy jak ogólny exp czy korzystanie z narzędzi. Z drugiej strony w dzisiejszych czasach ludzie używają różnych rzeczy i wystarczy, że ktoś np. używa jakichś ciekawych pluginów w IDE czy standalone narzędzi i już będzie miał problem aby dostosować się do tego co dajemy mu na rozmowie. Niemniej pomysł fajny i ciekawy jako dodatek do rekru.

hadwao napisał(a):

Nawet jak kandydat nie zostanie zatrudniony na stanowisko to przez X miesięcy taki wpis leży sobie w systemi HR i osoby w firmie, które mają potrzebę "na zasób" zamiast rozpisywać rekrutację mogą przejrzeć osoby, które się przewinęły i ewentualnie odświeżyć kontakt. Sam HR też co jakiś czas wraca do kandydatów, którzy dobrze wypadli w rozmowach, ale np. nie przyjęli oferty i ich co 6-12 miesięcy pinguje, aby odświeżyć kontakt.

a tak, HRówy mają wywalone na niezaznaczenie checkboxa ze pozwalamy na przechowywanie swoich danych i je sobie trzymają niezależnie od tego czy mają zgodę ewentualnego kandydata czy nie

Temat dowolny - zazwyczaj rozmowa o doświadczeniu kandydata. Tu wiele osób powie "przecież to jest w CV". Odpowiem, że robię to bo wielu kandydatów się stresuje i źle wypada w rozmowie. Jak zaczniemy od neutralnego tematu to kandydat ma szansę "wejść w rozmowę" na luzie. Dla mnie też jest istotne co kandydat robił, jakiej skali projekty ogarnial itp

tak, wqrwienie kandydata tym że się nie przeczytało jego cv to jest oczywiście dla dobra tego kandydata ;)
.

podsumowanie

Tutaj daję przestrzeń na zadanie pytań + daję feedback z rozmowy i o nim chwilę dyskutujemy.

Chętnie dowiem się od osób prowadzących rekrutacje jakie są ich patenty, a od osób rekrutowanych jak wg nich powinna wyglądać dobra rekrutacja. Zwróćcie proszę tylko uwagę, że wiele rzeczy, może się wydawać bez sensu (np. te proste pytania), ale maja one uzasadnienie np. w procedurze rekrutacyjnej czy doświadczeniu rekrutujacego na większej próbie przeprowadzonych rozmów.

bo rekrutujący z założenia ma doświadczenie ;)

Czego się spodziewa rekrutujący na rozmowie? Ano takiego zachowania kandydata jak w słynnym cytacie " Podwładny powinien przed obliczem przełożonego mieć wygląd lichy i durnowaty, tak by swoim pojmowaniem istoty sprawy nie peszyć przełożonego"
Myślisz inaczej niż rekrutujący, co z tego że poprawnie - skreślamy.
I potem jest zespół klonów, które podczas dyskusji na temat projektu nie wniosą nic nowego, bo ich zbiorowa wiedza jest wiedzą jednego osobnika tak naprawdę
Dobra rozmowa techniczna to jest rozmowa , nie przesłuchanie, ale trzeba by rekrutującego który chce się czegoś dowiedzieć naprawdę a nie tylko połechtać swoje ego

Miang napisał(a):

Dobra rozmowa techniczna to jest rozmowa , nie przesłuchanie, ale trzeba by rekrutującego który chce się czegoś dowiedzieć naprawdę a nie tylko połechtać swoje ego

W punkt.

Miang napisał(a):

a tak, HRówy mają wywalone na niezaznaczenie checkboxa ze pozwalamy na przechowywanie swoich danych i je sobie trzymają niezależnie od tego czy mają zgodę ewentualnego kandydata czy nie

Zawsze się zastanawiam czy warto to zaznaczać, bo jak źle wypadnę to będę w systemie jako słaby kandydat, a jak nie zaznaczę to chyba mam czysta kartę?