Dlaczego "juniorzy" nie mogą znaleźć pracy

2
PerlMonk napisał(a):

A co jeśli ktoś ma gorszy dzień i akurat kontraktu nie może sobie przypomnieć? Z resztą po co ma pamiętać jeśli metodę hashCode można wygenerować sobie w IDE albo Lombokiem? Idąc tym tokiem myślenia można powiedzieć, że dzisiejszy seniorzy w Javie to leszcze, bo nie wiedzą co to są rejestry procesora albo jak napisać kompilator nie mając kompilatora.
Fajnie, że problem został zauważony, ale jeśli rozmowa trwa godzinę i mam na niej tylko tego typu pytania, to nie wiem czy chce w takiej firmie pracować. Nikt przez to nie sprawdza sposobu myślenia u kandydata.

Przecież to są pytania na pierwsze 5 minut. Pytanie - odpowiedź i tak x5
Fibonacci to zadanie na kolejne 5 minut. Fibonacci to jest zadanie które mogą robić uczniowie w liceum, świetne na początek nauki programowania.

wartek01 napisał(a):

Tak się zastanawiam ilu tutaj troluje, a ilu naprawdę nie rozumie, że taki ciąg Fibonacciego to całkiem dobra sprawa do odsiania nieogarniętych ludzi. Na wszelki wypadek przypomnę klasyczny artykuł z FizzBuzzem: https://blog.codinghorror.com/why-cant-programmers-program/

Ogólnie to może nie dla juniorów, ale już dla midów i seniorów lubię wrzucić takie w miarę proste zadanie algorytmiczne i zobaczyć jak ktoś je rozwiązuje. Sam się dziwiłem ile seniorów potrafi wylecieć na naprawdę prostych zadaniach w stylu "znajdź największą możliwą sumę dwóch liczb w tablicy tak, żeby złożoność była O(n)".

Oczywiście, bo my błędnie zakładamy że ludzie po prostu nie mogą być aż tak głupi i kłamać na rekrutacji nie potrafiąc w ogóle programować. A okazuje się że jakieś 4/5 to tacy kłamcy. Nie potrafią rozwiązać fizzubzza ani w ogóle napisać czegokolwiek co piszą uczniowie uczący się Pascala czy czego tam się teraz uczą. To jest tragedia i dlatego trzeba ich odsiewać. Jest dużo ludzi którzy przez całe lata w pracy dodają tylko frameworki do projektu i piszą kod który składa się w 99% z:

  • konfigurowania beanów w springu
  • tworzenia endpointów
  • delegowania do innego gotowego kodu
  • przeklejanek z drobnymi zmianami
  • wywoływania innych usług

Na rekrutacji nie potrafią napisać silni bez użycia reurencji. Zresztą zobacz ilu ludzi w tym wątku zapiekło :)

11

@The Pontiff: "Przecież to są pytania na pierwsze 5 minut. Pytanie - odpowiedź i tak x5" - powiedz to autorowi wątku. Ja spotkałem się z takimi, co dręczyli i cała rozmowa wyglądała jak recytowanie dokumentacji. Jestem przeciwny popadaniu w skrajność typu "nie umiesz hashcode - nie rozmawiam z tobą". Znajomość mechanizmu jest ważna, ale od tego mam dokumentację, żeby nie musieć zaśmiecać sobie głowy szczegółami. Przecież nawet pracując nad jednym projektem możemy zapomnieć jak działa moduł, którego nie ruszaliśmy trzy miesiące. Czy w tym czasie ma stać nade mną przełożony, który mnie zwolni jeśli nie wyrecytuje mu regułki o kontrakcie? Gdybym ja zadał takie pytanie, to oczekiwałbym, że ktoś wie dokładnie jak to działa albo wie gdzie szukać informacji na ten temat, żeby sprawdzić w parę minut. Jak ktoś wciśnie ctrl+q w Intellij, żeby zobaczyć dokumentację metody hashcode, to też uznam odpowiedź. Nie zawsze ważne skąd ktoś recytuje regułki - z dupy, z głowy czy z dokumentacji. Ważne, że umie sobie radzić.

17

Czy u Was w pracy taki junior będzie implementował algorytmy, gdzie złożoność obliczeniowa ma znaczenie i czy będzie analizował algorytmy rekurencyjne?

Pytam bez złośliwości, po prostu wydaje mi się, że to kolejny przykład, gdzie wymaga się algorytmiki i detali, a w pracy będą CRUDy, gdzie ważniejsza jest cierpliwość, a nie znajomość wyżej wymienionych rzeczy.

4

Moim zdaniem ułożyłeś pytania rekrutacyjne nie sprawdzające faktycznie umiejętności potrzebnych na dane stanowisko.

To nie będą typowe zadania, które junior będzie wykonywać.

1

