Zadanie rekrutacyjne na juniora - czy faktycznie aż tak źle zrobione?

Ostatnio robiłem zadanie rekrutacyjne na stanowisko Juniora (nie wymagali nawet żadnego doświadczenia) z takmi wymaganiami:

As an api consumer, given username and header “Accept: application/json”, I would like to list all his github repositories, which are not forks. Information, which I require in the response, is:

Repository Name

Owner Login

For each branch it’s name and last commit sha

As an api consumer, given not existing github user, I would like to receive 404 response in such a format:

{
    “status”: ${responseCode}

    “Message”: ${whyHasItHappened}
}

 

As an api consumer, given header “Accept: application/xml”, I would like to receive 406 response in such a format:

    {

    “status”: ${responseCode}

    “Message”: ${whyHasItHappened}
   }
Notes:
Please full-fill the given acceptance criteria, delivering us your best code compliant with industry standards.

Please use https://developer.github.com/v3 as a backing API

Application should have a proper README.md file

Tutaj zrobione to zadnie przeze mnie: https://github.com/Sampeteq/github-task
Dzisiaj rano dzwoni do mnie rekruter i dosłownie zjechał mnie ostro za takie rzeczy jak:
1.Paginacja, której nie było w wymaganiach a ją dodałem. Myślałem, że to standard w każdym API, tym bardziej, że to API GItHuba zwracało czasami kilkadziesiąt wyników.
2.Mappowanie odpowiedzi z WebClienta na Stringa zamiast na jakąś klasę mimo, że później jest to robione.
3.Użycie ObjectMappera do mapowania jsona z WebClient na obiekt Javowy. Powiedział, że to mnie definitywnie skreśla
4.Utworzenie WebClienta za pomocą create() zamiast utworzenia beana. Powiedział, że widać, że nie znam Springa
5. Użycie MockMVC w testach integracyjnych controllera zamiast WireMocka czy czegoś podobnego, nazwał to zbrodnią

Jak to oceniacie? Czy rekruter miał racje i takie błędy dyskwalifikują kandydata czy może moje rozwiązanie jest w miarę ok i rekruter przesadził? Nie ukrywam, że byłem w sporym szoku. Nie bardzo mogłem wejść z nim w polemikę, bo telefon zerwał mnie z łóżka i byłem zaspany

Tylko tyle rzeczy wymienił?

Ten motyw z paginacją trochę dziwny. Raczej nie ma nic złego jak kandydat doda coś od siebie, szczególnie, że to nie zaburza działania aplikacji.

Nie powiedziałbym, że to jest "tragicznie", ale błędy są dobrze wytknięte. IMO te problemy biorą się z braku doświadczenia ze światem rzeczywistym - ale to jest coś, czego od początkujących się nie wymaga.

Jest jednak kwestia taka, że junior juniorowi nierówny. Tj. w jednej firmie od juniora wymaga się właśnie takiej znajomości Springa, a w drugiej już nie. Najlepiej dla ciebie będzie jak olejesz wrzutki typu "widać, że nie znasz Springa", ale feedback stricte techniczny weźmiesz i rozkminisz, bo jest całkiem ok.

A co ci po tym jak my to oceniamy?

Jak dla mnie twoje błędy nie mają znaczenia, ale co ci po tym? Wydrukujesz sobie moje zdanie na serwetce i będziesz sobie nią ocierał łzy w kącie?

Wyluzuj, trafiłeś na jakiegoś odklejeńca.
Kodzik całkiem spoko, szczególnie jak na juniora
Jakbym miał za takie rzeczy uwalać ludzi / odrzucać PRy to spokojnie ponad połowa firmy do wymiany.

dosłownie zjechał mnie ostro

Powiedział, że to mnie definitywnie skreśla

Powiedział, że widać, że nie znam Springa

nazwał to zbrodnią

Nie chciałbym pracować z osobą, która nie panuje nad swoimi emocjami.
Jesteś juniorem więc to normalne, że w codziennej pracy na początku będziesz popełniał tego typu błędy. Nie przejmuj się, wyciągnij wnioski techniczne, niepotrzebne jego komentarze olej i rób dalej swoje.

