Słabo wypadam na rozmowach kwalifikacyjnych

Cześć,
Może ktoś miał taki problem i powie mi jaką najkrótszą ścieżkę obrać do osiągnięcia swojego celu.
Byłem na dwóch rozmowach kwalifikacyjnych dla sportu ostatnio, tak żeby nie odwyknąć i sprawdzić co jest teraz wymagane, o co się pyta.
Rozmowy były spoko, nawet łatwe bym powiedział, ale ... wykładałem się na podstawach.
Dlaczego?
Bo klepałem w pracy przez ostatnie 2 lata kod często nie zastanawiając się nad mechanizmami pod spodem, a nie uczyłem się bieżąco.

• Używałem Spring JPA Data zamiast Hibernate, a pytania były z Hibernate właśnie, o którym dawno nawet nie myślałem.
• JVM parę nietrudnych pytań, ale też jak klepiesz CRUDa to się nie zastanawiasz czy jest tak czy inaczej
• GC - a na co to komu? Działa to działa. (żartuję oczywiście, ale chodzi o to, że nie potrzebowałem tego wiedzieć do klepania ticketów)
• Algorytmy - no tutaj to już serio, quick sort to implementowałem z 3 lata temu jak się Javy uczyłem. Teraz to już nawet zapomniałem czym się różnią algorytmy sortujące.

Generalnie mam wrażenie, że do przypomnienia mam niemal WSZYSTKO.

• Jak zacznę czytać książki o Javie, JVM, Springu, Hibernate, SQL od nowa to z rok chyba będę siedział.
• Jak pouczę się pod rekrutację to wszystko tylko po łebkach obskoczę.

Jakieś propozycje mają drodzy współforumowicze?

@NeutrinoSpinZero: to jest prawdziwa bolączka tego zawodu
klepanie w pracy, bez uczenia się nowych rzeczy
rozmowy kwalifikacyjne które nijak się mają do późniejszych zadań, pracy

Sam tego doświadczyłem, że na rekrutacji cuda jakieś, algo, asynchroniczność, planowanie architektury systemu, kolejki itd
a potem taski w pracy to zgłoszenia głownie bugów od klienta, gdzie się męczyłem ze starym kodem

Przechodzenie rekrutacji to umiejętność sama w sobie - po tych 2 wiesz czego nie wiesz i po prostu zacznij od pójścia tą drogą

Jest taki kurs, żeby dobrze wypadać na rozmowach :]
https://www.techseries.dev/

Tak niestety jest. Na rozmowie potrafił pytać z niewiadoma czego. Pół biedy jak uparcie odpytują z czegoś czego używają w projekcie. Ale mam wrażenie że często te pytania mają tylko na celu zbicie stawki
Alternatywa to pójść w jakoś mniej popularną technologie gdzie brakuje programistów np jak Scala w tym momencie

Jeśli z jakiegoś powodu ci zależy na pracy w zblizonych do tych firm waunkach to przypominasz sobie detale tego co przedstawiłeś i tyle. Jeśli to nie wystarczy - widocznie ty i firma która prowadzi rekrutację nie pasujecie do siebie. Lub firma sama nie wie kogo szuka - wtedy tym bardziej należy ją omijać.

Najlepiej do rozmów kwalifikacyjnych przygotowują... rozmowy kwalifikacyjne ;) Poczytaj te 100 Java/Spring/Hibernate Interview Questions ze zrozumieniem, przećwicz algorytmy z Cracking the Coding Interview (na necie jest online pdf), w sumie możesz się ograniczyć do sekcji o arrayach, listach, system design i (opcjonalnie) behavioral questions.

Poza tym, rekrutacja rekrutacji nie równa - pamiętam jak kilka miesięcy temu, miałem w jednym tygodniu dwie rozmowy (z 2 różnych firm) - na jednej typek mnie dosłownie wyśmiał, że nie znam JVMa, a na drugiej mnie zachwalali jaki to nie jestem super :P

