Pytanie do developerów: Jak przeprowadzacie rekrutację

0

Cześć Wszystkim.
Mam kilkumiesięczne doswiadczenie w rekrutowaniu ludzi.
Jednak uważam że narzucona przez pracodawcę metodyka nie jest najlepsza.
Mamy stos pytań technicznych, z którego odpytujemy kandydata.
Moim zdaniem to średnio się sprawdza.

Jak wy przeprowadzacie rozmowy kwalifiakacyjne?

1

Moim zdaniem najlepsze są rekrutację gdzie daje się jakieś zadanie na dwa-trzy dni w stosie technologicznym w jakim firma rekrutuje. Później tylko na rozmowie odpytuje się kandydata dlaczego zrobił to tak a nie inaczej. Rekrutacje oparte na sztywnej puli pytań uważam za słabe bo każdy sobie sobie definiuje, zarówno kandydat jak i pracodawca, co na stanowisku np. regulara jest podstawą.

Edit:
Dawanie zadań bez określonej technologii też jest słabe, spotkałem się z sytuacją gdzie znajomy z pokoju zrobił zadanie - funkcjonalnie ok, ale nie w takim stosie jak oczekiwałby tego pracodawca.

5

Dwóch znajomych w dwóch różnych firmach robi dobre rekrutacje. Dają do zrobienia CRUD (u drugiego kolegi jakieś zadanko z Reacta z racji frontu). Robią code-review, i jeśli się nadaje to zapraszają do siebie. Na rozmowie lekka rozmowa na temat napisanego kodu, i ewentualne pytania dlaczego coś zostało zrobione tak, a nie inaczej. Nie ma nic gorszego niż zadawanie głupkowatych pytań, a w szczególności nie związanych z tematem w którym przyjdzie się poruszać. I tu znowu - lepiej dać zadanie z jakimś sensem niż zaawansowaną algorytmikę gdy w pracy jedyne co przyjdzie robić to selecty i inserty.

Inny znowu pyta o jakiś swój projekt / open-source czy rzeczy robione po godzinach. Często bez zaglądania w kod, i z rozmowy da się wyłapać czy gość wie o czym mówi. Ale tutaj na stanowiska od regulara w górę. Wbrew pozorom luźna rozmowa technologiczna często daje lepszy feedback niż wałkowanie jakichś pytań z kosmosu czy nawet tona zadań.

3
Hispano-Suiza napisał(a):

Wbrew pozorom luźna rozmowa technologiczna często daje lepszy feedback niż wałkowanie jakichś pytań z kosmosu czy nawet tona zadań.

O właśnie, z tym się zgodzę i podkreślę - oprócz jakiegoś otwartego zadani ana 1-2 dni, bardzo dobrze można poznać kandydata, zadając mu luźne pytania, jak by rozwiązał dany problem... albo nawet mówiąc mu cel projektu, a kandydat powinien wskazać potencjalne zagrożenia... rekrutowałem 2 razy, o wiele częściej byłem jednak jako kandydat, i stwierdzam że faktycznie to co napisałem się sprawdza.

10
Black007 napisał(a):

Mam kilkumiesięczne doswiadczenie w rekrutowaniu ludzi.
Jednak uważam że narzucona przez pracodawcę metodyka nie jest najlepsza.
Mamy stos pytań technicznych, z którego odpytujemy kandydata.
Moim zdaniem to średnio się sprawdza.

Jak wy przeprowadzacie rozmowy kwalifiakacyjne?

W przećwiczeniu kandydata pytaniami technicznymi nie ma nic złego. O ile nie są to pytania "teleturniejowe", czyli niepotrzebnie podchwytliwe, dzielące włos na czworo itd.

To, że ktoś nie kojarzy, jak można zamienić wartości dwóch numerycznych zmiennych bez użycia trzeciej, o niczym w zasadzie nie świadczy.

Pytania techniczne powinny jednak służyć bardziej do odsiewania złych kandydatów. Do znajdywania dobrych - to za mało.

