Dlaczego "juniorzy" nie mogą znaleźć pracy

Kilka luźnych mysli.

1. To prawda, że duża ilość kandydatów nie ma pojęcia o programowaniu. Tak jest od 30 lat (w Polsce może od 15tu) i niewiele się zmieniło. Dla mnie jest szokiem jak widze, że człowiek ma już za sobą pięć lat programowania, 6 różnych firm i na 100% nie ma bladego pojęcia poza "Hello world". Dopiero w Szwajcarii zobaczyłem jak tacy programiści "się rodzą".
2. Pytania z podstaw są najtrudniejsze i to normalka, że odsiewają. Tą prawde to już odkryłem w liceum - mieliśmy takiego matematyka, który uwalał każdego na pytaniach z podstaw. Lepiej było poprosić o zadanie z olimpiady matematycznej, przynajmniej był mniejszy wstyd i problem jak się nie rozwiązało. Bo podstaw jest bardzo dużo. Łatwoczegoś nie pamiętać. A jak nie zapomnisz to jest od razu awantura (z ust mojego matematyka padały wtedy słowa "to jest jakieś nieporozumienie" - co często oznaczało, awans do innej klasy / szkoły).
   Dlatego pytania typu hashCody to loteria, gdzie przypadkowo zdobyta przez rekrutera wiedza spotyka się (lub nie) z przypadkowo zdobytą wiedzą przez rekrutowanego. Programowanie to już od dawna za szeroka działka, żeby znać chociaż 10% podstaw :-). I każdy z tu wymądrzających się polegnie na jakichś prostych pytaniach, Jak jest młody to za mało jeszcze widział. Jak jest stary to już zapomniał.
   Egzaminu typu OCP Java X z marszu nie przejdzie nie tylko junior, raczej nie przejdzie żaden mid, a już na pewno senior. A to są podstawy... W innych językach podobnie - typowy quiz z javascriptu (w stylu ydkjs) zabije każdego, a przecież zawiera pytania z podstaw...
3. Największy problem to taki, że w 90% przypadkach firmy nie szukają juniorów. Tylko tak piszą w ogłoszeniach. (oczywiście procent wzięty na czuja).
   Szukają programisty, któremu będzie można pokazać: o tu jest komputer, tu baza danych, pod tym linkiem jest jira, tam jest kuchnia, a w drugą strone toalata. Bierz i napierdalaj. Nie zadawaj za dużo pytań, bo i tak nie mamy na ciebie czasu.
   To nie jest junior. Może 20 -10 lat temu takie coś mogło działać, ale za bardzo działka się rozrosła, chmury, CI, Gity, frameworki, NoSQL, agile clowning, security itd. człowiek zanim ogarnie to już jest stary. Firmy szukają napierdalaczy (powiedzmy midów), a hasło junior wstawiają w dwóch celach:
   a) żeby podkreślić, że nie będzie za dużo kasy
   b) żeby podkreślić, że przyszły pracownik ma nie pyskować (to nawet ważniejsze)
   Oczywiście są ludzie, którzy wychodzą po studiach jako napierdalacze - da się. Ale to raczej zawsze była i będzie garstka. Co więcej jest duża szansa, że taki napierdalacz potrafi sam zrobić serwis od a do z, ale zapomniał już całkowicie algorytmów itp. więc odpadnie...