To fakt, rozmowy są niedopasowane do rzeczywistości. Chociaż np. w obecnej firmie miałem fajną rozmowę- najpierw pogadaliśmy luźno (co ja robię, co firma robi), po czym stwierdziliśmy, że "jest chemia" i dostałem zadanie do zrobienia, ale nie żadne wydumane tylko takie z jakimi mam teraz do czynienia w firmie. Potem oczywiście musiałem uzasadnić czemu coś zrobiłem tak a nie inaczej, ale nie było pytań o 254 stronę dokumentacji Spring-a i adnotację, której używa się raz na 10 lat czy o narysowanie schematu JVM. Niestety większość rozmów wygląda jak wygląda i trzeba się do nich przygotować.

Niestety tak to wygada. Zatrudnienie nieodpowiedniego pracownika jest drogie. Więc zawyża się wymagania. Jeżeli firmy, do których się rekrutujesz mają takie podejście, to możesz albo to zaakceptować albo szukać innych firm, z niższymi wymaganiami, ewentualnie rozwinąć własną działalność. Polecam:

1. Uczyć się na bieżąco. Utrwalać raz zdobytą wiedzę, aktualizować widzę o kluczowych narzędziach i eksplorować nowe obszary. Blogi techniczne, śledzenie profili na twiterze liderów w danej dziedzinie, książki, artykuły, czytanie for internetowych, oglądanie nagrań z konferencji. Często jest okazja by zabłysnąć taką wiedzą podczas rekrutacji.

2. Przed rekrutacją przyjrzeć typowe pytania rekrutacyjne. Skoro już raz się czegoś nauczyłeś, to wystarczy drobne przypomnienie. Dużo łatwiej przypomnieć sobie mętne obszary wiedzy lub nauczyć się czegoś nowego mając już odpowiedni punkt zaczepienia, to jest wiedzę praktyczną lub raz już przerobioną teorię.

3. Ćwiczyć zadania algorytmiczne jeżeli firmy, w których chcesz się zatrudnić, mają je procesie rekrutacyjnym To jest najmniej przydatna wiedza w codziennych obowiązkach dla 90+% programistów. Pytania zazwyczaj są bardzo szablonowe ale wymagają biegłości w rozwiązywaniu. Tego można się nauczyć na portalach jak leetcode czy hackerrank, ale ilość czasu jest naprawdę znaczna. W korpo wraz z wyższymi stanowiskami pojawia się mniej algorytmów, a więcej projektowania i wiedzy technicznej. Szczerze, to mam wrażenie, że teraz prawie każdy próbuje naśladować wielkie firmy technologicznie i na start męczy kandydatów pytaniami algorytmicznymi, nawet mając świadomość, że ma się to nijak do obowiązków na danej pozycji.

4. Zaznajomić się z projektowaniem systemów. Jeszcze pewnie nie dotarłeś do tego etapu, ale w pewnym momencie niektóre firmy mogą zacząć od Ciebie wymagać takiej wiedzy. Bez odpowiedniej wiedzy technicznej, umiejętności zebrania wymagań, umiejętności zrozumienia i rozłożenia na czynniki pierwsze kompletnie nowego problemu przejście tego etapu może okazać się bardzo problematyczne.

Generalnie to możesz omijać szerokim łukiem firmy, które prowadzą w ten sposób rekrutację albo nauczyć się je przechodzić. Opcja opcja piersza zapewni Ci święty spokój, druga w pewnym stopniu rozwinie Cię jako programistę, ale przełożenie na realne obowiązki w pracy będzie nikłe.

A ja sugeruje w ogóle się tym nie przejmować. Trik polega na tym, ze umiesz to czego używasz/co cię interesuje więc takiej pracy powinieneś szukać. Jesli na interview pytają o rzeczy których nie wiesz, to widocznie firma nie jest dla ciebie, bo robią rzeczy które cię nie kręcą i tyle. Skillowanie "pod interview" uważam za bardzo dziwne. Jasne, dostaniesz może pracę ale co później? Skoro nie interesuje cię algorytmika, to będziesz potem narzekać że w robocie non stop algorytmy a ty chciałeś crudy od metra. Albo wręcz przeciwnie nie chcesz crudować, ale na interview doskillowałeś sobie hibernate na szybko i zaraz będziesz narzekać że gówniana robota :)

