Jak dobrze rekrutować programistów?

Wciąż mam niewielkie doświadczenie w byciu po tej drugiej stronie i rekrutowaniu.

Mój obecny styl rekrutacji na stanowiska mid i senior wygląda następująco:

• manager i ja opowiadamy o projekcie
• sekcja pytań miękkich (o osiągniecia, co fajnego ostatnio robił itp)
• sekcja techniczna
  • 2 pytania o jakieś podstawy
  • potem jakieś 2 pytania bardziej zaawansowane
  • pytanie otwarte, gdzie jest to bardziej dyskusja, sprawdzenie jakie kandydat ma doświadczenia i pomysły, jak rozumuje
  • tutaj w zależności czego mi brakuje, dopytuje jeszcze o techniczne rzeczy lub miękkie (typu jakie odpowiedzialności w projekcie itp).
• czas na pytania kandydata

Zazwyczaj daje mi to ogólny obraz wiedzy (czy ktoś rozumie takie powszechne rzeczy, na ile głęboko rozumie - przy okazji jak kandydat jest dobry to dopytuję, żeby zbadać głębię, jak jest słaby to zadaję pomocnicze pytanie, żeby zobaczyć czy ogólnie dobrze rozumuje). Moim ulubionym pytaniem jest to otwarte, gdyż to pokazuje rozumowanie i doświadczenie (i to daje mi obraz tej osoby).

Pomyślałam, że może Wy podzielicie się swoimi sposobami, spostrzeżeniami itp.

I teraz moje obawy:

• Pytań teoretycznych można się nauczyć i zakładając, że ktoś lubi chodzić na rozmowy i trochę mam obawę, żeby mi taki "teoretyk nie przeszedł", co nabył swobody w rekrutacjach ale niekoniecznie idzie za tym wartość tej rangi.
• Jak wyłapać, że ktoś będzie problematyczny np. w komunikacji

szarotka napisał(a):

• sekcja pytań miękkich (o osiągniecia, co fajnego ostatnio robił itp)

sekcja pytania wnerwiających kandydata

• sekcja techniczna
  • 2 pytania o jakieś podstawy

obrażających kandydata

• potem jakieś 2 pytania bardziej zaawansowane
• pytanie otwarte, gdzie jest to bardziej dyskusja, sprawdzenie jakie kandydat ma doświadczenia i pomysły, jak rozumuje

a w jaki sposób wykrywasz JAK rozumuje?

• tutaj w zależności czego mi brakuje, dopytuje jeszcze o techniczne rzeczy lub miękkie (typu jakie odpowiedzialności w projekcie itp).

gdzie pytanie jakim jesteś zwierzęciem ?

Zazwyczaj daje mi to ogólny obraz wiedzy (czy ktoś rozumie takie powszechne rzeczy, na ile głęboko rozumie - przy okazji jak kandydat jest dobry to dopytuję, żeby zbadać głębię, jak jest słaby to zadaję pomocnicze pytanie, żeby zobaczyć czy ogólnie dobrze rozumuje). Moim ulubionym pytaniem jest to otwarte, gdyż to pokazuje rozumowanie i doświadczenie (i to daje mi obraz tej osoby).

Pomyślałam, że może Wy podzielicie się swoimi sposobami, spostrzeżeniami itp.

ponawiam pytania w jaki sposób wiesz jak rozumuje? telepatia?

I teraz moje obawy:

• Pytań teoretycznych można się nauczyć i zakładając, że ktoś lubi chodzić na rozmowy i trochę mam obawę, żeby mi taki "teoretyk nie przeszedł", co nabył swobody w rekrutacjach ale niekoniecznie idzie za tym wartość tej rangi.
• Jak wyłapać, że ktoś będzie problematyczny np. w komunikacji

no ale przecież wiesz jak rozumuje, to wiesz też pewnie jak się komunikuje(ironia)

właśnie opisałaś jak rekrutować juniora

a ja kurcze po prostu z ludźmi rozmawiam, oldskoolowa jestem

Miang jestem otwarta na sugestie, by ulepszyć jako że jak napisałam, mam stosunkowo małe doświadczenie w tym zakresie.
Jak napisałam, mam pytanie otwarte, gdzie stawiam problem i zaczynam dyskusję - to pokazuje jakie ktoś ma doświadczenia, jak rozumuje (to nie jest pytanie z jedną dobra odpowiedzią), tylko kwestia co ktoś bierze pod uwagę.