Ten sam post na wykopie - w komentarzach szkalowany i nieradzący sobie z emocjami rekruter.
Ten sam post tutaj - w komentarzach szkalowany i nieradzący sobie z emocjami kandydat.

Zdania ekspertów są podzielone xD

ad 1.

To może mieć znaczenie, ale nie na tym etapie.

ad 2.

Zależy od kontekstu. IMO, można się do tego przyczepić, bo klient powinien zinterpretować odpowiedź. Tutaj problem leży raczej w tym, że w RepositoryReadService masz wmieszaną logikę, która powinna być po stronie klienta. Przykładowo z metody String getRepositoriesByUsername(RepositoryQueryDto dto); można zrobić:

UserRepositoriesResponse getRepositoriesByUsername(RepositoryQueryDto dto);

record UserRepositoriesResponse(List<Repository> repositories);

Wtedy GitHubMapper nie wycieka za pakiet klienta, a serwis korzysta ze zdefiniowanej struktury, którą w razie czego może sobie przetłumaczyć na bliższą sobie. Rzuć okiem na prezentację Dominika Przybysza o Portach i adapterach

ad 3.

Trochę tak, ale dużo w tym jadu. Od juniora nie trzeba wymagać wiedzy, że jest T toEntity(Class<T> bodyClass). Można to zupełnie inaczej ocenić i wskazać, że są optymalniejsze metody pracy.

ad 4.

Chcę zobaczyć, jak on zna Springa. I znowuż, to jest błąd, ale typowo juniorski i jest to miejsce do dyskusji i zadawania pytań, a nie „zjebki”.

ad 5.

Ktoś ma ulubioną bibliotekę… Szczególnie, że jak używasz reaktywnego WebClient, to docelową metodą testowania jest raczej WebTestClient.

ps. trafiłeś na kogoś, kto nie potrafi dawać feedbacku. Nie przejmuj się, może lepiej odpaść teraz niż użerać się z takim „szefem” w przyszłości.

imo rekruter wytknął ci rzeczy, które akurat są najmniej istotne

moim zdaniem największy błąd jaki to popełniłeś to taki "tutorialowy" czyli 'package by layer' - nazwy takie jak infrastucture, dto, respositories, controller itd. Przez to wszystko co stworzyłeś musi być publiczne, bo znajduje się z osobnym pakiecie. W realnych projektach stosuje się "package by feature" czyli w tym samym pakiecie masz np: DTO, encję, serwis, kontroler, repo - i wtedy niektóre rzeczy możesz wyenkapsulować stosując dostęp package-private, (pracująć w realnym projekcie chcesz mieć jak najmniej klas, metod z dostępem public - zaufaj mi) a jeżeli serwis z innego pakietu potrzebuje dostęp do tego pakietu to robisz fasadę (w realnym projekcie oczywiście, bo ten jest za mały, tu byłby to przerost formy nad treścią)

Poczytaj o 'package by feature' - w kilka minut zrozumiesz o co chodzi

CoderOne napisał(a):

imo rekruter wytknął ci rzeczy, które akurat są najmniej istotne

moim zdaniem największy błąd jaki to popełniłeś to taki "tutorialowy" czyli 'package by layer' - nazwy takie jak infrastucture, dto, respositories, controller itd. Przez to wszystko co stworzyłeś musi być publiczne, bo znajduje się z osobnym pakiecie. W realnych projektach stosuje się "package by feature" czyli w tym samym pakiecie masz np: DTO, encję, serwis, kontroler, repo - i wtedy niektóre rzeczy możesz wyenkapsulować stosując dostęp package-private, (pracująć w realnym projekcie chcesz mieć jak najmniej klas, metod z dostępem public - zaufaj mi) a jeżeli serwis z innego pakietu potrzebuje dostęp do tego pakietu to robisz fasadę (w realnym projekcie oczywiście, bo ten jest za mały, tu byłby to przerost formy nad treścią)