Ostatnio brałem udział w rekrutacji i nie przygotowałem się do niej specjalnie. Przez to nie znałem odpowiedzi na parę pytań, które na kiedyś bym spokojnie odpowiedział, a pewnie każdy student od razu zna odpowiedź. Jednak staram się być na bieżąco z technologią z którą pracuje i do której aplikuje. Generalnie odpowiedziałem na te pytania, że nie wiem albo nie pamiętam, nie starałem się dukać. Ofertę dostałem. Także to sporo zależy od rekrutera, akurat osoba która mnie rekrutowała wydawała się rozsądna :)

Ale co ci szkodzi przelecieć po "top 100 java interview question" na tydzień przed rozmową? Nie rozumiem w czym problem, ja też w pracy nie profiluję JVM, nie eksperymentuję z różnymi GC ani nie implementuję merge sorta, a jakoś dzięki temu, że poświęcę kilka dni na doczytanie podstaw to większość (nie każdą, ale większość) rozmów przechodzę.

Swoją drogą już drugi raz zakładasz temat jaki ten zawód programisty jest trudny, według mnie za bardzo panikujesz i wyolbrzymiasz.

obskocz po łebkach. W innej firmie też byś pracował tak, że wszystkiego zapomnisz

@anckor: Nawet nie chodzi mi o to, że zawód programisty jest trudny. Chodzi mi bardziej mi o to, o czym pisał @Shalom . Obecnie zajmuję się ostro konteneryzacją i kubernetesem, stąd siłą rzeczy zapomniałem czym się różni cache L1 od L2 w Hibernate. Poza tym uczciwie mówię, że nie wiem. Korci mnie, żeby się zapytać - a w jakim celu i kiedy ostatnio się ta wiedza przydała.
No ale może tak chcą odsiewać ignorantów i klepaczy z tutoriali.

To jest troche tak jak na randce laska ktora Ci sie bardzo podoba pyta sie czy lubisz skakac na bandzi w stroju Borata. A Ty mniej wiecej kojarzysz kto to ale na bandzi nie masz zamiaru skakac.
Co odpowiesz?

Ja osobiscie zawsze zle wychodzę na pytaniach STAR w Amazon. Chyba po drugiej lub trzeciej rekrutacji spasowalem bo mi szkoda bylo mojego i ich czasu na takie brednie.

Aplikuj do firm zachodnich, tam jest mniej tego Q&A, to polska domena. Jakis czas temu mialem maraton rekrutacji, kontraktornie jada z metra, wiec to jest to czego nie chcesz, firmy produktowe czesciej maja sensowne pytania, ale czesto mniej placa. Najsensowniejsza rekrutacje mialem do Allegro.

w stanach to standard ze nawet ludzie majacy wiele lat doswiadczenie przez rekrutacja spedzaja pare tygodni na nauke po godzinach pod pytania rekrutacyjne, robienie zadan z leetcode itp. Sa nawet bootcampy dla ludzie pracujacych juz jako programisci ktore ucza jak przejsc proces rekrutacji

1. Większość rozmów przeprowadzają osoby niekompetentne.
2. Większość firm które rekrutuje wcale nie szuka pracownika. A już na pewno nie szuka drogiego pracownika. Szuka taniego i dobrego.
3. Dobrze wypaść na rozmowie to umiejętność jak każda inna. Trzeba wyćwiczyć chodząc na X rozmów na X+1 wypadniesz dobrze. Ja byłem w swoim życiu na około 50 rozmowach na programistę.
4. Klepanie bez zastanowienia to wskakiwanie na własne życzenie w pułapkę zastawioną przez pracodawcę. Pracodawcy NIE zależy żebyś rozumiał co, po co i jak wynieść wartość dla siebie. Jemu zależy właśnie żebyś naklepał. A ty powinieneś klepać jak najwolniej. Po drodze i w godzinach pracy w twoim interesie leży to żeby rozkminiać po co, co pod spodem i jak to samo zrobić od 0 w innej firmie (być może nawet w swojej).