Miang napisał(a):

a ja kurcze po prostu z ludźmi rozmawiam, oldskoolowa jestem

Jak prowadzisz tę rozmowę? Jakie tematy poruszasz?

Bądź konstruktywna w swojej krytyce.

Co do pytań miękkich, dla mnie one są istotne jeśli poruszają kwestie:

• doświadczenie/styl pracy w poprzednich projektach
• obowiązki i odpowiedzialności
• pytając o osiągnięcie na początku, daję kandydatowi się wykazać/rozluźnić, może pochwalić się swoimi mocnymi stronami a ja mogę dać mu w głowie podświadomie plusa, są rzeczy które nie wyjdą w pytaniach technicznych, więc warto żeby kandydat sam się pochwalił czymś ciekawym co robił. Dodam jeszcze, że sporo osób marnuje ta szansę, szansę porozmawiania o czymś w czym dana osoba jest mocna i mogłaby tą wartość wnieść do zespołu. Jeżeli ktoś wymieni swoje mocne strony, to ja lubię kontynuować, dopytać i potem w feedbacku to uwzględnić.

Najlepsze rekrutacje jakie miałem to po prostu rozmowa. Rozmawialiśmy o tym co umiem, co robiłem w poprzedniej pracy, czy znam XYZ, jak się zapatruję na poznanie ABC itd. Zero jakiś durnych zadań, stresującego live codingu, testów itd. Po prostu zwykła rozmowa gdzie obie strony mogą sie zorientować. Niestety jest to rzadki sposób rekrutacji :(

U mnie wygląda to tak:

• Opowiadam o projekcie,
• Pytam się o projekty z poprzednich miejsc pracy kandydata, by opowiedział co robił, czy były jakieś ciekawe zadania/przypadki. To od razu prowadzi mnie dalej, jeśli coś mnie zainteresuje, to dopytuję o szczegóły. Np. jeśli opowiada o jakiś problemach, to się go pytam, czy po wszystkim ma jakieś przemyślenia i jak inaczej teraz by to zrobił. Staram się nie zadawać wprost pytań typu, czy wiesz czym jest interface, itd. Lubię też pytać o technologie, które ma kandydat w CV, na zasadzie, w którym projekcie używał, jego przemyślenia na ten temat, itd.
• Mam też jedno pytanie kontrolne, które jest mi po to bym mógł "skalibrować" kandydatów. Zadaję na każdej rozmowie to samo pytanie.
• Gatkę/szmatkę zostawiam na koniec, by się dowiedzieć czy leżą im moje żarty XD

Czy ja dobrze przeczytałem, nie kodujecie tam? W gębie każdy mocny, nie jeden kozak opowiada rzeczy niestworzone, historie i przygody kolegów na produkcji lub wciela się w swojego uwczesnego team-leada. Dlatego dla mnie podstawą interview jest zadanie techniczne, a pytania otwarte są tylko po to by odsiać zaburzonych, buców i psychopatów.

W zależności od projektu można mieć:

• Zadanie algorytmiczne tam gdzie wszystko jest custom, a więc wiedza powszechna typu Spring i tak nie miała by znaczenia.
• Zadanie techniczne w dokładnie takich tech'ach jak są w projekcie. To zadanie w formie zadania domowego + omówienie na interview.

Jeśli już pytać to o rzeczy rzadkie które świadczą o "ubrudzeniu sobie rączek na produkcji":

• Do czego można wykorzystać heapdump a do czego thread dump?
• Jak byś zmigrował schemat dużej bazy danych na produkcji do nowszej wersji?
• Robisz dashboard dla aplikacji X, jakie metryki powinny się na nim znaleźć?
• W jaki sposób przetestować funkcjonalność obejmującą 5 różnych mikroserwisów?
• Czy test coverage jest ważne? W jaki sposób należy z niego korzystać?

Na role senior co najmniej 3 lata pracy w jednym miejscu (i nie jako konsultant).

Dobry angielski, bez tego obecnie ani rusz. Testować rozmową lub prowadząc cały interview po angielsku. Ewentualnie wysyłając opisy zdań po angielsku.

Zapytać jakie ksiażki ostatnio czytał/a? Lub kursy robił? Jeżeli nic nie czytał i nic nie robił, a pojechał tylko na konfę z budżetu firmowego to czerwona chorągiewka się należy.

szarotka napisał(a):

Miang jestem otwarta na sugestie, by ulepszyć jako że jak napisałam, mam stosunkowo małe doświadczenie w tym zakresie.
Jak napisałam, mam pytanie otwarte, gdzie stawiam problem i zaczynam dyskusję - to pokazuje jakie ktoś ma doświadczenia, jak rozumuje (to nie jest pytanie z jedną dobra odpowiedzią), tylko kwestia co ktoś bierze pod uwagę.

jak oceniasz jego rozumowanie jeśli wykracze poza Twoje doświadczenie? jak ustalasz te "kilka dobrych odpowiedzi" co robisz jak odpowiedź Ci nie podpasuje, czy wychodzisz ze strefy komfortu i próbujesz rozważyć że gościu może mieć rację ?

Miang napisał(a):

a ja kurcze po prostu z ludźmi rozmawiam, oldskoolowa jestem

Jak prowadzisz tę rozmowę? Jakie tematy poruszasz?

Bądź konstruktywna w swojej krytyce.

nie stawiam kategorycznych żądań pokazujących że mam niby jakąś władzę

Co do pytań miękkich, dla mnie one są istotne jeśli poruszają kwestie:

• doświadczenie/styl pracy w poprzednich projektach
• obowiązki i odpowiedzialności
• pytając o osiągnięcie na początku, daję kandydatowi się wykazać/rozluźnić, może pochwalić się swoimi mocnymi stronami a ja mogę dać mu w głowie podświadomie plusa, są rzeczy które nie wyjdą w pytaniach technicznych, więc warto żeby kandydat sam się pochwalił czymś ciekawym co robił. Dodam jeszcze, że sporo osób marnuje ta szansę, szansę porozmawiania o czymś w czym dana osoba jest mocna i mogłaby tą wartość wnieść do zespołu. Jeżeli ktoś wymieni swoje mocne strony, to ja lubię kontynuować, dopytać i potem w feedbacku to uwzględnić.

to nie są pytania miękkie tylko upierdliwe.
a gdzie pytanie jakim zwierzęciem jesteś?

szarotka napisał(a):

• Jak wyłapać, że ktoś będzie problematyczny np. w komunikacji

Nie powinnaś brać na siebie całej odpowiedzialności za kandydata. Rozumiem, że będziecie razem w projekcie, więc ci na tym zależy, ale ta część powinna należeć na HR i być sprawdzona przed rozmową z tobą, np. podczas "culture fit". Oni się na tym znają, mają całe szkolenia na temat rekrutacji, a nawet specjalizacje w konkretnych dziedzinach. Dzięki temu będziecie mieli dużo większe prawdopodobieństwo, że będą trafiali tylko "właściwi" ludzie, a ty będziesz mogła skupić się na ocenianiu tego, do czego rzeczywiście masz kompetencje

Ja lubię, gdy rozmowa "płynie". Po prostu rozmawiamy co robiłem, co chciałbym robić, a czego nie. Jakie projekty udało się zrealizować, jakie problemy napotkałem i fajnie jak druga strona dopowiada i przedstawia jak to jest realizowane w projekcie. Można wpleść jakiś live coding, ale lepiej by to było coś prostego i szybkiego bez żadnych narzędzi, aby dodać pewności siebie kandydatowi.

Mój najnowszy pomysł na rekrutację, to wzięcie jakiegoś PR z przeszłości i poproszenie kandydata o zrobienie code review. Jest to mniej stresujące niż live coding, a także pozwala kandydatowi zapoznać się z tym jak wygląda kod od środka i daje pretekst do dłuższej rozmowy.

Rozmowa o projekcie spoko. To powinien być również wstęp do rozmowy technicznej. Mówicie o swoich rozwiązaniach i na tej podstawie pytacie kandydata jak to wygląda technicznie u niego - Architektura, testy itp. Na podstawie tego opowiadania można wchodzić w inne pytania techniczne i już wtedy widać, czy gość mówi z sensem, czy bajdurzy / unika pytań. IMO sztywne pytanie rodem z "100 the most popular java questions" mija się z celem. Natomiast rozmowa w oparciu o projekt kandydata / Wasz projekt ładnie obnaży kolegę, jeśli nie ma o tym pojęcia.

Warto porozmawiać o zarządzaniu w projekcie, żeby miał obraz jak to wygląda i przy okazji zobaczyć czy umie np w scrumy (jeśli używacie).

Co do problemów w komunikacji to można bawić się w pytania typu co byś zrobił gdy by. Jednak jak trafisz na cwaniaczka, który umie markować to zwyczajnie powie to co chcecie usłyszeć. Takie rzeczy po prostu wychodzą w pracy.

Jak wyłapać, że ktoś będzie problematyczny np. w komunikacji

Zapytać jakby postąpił jeśli w zespole miałby nowa osobę ktora potrzebowałaby wdrożenia a on miał swoją pracę do wykonania.

Co byłoby dla niego priorytetem, pomoc tej osobie czy zajęcie się swoimi zadaniami?

Jeśli odpowiedziałby że dla niego priorytetem byłoby dowiezienie swoich zadań i zignorowanie pytań innej osoby, ignorowanie, to jest to ewidentny znak że koleś nie jest team Playerem.

Za dużo samolubów w typie JA, JA, JA się zdarza a przydałoby się ich jakoś odsiac.

Inne dobre pytanie - jak traktuje mniejszości - osoba z innego kraju, kobieta, osoba starsza. Zbadać czy jest wyznawca tego że pochodzenia, płeć lub wiek determinuje predyspozycje. W IT jest grono fanów konfederacji którzy w w pracy maskują swoje poglądy a w internecie są zdolni do naśmiewania się z kobiet w HR, kobiet w IT, hindusów, starszych, młodszych. Takich przydałoby się odsiać bo to największe toksyny.

Sprawdziły by się również pytania kulturowe - np. podać przykład sytuacji z wyżej postawionym klientem i jak zachowałby się w danej sytuacji. Np. w kalendarzu nakładają mu się dwa spotkania - z klientem i że jego kolegami, co zrobi - nie przyjdzie na jedno (które?), odwoła, przełoży.

Podczas przepytywanek to się rzygać chce (normalnemu) kandydatowi i sam osobiście raz udałem, że odłączyło mi prad bo nie chciało mi się już bawic w Familiade czy Milionerów

Jak to jak. Wyciągasz nienaturalny nigdzie nie występujący case i sprawdzasz czy kandydat nauczył się standardu na pamięć i zna każdy najmniejszy niuans, żeby zbić mu pensje a potem żeby w robocie pisał testy jednostkowe xD

Co Ty nowy w tej branży, że trzeba Cię uczyć?

W sumie to zadałbym jedno pytanie, na które wymagałbym bardzo obszernej odpowiedzi (najlepiej popartej próbkami kodu).

Chciałbym dowiedzieć się jakie oczekiwania i zarazem wymagania ma kandydat w kwestii rozwijania / utrzymania projektu.

Jeśli to co powie zgra się z celami / potrzebami firmy wtedy werbuje tą osobę wstępnie na miesiąc.

Gdy upłynie miesiąc to decyzje o tym, czy przyjmujemy osobę podejmuje zespół.

A jeśli masz sił więcej to co tydzień rób wywiad z nowym, w kwestii tego co go boli i co mu odpowiada.

EDIT:

Dlaczego nie miękkie pytania, bo są dziwne i można udawać. Ja co rozmowę mówię ładne rzeczy z którymi się w ogóle nie zgadzam.

Dlaczego nie algorytmy. Bo w pracy jest mało algorytmów. Nie raz byłem podekscytowany jakimś zadaniem na rekrutacji, a potem w pracy nic podobnego mi nie dali do rozwiązywania. Koniec końców kończyło się na nudzie.

Dlaczego nie pytania z frameworków. Bo to tak zwerbujesz osobę wyspecjalizowaną w jednym, a przeoczysz osobę, która lepiej rozwiązuje problemy.

Dlaczego nie code review. Bo tak zweryfikujesz kogoś kto pilnuje przecinki. W czasie rozmowy jest za mało czasu, aby wgłębić się w kontekst zadania.

Wiele angaży jest wykonywanych z marszu jak ktoś ma własny wkład w własne projekty. Przykładowo przychodzi, mówi że projekt A czy B i D jest jego i pokazuje od nich dostęp. Nie współpraca tylko własne projekty jakie działają online. I to już rozwiązuje często problem pozostałych testów.

Tak mój kolega był zatrudniany, na rozmowie powiedział jakie apki są jego, tamci sobie je przejrzeli zdali do nich parę pytań i dziękujemy jesteś zatrudniony. Czyny lepsze niż słowa i papierki uczelni itp. Dlatego wiele też osób prowadzi własne blogi itp w tematyce w jakiej pracuje bo to też mogą dać jako wizytówkę swojej kompetencji i wiedzy na rozmowie.

Najlepsza rozmowa w jakiej uczestniczyłem i też najbardziej ludzka to etap rozmowy: poprzednie projekty i czym się zajmowałem, rozmowa o przyszłym projekcie - czy wiem jak działają technologie/czy znam architekturę w którą projekt idzie chociaż mniej więcej i część kodowania: prosty problem, ale sprawdzający jak się pisze kod, nie zajęło to więcej niż 20min, a cała rozmowa 1h. No, ale prowadził ją facet 15 lat w branży wyczuwający bullshit na kilometr. Moim zdaniem nie da się przeprowadzić dobrego procesu bez osoby, która pyta o praktyczną wiedzę wykorzystywaną w projekcie, a nie łechtającą swoje ego, co zwykle ma miejsce.

Cimron napisał(a):

Wiele angaży jest wykonywanych z marszu jak ktoś ma własny wkład w własne projekty. Przykładowo przychodzi, mówi że projekt A czy B i D jest jego i pokazuje od nich dostęp. Nie współpraca tylko własne projekty jakie działają online. I to już rozwiązuje często problem pozostałych testów.

Tak mój kolega był zatrudniany, na rozmowie powiedział jakie apki są jego, tamci sobie je przejrzeli zdali do nich parę pytań i dziękujemy jesteś zatrudniony. Czyny lepsze niż słowa i papierki uczelni itp. Dlatego wiele też osób prowadzi własne blogi itp w tematyce w jakiej pracuje bo to też mogą dać jako wizytówkę swojej kompetencji i wiedzy na rozmowie.

Ale jesteś świadomy, że nie trzeba rzeźbić własnych projektów, żeby być dobrym programistą? Takie podejście ma sens w przypadku web developerów z naciskiem na FE, gdzie efekt pracy jest widoczny.

Ja tam bym wpisywał w Google 100 java interview questions i jechana :D jeśli ktoś je umie to znaczy, że przygotowuje się do swoich zadań (bo tutaj przygotowaniem do rozmowy kwalifikacyjnej jest wpisanie właśniej tej frazy w Google i nauczenie się odpowiedzi).

Miang napisał(a):

szarotka napisał(a):

• sekcja techniczna
  • 2 pytania o jakieś podstawy

obrażających kandydata

Wielcy programiści, obrażają się bo ktoś zadaje pytania techniczne. Wielkie xDD tutaj.
Doświadczenie pokazuje, że nie raz zdarza się, że ktoś ma > x lat doświadczenia, ale nie zna podstaw (pod x kryje się 10, 15, 20)
Może mu nigdy nie były potrzebne? No może, zależy też co ktoś ma na myśli przez "podstawy".
Wiele razy rekrutowałem osoby z wieloletnim doświadczeniem, które nie wiedziały jaki kod HTTP powinien być zwrócony (edit: nie mam na myśli bardzo szczegółowych kodów, bardziej chodziło mi o to, żeby ktoś wiedział czym różni się 400 od 500). Może w wielu projektach nie jest to potrzebne, ale w wielu jest, to już zależy od rekrutującego czy firmy co tam uważa za absolutne minimum.

Co do samego pytania w wątku.

Rekrutacja nigdy nie będzie 100% skuteczna, zawsze zdarzy się zatrudnić ludzi, którzy nie będą pasować do zespołu czy firmy, czy to technicznie czy "osobowościowo". I tak samo w drugą stronę, zdarzy się też odrzucić osoby, który świetnie by się odnalazły w danej firmie czy zespole.

Zdarzyło mi się zatrudnić kilka osób, które do niczego się nie nadawały. I po co to komu, i ja się denerwowałem, i oni się denerwowali. Może było inne miejsce w którym świetnie by się odnaleźli. Wspominam o tym, bo przyjąłem te osoby, bo ufałem swojej intuicji, błędnie jak się okazało. Przy kolejnych rekrutacjach bardziej postawiłem na twarde dane, poprawne czy błędne odpowiedzi, a nie to co mi się wydaje, że ktoś umie czy że dobrze jej/jemu z oczu patrzy. Poszło o wiele lepiej.

Polecam "Thinking Fast and Slow" Daniel Kahneman. Jest tam cały rozdział (albo akapit, nie pamiętam) o rekrutacji.

Ąowski napisał(a):

Miang napisał(a):

szarotka napisał(a):

• sekcja techniczna
  • 2 pytania o jakieś podstawy

obrażających kandydata

Wielcy programiści, obrażają się bo ktoś zadaje pytania techniczne. Wielkie xDD tutaj.

W jednej z rekrutacji na Senior DevOps kilka lat temu, zadano mi pytanie "jak wylistować uruchomione kontenery Dockera". I ogólnie nie miałem z tym problemu, że zadano mi (w skali sporych wymagań na to stanowisko) ultra trywialne pytanie, ale szczerze mówiąc poczułem się obrażony, jak chwilę później na tym pytaniu poprzestano i rozmowa potoczyła się dalej w zupełnie inną stronę. Oczekiwałem jakiegoś follow-up, przynajmniej wytłumaczenia co oznaczają kolumny w docker ps, albo co się dzieje przy odpalaniu tej komendy, albo coś z Kubernetesa, ale nic. Odniosłem negatywne wrażenie, że prowadzący rozmowę sam nie zna się na temacie.

Więc zgadzam się, że zadawanie jedynie podstawowych pytań niewspółmiernych do wymagań na dane stanowisko, może zostać potraktowane jak obraza.

EDIT: może właśnie alternatywą byłoby rozpoczęcie rozmowy od pytań trudnych? Tak żeby sensowny kandydat od razu mógł się zaprezentować od najlepszej strony, a mniej sensowny po prostu się odbije i interviewer zejdzie z poziomem.

kelog napisał(a):

W jednej z rekrutacji na Senior DevOps kilka lat temu, zadano mi pytanie "jak wylistować uruchomione kontenery Dockera". I ogólnie nie miałem z tym problemu, że zadano mi (w skali sporych wymagań na to stanowisko) ultra trywialne pytanie, ale szczerze mówiąc poczułem się obrażony

ale dlaczego? czego oczekiwałeś? że dadzą Ci trudne pytania, żebyś mógł się wykazać? A może już przy tym pierwszym pytaniu Twoja odpowiedź była na tyle dobra, że widać było, że wiesz o co chodzi i nie widział potrzeby drążenia

kelog napisał(a):

Odniosłem negatywne wrażenie, że prowadzący rozmowę sam nie zna się na temacie.

może szukał kogoś, kto zna się lepiej (np. Ciebie)

kelog napisał(a):

EDIT: może właśnie alternatywą byłoby rozpoczęcie rozmowy od pytań trudnych? Tak żeby sensowny kandydat od razu mógł się zaprezentować od najlepszej strony, a mniej sensowny po prostu się odbije i interviewer zejdzie z poziomem.

jest to jakaś alternatywa, ale często zaczyna się od pytań łatwiejszych albo w ogóle nietechnicznych, żeby rozluźnić trochę atmosferę i pozwolić kandydatowi nabrać trochę pewności siebie, ale wiadomo, każde podejście ma swoje plusy i minusy

Crowstorm napisał(a):

Podczas przepytywanek to się rzygać chce (normalnemu) kandydatowi i sam osobiście raz udałem, że odłączyło mi prad bo nie chciało mi się już bawic w Familiade czy Milionerów

Albo to mi się śni albo nie wziąłem znowu leków. Ja rozumiem być zmęczony/frustracja/zły dzień ale no chłopie xD

EDIT: może właśnie alternatywą byłoby rozpoczęcie rozmowy od pytań trudnych? Tak żeby sensowny kandydat od razu mógł się zaprezentować od najlepszej strony, a mniej sensowny po prostu się odbije i interviewer zejdzie z poziomem.

Nie ma takiej możliwości. Zaczynasz od rozluźniaczy i stopniowo podbijasz poziom, aż napotkasz opór. W drugą stronę ryzykujesz, że kandydat się rozłączy, bo nie chce mu się bawić w Familiadę czy Milionerów. Albo po prostu zestresujesz za mocno.

Ja pytania z technologi traktuję, jak weryfikację ile jest prawdy w CV i czy kandydat umie się wysławiać. Jak kandydat ma np Kafkę na drugim miejscu w CV, to powinien umieć wytłumaczyć, co to jest consumer group.

@szarotka ,

Jak wyłapać, że ktoś będzie problematyczny np. w komunikacji

Nie wyłapiesz, ale można próbować.

Tu mnie koledzy zjedzą, ale zadanie programistyczne na pół godziny jest obowiązkowe. Bardziej chodzi o rozmowę i zrozumienie, jak kandydat reaguje na uwagi, że w jego kodzie jest coś nie halo, albo czy zadaje pytania do zadania.

szarotka napisał(a):

• pytając o osiągnięcie na początku, daję kandydatowi się wykazać/rozluźnić, może pochwalić się swoimi mocnymi stronami a ja mogę dać mu w głowie podświadomie plusa, są rzeczy które nie wyjdą w pytaniach technicznych, więc warto żeby kandydat sam się pochwalił czymś ciekawym co robił

Proszę, nie rób tego. Programiści mają silny imposter syndrome i pytanie o osiągnięcia powoduje stres. Zwłasza, że ciężko o ciekawe projekty, którymi można się pochwalić. Wszędzie crudy i spaghetti.
Do dzisiaj pamiętam rozmowę, jak pewien pajac miał do mnie pretensje, że jako developer brałem udział w projekcie, który był biznesową klapą.

Ale macie problem. Bardzo wiele rzeczy można powiedzieć tylko trzeba sobie zdawać z tego sprawę i mieć dobre CV żeby sobie zerkać.
Możesz opisać zwykłe taski/refactory jako osiągnięcie np:
Poprawiłem wydajność najczęściej używanego endpointa o x %. Opisać jak zmierzyłeś jego wydajność, jak znalazłeś bottle necki itd. i po tym opisie fajnie już widać, że wiesz w jaki sposób takie rzeczy się robi.
Potem może pojawić się pytanie jak uznałeś, że ten endpoint jest do poprawy itd.

Ładnie trzeba mieć wywalone ego w kosmos by zwykłe taski, refactory czy CRUDy opisywać jako osiągnięcia.

Pytanie generalnie moim zdaniem fajne, ale nie w tej branży (a przynajmniej nie jak większość, w tym ja, pracują). Nie ma nic ekscytującego, że zrobiłeś endpointa, pobrałeś listę i wyświetliłeś dane a nawet zrobiłeś formularz i zintegrowałeś się z google maps. Jak ktoś potrafi o tym powiedzieć w sposób ekscytujący to wybierają właśnie opowiadacza, który będzie dużo gadał na spotkaniach a pewnie mało robił

@Crowstorm nie ma nic ciekawego bo nie umiesz o tym opowiedzieć i na tym tracisz. Rekrutacja to przecież gra w której jedna strona (pracodawca) chce wyczaić czego nie umiesz a co umiesz żeby jak najmniej ci zapłacić a druga strona (pracownik) próbuje ukryć swoje niedoskonałości i wyeksponować to co umie żeby dostać jak najwięcej.

Umiem o tym opowiedzieć. Powtarzam jednak, że jak umiesz o tym opowiedzieć z ekscytacją to masz ego w kosmosie i nie obchodzi mnie, że udawałeś. Chwalić się można czymś wyjątkowym a nie tym co robi miliony osób.
Ja wiem, że pracodawca chce, żebym był podniecony samym faktem pisania CRUDa no ale nie jestem i nie będę. Mogę być tylko podniecony wypłatą.

Dodam dla pewności - ja wiem, że przez to jesteś od razu na dużo gorszej pozycji ale nie poradzę, jakbym chciał tracić resztki godności to pokazywałbym rowa na OF