Wiesz co, ja znam to podejście z package by feature i package scope i nawet z paru rzeczy udało mi się usunąć "public", ale bałem się iść całkowicie w tym kierunku, bo to podejście nie jest zbyt popularne i bałem się, że rekruter nie będzie wiedział o co chodzi i powie, że mam bałagan w kodzie, bo nie ma wydzielonych warstw

@Nofenak: debil nie rekruter. powodzenia z dalszym szukaniem pracy.

Jedynie do czego bym się przyczepił to ten create webclient zamiast beana

generalnie abstrahując od tego ze ten typ to buc z twoich wypowiedzi widać ze było za mało interakcji z rekruterem. Generalnie wszędzie gdzie masz wątpliwości powinieneś pytać. Bo da to rekruterowi zrozumienie twojego toku myślowego. A jak ktoś cię zjebie ze zadajesz za dużo pytań tzn ze nie chcesz tam pracować.

Na Juniora nie jest źle.

Trochę pomieszałeś przy architekturze, w katalogu infrastructure nie powinno być interface'ów tylko ich implementacje.
I brakuje symetrii jak masz klasę XyzRequest to warto też mieć XyzResponse.

Testy wyszły nieczytelne, generalnie jak masz duży JSON w teście to lepiej go załadować z resource'ów niż mieć takie coś w kodzie na 50+ linijek.

Powiem Ci taką prawdę: rekrutują zwyczajni ludzie, czasami pies rekrutera ugryzie lub żona, ma zły dzień i potem pluje jadem. Absolutnie się tym nie przejmuj. Generalnie nie jest źle, rekrutuj dalej.

O Springu się nie wypowiadam, nic a nic z tego xyz nie pamiętam, w robocie nie używam, jak do tej pory nie spotkały mnie z tego powodu nieprzyjemności. Warto nauczyć się frameworka ale dopiero jak będziemy wiedzieli że zwiążemy z nim naszą karierę na kilka lat.

W dobrze prowadzonym projekcie, wszelkie zagadnienia frameworkowe są ukryte, tak że nowa osoba wchodząca do projektu jest dosłownie prowadzona za rękę przez istniejącą architekturę i konwencje. Można na ten temat napisać blog'a, więc skończę tutaj.

jeszcze nie przeczytałem w całości, ale już widzę pewien rozdźwięk. Dane w wymaganiu wymagają, żeby mieć właściwość Message w tym JSON, a w tym readme jest napisane, że tworzysz właściwość message. Zupełnie inna właściwość, czyli robisz coś niezgodnego ze specyfikacją XD No ale czasem specyfikacja jest pisana na kolanie, więc trzeba dopytać, co autor taska miał na myśli (bo właściwość Message nie pasuje stylistycznie do właściwości status, która jest pisana z małej. To w końcu jak).

Odnośnie części technicznej, to już wszystko zostało powiedziane - jest kilka rzeczy do poprawy, każda firma ma inna definicje „juniora”, własną drabinkę. Z ta paginacją to tricky sprawa, ja jako reviewer bym to docenił, przecież każdy kandydat chce się wykazać i walczy o dodatkowe punkty.

Odnośnie stylu feedbacku, to takie coś absolutnie zle świadczy o firmie. Nie wiem, czy to rekruter sprawdzał to zadanie czy zapomniał zwrócić uwagi reviewerowi na język. Kiedyś dostałem podobny negatywny feedback i z perspektywy czasu cieszę się, że nie pracowałem z takimi ludźmi.

Powodzenia przy kolejnych. Wiesz, co nadrobić, będzie lepiej.

A jakbyś nie zrobił paginacji, to równie dobrze mogliby napisać, że nie zrobiłeś paginacji, masz odjęte punkty, bo powinieneś się tego domyślić.

3.Użycie ObjectMappera do mapowania jsona z WebClient na obiekt Javowy. Powiedział, że to mnie definitywnie skreśla

4.Utworzenie WebClienta za pomocą create() zamiast utworzenia beana. Powiedział, że widać, że nie znam Springa

5.Użycie MockMVC w testach integracyjnych controllera zamiast WireMocka czy czegoś podobnego, nazwał to zbrodnią

