Rodzaje rozmów kwalifikacyjnych

Hej,
Ostatnio miałem rozmowę kwalifikacyjną, która wydaje mi się dość specyficzna. Chciałem Was zaptyać czy zdarzyło Wam się kiedyś podobna rozmowa. Wyglądała ona mniej więcej tak, że siedliśmy sobie i zaczeliśmy rozmawiać o podejściach we frontendzie, o framewrokach, o moim doświadczeniu i dlaczego tak, a nie inaczej wygląda moja historia w cv. Nie było żadnych pytań technicznych, sprawdzenia mojej wiedzy. Nie wiem jak to odbierać, generalnie firma dopiero powstaje i nie mają jeszcze zespołu FE. Nie wiem czy się decydować bo w sumie nie chce iść w kolejne g**no. Mieliście podobne sytuacje w karierze ?

W moich trzech przypadkach zawsze zadawali techniczne pytania.

dotychczas u mnie tez

nom u mnie też było technicznie i raczej z kimś kto tą "technikę" ogarniał

Czekaj, ale o czym rozmawiałeś. Skoro o frameworkach to nie było techniczne?

• Niech pan wymieni 10 frameworków JS?

Skoro o podejściu:

• Co pan sądzi, za dużo tego co?

Czy było merytorycznie ale bez pytań co to jest selektor i jak się go używa?

Moim zdaniem rozmowa typu: jakbyś coś zrobił, jakie znasz technologie itp jest sensowniejsza, bo sprawdza znajomość w praktyce i to jak dana osoba rozumuje. Sprawdzanie kruczków języka czy znajomości składni, ok, ale to nie daje obrazu rekrutowanej osoby (ale wiadomka, po to są wstępne testy żeby odsiać tych co coś wiedzą od tych co nic nie wiedzą). No ale właśnie meritum rozmowy, jest poruszanie zagadnień. Słyszałam od kumpla, że w jednym korpo rekrutował i dostał na kartce pytania, które czytał, sam będą specjalista w innej technologii, to dla mnie paranoja, po to jest rozmowa, żeby odejść od schematu i móc wybadać. Znaczy to moja opinia, aczkolwiek wiadomka, że indywidualne podejście nie może mieć wszędzie miejsca. W mojej obecnej firmie, był test a potem rozmowa na podstawie zagadnień spisanych na kartce, uważam, że to fajna forma sprawdzenia wiedzy.

Właśnie nie było żadnych pytań technicznych zgłębiających się czy to w css czy js, to mnie martwi

A aplikujesz na juniora? Bo jeśli nie to może po prostu założyli że jak ktoś ma kilka lat doświadczenia i można z nim sensownie pogadać to nie trzeba sprawdzać jakichś konkretnych szczegółów technicznych.

Na seniora. Tak jak pisalem oni buduja zespol maja tam moze z jednego FE deva, moze dlatego. W sumie powiedziano mi, ze git (bo teraz maja svn ale beda wszystko przenosic i klepac nowe systemy) bedzie, ze wszystko dopiero sie ksztaltuje bo oni tu sa od 3miechow. Moze za bardzo panikuje ?

Nie no jak na seniora to w ogóle mnie taka rozmowa nie dziwi.

Ja też miałem podobną sytuację. U Helwetów w UBS i w Credit Suisse. Zero pytań technicznych. Też byłem zaskoczony. (A oferty dostałem i wybrałem CS bo dawali więcej)

Jak ja bym kogoś rekrutował na seniora, to oprócz takiej rozmowy, zoorganizował bym rozmowe strikte techniczną

Jeden raz miałem taką rozmowę. Właściwie słów padło niewiele. Było CV w nim częste zmiany pracy i różnorodna tematyka zadań, co zostało uznane za doświadczenie zawodowe. Zatrudnili na okres próbny od razu. Potem zostałem na stałe. Firma była niewielka. Pracowałbym tam do dzisiaj, ale szef i wiceszef się przestali dogadywać i to się rozleciało.