Eh, smutne to. Ja reviewowałem w pracy ostatnimi czasy kod, który by na SO został wywalony za niską jakość (sic! tak źle było). Zgadzam się poniekąd z tym co @The Pontiff pisze, zastanawiam się tylko, na ile to jest wina tych ludzi ("że są głupi"), na ile rynek wymaga od nich bycia niskiej jakości wyrobnikami. Bo takimi ludźmi jednak się projekty dowozi, bo szybciej, szybciej, ficzer butem dopchnąć i niech leci. Projekt zrobiony, lata doświadczenia i cyk, leci.

@rgawron z jednej strony racja, z drugiej - trochę wstydzior jak "midosenior" odwala (w sensie: ocenia negatywnie) na review binary_search na rzecz fora po posortowanej kolekcji, bo nie wie czym jest to pierwsze twierdząc jednocześnie, że dba o czytelność.

5

Takie pytania na juniora to sprawdzą co najwyżej czy dzień przed rekrutacją ktoś se odpalił top 100 java interview questions. Tydzień po rekrutacji taki człowiek już i tak nie będzie nic z tego pamiętał xd
Wg mnie na juniora najlepiej sie sprawdza zadanie domowe, w którym ocenisz jak ktoś dzieli klasy, pakiety, czy pomyślał o testach itp itd.
Oczywiście to wszystko w kontekście 95% projektów aka smutnych crudów.
No i czasu oszczędzisz, bo szybciej sie to przegląda niż odbywa rozmowe

2

Zacznij robić interview przez telefon, 15 min i szereg pytań. Albo oddeleguj juniora albo babkę z hr do weryfikacji.

0

@PerlMonk: Kto ci powiedział, że takie męczenie trwało godzinę? Łamanie tego nieszczęsnego kontraktu jest nagminne w produkcyjnym kodzie, bo żeby "zajrzeć w dokumentację" musisz wiedzieć, że to tam jest. Podałem absolutnie wstępne, pytanka z Java, które zadawaliśmy pierwotnie "na rozgrzewkę", żeby kandydat trochę się uspokoił. Nie jestem w stanie wymyślić nic prostszego. Oczywiście może to być mój problem. Jak ktoś deklarował, że zna Springa, to dostawał np. pytanie o sposób wstrzykiwania zależności, czyli najbardziej podstawową i najbardziej powszechnie używana funkcję tego frameworku, efekt nie był lepszy. Wszystkie te pytania, to przeraźliwie nudne pytania quizowe, które dostają ludzie na połowie rozmów kwalifikacyjnych i są na każdej liście "jak przejść rozmowę na programistę".

Co do zadania - jest dużo narzekania, że na rozmowach każą komuś pisać kod na kartce, to zrobiliśmy "lepiej", poprosiliśmy o przygotowanie IDE, pełen komfort, podpowiadanie składni, makra, dokumentacja, co kto chce. I problem, bo poprosiliśmy osobę, której podstawowym zadaniem ma być pisanie kodu o napisanie kawałka kodu? Przecież przeczytanie banalnego kawałka programu, rozwiązanie problemu, który w nim jest to absolutna podstawa pracy programisty.

@rgawron: Projekt jest wieloczęściowym systemem, występują w nim aplikacje klienckie, chmurowy backend, w cholerę roboty z infrastrukturą, bezpieczeństwem. W jego fragmentach występują duże problemy z wydajnością i trzeba "coś" sprytnie zrobić, żeby zredukować koszty infrastruktury, albo poprawić wrażenia użytkownika. Zadanie takie, a nie inne, bo nie byliśmy w stanie wymyślić nic prostszego. Ot pobrać projekt z gita, dopisać test, poprawić, done.

3

Wszystkie metody rekrutowania są dobre, a zarazem złe - pytanie tylko kogo pytasz.

Bezdzietny lub desperat pewnie chętniej zrobi zadanko domowe czy pójdzie na 15 etapów rekrutacji

Ktoś, kto jedyny "algorytm" jaki przez ostatnie 2 lata napisał, to przejście po drzewku pewnie nie będzie zadowolony z Leetcoda

Ktoś, kto ćwiczył do interview teoryjkę OOP, SOLIDa i Leetcoda pewnie się zdziwi jak zapytasz go jakby coś zaprojektował lub jak działa DI w Springu

itd.

2

@piotrpo: ja do hashcode ostatnio zaglądałem może rok temu. Zgadzam się, że to są podstawy i można się bardzo boleśnie wyłożyć, jeśli się nie wie, że do czego jest hashcode. To jednak jest jedna z wielu rzeczy z jakimi programista ma do czynienia. Ja dziś spędziłem pół dnia na szukaniu przyczyny, dla której tabelka sortuje się na jednym widoku a na innym nie. Była mi przydatna cierpliwość i umiejętność debugowania w IDE. Tym razem bardziej przydała mi się wiedza czemu Intellij nie pokazuje zawartości zmiennej, jeśli używam Springa. Innym razem pewnie wyjdzie co innego i będę się uczyć.

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