Nie wiem, czy technicznie miał rację, czy nie (bo nie programuję w Javie), ale nawet jeśli faktycznie tego Springa nie znasz, to ironia polega na tym, że tobie podziękują, po czym zatrudnią innego kandydata, który... również będzie miał jakieś braki w wiedzy i będzie robił coś niezgodnie z regułą sztuki albo będzie czynić "zbrodnię". Bo jeśli firma szuka juniora, to raczej wątpliwe, żeby inni kandydaci mieli jakąś super wiedzę i robili wszystko poprawnie, niczym senior (chociaż również trzeba wziąć pod uwagę, że jest spora konkurencja, więc rekruterzy mogą sobie wybierać do woli i na zasadzie ten nie znał pierdółki, odrzucamy, ten napisał o 10% ładniejszy kod, to przyjmujemy). Więc to, co możesz wyciągnąć, to jeśli czegoś faktycznie nie umiesz, to się nauczyć i na kolejnej rekrutacji w innej firmie już wypaść lepiej).

Trafiłeś na przychlasta który chciał zrobić sobie dobrze i poczuć się lepiej poprzez "zjechanie" drugiej osoby. Komentarze w stylu "widać, że nie znasz springa" brzmią jak jakiś snowflake, który nauczył się kilku rzeczy z tutoriala i zgrywa eksperta xD

Rekruter to jest nie jest zdecydowanie człowiek, z którym chciałbym współpracować, ale w kilku punktach ma rację. Niestety, jest ogromna konkurencja i trochę mnie to nie dziwi przywalanie się do takich szczegółów, kogoś musi odrzucić. Teraz na juniora trzeba tyle co kiedyś na mida.

bustard2 napisał(a):

Rekruter to jest nie jest zdecydowanie człowiek, z którym chciałbym współpracować, ale w kilku punktach ma rację. Niestety, jest ogromna konkurencja i trochę mnie to nie dziwi przywalanie się do takich szczegółów, kogoś musi odrzucić.

To by było dobre podejście, jeśli celem rekrutacji byłoby odfiltrowanie kandydata, któremu najlepiej pójdzie.

I niestety wiele osób tak postrzega rekrutację. Jako cel sam w sobie.

Tylko, że rekrutacja to zaledwie początek do tego, żeby takiego kandydata później zatrudnić i z nim współpracować. I tu już widać nieadekwatność tego typu rekrutacji, gdzie nie myśli się o całokształcie czy czyimś ogólnym potencjale albo skillach miękkich, tylko to, czy ktoś zrobi idealnie zadanie techniczne.

Możecie mówić, że "okej, ale firma musi po czymś przefiltrować", tylko zwróćcie uwagę, że ta firma odrzuciła gościa, który coś nie wiedział z Javy, a zatrudniła gościa, który ma braki w skillach miękkich i nie potrafi się profesjonalnie komunikować bez chamstwa. Jeśli ten styl komunikacji stosuje również na codzień, to firma traci hajs na nim (np. mogę sobie wyobrazić, że junior do niego prosi o pomoc, a on go zjeżdża i w rezultacie junior nie dowozi taska w terminie).

Mi się podoba zgrubsza. ;) Jak dla mnie jednak fajniej jest wszedzie dawać public przed class oraz od razu zwracać wynik zamiast przypisywać go i zwracać zmienną, warto też rozważyć dodanie final przed var. Ogólnie trochę mało tych testów. Mogłeś też zrobić testy end to end i jednostkowe. Co do jego zarzutu z tym WireMockiem, to jeśli nie było to narzucone, to po co się czepia? Ogólnie nie jest źle. Gościa pewnie gnoili w szkole więc się mci. ;)

Zakładając, że to nie zarzutka.
Uważam, że z tej rekrutacji nie da się wyciągnąć żadnych wniosków technicznych i nic co by autor mógł naprawdę poprawić/zmienić. (nie czytałem kodu z GH, więc odnoszę się tylko do samych zarzutów).
Nie ma w nich prawie żadnego głębszego uzasadnienia.

Na każdy z punktów dałoby się jakieś uzasadnienie sklecić sensowne w danym kontekscie - "dlaczego zbrodnia" itp. (choć punkt 4 nie miałbym pojęcia. Wręcz uznaję filozofię odwrotną - ze względu na testowalność. O wiele łatwiej i szybciej testuje się kod, który nie używa beanów - nie ma potrzeby podnoszenia kontekstu springowego.).