Przyjęcie do pracy programisty bez sprawdzenia, jak programuje, to absurd. Czy ktoś zatrudniłby szefa kuchni tylko na podstawie (udanej) przepytanki z teorii żywienia?

Kilka innych, może mniej oczywistych pomysłów:

  • Sprawdzić praktyczną znajomość innych koniecznych w pracy narzędzi. Nie tylko kodowania. Na przykład - systemu kontroli wersji. Bardzo rzadko spotykane na rozmowach. Moim zdaniem niesłusznie. Każdy może wyrecytować, czym różni się system rozproszony od scentralizowanego. Ale jeśli kandydat na seniora nie umie sobie poradzić ze zrobieniem interaktywnego rebase... to nic dobrego nie wróży. Inna umiejętność to debugowanie. To jest sztuka sama w sobie.
  • Umiejętność radzenia sobie z rozwiązywaniem problemów w czasie rzeczywistym. Może to być sesja programowania "pod nadzorem", może być teoretyczna dyskusja (o implementacji, architekturze, algorytmie). Tak czy siak rzucamy kandydatowi kilka kłód pod nogi - zmieniamy założenia, dokładamy wymogi. To taki test inżynierskiej błyskotliwości. Ale też komunikacji. Czy kandydat siada w milczeniu do zadania, czy najpierw dopyta o szczegóły? (Specjalnie zostawiamy kilka niedomówień). I wreszcie daje to pewien wgląd w jego osobowość. Jeśli ktoś kiepsko reaguje na - jak by nie było - pewną formę krytyki podczas rozmowy kwalifikacyjnej... jak będzie się z nim współpracowało w teamie? Może jest zakochany w swoim kodzie i każde code review to dla niego obrona Częstochowy?
  • Skoro o tym mowa - dać mu kawałek kodu do review. To jest istotna część naszego fachu. Czy wyłapie przygotowane niedociągnięcia? Czy umie określić priorytety zastanych problemów - który jest poważny, który raczej kosmetyczny? Czy będzie próbował forsować swoje dogmatyczne przekonania? Czy, przede wszystkim, potrafi zrozumieć cudzy kod, zwłaszcza kiepsko napisany? W końcu kod częściej trzeba czytać, niż pisać.
  • Co się kandydatowi nie podoba w używanym języku programowania, bibliotekach, narzędziach (np. IDE)? Co by zmienił? Dobry profesjonalista zazwyczaj ma swoje zdanie na temat ekosystemu, w którym pracuje. Jeśli komuś nie przychodzi na myśl żadna jego wada, można przypuszczać, że używa idealnego środowiska. Ale takie zainstalują nam dopiero po Sądzie Ostatecznym. A zatem raczej mało je zna, albo niezbyt go to obchodzi. To nie najlepszy znak. Na drugim końcu spektrum sytuują się fanboye i flamerzy o fanatycznym podejściu do technologii. Takich ludzi też warto identyfikować możliwie najwcześniej. Najlepszy kandydat to człowiek z wyrobionym zdaniem, ale pragmatyczny.
  • Znajomość branżowych blogów, newsletterów, książek... Oczywiście nie każdy musi siedzieć nad lekturą dniami i nocami. Ale jeśli "pasjonat z pięcioletnim doświadczeniem", który "programowanie" wstawił sobie nawet w "hobby", potrafi sobie przypomnieć tylko StackOverflow, i że jeszcze jest GitHub, trudno nie nabrać pewnych podejrzeń.
2

Moim zdaniem najlepsze są rekrutację gdzie daje się jakieś zadanie na dwa-trzy dni w stosie technologicznym w jakim firma rekrutuje

Jako kandydat - nie bardzo, bo za te 2-3 dni nikt mi nie płaci a trzeba robić coś niekoniecznie fajnego (najczęściej cruda jak w tutorialu).
Jako techniczny w procesie - też nie bardzo bo często nie ma czasu żeby w ten kod w ogóle zajrzeć.

W samej rozmowie można wyłapać czy ktoś potrafi programować czy nie, zweryfikować praktycznie można to w pierwszych tygodniach pracy.

1

Płacicie za zadania rekrutacyjne? Jeżeli nie to czy ktoś zgadza się pracować za darmo?

