Zadanie rekrutacyjne a testy

0

Pytanie może troche głupie, ale czy jeżeli dostałem przy rekrutacji zadanie do domu do napisania w określonym języku to muszę/wypadałoby napisać też do niego testy jednostkowe ?

0

Możesz jak umiesz, aczkolwiek zapewne chodzi o to czy rozwiązanie będzie działające,

0

czasem w paczce z zadaniem sa napisane tsty, ktore musza przejsc

0

U mnie nie było. Dlatego pytam.

1

Najlepiej zapytać u źródła a nie na forum, za zadawanie pytań do niejasnych specyfikacji zwykle dostaje się ekstra punkty w trakcie procesu rekrutacji :).

0

ogolnie powinienes zapytac czego oczekuja. dokladnie czego. czy wazne jest pomyslowe rozwiazanie, testy, jakas inna magia. Przy rozmowie nalezy zwrocic uwage ze wszystko zajmuje czas i jesli to nie jest praca ktorej pragniesz to nie czujesz potrzeby tracic kilku dni zamiast godziny

1

IMO to właśnie o to chodzi w zadaniu żeby zobaczyć jak się zabierasz do problemów i jak kod piszesz.
Jak nie napiszesz testów to dla mnie by to było bardzo na minus, bo sugeruje, że albo nie umiesz pisać testów albo umiesz, ale z jakichś przyczyn tego nie robisz i obydwa przypadki w pracy są nieakceptowalne(przynajmniej na mida).

Pamiętaj, że Ty masz się rozwiązaniem tego zadania pokazać, więc to powinno być rozwiązanie porządnie.
Nie może być ośmiotysięczników, zmiennych nazwanych 'a', 'b', 'c' ani innych tego typu bzdur niezgodnych ze sztuką.
Ktoś kto to będzie sprawdzał ma też inne zadania, więc jak masz to zrobić na odwal, to nie rób wcale, bo sobie tylko opinię popsujesz.

0

Z tym na odwal się nie ma problemu, akurat wiem jak to zadanie dobrze napisać i sądzę, że już 2 potencjalne haczyki w nim znalazłem. Umiem nazywać zmienne i kod na jakimś tam poziomie też napisać (a przynajmniej tak sądze). Zastanawiałem się tylko czy jak dopiszę do tego jakieś testy w Mockito to stwierdzą że jestem nadgorliwy.

0

Aha i to nie na mida, a na juniora.

2

Napisz testy, podziel dobrze kod, dobrze wszystko ponazywaj itd, bo im lepsze wrażenie zrobisz, tym więcej kasy wytargujesz, a nawet jeżeli mają sztywny limit na kasę na początku, to zawsze to będzie jakiś plus przy rozmowie po okresie próbnym.

Jeżeli ktoś by się przyczepił o to, że napisałeś testy to możesz to traktować jako pierwszy sygnał, że firma idzie w ilość kodu, a nie w jakość.
Kilka lat temu w takiej pracowałem gdzie prezes powiedział, że "nie ma czasu na testy, trzeba napierdalać" i nie polecam.

0

Zresztą testy są nie tylko jednostkowe. Za wyższego poziomu testy też są punkty.

3

A w jaki sposób bez testów chcesz sprawdzić i udowodnić że twoje rozwiązanie działa? :) Przecież testy to nie jest żadna nadgorliwość, ani jakiś zbędny wysiłek. One mają pewne realne zastosowanie! Oczywiście jak naklepiesz testy dla setterów/getterów/konstruktorów to uznają że nie rozumiesz co robisz, więc to też nie chodzi o to żeby coś bezmyślnie zaklepać.
Testy pokazują:

  1. Że zrozumiałeś wymagania (masz ileśtam przypadków testowych które sprawdzają czy spełniasz wymagania)
  2. Jak używa się twojego kodu i czy API ma sens
  3. Czy to w ogóle działa.

Ja osobiście sprawdzanie takiego zadania to w ogóle zacząłbym od patrzenia na testy, a nie na kod.

Jeśli firma tego nie ceni, to zaręczam ci że nie chcesz tam pracować, bo to jakaś januszownia.

0