Co więcej można by prosić o poprawkę, zmiany, choćby dopytać czy kodujący zna inne podejście. Natomiast określenia typu "skreśla" to jakiś absurd.

Pewnie nie raz powiedziałem, że MockMVC to zbrodnia, do jakiegoś kolegi w zespole. Ale raczej z uzasadnieniem dlaczego w danym przypadku MockMVC jest bez sensu (przeważnie jest). I dokładnie w tym samym czasie w innych projektach używałem MockMVC (płacząc), bo ze względu na powaloną architekturę/infra - trudno było inaczej.

Ogólnie - nie wiem jak było, ale jest szansa, że spotkałeś zakomplesionego buca, który ma małe pojęcie o springu i każde odejscie z wyznaczonej wąskiej ścieżki wywołuje odruch obronny.
Oczywiście, możliwe że dostałeś jakiś rozsądny feedback i tylko przedstawiasz go w przerysowany sposób (tak też zapamętałeś), bo poczułeś się zaatakowany i przestałeś tak naprawdę słuchać. Tak też bywa.

Moim zdaniem warto w tym momencie żebyś wykupił choćby godzinę z seniorem i żebyście razem poprawili sobie projekt, zwłaszcza wydzielając pakiety i tego jak Ty widzisz domenę, bo tutaj po prostu brakuje komercyjnego doświadczenia i to nic złego.

Następnym razem na pewno pójdzie Tobie lepiej, a typ imo powinien wylecieć z roboty.
Jedna sprawa to przekazanie review, więc siłą rzeczy trzeba wytknąć to co mogłoby być inaczej, a druga to bycie totalnym bucem w trakcie tego, nikt nie chciałby z kimś takim współpracować.

Nofenak napisał(a):

Dzisiaj rano dzwoni do mnie rekruter i dosłownie zjechał mnie ostro za takie rzeczy jak:
1.Paginacja, której nie było w wymaganiach a ją dodałem. Myślałem, że to standard w każdym API, tym bardziej, że to API GItHuba zwracało czasami kilkadziesiąt wyników.
2.Mappowanie odpowiedzi z WebClienta na Stringa zamiast na jakąś klasę mimo, że później jest to robione.
3.Użycie ObjectMappera do mapowania jsona z WebClient na obiekt Javowy. Powiedział, że to mnie definitywnie skreśla
4.Utworzenie WebClienta za pomocą create() zamiast utworzenia beana. Powiedział, że widać, że nie znam Springa
5. Użycie MockMVC w testach integracyjnych controllera zamiast WireMocka czy czegoś podobnego, nazwał to zbrodnią

No nie no, nic z tego co tutaj jest napisane nie powiedziałbym że jest to definitywnym skreśleniem.

Jakiś perfekcyjny ten projekt nie jest, ale nie jest też jakoś bardzo zły IMO.

Cześć
Z tej strony właściciel/rekruter z firmy Atipera. Dostałem informację na wyjeździe firmowym od moich pracowników, że pojawiają się tematy lekko oczerniające mnie jako osobę i moją firmę. Chciałbym się odnieść do paru punktów.

1. Rekruter to cham/buc/gnoili go w szkole/brak kultury etc
   Ciężko mi się odnieść do takich zarzutów, wypowiadanych z ust osób, które mnie w życiu nie spotkały, nie było obecne podczas tej rozmowy. Myślę jednak, że ten język jest przynajmniej nieadekwatny.

2. Co skreśla w rekrutacji
   Jest to oczywiście kwestia względna i różne rzeczy są akceptowalne w różnych firmach.

3. Poziom na Juniora
   Nie do końca tak działają rekrutacje w małych firmach. Dostałem około 1500 zgłoszeń w ostatnich rekrutacjach. Jako, jako że nie jestem dużą firma, nie zatrudniam każdego kto mi się podoba, tylko mam X miejsc. Moim celem oczywiście jest wybrać (subiektywnie) X najlepszych osób a nie zatrudnić pierwsze X, które spełni jakieś założone przeze mnie standardy. Stąd kwestia czego wymagać od juniorów, jest moim przypadku definiowana przez poziom konkurencji w danej rekrutacji. Nie istnieje więc „Wymagany poziom na Juniora”