Jak ja rekrutowałem to była tylko rozmowa, 1.5 godziny i po niej byłem w stanie wiedzieć czy kandydat się nadaje.

2

Zadania na 2-3 dni są spoko. Szczególnie jak ktoś nie ma dużo doświadczenia to może poćwiczyć.Najgorzej jest jak potem nie ma żadnej odpowiedzi. Ja ostatnio tak miałem. Zadanie poszło. Po zadaniu miałem zaproszenie na techniczną rozmowę (zdalnie) i tego samego dnia miała być informacja zwrotna. Tydzień minął i nic. Ehh

8

Problem z "zadaniami na 2-3 dni" jest taki, że nie każdy ma tyle samo wolnego czasu. Nie mamy wiecznie po 25 lat. Jeden kandydat jest wolny jak ptak, drugi ma małe dzieci. Obaj świetnie radzą sobie w codziennej pracy, ale jeśli mają wygospodarować dodatkowy czas na spore zadanie domowe - to są już w bardzo różnej sytuacji.

Oczywiście bywają ustalenia elastyczne: "niech pan poświęci na to z 2 dni, ale ja wiem, że mały Krzysiu panu kaszle... więc przysłać można jak będzie gotowe... umówmy się na spokojnie, że do końca przyszłego tygodnia". Niby super. Tylko powstaje wtedy inny problem. Nikt nie sprawdzi, czy praca rzeczywiście zajęła 2 dni. A zatem konkurujemy z kandydatami, którzy nie musieli latać po syropek dla Krzysia, tylko siedzieli nad zadaniem 7 dni. (Czy nawet cały tydzień).

Nie mówiąc już o tym, że kiedy składamy CV do trzech różnych firm - nie jest to wiele - to nawet z tych teoretycznych, krótkich czasów składa się nam nagle już 6 do 9 dni :) Można powiedzieć "to problem kandydata". Ale to jest także nasz problem. Bo znaczy, że nasz filtr rekrutacyjny zaczyna źle działać. Będzie premiował ludzi, którzy mają bezmiar czasu wolnego. Nie musi to wcale oznaczać wyższych kompetencji.

Firma ma prawo oczekiwać od kandydata, że zainwestuje czas w swoją aplikację, może nawet weźmie wolne. Ale logiczna zasada jest taka - im więcej sama firma sobą reprezentuje, tym większej inwestycji ma prawo oczekiwać. Google czy Apple mogą sobie zlecać zadania domowe na kilka dni, bo to są marki. Żeby tam się dostać, utalentowani ludzie będą siedzieć po nocach. W przypadku firmy "CEO Rychu & CTO Zbychu Software, Inc." jest to trochę śmieszne. Szczególnie na wczesnym etapie rekrutacji, gdy perspektywy pracy wciąż są niejasne. A i sam kandydat nie ma jeszcze klarownego obrazu firmy i stanowiska.

3

Ostatnio słyszałem ciekawy pomysł, żeby nie dawać kodu do napisania od zera, tylko dać jakiś istniejący kod i kazać coś do tego kodu dopisać/coś zmienić, ewentualnie powiedzieć co by się zrobiło inaczej. Bardziej to oddaje codzienną prace niż szybkie naklepanie CRUDa

0
danek napisał(a):

Ostatnio słyszałem ciekawy pomysł, żeby nie dawać kodu do napisania od zera, tylko dać jakiś istniejący kod i kazać coś do tego kodu dopisać/coś zmienić, ewentualnie powiedzieć co by się zrobiło inaczej. Bardziej to oddaje codzienną prace niż szybkie naklepanie CRUDa

To ja dziękuję. Już raz dostałem takie zadanie. Kompletnie z d... Miałem sobie wziąć wyimaginować sobie bazę nie znając jej struktury, nie mogąc do niej zajrzeć, nie wiedząc jakie dane ma w sobie, a następnie obsłużyć jakieś wyimaginowane wyjątki, errory, i tym podobny stuff. Strasznie rozsądne zadanie na dwa zdania do którego miałem pytania, a jednocześnie nie miałem komu ich zadać ;-)
I tutaj definitywnie skończyłem w większości przypadków z rozwiązywaniem zadań kompletnie z d...