Jak chcesz zrobić lepsze wrażenie to wyślij całe repo gita lub ling do niego, ale tak żeby pierwsze commity zawierały testy,a dopiero jak testy będą to napisz kod.
To pokaże, że stosujesz TDD, więc przynajmniej dla mnie to by było na +

0

Dokładnie tak jak koledzy wyżej napisali, pisz testy nawet jeśli nie są wymagane, bo wtedy masz więcej pewności, że wszystko działa jak należy.

Dobrze otestowany kod to podstawa, a gdyby się jakimś cudem przyczepili do tego, że testy w ogóle napisałeś to zastanów się dwa razy czy warto tam pracować.

2

Zalezy od pracodawcy - wiele osob sie naczytalo jak wspaniale sa testy (i w wielu przypadkach sa) ze az sie zgubilo. Tworzac jakas prosta aplikacje crud z webowka testy nic nie dadza bo i tak piszacy to przeklika. W takiej sytuacji stwierdzenie od zlecajacego ze testy sa niepotrzebne nie jest januszowaniem. Natomiast twierdzenie ze w czyms takim (testowej aplikacji, ktora zostala przeklikana i zostanie wyrzucona) testy sa potrzebne to takie sztuczne robienie z siebie "specjalisty". Oczywisci testy moga byc wymagane przez pracodawce (zeby zobaczyc czy ktos to kojarzy) i wtedy nalezy je zrobic - jesli jednak mowi ze nie sa potrzebne to tez jest to dobre podejscie.

0

Jakbym komuś dał zadanie do napisania w ramach rekrutacji i ta osoba by nie napisała testów nie przeszłaby u mnie dalej :)

1

Jak chcesz zrobić lepsze wrażenie to wyślij całe repo gita lub ling do niego,
ale tak żeby pierwsze commity zawierały testy,a dopiero jak testy będą to napisz kod.
To pokaże, że stosujesz TDD, więc przynajmniej dla mnie to by było na +

To pokaże, że stosujesz naiwnie pojmowane TDD i nie słuchasz zaleceń Wujka Boba, które mówią o tym, żeby nie pisać testów "na zapas".

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Czyli w takim wujko-bobowym TDD (bo mogą być i inne odmiany) raczej byłoby tak, że piszesz asercję, potem piszesz kod, który złapie tę asercję, potem znowu asercję, potem znowu kod itp. Byś musiał więc masę mikro-komitów zrobić (co byłoby śmietnikiem), ponieważ pisanie testów by się przeplatało z pisaniem kodu, a nie "napiszemy całe testy, a potem cały kod".

0

@LukeJL:
Ok, źle się wyraziłem, chodziło mi o to, że najpierw testy danego małego kawałka, a później ten mały kawałek.
I tak, to ma iść iteracyjnie.

Byś musiał więc masę mikro-komitów zrobić (co byłoby śmietnikiem)

To można potraktować jako okazję do pokazania znajomości linear history
Wiem, że to jest na wyrost jeżeli tylko ja commituję, ale ja bym tak właśnie zrobił, bo:

  • Jak ktoś nie chce /nie ma czasu analizować historii gita to zobaczy tylko najnowszy commit i w niczym mu to nie przeszkadza
  • Jak ktoś chce i ma czas, to zobaczy, że gita też pewnie ogarniam (co z doświadczenia wcale nie jest oczywiste)

Z innej beczki:
Część osób w zadaniu rekrutacyjnym lubi się też pochwalić znajomością wzorców, ale to potrafi być już często overkill jeżeli ktoś nie zachowa zdrowego rozsądku.
Wtedy sprawdzając zadanie mam mieszanie uczucia, bo niby człowiek umie, ale z drugiej strony, po co na siłę je ładować.
Także o ile testy imo są konieczne, to z wzorcami lepiej nie przesadzać, tzn powinny być użyte tylko te które faktycznie są potrzebne.

0

Wpisywanie w wymaganiach zadania jednego, a oczekiwanie tego plus czegoś jeszcze innego to kompletny absurd. Ci którzy tutaj twierdzą, że odrzucaliby kandydatów, którzy nie napisali testów, to po prostu chwalą się zapędami do nieuczciwego potraktowania kandydata.