Jako rekrutujący nie mam dobrego pomysłu - daję zadania do domu (też na tym forum krytykowane) - zależy mi, żeby ludzie na spokojnie mieli szansę popisać kod - potem magluje z rozwiązania, żeby potwierdzić rozumienie. I tak zwykle zadaje pytania dodatkowe i co jakiś czas orientuje się, że znowu zadałem pytanie zbyt proste, żeby ktokolwiek normalny znał odpowiedź :-( (ale czasem ta refleksja przychodzi do głowy mi za późno, jak już widzę, że kandydat zaczyna panikować).

Wniosek mam taki - duże firmy, korporacje mają możliwości i środki na szkolenie juniorów i coraz lepiej ogarniają problem (staże, szkółki itp). Będa wygrywać na tym, że umieją w juniorów. Małe firmy niech się przyzwyczają: juniorzy są nie dla was - nie nadajecie się. Trzeba szukać midów i seniorów i płacić, a do tego znosić pyskowanie.

Tak, dawajcie na zadania rekrutacyjne typowe zadania algorytmiczne. Odsiejecie tych, którym się nie chciało przygotować na spotkanie z Wami i zostanie Wam całe nikt, może 2 osoby, które niekoniecznie wpasują się w zespół. Ja już się nauczyłem, że do zadań algorytmicznych się człowiek nie przygotowuje. Jak ktoś to rył w młodym wieku to może mu to weszło w krew i pamięta rozwiązania na pamięć. Ja już ich nie pamiętam i serio szkoda mi czasu na przypominanie ich sobie, bo ta wiedza mi się do niczego nie przyda, a i tak wyleci mi z głowy. Może kilka firm mi przez to odpadnie, ale jakoś to przeżyję. Mam lepsze rzeczy do roboty w wolnym czasie niż przypominanie sobie zadanek, na ktorych na ogół odsiewa się studentów, w tym momencie na przykład uciekam na szybkie 10min nauki tureckiego, a potem jadę się szczepić :P

@ToTomki: zgoda i nie zgoda. Bo tak, uważam że sprawdzanie czy ktoś zna alg. Dijkstry na pamięć ("personal bias", bo sam na takim czymś kiedyś poleciałem. Wiedziałem który algorytm tam spasuje bo zadanie było iście podręcznikowe, ale miało być z głowy a po prostu nie pamiętałem go ;P) jest przeciwskuteczne poza rekrutacją do algorytmicznego R&D. Jednocześnie: przepraszam, ale o co pytać? Pamiętam kiedyś jak dali mi stringa do odwrócenia, napisałem std::reverse, rekruter nawet się ucieszył że bibliotekę standardową znam i nie drążył. Ale jeżeli kandydatowi wspomnianemu przez OP dasz Fibonacciego, nie pyknie (ok, zaciął się), potem fizzbuzza a na końcu okazuje się, że typ ma problem z pętlą for ogólnie to co masz myśleć?
I żeby nie było. Ja np. bardzo lubię zadania domowe. Ale popatrz ilu tu na forum marudzi, że hurrr, durr czas. To jak delikwenta sprawdzisz? Wszystkim nie dogodzisz, sorry ;p

@alagner: "Ale popatrz ilu tu na forum marudzi, że hurrr, durr czas." - akurat tutaj często jest na coś narzekanie i najlepiej w ogóle nie zadawać pytań na rozmowie, bo jeszcze wyjdzie, że miś tak naprawdę nic nie umie ;) .
W każdym razie godzina rozmowy to naprawdę mało czasu. Jeśli rekruter woli spędzić ten czas na klepaniu formułek, to trochę nie baudzo to wygląda.

Jak się rekrutowałem do mojej pierwszej pracy jako junior oczywiście, to rozmowa kwalifikacyjna była najtrudniejszą rzeczą jaka mnie spotkała w tej robocie :) Nigdy potem nie użyłem tak zaawansowanych cech języka (c++). Jak aplikowałem do drugiej roboty to rozmowa obiektywnie była o wiele prostsza bo pytali po prostu o doświadczenie i luźna pogadanka o pisaniu kodu.
Padł tutaj temat odwracania ciągu tekstowego albo fibo. Zrobiłem oba tematy od razu w C++ i w Pythonie... ale z pomocą internetu. Fibo sam zaimplementowałem ale z wikipedią bo nie pamiętałem jak szedł ciąg na samym początku, natomiast string reverse sprawdziłem jak wygląda to dla cpp i pythona (pomijam samodzielną implementacje tego typu rzeczy).
Dokąd z tym zmierzam?
Otóż mam tak, że naprawdę nie mam pamięci do takich rzeczy, nie wiem jak inni :) Za 3 dni znowu zapomnę jak to szło z tym string reverse. Dlatego jestem zwolennikiem pisania kodu na rozmowie ale z IDE + internet. Obie moje rozmowy miałem z kodowaniem na kartce papieru, co uważam za niezbyt dobre podejście. Mam nadzieję, że to nie jest częsta praktyka i ja miałem pecha po prostu.
Natomiast zadania algorytmiczne tylko do domu, na spokojnie do przeanalizowania. Albo na rozmowie ale gdy naprawdę stanowisko pracy jest znacząco powiązane z algorytmiką. Inaczej nie widzę żadnego sensu w tego typu zadaniach.

