Jaki procent z tego co używacie w pracy znajdujecie potem na rozmowach rekrutacyjnych?

Oczywiście chodzi mi o rekrutację w swoim stacku w którym aktualnie pracujecie. Czyli np programista Javy i idziecie na rekrutację na programistę Javy.

Zastanawia mnie ile z tych funkcjonalności których używacie nacodzien przydaje się żeby potem zabłysnąć na rozmowie.

W moim przypadku mam wrażenie, że tak z 10-20%. I gdybym się nie uczył samodzielnie po godzinach to generalnie nic bym chyba nie wiedział, bo ciągle na jakichś rozmowach znajdują się rzeczy/funkcjonalności których ostatni raz używałem np na studiach, albo pytania o szczegóły implementacyjne które nigdy mi się nie przydały i o których zapominam zaraz po przeczytaniu, bo ich po prostu nie używam.
Nie wiem czy kod w moim projekcie jest tak prosty i generalnie nie trzeba o niczym myśleć czy jak...

Dokładnie jest tak jak piszesz.

Też w drugą stronę - praktycznie nic z tego o co pytają na rozmowie rekrutacyjnej nie przydaje się później w pracy. Dziwne więc żeby w drugą stronę to działało.

Czitels napisał(a):

Nie wiem czy kod w moim projekcie jest tak prosty i generalnie nie trzeba o niczym myśleć czy jak...

Z jednej strony tak, jednak po paru latach pracy odkryłem że tak naprawdę nigdy nie będą ode mnie wymagać zaawansowanej wiedzy i to ode mnie zależy czy jej użyję. A okazuje się przy odrobinie inicjatywy miejsc gdzie można jej użyć znajduje się całkiem sporo nawet w prostym projekcie. Trzeba tylko uważać żeby nie przesadzić i nie zrobić over-engineeringu i niepotrzebnie nie komplikować prostych rzeczy.

Zero

o szczegóły implementacyjne które nigdy mi się nie przydały

Albo czasem pytają o wytłumaczenie jakiegoś skrótu, czy wylistowanie wszystkich możliwych sytuacji, charakteryzujących się X, czy każą wymieniać wszystkie rodzaje Y. Ogólnie pytanie o teorię. Nie lubię takich pytań, bo są one dość zbiasowane i trzeba się wstrzelić w to, co pytający chce usłyszeć. Trochę jak kucie definicji na informatyce w szkole. Powiesz nie tak, jak nauczyciel chce, albo zapomnisz wymienić czegoś czy nie zrozumiesz pytania (bo te pytania mają zwykle podtekst i trzeba umieć czytać między wierszami), obniżona ocena.

Jak firmy zadają takie pytania, to powinno być w ogłoszeniu wprost napisane, że wskazane jest, żeby kandydat się zapoznał z teorią i np. link do bloga firmowego z definicjami do nauczenia się na pamięć.

Zastanawia mnie ile z tych funkcjonalności których używacie nacodzien przydaje się żeby potem zabłysnąć na rozmowie.

Rozmowa rozmowie nierówna.

• na niektórych rozmowach będą odpytywać z teorii czy duperelek, które rekrutujący zna na pamięć i chce podręczyć kandydata
• na innych będą pytać o podstawowe funkcjonalności języka czy frameworka, wtedy jak umiesz cokolwiek, to zdasz (nie znaczy, że cię zatrudnią, tylko że przejdziesz rozmowę techniczną)
• na innych będą pytać o algorytmy (chociaż rzadko się z tym spotykam w świecie JSa).
  itp.

W aktualnej pracy jakies 80-90% bo pytania bazowaly na tym co sie robi na codzien. W sumie u mnie wyglada to tak ide na rozmowe z marszu, jesli przejde i firma mi sie spodoba na rozmowie to zmieniam. Jesli odpadne bo pytali o dziwne rzeczy, to nie ma czego zalowac. Sam staram sie nie pytac o rzeczy ktorych nie wiedzialbym z marszu.

Jak chodziłem po rekrutacjach tak ze 2 lata temu, to tak prawie 100% rzeczy o które pytali były rzeczami których używa się bardzo często. C#.

