[Nofenak]

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](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
4. 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
#programowanie #programista15k #java #pracbaza

[Gr4bek]

@Nofenak: Masz już jakieś doświadczenie czy pierwsza praca?

[apo]

@Nofenak: Ton odpowiedzi i czepianie się o paginacje dyskwalifikują człowieka.

API bez paginacji z perspektywy inżynierii danych to wadliwe API. Największe moje koszmarki to API gdzie musisz znać wszystkie wartości zanim o nie zapytasz - może to się sprawdza dla mobilek ale leży przy zbieraniu danych, a na takie wygląda to zadanie.
@coll
Jak przetwarzasz ze źródła zwracającego dużo danych - github to idealny przykład - musisz mieć sposób

[coll]

@apo: Ja pokazałem perspektywę rekrutera który oczekuje zrealizowania zadania zgodnie z założeniami. Od tego jest rozmowa nad zadaniem, jeśli taka następuje, żeby je omówić i zastanowić się, czy istnieje bardziej optymalne rozwiązanie tego problemu. Przynajmniej ja tak do tych zadań podchodziłem, zarówno jako rekrutowany jak i rekruter. Ale nie na stricte deweloperskie stanowiska.

[apo]

@coll: Cóż inne oczekiwania wynikająca z doświadczenia zawodowego. Ja zawsze rekrutowałem ludzi od których oczekiwałem jednak więcej umiejętności samodzielnego myślenia, a junior sugerujący inne rozwiązanie czy uwzględniający rzeczy o któych nie wspomniano w zadniu wypadał na plus. Zresztą jak patrze na karierę tych bystyrch to mają teraz świetne posady, a klepacze dalej klepią.

Nie mniej spotkałem ten drugi typ gdzie masz zrobić dokładnie to co napisano. Pracowałem w takim środowisku

[coll]

@apo: Nie do końca o to mi chodzi. Chodzi mi tylko o zakres zaimplementowania zadania rekrutacyjnego i tego, jak jest sformułowane a nie o metodologię pracy w projekcie, przejmowanie inicjatywy względem klepania kodu i nie zadawania pytań. Junior sugerujący rozwiązanie przed implementacją lub nawet podczas jego robienia to co innego, niż junior oddający zadanie które nie spełnia założeń bo miał taką wizję. Już niezależnie, czy ta wizja jest dobra czy

[t4il]

@Nofenak: Nie wiem o co chodzi, ale zazwyczaj jeżeli odbywa się jakaś patola na rozmowach rekrutacyjnych to zazwyczaj pojawia się tam Java xD A co do tej odpowiedzi to uwierz że nie chciałbyś być w zespole z kimś takim jak ten "Pan Rekruter" :)

[RapIArbuzy]

@Nofenak: A czego oczekujesz od rekrutacji w gówno firmach? W normalnej firmie dostałbyś system design, jakiś live coding sprawdzający algorytmiczną wiedzę. Ewentualnie zadanie domowe sprawdzałoby, czy potrafisz programować
Bardzo dobrze, że zrobiłeś paginacje, a w testach widziałem, że dosyć spoko użyłeś given/when/then. Zrobiles mocka operacji I/O, czyli githuba i użyłeś mockmvc. Przy czym to są testy unitowe, ponieważ całe twoje I/O odpada. W przypadku integracyjnych testów powinieneś odpalać całą aplikację

[RapIArbuzy]

@kwas_rybonukleinowy:
1. Nie masz racji
2. To WebClient, a nie endpoint.
3. Nie masz racji, Jackson to standard w Spring oraz WebFlux. Metody mapujące w chainie używają Jacksona, tudzież ObjectMappera gdy wykryją jsona. Wyjątek w przypadku nieznanych pól to bardzo często desired zachowanie, ponieważ to oznacza zmianę API
4. Tworzenie wszędzie beanów pokazuje tylko brak świadomości, jak powinno się programować. Spring container to nie jest rozwiązanie na wszystko, a ilość

[apo]

@coll: Rozumiem o co Ci chodzi, ale po prostu to dwa światy. Zadania które ja przygotowywałem stawiały na podanie rozwiązania i wyjasnienie dlaczego. Do tego były wielopoziomowe co pozwałało sprawdzić ile wyłapie, czy jest zorientowany na szczegóły, na ogół, czy rozumie kwestie bezpieczeństwa i prawne. Tutaj są zadania zaimplementuj wg. wymagań i potem sobie porozmawiaj o ew. innych opcjach. To są dwa światy, stricte programowanie vs programowanie, inżyniera danych +