ToTomki napisał(a):

Tak, dawajcie na zadania rekrutacyjne typowe zadania algorytmiczne. Odsiejecie tych, którym się nie chciało przygotować na spotkanie z Wami i zostanie Wam całe nikt, może 2 osoby, które niekoniecznie wpasują się w zespół. Ja już się nauczyłem, że do zadań algorytmicznych się człowiek nie przygotowuje.

Nie rozumiem co to za podejście, że od biednego kandydata nie można nic wymagać bo jeszcze nie przejdzie :D

Szukasz człowieka do klepania CRUDów. I:

• algorytmiki sprawdzić nie można - bo niepotrzebne
• znajomości kontraktu hashCode/equals sprawdzić nie można - bo IDE generuje :D
• znajomości standardowego API sprawdzić nie można - bo istnieje Google, a przecież funkcji i tak się nie pamięta
• znajomości SQLa sprawdzić nie można - bo jest Hibernate

Jedyne co można to dać jakieś zadanie do domu, które kolega rozwiąże i wytłumaczy :D Trochę powagi, nikt przy tych zadaniach algorytmicznych nie wymaga od ciebie żebyś pisał quicksorta. W komentarzach napisałem już jeden ekstremalny przypadek - człowiek mający 10 lat doświadczenia miał Ideę, informację o metodach toCharArray(), getCharAt(i) i length() - i nie potrafił wypisać na standardowe wyjście odwrotnego Stringa - jeśli tak ma wyglądać mój przyszły współpracownik to faktycznie wolę pracować sam.

czasem chcą tego quicksorta i sprawdza to automat. Wtedy gorzej ;P
Ale odnoszę wrażenie, że większa ilość tego typu rekrutacji wynika - po części przynajmniej - z pewnego obniżenia poziomu kandydatów. Na początku do IT szli chyba tylko pasjonaci, bo to była nowa branża. Obecnie - jest kasa to ludzie się cisną. Ciężko się dziwić situ...

Oblicz sumę od 1 do N to też jest algorytmika?

wartek01 napisał(a):

Nie rozumiem co to za podejście, że od biednego kandydata nie można nic wymagać bo jeszcze nie przejdzie :D

Szukasz człowieka do klepania CRUDów. I:

• algorytmiki sprawdzić nie można - bo niepotrzebne
• znajomości kontraktu hashCode/equals sprawdzić nie można - bo IDE generuje :D
• znajomości standardowego API sprawdzić nie można - bo istnieje Google, a przecież funkcji i tak się nie pamięta
• znajomości SQLa sprawdzić nie można - bo jest Hibernate

IMHO najlepiej pytać z tego co jest używane w projekcie :) Czyli jak projekt to CRUDy na Springu i Hibernate to najlepiej pytać o REST, Springa i Hibernate, np problem N+1 selectów lub problem leniwego ładowania :)
BTW jak mnie pytają o Springa i Hibernate to już wiem że nie chce tam pracować :D
BTW2 na Scalę pytali mnie z Monad, Type Class (raz) i Case Class (przemaglowali chyba każde możliwe użycie). Z Type Class poległem bo nie umiałem napisać z palca w Scali 2. Wiem co to ale pisałem tylko w Haskellu :D

Algorytmy tak ale po coś. Jakby mnie ktoś spytał o kolizje brył geometrycznych w game dev to bym się nie zdziwił ale jakbym aplikował do software house to walnąłbym WTF bo jak to niektórzy powiedzieli to nic nie sprawdza.

Najlepiej jest zaprosić kandydata z którym się luźno rozmawiało wcześniej przez telefon. Nie ukrywajmy jak się ma doświadczenie to czuć jest czy osoba Ci ściemnia czy nie. Zresztą można prosić o konto na githubie czy code wars. Jeśli po człowieku NIE MA śladu to są dwie opcje albo wymiatacz albo gość co nic nie potrafi.