Jeśli rekrutujący szanuje potencjalnych kandydatów, to przygotowując zadanie rekrutacyjne, dba o to aby nie zajęło ono kandydatowi jakoś szczególnie dużo czasu, a jednocześnie aby dało się cokolwiek zorientować w zdolnościach kandydata - a nie w tym, jak mocno został zindoktrynowany przez różne około-programistyczne ideologie. Indoktrynować do swojej ulubionej ideologii można, gdy kandydat już będzie zatrudniony.

Rekrutujący jest w stanie przewidzieć, ile czasu zajmie spełnienie tych wymagań, które kandydatowi przedstawił, natomiast nie ma żadnej możliwości przewidzieć, ile czasu zajmie, jeśli kandydat doda sobie do zadania co tylko mu przyjdzie do głowy. Rekrutujący ma za zadanie przedstawić wprost, czego oczekuje, a nie żeby kandydat czytał w myślach.

0

@Troll anty OOP
Pisanie testów nie wydaje Ci się oczywistą częścią pisania aplikacji?

Dla mnie polecenie w stylu: "Napisz aplikację która ..." nie wymaga doprecyzowania, że chodzi o to żeby była napisana z zachowaniem dobrych praktyk.
Jeszcze trochę i będzie trzeba wprost pisać w zadaniu żeby ktoś całej aplikacji nie zrobił w jednej klasie, a zmienne nazywał sensownie - bez przesady.

0

@Troll anty OOP
To jest szansa, że rekrutujący zachowałby miejsce dla kogoś innego.

Nie wiem w czym widzisz problem.
Testy przecież i tak piszesz żeby sprawdzić czy napisane rozwiązanie działa i zaoszczędzić czas na szukanie błędów.
Jeżeli piszesz je najpierw, to jeszcze klaruje Ci się sama struktura aplikacji.
To skoro i tak je masz, to jaki problem dołączyć je do zadania?

No chyba, że nie piszesz testów i testujesz ręcznie, ale to mi mówi, że nie umiesz pisać testów i nie rozumiesz po co są, więc to jest minus.
Jeżeli aplikujesz na stanowisko wyższe niż junior to wybrałbym jednak kogoś innego, bo sporo osób pisze testy.

1
Nadziany Ogrodnik napisał(a):

Nie wiem w czym widzisz problem.
Testy przecież i tak piszesz żeby sprawdzić czy napisane rozwiązanie działa i zaoszczędzić czas na szukanie błędów.
Jeżeli piszesz je najpierw, to jeszcze klaruje Ci się sama struktura aplikacji.
To skoro i tak je masz, to jaki problem dołączyć je do zadania?

No chyba, że nie piszesz testów i testujesz ręcznie, ale to mi mówi, że nie umiesz pisać testów i nie rozumiesz po co są, więc to jest minus.
Jeżeli aplikujesz na stanowisko wyższe niż junior to wybrałbym jednak kogoś innego, bo sporo osób pisze testy.

Oczywiście, że w większości przypadków nie piszę testów, zaczynam je pisać dopiero wtedy, JEŚLI okaże się, że do danej części programu są potrzebne.
Ale wątek jest o czymś innym: o zadaniu rekrutacyjnym, które ma w możliwie krótkim czasie pokazać, czy kandydat się przyda w pracy. Jeśli dany człowiek nie ma zwyczaju robić testów, a ja chciałbym aby w pracy je robił, to nie widzę żadnego problemu - kierownik powie mu, aby robił - i będzie robił. Także w zadaniu rekrutacyjnym kompletnie mnie nie interesuje, czy zazwyczaj je robi - interesuje mnie tylko, czy potrafi sprawnie osiągnąć efekt, o który został poproszony.