Starczy zadac podchwytliwe pytanie 'z jakiego Twojego projektu byles ostatnio dumny' by wychwycic czy ktos cos robil czy nie + wlasnie pogadanka. Jak ktos ogarnia to latwo wyczaic czy ktos wie o czym mowi.

Kompleksowo to pewnie rekrutuje Spartez, ktory niby robi pair programming.
I wedlug mnie delikwent wcsle nie musi zadania pair programming zrobic, tylko wazne jak mysli.

• pare oczywistych pytan z jakis popularnych frameworkow.

Przynajmniej ja bym taka rozmowe zrobil.

Glupie pytania to sa wlasnie takie rodem z certyfikatow.

• ArrayList vs LinkedList różnice
• Interfejs vs klasa abstrakcyjna

xDDDDDDDDDDD

Zdarzało mi się być na rozmowach, w których nie było twardych pytań technicznych, a co najwyżej jakieś ogólniki. W tych przypadkach dostałem ofertę pracy, ale z niej nie skorzystałem. W jednym przypadku sama rozmowa i firma wydały się dziwne, a rekrutacja mało wnikliwa. Zacząłem się zastanawiać nad tym, kto tam pracuje, jeśli innych też tak rekrutowali. Natomiast w drugim przypadku zaproponowano mi słabą ofertę.

Hmm... może dlatego potem ci "seniorzy" są tak słabi technicznie, że ich firmy zbyt dobrze nie maglują technicznie na rozmowach (zakładając mylnie, że jak ktoś ma lata doświadczenia, to musi być dobry).

Wyglądała ona mniej więcej tak, że siedliśmy sobie i zaczeliśmy rozmawiać o podejściach we frontendzie, o framewrokach

No to właśnie jest rozmowa techniczna w takim razie.

o moim doświadczeniu i dlaczego tak,

Śliskie pytania. Często firmy aż wciskają nos gdzie nie trzeba nie szanując prywatności i faktu, że np. kandydat podpisał NDA z poprzednią firmą (a jednak ciężko opowiadać szczegółowo o swoim doświadczeniu i projektach, przy których się pracowało, jeśli się podpisało NDA).

a nie inaczej wygląda moja historia w cv.

Pytania raczej takie, które zadają nieświadome niczego panie z HRu. CV to kartka papieru / plik PDF który się pisze dla formalności/dla zwyczaju, tak jak kiedyś był zwyczaj rozdawania wizytówek albo do dzisiaj jest zwyczaj wysyłania zaproszeń ślubnych. Albo tak jak firmy drukują ulotki do rozdawania na ulicy.

Dyskutować o CV to trochę tak jakbyś wziął ulotkę banku na ulicy i dyskutował potem z kasjerem zamiast np. o oprocentowaniu to o kroju pisma na ulotce czy o tym z jakiej strony wzięli stockowe zdjęcia do ulotki. CV to tylko przecież reklama samego siebie.

Myślę że słaby poziom rozmów kwalifikacyjnych świadczy o słabej wiedzy rekrutującego (i jeżeli tak jest to Ci "słabi" pracownicy wybrali na rekrutera najlepszego z nich).

Brak pytania o szczegóły techniczne może doprowadzić do tego, że w firmie będzie przewaga złotoustych/bajkopisarzy mocno kłamiących w CV, którzy niewiele będą robić, a to zwykle torpeduje motywację ludzi nastawionych na solidną pracę i rozwój, którzy tam się jakoś zaplątali.

Mi się wydaje że im na wyższy "level" aplikujesz tym mniej pytań technicznych. To się czuje i to się wie że ktoś ogarnia po samej rozmowie i sposobie mówienia. A taki sposób mówienia da się wyrobić tylko przez X lat doświadczenia.

Pinek napisał(a):

• ArrayList vs LinkedList różnice
• Interfejs vs klasa abstrakcyjna

Jakie wzorce projektowe pan stosuje w swoich projektach i dlaczego właśnie singleton?