Dać kandydatowi link do artykułu z objaśnieniem jakiegoś algorytmu i poprosić go o napisanie kodu na podstawie ów artykułu. Sprawdza się czy człowiek umie czytać ze zrozumieniem i czy potrafi zaimplementować to o czym przed chwilą się dowiedział. Braki w wiedzy o bibliotekach używanych w projekcie można szybko nadrobić, a to coś albo się ma albo nie.

@jarekr000000 miał 100% racji każdy z nas poleci na podstawach języka bo ich nie pamiętamy albo one są tak mało istotne że nigdy się ich nie musieliśmy uczyć. Ktoś tutaj przytoczył sprawę algorytmu Dijkstry NIE MA opcji żebym z głowy napisał Dijkstre czy A*, sortowanie bombelkowe czy quicksorta. Jakieś sortowanie napiszę ale jak ono się nazywa y....? To jest trochę jak z REST'em każdy używał ale nikt nie wie jak wygląda prawdziwy RESTFull i do czego są te wszystkie komendy :D

Pod katem procesu rekrutacyjnego zazdroszcze lekarzom. Idziesz pokazujesz papiery, ustalasz godziny pracy dogadujesz sie o stawke i tyle. Nikt nie pyta czy np. hobbistycznie operujesz kurczaki wieczorami, albo czy w ramach pet projectow leczysz sasiadow po godzinach.

Tak widzę te Wasze rekrutacje w których pytanie o fibonaciego czy inne hashcody...

Zołnierz ma strzelać, a nie recytować regułki.
Programista ma pisać kod, projektować, a nie recytować regułki.

@WhiteLightning:

Wiele osób powyżej kwestionuje cel zadawania "pytanek algorytmicznych" na rozmowach. Według mnie akurat ten sposób sprawdzania wiedzy jest bardzo dobry. Już tłumaczę dlaczego. Zadania typu leetcode nie mają na celu zapamiętania ich rozwiązań, ale sprawdzenia logicznego myślenia, sposobu podejścia do problemu i poniekąd też inteligencji, poniewaz osoba bez jakiegokolwiek podloza analitycznego bedzie miala prawdopodobnie problem z rozwiazaniem trudnych zadan. 99% tych zadań bazuje na prostych strukturach danych, które powinny być znane (w mojej opinii) każdemu inżynierowi oprogramowania. A samych utartych algorytmów jest bardzo niewiele... wyszukiwanie binarne, dfs, bfs... Ciągle widzę przykład "Dijkstra na pamiec!!!" - otóż nie... Jestem ciekaw czy ktokolwiek spotkał się z tym, że musiał napisać go z głowy - a jeśli tak to firma w której sie rekrutował prawdopodobnie zle interpretuje ten zaciągnięty z zachodu "problem solving". Sam Fibonacci jest przecież podstawą podstaw, ale oczywiście każdemu może sie zapomnieć - Wtedy poproście rekrutera o pierwsze kilka liczb, po ich zobaczeniu pattern powinien być od razu widzialny... Nie twierdze, że skill w rozwiązaniu tych zadań nie słabnie wraz z czasem, ale zakładając scenariusz zmiany pracy co rok, czy nawet co pół roku... to czy nie warto poświęcić tego tygodnia na poćwiczenie? I dzięki temu zyskać potencjalnie ciekawszą pracę? Ludzie z doliny krzemowej raczej nie narzekają, że muszą poćwiczyć LC. Nie chce nikogo urazić, to tylko moja subiektywna opinia.

@Snatch and Pizza: no właśnie Dijkstra z głowy mi się przytrafił w ramach codility (z kamerą i nagrywaniem pulpitu, zasady były jasne co wolno sprawdzać).

Ale tu nie ma sporu, o jakieś proste rzeczy typu binary search imho warto spytać, bo jak mówiłem - widywałem seniorów, którzy tego nie znali nawet z nazwy, a to powinno wszystkie alarmy odpalić momentalnie.

Snatch and Pizza napisał(a):

ale zakładając scenariusz zmiany pracy co rok, czy nawet co pół roku... to czy nie warto poświęcić tego tygodnia na poćwiczenie?