Zdarzyło mi się przygotowywać zadanie rekrutacyjne i raz kandydat robił to w firmie, mogąc na bieżąco dopytywać o takie właśnie rzeczy, czy chcę aby był dorobił to czy tamto. Za każdym razem odpowiedź była "nie" - zadanie specjalnie przygotowałem tak, aby znalazły się w nim elementy, przypominające rzeczywiste problemy, z którymi w późniejszej pracy miałby się mierzyć i aby było jak najmniej wypełniaczy, marnujących czas kandydata (bo nie wiadomo, czy zostanie przyjęty), a mi nie dających informacji, czy posiada zdolności o które mi chodzi. Zalecenie komuś nie robiącemu testów, aby zaczął je robić, jest bez porównania skuteczniejsze, niż przekonanie człowieka by był bardziej zdolny.

1

Ja bym testów domyślnie nie pisał (o ile nie poprosiliby inaczej), bo zadania rekrutacyjne polegają często na hakowaniu czegoś na szybko. Człowiek dostaje zwykle mglisty opis zadania, za które nie dostaje żadnych pieniędzy i ma powiedziane "nie powinno ci to zająć więcej niż 2 godziny".

Ciężko w takich warunkach pisać testy. I nie mam na myśli samego pisania, bo to się wbrew pozorom szybko robi, tylko raczej o decyzję "co w zasadzie testować, w jaki sposób?" czy "w jaki sposób chcę podejść do kwestii implementacji" (testy niby powinno się pisać tak, żeby uniezależnić je od implementacji, ale moim zdaniem i tak mimo wszystko w jakiś sposób będą odzwierciedlały implementację, bo ciężko to uniezależnić w 100%)

Zauważcie, że zadania o poziomie trudności "zadania rekrutacyjnego", gdyby pojawiły się w prawdziwym projekcie*, to zostały by wycenione na kilka dni roboty. Wtedy jest czas na eksplorację problemu i przemyślenie kwestii takich jak testy. A tutaj nazywamy coś "zadaniem rekrutacyjnym" i mamy na to czas np. 2 godziny (czasem jest to wręcz sztywno ustalone, np. jeśli firma używa jakiegoś Codility). Więc bez przesady. Przez taki krótki czas to się hakuje na żywca i zmienia całą implementację co 5 minut, więc po co pisać testy, jeśli i tak nie mamy pojęcia co robimy (chyba, że na samym końcu, jak już będzie wiadomo).

* nie mam na myśli zadań typowo pod algorytmy, tylko o zadania zbliżone do prawdziwych tasków w pracy typu "zakoduj moduł, który łączy się z API o nazwie X, wyświetla dane w sposób Y i zapewnia interfejs użytkownika według wytycznych Z"

0

@LukeJL no dobra ale nadal pozostaje pytanie: jak sprawdzisz czy ten kod w ogóle działa? Klepiesz i się modlisz? Czy jednak odpalisz to pare razy z jakimiś przykładowymi danymi żeby się upewnić? Bo jeśli to 2, to własnie napisałeś... testy!

1

To może z innej strony.

Ssanie na wannabe juniorów jest bardzo małe, na juniorów jest małe, na midów spore a na seniorów ogromne.
Im niższe stanowisko masz, tym bardziej musisz się postarać czy rozwiązaniu zadania rekrutacyjnego, bo senior może go wcale nie dostać jak jest polecony.

Wannabe junior przeważnie polecony nie jest więc w jego interesie jest napisać to zadanie rekrutacyjne najlepiej jak tylko może, z zachowaniem dobrych praktyk, z testami, wzorcami i ogólnie ładnie.
Jak w to włoży nawet tydzień zamiast 2h to imo warto, bo to zadanie stanowi jakieś 70% tego czym się może pochwalić - reszta to rozmowa rekrutacyjna.

Jak już jesteś juniorem to masz dużo prościej bo próg wejścia masz niższy, ale dalej, jak nie chcesz jak najszybciej przestać być juniorem to proaktywne podejście do tematów w tym zdecydowanie pomaga.

Z midem sytuacja jest taka, że bardzo często decyduje samo polecenie, więc o ile nie odwali fuszerki w zadaniu, to nawet jak nie ma testów to będzie to minus, ale nie decydujący.

1

Powiem z własnego doświadczenia- zawsze byłem chwalony za napisanie testów. Zasada jest prosta - jeżeli nie piszesz testów w śmiesznie małej apce, jest niestety spora szansa, że w znacznie większym projekcie, też nie będziesz chciał tego robić.

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