Zadawanie pytań o składnię języka albo o standardową bibliotekę kandydatowi na seniora jest absurdalne. Senior, to ktoś kto ma rozwiązywać problemy, wybierać technologie, odpowiadać za działanie jakiegoś modułu, a nie tylko klepać instrukcje języka. Seniora powinno się pytać o to, jak by coś zaimplementował, jaką bibliotekę wybrał, którą woli, w czym ma doświadczenie, a nie o to, do czego służy virtual i new.
I jeśli komuś juniorskich pytań brakuje w rozmowie na seniora, to chyba sam nie bardzo rozumie kim jest senior.

Dotychczas jak bralem udzial w rekrutacjach Seniorskich zawsze pojawialy sie obie serie pytań, ale macie racje

somekind napisał(a):

Pinek napisał(a):

• ArrayList vs LinkedList różnice
• Interfejs vs klasa abstrakcyjna

Jakie wzorce projektowe pan stosuje w swoich projektach i dlaczego właśnie singleton?

Zadawanie pytań o składnię języka albo o standardową bibliotekę kandydatowi na seniora jest absurdalne. Senior, to ktoś kto ma rozwiązywać problemy, wybierać technologie, odpowiadać za działanie jakiegoś modułu, a nie tylko klepać instrukcje języka. Seniora powinno się pytać o to, jak by coś zaimplementował, jaką bibliotekę wybrał, którą woli, w czym ma doświadczenie, a nie o to, do czego służy virtual i new.
I jeśli komuś juniorskich pytań brakuje w rozmowie na seniora, to chyba sam nie bardzo rozumie kim jest senior.

Całkowita racja.

I jeśli komuś juniorskich pytań brakuje w rozmowie na seniora, to chyba sam nie bardzo rozumie kim jest senior.

Bywa tak, że te rozmowy wyglądają jak ustne kolokwium na 2 roku studiów...

Pisałem kiedyś że trafiło mi sie na rozmowie pytanie o to co sie robi żeby w systemach współbieżnych nie mieć kłopotów z deadlockami i zagłodzeniem i zacząłem opowiadać o obiektach immutable i bezstanowych serwisach, a tu się okazało że moi "rekruterzy" (ledwo po studiach, ze znacznie krótszym doświadczeniem niż moje...) stwierdzili że zupełnie nie o to chodzi i oni chcieli usłyszeć o Banker's algorithm. Pewnie niedawno mieli to na kolokwium ;)

Jak dla mnie podejście, że pytania są zakładany poziom dostosowywane pod kandydata jest błędne i odpowiada za sporo problemów w IT.

Kandydata powinno się przepytać kompleksowo i dopiero po tym ocenić prezentowany poziom!

Jak się tego nie zrobi, to można dostać same pytania jak na kolokwiach i żadnego pytania o projektowanie rozwiązania, albo same pytania ogólne i żadnych konkretów.

Główną przyczyną problemów w IT jest nazywanie juniorów z 3 latami doświadczenia seniorami, rzucanie się na nowe biblioteki jak szczerbaty na suchary, bezmyślne stosowanie ifologi i mutowalności zamiast prostych rozwiązań, i pisanie kodu tak, jakby płacono od każdej linijki.

Jeśli ktoś, kto ma link do mojego GitHuba pyta mnie czy wiem, czym się różni interfejs od klasy abstrakcyjnej, to chyba sam nie bardzo ma pojęcie o programowaniu.

@somekind
Jeżeli kogokolwiek pyta o to czym się klasa abstrakcyjna różni od interfejsu to nie ma pojęcia co robi.
Pytania powinny być tylko z sensownych zagadnień, a nie dukania definicji czy klepania kolejnych wersji sortowań, bo zakładamy, że jak jesteś juniorem to nic więcej nie zrobisz.
Seniora też nie powinno się pytać o ogólniki do nauczenia na pamięć, tylko postawić konkretny problem i oczekiwać konkretnych propozycji z uzasadnieniem, tylko to wymaga przygotowania od strony rekrutera, a nikomu się nie chce.
Jak się da konkretne zadania kandydatowi to po nich widać czy umie pisać, czy umie projektować i na jaki poziom się nadaje, a nawet jak bardzo jego mniemanie o sobie się potwierdza, co też się przydaje bo widać czy czyjeś przechwałki dzielić przez n czy mnożyć razy n. n>0 :D