Nie. Bo mam dużo więcej innych ofert, do których ćwiczyć nie muszę. Tydzień na klepanie zadanek, które kiedyś rozwiązywałem, a teraz nie pamiętam (co pokazuje jak to dla mnie użyteczne), to bardzo dużo. Czasu nikt mi nie odda, a życie mamy jedno.

Edit. Ale co ja tam wiem, o binary search usłyszalem tylko raz, a przynajmniej tak mi się wydaje, na rozmowie rekrutacyjnej : P

Edit 2. Jednak nie, to bylo na teście do zrobienia w domu. Wygooglowalem i zadanie zrobilem raczej poprawnie : P

Tak, powinni brać jak leci, nie zadawać pytań i dawać 5k na łapę bo komuś zamarzyło się wejść do mitycznego IT i zarabiać 15k. Wszystkie te zagadnienia, które przedstawił autor zna w stopniu przynajmniej przeciętnym każdy ogarnięty student 1. roku lub uczeń 3-4 klasy technikum informatycznego a na pewno też ktoś kto zwyczajnie interesuje się tematem. Nawet jeśli czegoś nie będzie wiedział to będzie w stanie coś sensownego powiedzieć o 3/4 przedstawionych przez autora tematów.

Zamiana rekurencji na iteracyjne podejście to była chyba 2. klasa technikum informatycznego? Pierwszy lub drugi semestr studiów i to nawet takich w wyższej szkole gotowania na gazie?

W necie są gotowe listy zagadnień z czego warto by było się przygotować do rozmowy na stanowisko juniora, mida i seniora. To nie jest wiedza tajemna i choćby z przyzwoitości wypadałoby dobrze poszukać i odrobinę się przygotować. Nigdy nie uda się przygotować w 100% ale wypada prezentować jakiś poziom. A czy to przydatne w pracy? Raz przydatne a raz nie ale na pewno pokazuje, że kandydat ma podstawową wiedzę i wyrobione pewne schematy myślenia. Tak jak kolega @YourFrog2 napisał implementowanie algorytmu z głowy może nie ma większego sensu ale za to przerobienie istniejącego kodu albo napisanie algorytmu z kartki/ticketu na ździrze to jest coś co robi się w pracy bardzo często.

Wg mnie to jest tak, że kilka lat temu sporadycznie ludziom nie mającym nic wspólnego z IT udawało się zostać programistą. Niekiedy nawet tacy ludzie wymiatali lepiej od klasycznie wykształconych rzemieślników(bo dla mnie to rzemiosło). Wokół tych nielicznych przypadków zbudowana została narracja, że IT to eldorado dla wszelkiej maści osób pragnących "odmienić" swoje życie. Nie, to nie jest żadne eldorado tylko branża jak każda inna w której chwilowo brakowało pracowników.

To były takie moje rozważania na temat: Dlaczego "juniorzy" nie mogą znaleźć pracy.

Ale to pytanie o implementację ciągu Fibonacciego to jest męczenie z algorytmów?
Serio ktoś takie coś potrafi w środku tygodnia przed południem i na trzeźwo napisać?

@alagner:

Ale tu nie ma sporu, o jakieś proste rzeczy typu binary search imho warto spytać, bo jak mówiłem - widywałem seniorów, którzy tego nie znali nawet z nazwy, a to powinno wszystkie alarmy odpalić momentalnie.

Na pewno kilka lat temu jakbyś mnie zapytał o algorytm dijkstry to bym zrobił tylko wielkie oczy. 20 lat programowania - co za porażka.
Żeby było śmieszniej to akurat potrafię i potrafiłem napisać z palca - tyle, że po prostu znałem to jako mało interesujący przypadek A*, a nazwa już mi dawno wyleciała z głowy.
Żeby było śmieszniej - jako programista typowego web devu nigdy żadnego A* nie musiałem pisać ani użyć - więc normalnie bym zupełnie zapomniał. Przypadek tylko, że siedziałem trochę w gauano game devie ( bo do indie temu było daleko).