Generalnie nie trafiłem jeszcze na rekrutacje którą bym uznał za bezsensowną.

Nie wiem. Może 1%? Aktualnie jestem w projekcie (już na szczęście spadam, tylko kasa mnie ty trzymała), gdzie od 3 miesięcy może 30 linijek kodu napisałem w Javie. Za chwilę zapomnę podstaw. (A jestem jednym z tych, którzy sporo tasków biorą he he), reszta to same sqle i jakieś pie..one workflowy.

WhiteLightning napisał(a):

Jesli odpadne bo pytali o dziwne rzeczy, to nie ma czego zalowac. Sam staram sie nie pytac o rzeczy ktorych nie wiedzialbym z marszu.

Rekrutacje są często przeinżynierowane. Programiści odpowiedzialni za rekrutację często zamiast zapytać o proste (ale ważne) rzeczy, to starają się wymyślać rzeczy z kosmosu, chyba tylko, żeby samemu się dowartościować, że coś znają, a kandydat nie.

ja pytałam o to co chciałabym żeby robił w projekcie. KAndydat też potrai być przeinżynierowany, zadanie do zrobienia w php a ten Js nawalił

Zależy od rozmowy.
Ogólnie duża rozbieżność.
Od 10 do 90 procent "przekładalności na pracę", tak bym oceniał.

Czitels napisał(a):

Oczywiście chodzi mi o rekrutację w swoim stacku w którym aktualnie pracujecie. Czyli np programista Javy i idziecie na rekrutację na programistę Javy.

Zastanawia mnie ile z tych funkcjonalności których używacie nacodzien przydaje się żeby potem zabłysnąć na rozmowie.

W moim przypadku mam wrażenie, że tak z 10-20%. I gdybym się nie uczył samodzielnie po godzinach to generalnie nic bym chyba nie wiedział, bo ciągle na jakichś rozmowach znajdują się rzeczy/funkcjonalności których ostatni raz używałem np na studiach, albo pytania o szczegóły implementacyjne które nigdy mi się nie przydały i o których zapominam zaraz po przeczytaniu, bo ich po prostu nie używam.
Nie wiem czy kod w moim projekcie jest tak prosty i generalnie nie trzeba o niczym myśleć czy jak...

Może z 5-10% jako programista Javy mam z tego co przydaje się na rozmowie rekrutacyjnej na to stanowisko. Rozstrzał pytań także na Java Developera jest ogromny. Mnie potrafili pytać z Kafki, Kubernetesa, Redisa, samej Javy, wielowątkowości, baz danych i to tak naprawdę w wersji hardcore.

Masz taki zawód który jest lipny, bo w przypadku zmiany pracy masz znikłe szanse na robienie podobnych rzeczy co robisz w poprzedniej pracy. Tak samo nie wiadomo jak się przygotowywać na rozmowy rekrutacyjne.

Rozwiązanie na to jest pójście w niszę, np. PEGA Developer, Mulesoft Developer, Azure Enginieer, Oracle Database Developer, SAP itd. itd. itd.

Wtedy masz tak, że technologia Ci się pokrywa z tym co robisz w 1-2-3 pracy itd i wiesz z czego się specjalizować. Jako Java Developer nie masz specjalizacji.

Z 60-80%, bo zawsze jakaś cześć stosu technologicznego jest inna.

Są dwa typy rozmów:

1. Jeden z dziesięciu
2. Sensowne odpytanie z używanego stacku

W przypadku tej pierwszej można się spodziewać pierdół implementacyjnych, czy jakiś zadań oderwanych od rzeczywistości. Jak sama nazwa mówi - Konkurs wiedzy bezużytecznej.

W przypadku tej drugiej pojawiają się sensowne zagadnienia i problemy bliskie codziennej pracy. Sprawdza się realną i użyteczną wiedzę z technologii i jej użycie na żywo.

To na jaki typ rozmowy trafisz jest loterią. Nie bez kozery przyjęło się, że przechodzenie interview to umiejętność sama w sobie. Z czasem i doświadczeniem będziesz kojarzył pewne (mało przydatne) zagadnienia i po prostu je sobie powtórzysz przed rozmową.