2
danek napisał(a):

Ostatnio słyszałem ciekawy pomysł, żeby nie dawać kodu do napisania od zera, tylko dać jakiś istniejący kod i kazać coś do tego kodu dopisać/coś zmienić, ewentualnie powiedzieć co by się zrobiło inaczej. Bardziej to oddaje codzienną prace niż szybkie naklepanie CRUDa

Podsunąłem taki pomysł na tym forum 2 tygodnie temu :) https://4programmers.net/Forum/1597812

2

Klepanie CRUDa na rekrutację jest bez sensu. Niewiele wnosi, a jak się tak zastanowić do jakiego stopnia ma być zrobiony to może być robotą na 4h albo 4 dni po 8h. A koniec końców i tak nie będzie w nim niczego, czego nie dałoby się wyjąć z jakiegoś tutorialu ;) nie mówiąc o paskudnym zwyczaju nie dawania feedbacku, bo czas rekrutera jest cenny ale Twój już nie.

Już bardziej mi się podobała rekrutacja gdzie CRUD z jakąś tam logiką i testami już był, tylko trzeba było wyłapać jakieś błędy i niedoróbki (i uzasadnić czemu to jest niedoróbka)

3

Najlepsze, według mnie, sposoby rekrutacji.

  1. Zaprosić kogoś na cały dzień do siebie, razem rozwiązywać zadania, zjeść obiad itd. Oczywiście ogromna wada jest taka, że taki proces jest kosztowny.
  2. Pair programming. Dajemy kod jakiejś aplikacji, do której trzeba coś dorobić, dodajemy w kodzie gdzieś jakiś błąd albo kilka, żeby sprawdzić, jak kandydat myśli i rozwiązuje przeszkody i piszemy razem tak od godziny do dwóch.
  3. Zadanie do domu, które można zrobić w 2, 3 wieczory do oddania np. na za dwa tygodnie. Nie ma presji czasu, bo jeśli ktoś potrzebuje więcej niż 3 dni, to może zawsze wykorzystać. Nie widzę problemu, że ktoś zadanie kilkudniowe będzie rozwiązywał dłużej, bo może będzie miał naprawdę super rozwiązanie. Potem przy dyskusji i tak mniej więcej wyjdzie, ile coś zajęło i to też nie jest straszne, jeśli komuś zejdzie na to dłużej, jeśli kod jest ładny. Tempo zawsze można wyszlifować.

Najgłupsza rozmowa jaką miałem, to było zadanie do domu na dwa wieczory, o którym nie rozmawialiśmy potem w ogóle i byłem pytany z rzeczy związanych z Androidem. Nawet słowem nie wspomnieli o nim, a jak chciałem sam nawiązać do tego, to moja prośba została zignorowana.

0
Michał Sikora napisał(a):

Najlepsze, według mnie, sposoby rekrutacji.

  1. Zaprosić kogoś na cały dzień do siebie, razem rozwiązywać zadania, zjeść obiad itd. Oczywiście ogromna wada jest taka, że taki proces jest kosztowny.

Też tak myślałem dopóki nie trafiłem oferty w której taki proces rekrutacji występuje 400km ode mnie. Raczej kiepsko wstać o 3 żeby wyjechać o 4 w celu zameldowania się w firmie na 9, przerobienia całego dnia, i powrotu o 17 kolejnych 400km do miejsca docelowego.

Michał Sikora napisał(a):
  1. Pair programming. Dajemy kod jakiejś aplikacji, do której trzeba coś dorobić, dodajemy w kodzie gdzieś jakiś błąd albo kilka, żeby sprawdzić, jak kandydat myśli i rozwiązuje przeszkody i piszemy razem tak od godziny do dwóch.

To też często jest przeszkodą. Zwłaszcza jeżeli ma się na głowie chaotyczną rodzinę za plecami ;-)