Nie łączyłbym gównianych rozmów z chęcią płacenia mniej, ludzie którzy prowadzą rozmowy techniczne w wielu firmach nie mają (oficjalnie) pojęcia jakie są widełki są na danym stanowisku i nie mają absolutnie żadnego interesu w tym żeby komuś płacono mniej.

Byłem dzisiaj na rozmowie kwalifikacyjnej, na której musiałem napisać drzewo binarne a potem algorytm odwrotnej notacji polskiej.

Nigdy w życiu w pracy nie musiałem napisać drzewa binarnego.

to jest właśnie przykład rekrutacji gdzie firma tak naprawdę nie szuka bądź rekruterzy nie wiedzą co czynią bądź szukają osoby do tworzenia tutoriali dla studentów

Jeśli chodzi o algorytmy to sam bym się wyłożył. Nie wiem czy to Cię pocieszy. Z wykluczeniem sytuacji gdzie firma faktycznie używa bezpośrednio algorytmów i pracuje się z tym na codzień, to tylko świadczy że firma ma absurdalny proces rekrutacyjny i mają wymagania nie adekwatne do codziennej pracy. W takim przypadku ja sam bym kwestionował czy chce pracować w takim miejscu, skoro firma rekrutuje osoby niekoniecznie na podstawie tego co rzeczywiście jest potrzebne.

Najprostszy sposób na zaliczenie rozmowy to:

while(!suceed){
  Pójść na rozmowę
  zanotować czego się nie wiedziało
  jeżeli się da, to zapytać o odpowiedź
  douczyć się z tego na czym się poległo
}

Z mojej obserwacji na ~90% rozmów zadają te same pytania typu

• czym się różnią klasa/klasa abstrakcyjna/interface
• jakie są typy i przykładowe implementacje kolekcji w Java
• co to jest solid, yagni, kiss
• Jak coś tam wstrzyknąć w Springu i dlaczego IoC jest super
• Jakiś z d... wzięty wzorzec projektowy (i najczęściej sami nie mają pojęcia kiedy i dlaczego należy go użyć)

Zakładam, że ta spójność wynika stąd, że ludzie którzy te rozmowy przeprowadzają, sami chodzą też na rozmowy i powstaje taki samoreplikujący się schemat

Generalnie większość rozmów, które miałem w życiu była szukaniem powodu, żeby mnie nie zatrudnić (czyli taka IT Wielka Gra), zamiast szukaniem powodu, dla którego powinienem dołączyć do zespołu. Pół biedy, jeżeli taki techniczny quiz jest na samym początku i sprawdza rzeczy które każdy na oczekiwanym poziomie doświadczenia powinien wiedzieć, gorzej zaj zaczynają pytać o szczegóły z jakiegoś frameworka, wykorzystane przypadkiem tydzień wcześniej i teraz nabrali przekonania, że każdy powinien to wiedzieć.

Sam bylem dzisiaj na rozmowie, fakt ze wdzwonilem sie na rozmowe z kamerka, a pozostale (3) osoby jej nie raczyly wlaczyc bylo troche zenujace.
Potem przeszlismy do hardkorowego orania mnie z c++, przez 30 minut pytan polecialo chyba z 40. Na koniec az spocony bylem jakbym wychodzil z egzaminu ustnego na polibudzie.
Od najprostszych rzeczy jak static member w klasie, przez konkrety jak RAII, roznice miedzy smart pointerami czy niektorymi kontenerami konczac na absurdalnych pytaniach o templejty i teorie ktora znasz chyba tylko jak jestes tydzien po przeczytaniu C++ Templates: The Complete Guide.
Z jednej strony czulem sie jakbym bral udzial w 1 z 10, a z drugiej jakbym byl na komisariacie gdzie tylko szukaja momentu zeby mnie nakryc.

Zastanawia mnie to że, z jednej strony wśród programistów wypowiadających się w tym wątku, istnieje konsensus na temat częstej bezsensowności padających pytań technicznych, a zarazem te rekrutacje prowadzone przecież przez programistów właśnie tak wyglądają.