Oddzielne pytania dla seniora i dla juniora to jest patologia niepozwalająca poznać faktycznego poziomu, a wynikająca w dużej mierze z faktu, że ludziom się wydaje, że żeby zaprojektować to trzema umieć samemu napisać w sensownym czasie, gdzie tymczasem trzeba rozumieć woady i zalety wybranych rozwiązań i umieć to zbilansować.
O ile Senior = super projektant + super klepacz + super ogar istniejącego kodu + super ogar wymagań, to kolejność nabywania poszczególnych umiejętności nie jest stała.

Jeżeli się założy, że najpierw się umie klepać, później się umie ogarniać wymagania, później istniejący kod, a dopiero na końcu projektować, a pytania dla zakładanego juniora są inne niż
dla zakładanego seniora, to algorytm rekrutacji zadziała źle dla każdego kandydata który się rozwijał w innej kolejności, bo zwyczajnie pozna się go tylko z jednej strony.
W takim wypadku losowanie spośród ludzi z 5. letnim doświadczeniem beż żadnej rozmowy może mieć większy sens.

Brak zrozumienia co się robi jest powszechny, i w efekcie kopiowane są bezmyślnie rozwiązania wszelakie.
Jak mnie ktoś o zbdety pytał przez codility to widocznie ma to sens i ja też tak będę.
Jak wszyscy gadają o scrumie to ten projekt też w nim będzie, ale trochę zmienimy i dodamy deadline, velocity licząc tylko pro forma.
Jalk modne są mikroserwisy to tak zrobimy, nie ważne, że nagle się zrobi microservices hell a my nie mamy żadnego opsa, a komunikacja ubije wydajność.
Jak 5 lat temu JBoss był super modny, to teraz też wszystko monolitem.

, bezmyślne stosowanie ifologi i mutowalności zamiast prostych rozwiązań, i pisanie kodu tak, jakby płacono od każdej linijki.

Do tego trzeba dojrzeć. Jest taka stara mądrość w programowaniu, że najpierw się programuje byle jak, potem się programuje bardziej "elegancko" niż to potrzebne (kod przeinżynierowany) a dopiero po tym etapie człowiek się uczy jak pisać prosty kod.

Niestety na rynku większość programistów to albo początkujący albo zaledwie średniozaawansowani, więc nic dziwnego, że jest albo spaghetti kod, albo kod przeinżynierowany do granic możliwości...

Na dodatek pytania na rozmowach faworyzują właśnie często przeinżynierowanie - czyli im więcej znasz pojęć, wzorców i im więcej narzędzi, tym lepiej (zamiast faworyzować zdrowy rozsądek i zdolność do zdrowego krytycyzmu)

90% rozmow jest o projektach w ktorych bralam udzial, zakresie obowiazkow, wyzwaniach etc. pytania techniczne sa raczej na zasadzie 'jak mierzycie latency' albo 'na co zwrocisz uwage przy implementacji jakiejs tam struktury danych' niz 'napisz singletona' albo 'ile jest generacji w gc'.
mimo wszystko uwazam ze warto takie pytania zadawac, przynajmniej kilka dla kontroli, bo trafiaja sie rozni sciemniacze zwlaszcza zaczynajacy w branzy (ale niekoniecznie!) i sie okazuje ze ktos nie wie ile bajtow ma int32 albo mysla ze list == lista polaczona :)

@katelx
Zależy od zastosowania. W embeded to znajomość wielkości inta pewnie ma sens, ale już w korpo javie zupełnie nie ma, tym bardziej, że to jest w 2 minuty do wygooglania.