Na rozmowach zazwyczaj jest 100% tego co jest w pracy, a w drugą stronę to wiadome, że każda firma ma jakieś technologie, której inna firma może nie używać

Wszystko. Natomiast w drugą stronę absolutnie nie

Jaki procent z tego co używacie w pracy znajdujecie potem na rozmowach rekrutacyjnych?

Zero. Ale po rozmowach rekrutacyjnych to tak od 8% do 57% w zależności od nastroju.

Dla mnie te rekrutacje są jak testy na prawko, żeby zdać musisz znać np. prędkość maksymalną jazdy z przyczepą, ale typowemu kierowcy nie jest ci to potrzebne to raz, a dwa to jak będziesz chciał jechać z przyczepą to sobie w parę sekund sprawdzisz w internecie. I w programowaniu tak samo, w dobie internetu najważniejsze żebyś umiał szybko wyszukać i wykorzystać informacji, a nie być chodzącą dokumentacją. Tymczasem na seniora w javie moja typowa rekrutacja się zaczyna od pytania interfejs vs klasa abstrakcyjna xD Dosłownie miałem pojedyncze rekrutacje podchodzące inaczej niż odpytka z teorii (głównie coś praktycznego, raz dłuższa rozmowa o doświadczeniu i wykorzystywanych technologiach w projektach, bez wchodzenia w teorię) i w sumie tylko takie przechodziłem.

benoni12 napisał(a):

Dla mnie te rekrutacje są jak testy na prawko, żeby zdać musisz znać np. prędkość maksymalną jazdy z przyczepą, ale typowemu kierowcy nie jest ci to potrzebne to raz, a dwa to jak będziesz chciał jechać z przyczepą to sobie w parę sekund sprawdzisz w internecie. I w programowaniu tak samo, w dobie internetu najważniejsze żebyś umiał szybko wyszukać i wykorzystać informacji, a nie być chodzącą dokumentacją. Tymczasem na seniora w javie moja typowa rekrutacja się zaczyna od pytania interfejs vs klasa abstrakcyjna xD Dosłownie miałem pojedyncze rekrutacje podchodzące inaczej niż odpytka z teorii (głównie coś praktycznego, raz dłuższa rozmowa o doświadczeniu i wykorzystywanych technologiach w projektach, bez wchodzenia w teorię) i w sumie tylko takie przechodziłem.

Akurat takie pytania na seniora mnie nie dziwią. Wbrew pozorom jest mnóstwo słabych „seniorów”, którzy tytuł znaleźli w czipsach ew dostali za dupo godziny.

był lepszy mem z potężnym niedźwiedziem na rozmowie i kubusiem puchatkiem w pracy, ale nie mogę znaleźć

Proszę:

Czyli wychodzi na to, że rozmowy rekrutacyjne są takie bezsensowne i ciężkie tylko dlatego, że programiści rekrutujący nie chcą zatrudnić gościa, który będzie zarabiał tyle co oni(lub więcej) a umiał mniej niż oni mimo, że całej tej wiedzy nie potrzebuje żeby pracować w tej firmie i robić te same taski co oni.
Czyli po prostu dupa by ich piekła i rekrutacje są bardziej dla szacunku do samych siebie xD

@Czitels: a skąd ten programista ma niby wiedzieć ile ktoś będzie zarabiał? oO

WeiXiao napisał(a):

@Czitels: a skąd ten programista ma niby wiedzieć ile ktoś będzie zarabiał? oO

No przecież nie rzadko na rozmowach z programistami się mówi oczekiwania finansowe xD

Edit:

W dodatku z tymi rekruterami którymi gadałem to każdy wiedział jaki jest budżet na danego kandydata. Mówię tu o dużym korpo i mniejszej firmie

Nie mówiąc o faktu że jak już by to było chronione to można sobie wygooglav ofertę pracy do własnej firmy.

@Czitels:

nigdy się nie spotkałem z czymś takim :D

brzmi trochę suabo, nie sadzisz?