Michał Sikora napisał(a):
  1. Zadanie do domu, które można zrobić w 2, 3 wieczory do oddania np. na za dwa tygodnie. Nie ma presji czasu, bo jeśli ktoś potrzebuje więcej niż 3 dni, to może zawsze wykorzystać. Nie widzę problemu, że ktoś zadanie kilkudniowe będzie rozwiązywał dłużej, bo może będzie miał naprawdę super rozwiązanie. Potem przy dyskusji i tak mniej więcej wyjdzie, ile coś zajęło i to też nie jest straszne, jeśli komuś zejdzie na to dłużej, jeśli kod jest ładny. Tempo zawsze można wyszlifować.

+1

Michał Sikora napisał(a):

Najgłupsza rozmowa jaką miałem, to było zadanie do domu na dwa wieczory, o którym nie rozmawialiśmy potem w ogóle i byłem pytany z rzeczy związanych z Androidem. Nawet słowem nie wspomnieli o nim, a jak chciałem sam nawiązać do tego, to moja prośba została zignorowana.

Przechodziłem przez takie coś więc współczuję :D

2
Hispano-Suiza napisał(a):

Też tak myślałem dopóki nie trafiłem oferty w której taki proces rekrutacji występuje 400km ode mnie. Raczej kiepsko wstać o 3 żeby wyjechać o 4 w celu zameldowania się w firmie na 9, przerobienia całego dnia, i powrotu o 17 kolejnych 400km do miejsca docelowego.

No to jest problem czasem niestety i szkoda, jeśli jest tak daleko, ale nie widzę problemu jeśli firma rekrutująca płaci za przejazd, nocleg itd. Sam nie musiałem nigdy tak daleko jechać, ale nieraz słyszałem o sytuacji, że ludzie latali do innego miasta, Szwajcarii, Stanów czy gdzieś i mieli wszystko opłacone. Taka postawa świadczy o tym, że firmie bardzo zależy na tym kogo zatrudniają i inwestują w ludzi. Więc jeśli ktoś inwestuje w ten sposób w potencjalne zatrudnienie, to jest dla mnie ok odwzajemnienie tego poświęcając swój czas na to.

0

Zadania są super ale takie na 1-2 godziny. To że warto dać kandydatowi więcej czasu na jego zrobienie to co innego.

1

Możesz podać przykład zadania na 1-2 godziny, które mi pozwoli zweryfikować czyjąś wiedzę i porozmawiać o czymś konkretnym dotyczącym kodu?

1

Kreda, tablica, jakiś randomowy task z serii logiczne zagadki i jazda
Rekruter z całym działem IT siedzą w ławkach jak uczniowie i komentują :P

0
V-2 napisał(a):

Problem z "zadaniami na 2-3 dni" jest taki, że nie każdy ma tyle samo wolnego czasu. Nie mamy wiecznie po 25 lat. Jeden kandydat jest wolny jak ptak, drugi ma małe dzieci. Obaj świetnie radzą sobie w codziennej pracy, ale jeśli mają wygospodarować dodatkowy czas na spore zadanie domowe - to są już w bardzo różnej sytuacji.

Oczywiście bywają ustalenia elastyczne: "niech pan poświęci na to z 2 dni, ale ja wiem, że mały Krzysiu panu kaszle... więc przysłać można jak będzie gotowe... umówmy się na spokojnie, że do końca przyszłego tygodnia". Niby super. Tylko powstaje wtedy inny problem.

Programista to ktoś, od kogo oczekuje się umiejętności rozwiązywania problemów. Jeśli nie umie zamknąć Krzysia w szafie na kilka godzin, to raczej się do tej pracy nie nadaje.

Nikt nie sprawdzi, czy praca rzeczywiście zajęła 2 dni. A zatem konkurujemy z kandydatami, którzy nie musieli latać po syropek dla Krzysia, tylko siedzieli nad zadaniem 7 dni. (Czy nawet cały tydzień).

Dlatego po takim zadaniu domowym robi się godzinną sesję pair-programming, i każe wprowadzić jakieś drobne zmiany. No i wtedy wychodzi jakie tempo ma kandydat.

Michał Sikora napisał(a):