4. Wymagania są nierealne
   Większość osób, które na ten przeszło rekrutacje, nie miało komercyjnego doświadczenia. Zgodzę się z opinią, że jest do zadanie filtrujące. Nie oczekuję idealnych rozwiązań, ale poprzez przeprowadzenie dużej liczby rekrutacji wiem czego mogę oczekiwać. Możliwe, że w innych firmach wymagania są mniejsze.

5. Rekruter nie ma skilli miękkich, dzwoni aby się wyżyć
   Zapewniam, że nie mam takiego zamiaru. Chcę tylko uświadomić, że śmiało można szacować, że review + rozmowa telefoniczna zajmuje mi około 20-30min na osobę. Dostaję per rekrutacje 600-700 zgłoszeń, nie jestem w stanie wyrobić się z feedbackiem w niektórych momentach (mam też inne obowiązki niż rekrutacja) i muszę też oddzwaniać w soboty i niedzielę. Robię to, bo przyjąłem zasadę, że jak ktoś poświęca czas mi/mojej firmie to ja też chcę mu oferować mój czas, aby coś z tej rekrutacji wynieść. Naprawdę musiałbym być przedziwną osobą, żeby marnować swój cały prywatny czas, na „dowartościowanie się” poprzez review/roast juniorów. Celowo staram się punktować kandydata, żeby dokładnie wiedział co może poprawić/czego się douczyć, a nie rzucać ogólniki.

6. Wartość z feedbacku
   Oczywiście kwestia względna. Na swoją „obronę” podam tylko parę faktów.

• Nie jestem osobą z HR, więc mój język wypowiedzi, jest mniej korporacyjny a bardziej bezpośredni.
• Tak używam słowa zbrodnia i dopiero ta sytuacja uświadomiła mnie, że może kandydat odebrać je jako atak personalny.
• Nigdy nie zostawiam punktu bez wytłumaczenia.
• Po każdym punkcie pytam się kandydata/kandydatki czy zrozumiał.
• Na koniec pytam czy na kandydat/kandydatka ma do mnie jakieś pytania.

7. Opinie innych
   Pierwsze rekrutacje zacząłem już rok temu. Od tego czasu dostaję maile/telefony po rekrutacji z podziękowaniami od osób, że to był pierwszy feedback, który chociaż wskazał im jakaś drogę czego mają się nauczyć, albo że udało im się znaleźć pierwszą pracę w innym miejscu i dziękują za pomoc. Naprawdę mobilizuje mi to do trzymania się sztywno zasady feedbacku dla 100% osób. Większość czasu nie dostają żadnej odpowiedzi lub „za słaba znajomość Javy” i „nie mogę tego wyjaśnić szczegółowiej, jestem osobą nietechniczną, tylko przekazuje feedback”.

Co do opinii kandydata, rozumiem że mógł się poczuć oceniony nieobiektywnie, szególnie poniważ przekazywałem nieprzyjemną informację o nie przejściu dalej. Jest to dla mnie nauczka i postaram się zmienić formę przekazu, ale moim zdaniem niektóre tu zawarte komentarze od innych osób troszeczkę przekraczają granice i poczułem potrzebą ustosunkowania się

@Atipera: no i?

Jeszcze raz powtórzę, nikt nie oczernił Pana firmy i imienia, post totalnie anonimowy, ale duma urażona.

Feedback optymistyczny.
Szukamy mida za cenę juniora, cóż rozumiem, business.
Ale rozumiem też chłopaka co stracił niedawno robotę przez kryzys, coś tam już potrafi, a zostaje zjechany do poziomu "jedynki z Opola", bo nie używa Wiremocka

Ktoś kto nie potrafi się z kulturą komunikować w ogóle nie powienen pracować z ludźmi.

Plus dla Ciebie, że dostałeś feedback, bo to się akurat wcale nie zdarza często.