Na szczęśćie nie jestem juniorem i w większości firm o kod i algorytmy mnie nawet nie pytają. Wystarczy długie CV... A potem się zastanawiam jak to możliwe, że kolega z równym mi stażem (zespół od klienta) nie umie napisać testu, nie umie użyć debuggera, a jak kod wykracza poza gettery i settery to wpada w panikę.
Ale za to obserwowanie jak dodaje losowo kolejne adnotacje z listy wszystkich możliych adnotacji jakie znalazł w sieci z nadzieją, że po deploymencie coś zadziała jest nawet satysfakcjonujące - zwłaszcza jak raz na kilka miesięcy coś mu zadziała.

Juniorze! Zamiast płacić bootcampa, zrób sobie zabieg postarzania skóry (może jakieś instensywne opalanie + odwodnienie), doklej brodę, sfejkuj CV - i tak tego nikt nie sprawda, zachlej na dzień przed rozmową, żeby były wory pod oczami i głos jak przepitego 20letniego programisty i startuj od razu na seniora lub tech leada.
Łatwiej się będzie dostać, a i kasa lepsza.
Warto może sobie poczytać o jakichś modnych technologiach i rzucać losowo nazwami, wymyśl ze dwa skróty sam na wypadek gdyby o coś pytali. Im bardziej absurdalne odpowiedzi dasz tym większa szansa, że rekruterzy uznają, że czegoś nie wiedzą i jesteś wymiataczem.

@jarekr000000: ja znowu jestem bardziej programistą systemowym i chętnie bym zobaczył pytanie o kablorekina czy memory sanitizer albo inne core dumpy.
A debugger to chyba wszędzie podstawa.

I zgoda, niech to u Ciebie będzie pytanie o coś innego. U kumpla w projekcie (Java, Web) goście położyli aplikację zapytaniami do ogromnej bazy co trochę, bo nie wpadli żeby jakieś dane statystyczne policzyć przyrostowo. Tzn. koleżka wpadł, zrobił fixa, tłumaczy juniorom a oni do niego że pamięć jest tania ;)

Zresztą to nie chodzi o ten konkretny binary search, ale jak przy pięciu tego typu pytaniach z rzędu kandydat się wyglebia to przyznasz, że jednak zostawia to pewne złe wrażenie? Tzn. mówię, ja zawsze bardzo lubiłem zadania domowe i potem code review tego. Ale serio odwrócenie stringa (przykładowo) to nie jest coś czego należy unikać imho, chociażby jako wstępnego screeningu.

U kumpla w projekcie (Java, Web) goście położyli aplikację zapytaniami do ogromnej bazy co trochę, bo nie wpadli żeby jakieś dane statystyczne policzyć przyrostowo

No i?

Czy to znaczy, że nie umieli?
Czy to znaczy, że nie odratowali tej aplikacji i one umarła?
Czy to znaczy, że zawsze OSZCZĘDZAJ RAM GDZIEKOLWIEK JESTEŚ?
Czy to znaczy, że kolega (ten od fixa) nigdy nie położy aplikacji?

ależ dyskusja wyszła! Ja kiedyś miałem jakieś zadanka na złożoność obliczeniową itp. Firma opracowywała jakiś system oparty o real time. I tu się zgodzę to było dla nich ważne. Więc problemy algorytmiczne czy złożoności obliczeniowe jak najbardziej mają sens paść, byle miało to osadzenie w działalności firmy.
Jak ktoś szuka gościa do zrobienia stronki albo jakiegoś softu nie krytycznego obliczeniowo(czytaj większość softu w polsce) to nie widzę sensu pytania o coś więcej niż fibonacci. A na pewno nie widzę sensu w pytaniach z serii "damy ci link do codility".

Co do tego że ktoś nie wpadł na optymalizację X. Cóż jak widzicie że wydajność przysiada obojętnie czy na QA czy jakiś testach automatycznych , to najpierw próbujecie to poprawić a nie od razu "bo pan X czy Y zadał za dużo zapytań". Człowiek uczy się całe życie. Kto z nas się nie pomylił albo nie napisał spaghetti bo za plecami menago?

@jarekr000000: no nie, ale pominąłeś już część „koleżka wpadł, zrobił fixa, tłumaczy juniorom a oni do niego że pamięć jest tania ;)” (w sensie: mentalnie tego nie potrafili przyjąć, za jakiś czas problem się znowu pojawił z analogicznych powodów).

@alagner: a wiesz co ten koleżka spier ... zepsół? I to po całości.