W dodatku z tymi rekruterami którymi gadałem to każdy wiedział jaki jest budżet na danego kandydata. Mówię tu o dużym korpo i mniejszej firmie

budżet/widełki to szeroki rozstrzał

WeiXiao napisał(a):

@Czitels:

nigdy się nie spotkałem z czymś takim :D

brzmi trochę suabo, nie sadzisz?

Dodałem edit jeszcze jak coś.
No wiem to z doświadczenia i rozmow z innymi. Dziwi mnie, że się nie spotkałeś z czymś takim.

W sumie z tymi zadaniami rekrutacyjnymi jest tak, że po prostu ludzie są leniwi i łatwiej wejść na leetcode/hackerrank, wybrać sobie zadanie, zobaczyć 5 przykładowych rozwiązań, zadać je osobie starającej się o prace, a przy okazji wykorzystać testy do nich napisane i tyle, bardzo mały nakład pracy.

Ja raz robiłem jedno zadanie i miałem rozwiązać pewien problem, żeby go rozwiązać musiałem zaimplementowałem absorbing markov chain.
Jakiś czas potem chciałem zbudować MuZero algorytm, który nie ma modelu gry, gdzie model gry to znasz zasady i możesz sobie zagrać w pamięci i sprawdzić kiedy się gra zakończyła.
Bez modelu gry, nie idzie tego sprawdzić, ale możemy tym algorytmem policzyć terminal state, wtedy możemy grę traktować jakbyśmy mieli model, tyle że mamy model statystyczny.

Te zdania z grafami i wiele innych to często w ML/AI, w jakichś niestandardowych rozwiązaniach najczęściej inżynieryjnych.
Dużo algorytmów się nie implementuje from scratch, ale na fpga już tak, to warto umieć napisać sekwencyjnie za nim się zrobi równolegle sprzętowo, bo wiadomo będzie za duża przepaść wiedzy żeby poradzić sobie z zadaniem.
Ale też dobrze mieć wewnętrzną świadomość jak coś jest zaimplementowane i umieć to zrobić/wyobrazić sobie.

Czitels napisał(a):

Czyli wychodzi na to, że rozmowy rekrutacyjne są takie bezsensowne i ciężkie tylko dlatego, że programiści rekrutujący nie chcą zatrudnić gościa, który będzie zarabiał tyle co oni(lub więcej) a umiał mniej niż oni mimo, że całej tej wiedzy nie potrzebuje żeby pracować w tej firmie i robić te same taski co oni.

Nie spotkałem się żeby techniczni rekruterzy mieli dostęp do oferty kandydata, chyba że jednocześnie są na poziomie managera - to by był wyciek poufnych informacji w firmie i może jedynie się zdarza w małych startupach.
Za to widełki dla wszystkich w firmie na danym poziomie są takie same i każdy wie ile mniej więcej ta osoba będzie zarabiała. Nawet nie trzeba pracować w firmie żeby to wiedzieć. Natomiast zupełnie nie o to chodzi.
Chyba każdy zresztą chciałby móc pracować z lepszymi bo jest okazja żeby się czegoś nauczyć i nie tracić czasu na douczanie ich.

Nie wiem czy byłeś kiedyś z drugiej strony, ale jest cholernie trudno przetestować kogoś w 30 minut czy godzinę.
Jak zapytasz o "proste (ale ważne) rzeczy" to niemal 100% kandydatów odpowie perfekcyjnie i nie ma po czym odsiać, a potem mają w pracy problem z pierwszym zadaniem które wymaga trochę myślenia. W takiej rozmowie trzeba ocenić nie tylko umiejętności ale też jak się będzie pracowało z taką osobą, godzina to za mało na realne zadanie które sprawdzi to wszystko. Tak naprawdę zadanie ma małe znaczenie, więcej wniosków można wyciągnąć ze sposobu i szybkości jego rozwiązywania, słuchania procesu myślowego itp. Zazwyczaj to jaką ktoś jest osobą wychodzi dopiero gdzieś po miesiącu, a pozbyć się kogoś z teamu jest znacznie trudniej niż zatrudnić i potem trzeba się męczyć.