Możesz podać przykład zadania na 1-2 godziny, które mi pozwoli zweryfikować czyjąś wiedzę i porozmawiać o czymś konkretnym dotyczącym kodu?

Konsolowy konwerter z CSV na JSON z możliwością dodawania obsługi nowych formatów bez potrzeby ponownej kompilacji głównej aplikacji.

5
somekind napisał(a):
V-2 napisał(a):

Problem z "zadaniami na 2-3 dni" jest taki, że nie każdy ma tyle samo wolnego czasu. Nie mamy wiecznie po 25 lat. Jeden kandydat jest wolny jak ptak, drugi ma małe dzieci. Obaj świetnie radzą sobie w codziennej pracy, ale jeśli mają wygospodarować dodatkowy czas na spore zadanie domowe - to są już w bardzo różnej sytuacji.

Oczywiście bywają ustalenia elastyczne: "niech pan poświęci na to z 2 dni, ale ja wiem, że mały Krzysiu panu kaszle... więc przysłać można jak będzie gotowe... umówmy się na spokojnie, że do końca przyszłego tygodnia". Niby super. Tylko powstaje wtedy inny problem.

Programista to ktoś, od kogo oczekuje się umiejętności rozwiązywania problemów. Jeśli nie umie zamknąć Krzysia w szafie na kilka godzin, to raczej się do tej pracy nie nadaje.

Tak i samochody naprawiać, i ludzi leczyć powinien... w końcu oczekuje się rozwiązywania problemów ;) Z własną rodziną przede wszystkim.

A mowa była nie o "kilku godzinach" (zgoda), tylko o kilku dniach.

Przy zatrudnianiu kucharza nie powie mu się: "to niech pan przyjdzie u nas gotować przez tydzień, a my się zastanowimy". To się zdarza, owszem - ale nazywa się (w każdej branży) STAŻEM, i opiera się na innych założeniach.

W zaproszeniu kucharza na jedną zmianę nie byłoby nic dziwnego. Jeśli restauracja nie jest w stanie ocenić po takiej próbce pracy, czy ktoś się do niej nadaje - może coś jest nie tak z kompetencjami rekrutacyjnymi?

Podobnie jak dziennikarz zgłasza się do pracy w redakcji, to będzie miał rozmowę, przyniesie swoje portfolio itd. Ale jest naprawdę mało prawdopodobne, że usłyszy: "to niech pan teraz jedzie do Inowrocławia zrobić reportaż o wyścigach kotów, porozmawia z ludźmi, przepyta ekspertów, za tydzień czekam na materiał, a wtedy może się zastanowię, czy w ogóle dalej rozmawiamy, bo takich samych reportaży będę miał dziesięć".

To dlaczego akurat w naszej branży mielibyśmy się godzić na takie traktowanie?

Nikt nie sprawdzi, czy praca rzeczywiście zajęła 2 dni. A zatem konkurujemy z kandydatami, którzy nie musieli latać po syropek dla Krzysia, tylko siedzieli nad zadaniem 7 dni. (Czy nawet cały tydzień).

Dlatego po takim zadaniu domowym robi się godzinną sesję pair-programming, i każe wprowadzić jakieś drobne zmiany. No i wtedy wychodzi jakie tempo ma kandydat.

Przy założeniu, że każdy, kto złożył zadanie, zostaje zaproszony do jakiegoś następnego etapu. Założeniu mało realistycznym. Może i "robi się" - ale w praktyce mało kto zrobi :) Bo firma nie będzie rozpisywać sobie w kalendarzu np. dwunastu takich sesji pair programming, jeśli może wybrać z nadesłanych rozwiązań najlepszą czwórkę.

Hispano-Suiza napisał(a):
danek napisał(a):

Ostatnio słyszałem ciekawy pomysł, żeby nie dawać kodu do napisania od zera, tylko dać jakiś istniejący kod i kazać coś do tego kodu dopisać/coś zmienić, ewentualnie powiedzieć co by się zrobiło inaczej. Bardziej to oddaje codzienną prace niż szybkie naklepanie CRUDa