Jest jeszcze jeden aspekt w skali "makro". Jesteśmy Bangalore środkowej Europy.

• Większość projektów jest banalna jak budowa cepa
  -> Nie ma sensu się uczyć
  -> Dostajesz trochę bardziej zaawansowany projekt, ale nie da się go zrobić, bo "nie ma sensu się uczyć"
  -> GOTO #1

I żeby nie było, w aktualnej firmie miałem okazję dotknąć / mieć zapłacone / bawić się:

• geometrią analityczną
• algorytmami grafowymi (w tym Dijkistra)
• optymalizacją
• AI
• Big Data

Tymczasem:

• Najprostsze możliwe pytanie z Java - męczenie kandydata regułkami
• Najprostsze możliwe zadanie zbliżone do produkcyjnego - męczenie kandydata "algorytmiką"
• Wymiana paru zdań po angielsku też pewnie źle
• Zapytanie o podstawy frameworka, w którym niby coś tam robił - po co, to jest w Internecie, ważne jak sobie poradzi sklejając przypadkowe snippety ze SO

ToTomki napisał(a):

Kiedy startowałem na juniora przeprowadzona była rekrutacja w formie testu na kilkanaście osób, a ja jako jedyny takie podstawy ślicznie umialem (teraz nie umiem). Jak rozmawiałem z ludźmi to mówili, że im trochę głupio, że na rekrutację przyszli tacy nieogarnięci,

Czemu głupio? Przecież to się tak robi, że się próbuje zapamiętać, jakie były pytania, a potem się sprawdza je w domu i na poprawce, tfu, na kolejnej rekrutacji już się wie, czego się nie wiedziało wcześniej. Więc nawet jak się nic nie wie, to nie jest to powód do tego, żeby było głupio, tylko element planu działania. Rozmowy o pracę są świetną metodą uzupełnienia wiedzy i dostania feedbacku "czego nam jeszcze brakuje".

Studia dobrze tego uczą (niezależnie od kierunku). Czyli błyskawicznego uzupełniania niezbędnej wiedzy wtedy, kiedy okaże się potrzebna. W kilka godzin przed egzaminem, albo po spalonym egzaminie na 2, żeby na poprawce dostać 5 itp.

@piotrpo:

Pracuje w Szwajcarii, jest dokładnie tak samo. Widocznie jesteśmy Bangalore Zachodniej Europy.

Uważam, że należy maglować rekrutowanych, ale.

U juniorów nie ma co się oburzać jak to nie wiedzą iluś tam podstaw, od tego są juniorami, żeby nie wiedzieć - trzeba szukać czy umie na tyle by był przydatny i nauczalny. Niestety, jak się jest rekruterem i trzepie juniorów to jakoś tak same z siebie odpalają się skłonności sadystyczne (można by pewnie na ten temat badanie zrobić).
Po drugie (co już pisałem), warto w ogóle sobie odpowiedzeć na pytanie czy nasza firma tego juniora i tak nie zmarnuje...(bo raczej tak się stanie).
Po trzecie, o wiele bardziej (niż to jest przyjęte) trzeba maglować midów i seniorów, nie wiem jak w Polsce, ale w CH jest dramat. Straty po juniorze, który nie umiał są zwykle nieduże - ot najwyżej bazkę dropnie. Seniorzy rozpierdolu potrafią doprowadzić firmę do bankructwa... (i pójdą wtedy do kolejnej).
(Tak sobie o dwóch gościach konkretnych przypomniałem, szkoda, że nie można wystawiać minusów przy technologiach na linkedin).

Panowie nie podniecajcie się bo każdy z nas miał doczynienia z szeroko pojętą optymalizacją. Tyle że większość z nich ograniczała się do zmniejszenia wywołań aplikacji trzecich (w tym mówię o dowolnym storage).

Jak bawię się wieczorami w game dev bez silników to faktycznie potrzebuje "umieć" trochę matematyki i algorytmiki. Ale w komercyjnym projekcie najczęściej to jest najzwyklejszy CRUD / Formatki.