@Czulu: a mnie to wcale nie zastanawia. To po prostu typowy przejaw tego że ludzie często kierują się czymś zasłyszanym i nie przykładają większej wagi do "dla czego" i "po co". Innymi słowy to podejście w stylu "tak jest i się z tym nie dyskutuje" zamiast przyłożyć się porządnie do swojej pracy i zdefiniować zadania/pytania konkretnie na potrzeby danej firmy/projektu.

@Aventus: Tylko co to są pytania na potrzeby projektu? Mam pytać o jakąś pierdołę ze Springa, bo akurat w tym projekcie jej użyto i przekreślić kandydata, bo jej nie zna, chociaż w razie czego ogarnie w godzinę? Albo odrzucić kandydata, który ma dużą wiedzę o chmurze X, bo akurat my używamy Y? Koniec końców, lepiej zatrudnić dobrego programistę nie mającego np. pojęcia o Springu, niż kiepskiego, który wykuł na pamięć ileś tam adnotacji.
Druga sprawa - część tych bezsensownych pytań sprawdza inne cechy niż się wydaje. Nie jest ważne, czy kandydat zna dokładnie różnice pomiędzy np. modyfikatorami dostępu w Java, tylko czy potrafi je stosować.

@piotrpo:

Tylko co to są pytania na potrzeby projektu?

Takie które definitywnie dadzą znać że kandydat albo zna konkretne technologie z którymi na codzień się pracuje, albo nie będzie miał problemów z nauczeniem się ich.

Mam pytać o jakąś pierdołę ze Springa, bo akurat w tym projekcie jej użyto i przekreślić kandydata, bo jej nie zna, chociaż w razie czego ogarnie w godzinę?

Myślę że już na to odpowiedziałem wyżej.

Albo odrzucić kandydata, który ma dużą wiedzę o chmurze X, bo akurat my używamy Y?

To akurat błędne myślenie (ja nigdzie nie napisałem że należy szukać kandydatów obeznanych w dokładnie tych samych technologiach, to Ty wyciągnąłeś taki całkowicie błędny wniosek). Jeśli ktoś zna technologie cloud X, to raczej nie będzie miał problemów z ogarnięciem X. Podobnie z technologiami frontend- tutaj przykład z życia wzięty. Pracujemy w React (oraz Blazor ale to oddzielny temat) i szukamy kogoś kto zna technologie SPA (React, Angular, Vue lub podobne) oraz chętnie się nauczy React (jeśli już to nie zna).

Koniec końców, lepiej zatrudnić dobrego

Zdefiniuj "dobrego" bo jak dla mnie to kwestia względna...

Druga sprawa - część tych bezsensownych pytań sprawdza inne cechy niż się wydaje. Nie jest ważne, czy kandydat zna dokładnie różnice pomiędzy np. modyfikatorami dostępu w Java, tylko czy potrafi je stosować.

To prawda, a czy ja temu gdzieś zaprzeczyłem? Chyba nieźle nadinterpretowałeś moje słowa.

Spróbuję na przykładzie, bo wydaje mi się, że nasze opinie różnią się jedynie semantycznie.

W odniesieniu do juniora moje wymagania to podstawy wiedzy o języku programowania, ale przyswojone ze zrozumieniem. Chcę wiedzieć, że taka osoba coś już wie o programowaniu i faktycznie jest w stanie przyswajać wiedzę.

Zakładając, że chcę zatrudnić kogoś na poziomie seniorskim (kogo uważam za dobrego inżyniera) do projektu, chcę żeby taka osoba:

• Znała język programowania, w którym piszemy na przyzwoitym poziomie. Mogę rozważyć przyjęcie kogoś dobrego w innym języku programowania i jakiejś podstawowej wiedzy w tym, czego używamy (zakładając, że chce się tego nauczyć).
• Miała praktyczną umiejętność podziału kodu na funkcjonalne elementy (moduły, klasy).
• Znała od strony praktycznej wzorce projektowe. Nie ważne, czy potrafi nazwać jakiś wzorzec (chociaż wtedy komunikacja jest prostsza), ale chcę, żeby była w oparciu o tę wiedzę rozwiązywać praktyczne problemy. Czyli jeżeli poproszę ją np. o rozwiązanie problemu typu dorobienie listenerów reagujących na zmiany w kolekcji, to powie "zastosuję observer do powiadamiania o zmianach, a proxy do owinięcia istniejącej kolekcji". Oczywiście inne rozwiązania są możliwe.
• Umiejętność samodzielnego rozwiązywania problemów, które się pojawiają. Cos działa za wolno, coś czasami rzuca wyjątkiem, gdzieś konsumowane jest za dużo pamięci.
• Umiejętności wyrażenia swoich myśli słowami, oraz dyskusji popartej argumentami.
• Umiejętności naukowego rozwiązywania problemów. Postawienia hipotezy i jej potwierdzenia/odrzucenia.