To ja dziękuję. Już raz dostałem takie zadanie. Kompletnie z d... Miałem sobie wziąć wyimaginować sobie bazę nie znając jej struktury, nie mogąc do niej zajrzeć, nie wiedząc jakie dane ma w sobie, a następnie obsłużyć jakieś wyimaginowane wyjątki, errory, i tym podobny stuff.

To jest źle pomyślane zadanie. Pomysł z dokończeniem powinien zakładać, że kandydat dokańcza istniejący projekt, a nie jakiś hipotetyczny.

Czyli tak, jak (przeważnie) w prawdziwej pracy.

1

Po 2 latach przeprowadzania rekrutacji.

  • zadania domowe rekrutacyjne daję stażystom / osobom bez doświadczenia / freelancerom / osobom, które ewidetnie mają coś podejrzanego np. brak studiów i tylko bootcamp.
  • <= junior to do 2h rozmowy
  • = regular 2h+ rozmowy

Rozmowę zaczynam od CV. Tutaj głównie próbuję wyłapać czy kandydat nie ściemnia i jakie ma doświadczenie.

Za każdym razem kandydat musi napisać kod na tablicy, nie ma sytuacji, że przepuszczamy kogoś bez pokazania swoich umiejętności.
Nigdy nie stosuję laptopa z IDE i kodem -> moim zdaniem jeden z najgorszych pomysłów.
Zawsze proszę o pisanie kodu w dowolnym języku / pseudocodzie. Zakładam, że ktoś kto ma 3-10 lat doświadczenia, będzie w stanie na tablicy pokazać i powiedzieć -> "to jest lista, nie pamiętam jak nazywa się metoda do dodawania elementów w Javie, ale w większości języków to będzie push więc taką zastosuję", jeśli w trakcie rozmowy np. się zestresuje, czegoś zapomni itp

Przeważnie pisanie kodu na tablicy pokazuje na ile ktoś konkretnie programuje i rozumie co robi. Chciałbym przefiltrować osoby, które na "czuja" programują.
Pokazuje na ile kandydat jest ogarnięty bo np. jeśli np. PHP developer z wątpliwymi umiejętnościami na w/w zdanie, reaguje, że "no to pamiętam C i w tym napiszę zadanie" zamiast w pseudocodzie to strzela sobie w stopę.

Mam przygotowany przekrój historyjek z kontekstem i klientem w roli głównej, który prosi o implementację czegoś tam -> i kandydat musi zastanowić się nad problemem + interakcją z klientem. Historyjki dotyczą głównie różnych sytuacji problematycznych z systemu np. synchronizacje, programowanie asynchroniczne w jsie, skalowanie, projektowanie bazy danych itp itp. Głównie tematyka związana z tym co będzie robił w projekcie.

Zawsze też zadaję 1-2 podchwytliwe pytania, które sprawdzają osobowość kandydata np. przy rekrutacji na Java Developera: "Słuchaj, przychodzi do Ciebie kolega w pracy i mówi, że Java to najgorszy język na świecie i dużo lepiej będzie jak przepiszecie wszystko na PHP - jak reagujesz?"

2

Osobiście preferuję jakieś zadanie do wykonania. Wolę to rozwiązanie niezależnie czy to ja rekrutuję czy jestem rekrutowany. Tylko oczywiście bez przesady, zadanie do zrobienia na te +/- 4h (jeśli kandydat pracuje w tym stacku, inaczej wiadomo ze może zając mu coś więcej). I oczywiście bufor kilka dni na wykonanie.

Kiedyś miałem rekrutacje gdzie gośc mial liste chyba 100 pytań i leciał jedno po drugim. przerobilismy moze połowe bo mega dużo czasu to zajmuje, oczywiście większość dotyczyło kruczków języka nie wykorzystywanych na codzień.
Pair programmingu nie lubię, same rozmowy są stresem a co dopiero programować z obcą osobą.

1

Kiedyś miałem rekrutacje gdzie gośc mial liste chyba 100 pytań i leciał jedno po drugim. przerobilismy moze połowe bo mega dużo czasu to zajmuje, oczywiście większość dotyczyło kruczków języka nie wykorzystywanych na codzień.