Uwielbiam słuchać jak ludzie mówią że pracują przy BIG DATA, a tak naprawdę walą po prostu zapytania na apkę która jest "silnikiem" dobrze zoptymalizowanym pod dany problem. AI z jakim się spotkałem to tylko to w grach. Jeszcze nie widziałem aplikacji biznesowej gdzie potrzebna by była sztuczna inteligencja. Te wszystkie przerabianie zdjęć, postarzania ocry itp. To najczęśćiej dumnie stwierdzenie że AI pod spodem pracuje. A tam z tego AI to nic praktycznie się nie zgadza.

Są oczywiście dziedziny gdzie wydajność jest stawiana na równi z poprawnym wynikiem np samochody autonomiczne, rakiety (nie tylko kosmiczne) czy systemy wykrywania (np. samolotów). Ale na boga ilu z was tak naprawdę przy tym pracuje? Większość biznesu to klepanie sklepu, stronek, jakiegoś API opartego o inne api, coś z płatnościami, g**no aplikacje w telefonie itp. itd. Potrafie sobie wyobrazić że robimy autonomicznego robota np do giełdy i walczymy z innymi autonomicznymi robotami tam algorytmy będą MEGA ważne i będziemy się bić po głowach.

Kiedyś ktoś tutaj przytoczył blog riot'u związany z optymalizacją kodu w ich grach. I wiecie co? Wpis traktował o tym że arr[index] nie trafiał w cache procesora, a nie że używają złego algorytmu do indeksowania danych w strukturze.

Junior ma być juniorem. Ma potrafić sklepać proste problemy z którymi zmagamy się na codzień w pracy. Ja nie wiem jak zbzikowanym trzeba być by wysyłać juniora do części systemu który jest krytyczny wydajnościowo bez wstępnej rozmowy z nim o tym z czego ma skorzystać. A jeśli już nasz system cały jest krytyczny wydajnościowo to miejsca dla juniora w zespole NIE MA.

A jeśli już nasz system cały jest krytyczny wydajnościowo to miejsca dla juniora w zespole NIE MA.

Nie tylko wydajnościowo.
Przy czym to jest układ idealny. Ale czasem szefostwu nie wyjaśnisz i potem masz wagon outsourcingu bo to ciągle taniej niż jeden lepszy inżynier albo przyhamowanie na 3 dni w celu zrewidowania procesu.

EDIT: btw, wychodzi z tego smutny obraz tego, że lata doświadczenia to sobie można w buty włożyć, bo to żadna metryka.

jarekr000000 napisał(a):

U juniorów nie ma co się oburzać jak to nie wiedzą iluś tam podstaw, od tego są juniorami, żeby nie wiedzieć - trzeba szukać czy umie na tyle by był przydatny i nauczalny. Niestety, jak się jest rekruterem i trzepie juniorów to jakoś tak same z siebie odpalają się skłonności sadystyczne (można by pewnie na ten temat badanie zrobić).

Ja się nie oburzam, nie te lata. Ja się co najwyżej dziwię. Nie jestem rekruterem, a skłonności sadystycznych nie mam. Najłatwiej udowodnić że ja się szybko uczę prezentując wiedzę, którą się zdobyło wcześniej.

Po drugie (co już pisałem), warto w ogóle sobie odpowiedzeć na pytanie czy nasza firma tego juniora i tak nie zmarnuje...(bo raczej tak się stanie).

Nie sądzę - jak na juniora jest sporo możliwości uczenia się nowych rzeczy, jest na to czas, jest kogo pytać o radę. Jak postanowi iść ciemną stroną mocy i losować adnotacje do Springa, to będzie to jego wybór :D

Po trzecie, o wiele bardziej (niż to jest przyjęte) trzeba maglować midów i seniorów, nie wiem jak w Polsce, ale w CH jest dramat. Straty po juniorze, który nie umiał są zwykle nieduże - ot najwyżej bazkę dropnie. Seniorzy rozpierdolu potrafią doprowadzić firmę do bankructwa... (i pójdą wtedy do kolejnej).

Zgadzam się, ale to jest jedynie kolejny wyraz tego samego ciągu. Kiepski junior, u kiepskiego seniora, po jakimś czasie zostaje za dupogodziny "midem", jak wszyscy uciekną z projektu, to staje się najbardziej doświadczonym graczem na boisku, a wiedza jak w dniu rekrutacji czasami.