Typowa rozmowa, to:

• Krótka dyskusja o tym co kandydat robił, czego dokonał, czego szuka w nowej pracy
• Trochę teoretycznych pytań o język programowania (niby śmieszne, ale nawet część seniorów ma problemy z podstawami typu "kiedy pamięć zaalokowana na jakiś obiekt zostanie zwolniona".
• Pytania praktyczne "jak rozwiązałbyś problem X" typu "masz aplikację serwerową, która w przypadkowych momentach zostaje zabijana w przypadkowych miejscach OOE, jak podszedłbyś do naprawy takiego błędu", "Masz środowisko podstawowe, środowisko zapasowe do którego replikowane są dane. Jak byś podszedł do problemu spójności danych w drodze, przy replikacji"
• Proste (moim zdaniem) live coding polegające na poprawie istniejącego kodu. Większość kandydatów radzi sobie z nim rozwiązując istniejący problem, ale rzadko kto faktycznie potrafi zastosować te wszystkie YAGNI, TDD, KISS i resztę dyrdymałów o miłości do których zapewniali w poprzednich częściach rozmowy.

Dzięki takiemu podejściu udało się zatrudnić bardzo dobrych programistów. Nie wiem oczywiście, czy nie odrzuciliśmy kogoś nadmiarowo, ale z mojego punktu widzenia znacznie większą szkodę dla projektu / zespołu robi się zatrudniając niewłaściwego kandydata, niż odrzucając potencjalnie dobrego.

Dla odmiany nie interesują mnie ludzie::

• których wiedza/umiejętności ograniczają się do wykucia odpowiedzi na top 100 interview questions
• Ich doświadczenie i ambicje ograniczają się do fragmentu wybranego frameworku, czyli po latach pracy w jakiejś technologii nie mają o niej pojęcia.
• Wiedzą jedynie jak coś należy zrobić, nie mając pojęcia dlaczego tak.

Nie pytamy o rzeczy, których nie wykorzystujemy w projekcie, nie dopytujemy o jakieś techniczne upierdliwostki typu "masz hierarchię dziedziczenia C>B>A, w jakiej kolejności zostaną wywołane konstruktory oraz bloki statyczne".

A co z osobami, które piszą po pracy własne projekty? Wydaje mi się że jest to ciekawsze zajęcie niż zdobywanie odznak na HackerRank, gdzie rozwiązuje się stricte akademickie problemy. Oczywiście nie kwestionuje ważności algorytmów, struktur danych i optymalizacji. Jednak mam wrażenie że problemy, które pojawiają się podczas pisania aplikacji są bardzie wartościowe dla programisty niż te matematyczo-fizyczne zagadki i zapamiętanie algorytmów sortujących (które można w sumie wygooglować i użyć w razie potrzeby).

@travis.chigurh: właśnie to nazywamy doświadczeniem.
Klepacz taki jak ja, który zna tylko wierzchołek góry lodowej swojego tech-stacka, napisze bez problemu aplikację (lepiej, gorzej, ale napisze).
Ktoś kto zna doskonale JVM, tajniki frameworka, algorytmy i struktury danych, a nie robił żadnego komercyjnego produktu, nie napisze go w ogóle, albo zepsuje projekt, bo po prostu nie przebrnął jeszcze przez różne bariery, które spotkałem ja.

Mniejsza o to, sporządziłem sobie plan "naprawczy" i chciałbym go tutaj przedstawić jutro Wam z prośbą o konstruktywną opinię. Plan ten obejmie 6-cio miesięczne przygotowania.