Czemu rekruterowi nie przerwałeś i mu nie zwróciłeś uwagi, że to absurd / nie wyszedłeś z rozmowy?

3
saviolaa napisał(a):

Kiedyś miałem rekrutacje gdzie gośc mial liste chyba 100 pytań i leciał jedno po drugim. przerobilismy moze połowe bo mega dużo czasu to zajmuje, oczywiście większość dotyczyło kruczków języka nie wykorzystywanych na codzień.

Ciekawi mnie jaka jest Wasza reakcja gdy kandydat mówi "wiem, że dana konstrukcja jest tricky, jak ją używam to sprawdzam w dokumentacji"?

4

Przechodziłem przez różne rekrutacje, poniżej kilka przykładów (wspominam przykłady po których dostałem ofertę pracy - wypieram negatywne rozmowy z umysłu :) ):

  • rozmowa dla polskiego oddziału międzynarodowego korpo - 3.5h całość po angielsku - test + techniczne pytania + zadanie przy tablicy - za długo zdecydowanie, po takim czasie czujesz się wyprany i zmęczony, mogliby sobie darować godzinę, nie jest to komfortowe dla kandydata, poniekąd rekrutacja odrzuciła mnie od tej firmy,
  • software house - prawie 3h angielsko/polski - klepanie kodu na laptopie podłączonym do rzutnika + techniczne pytania - fajna, wymagająca rozmowa, ale naprawdę czułem się dobrze po rozmowie
  • międzynarodowe korpo - 45 minut polski/angielski - luźna rozmowa + kilka pytań technicznych + luźno angielski - wg mnie rozmowa była zbyt luźna i za łatwo poszło, jednakże czułem, że mam wiedzę większą od osoby zadającej pytania może dlatego trwała tak krótko.

Miałem okazje rekrutować do mojej obecnej firmy kilku nowych programistów. Po moich własnych doświadczeniach stwierdziłem, że najlepsza będzie rozmowa wraz z pytaniami.Te pytania są różne czasem stricte techniczne, niekiedy wymagające opisu jak kandydat rozwiązał problem x - często coś mi się nasuwa na bieżąco w trakcie trwania rozmowy mają na celu odpowiedzieć na następujące pytania:

  • czy dane w CV są zgodne z prawdą (panuje ciekawa zależność im lepsze CV tym większa ściema, kiedyś miałem kandydata, który opisał technologie nam bardzo przydatną, a okazało się, że jakaś zewnętrzna firma projektowała pewne rozwiązanie i kandydat wiedział, że oni pisali to we frameworku XY i na tym jego wiedza się skończyła, ale wpisał to w CV)
  • na ile jego wiedza/technologie będą przydatne do różnorodnych projektów jakie posiadamy,
  • czy kandydat interesuje się programowaniem, pytania o nowinki etc.,
  • patrzę też na sposób wypowiedzi tzn. czy są to formułki z książki, czy kandydat stara mi się wytłumaczyć jak dane pojęcie rozumie, bardziej niż wykutej formułki wolę stwierdzenia "użyłem tego, ale napotkałem problemy X i Y, próbowałem to rozwiąząć tak ...".

Rozmowa jest tylko rozmową i wg mnie proces rekrutacji nie odpowie nam na 100 % czy dany kandydat nadaje się do roboty, możemy jedynie przefiltrować kompletnie nienadające się jednostki od tych co rokują i będą wartością dodaną dla naszego zespołu. Dlatego nie ma też sensu tracić na niego x godzin.

0

Przez cały wątek nikt nawet nie wspomniał o codility? Nikt już tego nie uzywa? :P

Btw brakuje mi troche ankiety ale póki co chyba większość wolałaby dostać zadanie?

0
saviolaa napisał(a):

Przez cały wątek nikt nawet nie wspomniał o codility? Nikt już tego nie uzywa? :P

Ze wszystkich rekrutacji, które przechodziłem (powiedzmy z zadaniem praktycznym to było ich koło 7) raz mi się zdarzył Codility a ostatnio jeszcze TestDome.

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