Ja podałem tylko rozwiązanie na tamto zadanie, nie twierdziłem, że jest dobre.

Ehh... Moim zdaniem zadanie jest fajne. WIele przyjemności sprawiło mi rozwiązanie go.
Przydatności w nim faktycznie niewiele, ale jak też napisałem, było to jedyne pytanie niezwiązane z programowaniem.

Nie mówiłem, że nie





I tylko o to tutaj chodziło, bo przez x wcześniejszych postów była mowa o sensowności zadawanych na rekrutacjach pytań.

Większość tych pytań sprawdzi wiedzę, niektóre coś innego.
A jakie pytanie/zadanie zadalibyście aby sprawdzić czy kandydat dobrze ogarnia programowanie obiektowe?

to widac po kodzie czyims. oop != oop

Przede wszystkim o podstawy. Czyli różnice pomiędzy klasą, interfejsem a klasą abstrakcyjną, dziedziczenie, zakres widoczności metod, własności.
Może to i banalne ale widziałem już wielu wymiataczy obiektowych a nie znali podstawowych różnic.

Potem może coś o wzorce architektoniczne, czyli jakie zna, do czego mogą służyć, po co się je stosuje.
Coś z static może czyli staic czy nonstatic i dlaczego

Żeby sprawdzić OOP najprosciej dać kandydatowi cos do napisania. Bez frameworków. 100% własnego kodu, gdzie będzie trzeba użyć interface-ów, abstrakcji, dziedziczenia, SOLID i testów.

I nie chodzi o to, żeby kod działał. Powiedzmy, że kandydat ma 24h na napisanie tego. Dla mnie nie jest istotne, czy kod na końcu działa prawodłowo. Ja chcę widzieć, w jakim kierunku kandydat idzie i czy podczas rozmowy (jeśli kod się podobał) będzie w stanie uzasandnić dlaczego poszedł w tym kierunku a nie innym. Bezmyślne zapamiętanie regułki jaka jest różnica pomiędzy abstrakcją a interface-em nie mówi mi nic oprócz tego, że kandydat coś zna na pamięć. Mnie interesuje, czy potrafi wykorzystać tą wiedzę w praktyce.

Później oceniamy tylko napisany kod. Co system robi z błędami (jak widzę "return false" to nie wiem czy się śmiać czy płakać), czy są interface-y tam, gdzie być powinny. Co z abstrakcjami. Co z SOLID (ze szczególnym naciskiem na S i D, bo to sprawia najwięcej kłopotów nawet programistom z bardzo długim stażem).

Ja muszę widzieć, że kandydat wie o czym mówi i wie gdzie szukać, jeśli czegoś nie wie. Ja nie oczekuję od nikogo wyrycia regułek na pamięc i zapamiętania co dokumentacji słowo w słowo. Jak wie, czego nie wie i gdzie znaleźć odpowiedź to dla mnie zupełnie wystarczy.

Tutaj troche rzuciles tematy ktore wykraczaja poza poziom juniora, a senior z kolei nie powinien rozkminiac co moze byc na rozmowie o prace, powinien ja po prostu przejsc bez zajakniecia. Tak mi sie zdaje.

Ja tak jak patrze na to co piszecie to się zastanawiam czy rozmawiamy o pracy programisty ... Najlepiej to kur*a jak na wejściówkę się przygotowywać

Ja np. ogarniam to wszystko co napisaliście. Zaprojektuje i napisze to co trzeba, z testami, interfejsami i zgodnie z zasadami SOLID. Na ZF, ZF2, lub Kohanej, z D1 D2 lub bez ORMa.
Mimo to zawsze czuję, że coś jest źle, że można lepiej. Problem w tym, że nie wiem jak to sprawdzić (na jakim jest się poziomie).
Stąd moje pytanie Może ktoś miał kiedyś podobny problem.

Ja daję takie same zadania dla juniora i dla seniora. I jestem w pełnie świadomy tego, że wynik będzie się różnił, i to sporo. Nie spodziewam się dostać tego samego od juniora i od seniora. Ale to daje mi ogólny pogląd na to, czy kandydat posiada podstawową wiedzę. Jakąś teorię musi nawet junior posiadać. To nie jest tak, że na juniora zatrunia się kogoś kto tylko słyszał, że istnieje PHP - to może być stażysta a wtedy takie testy nie mają sensu. Pozostaje sprawdzenie wiedzy teoretycznej.

Oczekuję czegoś zupełnie innego po juniorze niż po seniorze. A to, że senior powinien przejśc coś takiego bez zająknieć to tylko pobożne marzenie W poprzedniej firmie byłem bezpośrednio odpowiedzialny za rekrutację i wiem że czasami senior=junior. Test kodu idealnie sprawdza się jako wstępna selekcja. Jeśli po kodzie widać, że ktoś nie ma pojęcia co robi, to fakt, że na końcu mu kod działa, zna teorię i ma X lat doświadczenia mnie nie interesuje. I tak na rozmowę nie zostanie zaproszony.



Zawsze można inaczej i czasami też lepiej. Ale najważniejsze jest, żebyś potrafił wybronić tego, co napisałeś. Ja jesteś w stanie logicznie umotywować tą czy inną linijkę kodu to spokojnie poradzisz sobie na rozmowie.
Tu nie chodzi (a przynajmniej nie powinno) o to, żeby twoje rozwiązanie było w 100% takie, jak ten co układał zadanie sobie wymyslił. Chodzi o to, żeby rozumieć i potrafić obrionić swoją wersję.

Ja sam jeszcze jakiś czas temu myślałem, że wiem już bardzo dużo. Do czasu, aż firma zatrudniła thePHP.cc jako konsultantów i Arne Blankerts robi z nami code review co 2 tygodnie. Jeszcze tak dużo się nie nauczyłem w tak krótkim czasie. Człowiek się całe życie uczy i kod, który raz się napisało pewnie jeszcze pójdzie do refactoringu kilka razy w ciągu swojego istnienia. Nie należy uznawać tylko jednego rozwiązania za jedyne słuszne.
Ważne, żeby rozumieć co się zrobiłoi potrafić uzasadnić dlaczego tak, a nie inaczej.

senior, junior...




Wydaje mi się, że nawet junior powinien umieć coś wykminić swojego. Jeśli ktoś umie tylko pisać "we frameworku X" to znaczy, że jest dupa a nie programista.

Co do testów - ja się nauczyłem ich w pracy dopiero, tyle i tak, podstawy tworzenia unit testów w jakimś frameworku testowym to raptem kilka dni nauki (piszę "podstawy", bo wiadomo, że dobre testowanie i tworzenie testowalnego kodu to sztuka, i nabywa się ją latami), więc myślę, że można by podarować juniorowi.


Dziedziczenia czasem trzeba faktycznie użyć, ale to są dość rzadkie przypadki. Jak ktoś ciągle wali dziedziczenie i tworzy długie drzewa dziedziczeń (np. A < B < C < D < E), to też wcale nie najlepiej świadczy o nim.


Albo widuje się czasem oferty pracy na "seniora", z widełkami płac raczej juniorskimi. Wtedy nie wiadomo czy się śmiać czy płakać.

Ja wolę dać zawsze to samo zadanie ale dla mid czy juniora zaznaczam, że nie wszystko musi być i jak czegoś nie wie, czy nigdy się t tym nie spotkał, to ma zignorować. Bo jak dam juniorowi za proste zadanie to mogę nie zauważyć potencjału. Wolę dać coś trudniejszego i zobaczyć w jakim pójdzie kierunku.


Bardziej chodzi mi o coś a la jedna abstrakcyjna klasa bazowa i dwie konkretne klasy rozszerzające ją. Oczywiści nie spodziewam się zobaczyć 'extend' konkretnej implementacji (cheba, że ktoś ma na prawdę mocne uzasadnienie) .


U nas płacą dobrze i jednym i drugim a i tak szukamy i szukamy. W tej chiwli 1xfrontend i 1xbackend. Problemem jest to, że niemca przekonać trudno do zmiany i tak już dobrej posady a obcokrajowcy boją się języka - mimo, iż w firmi w IT obowiązuje angielski.

Tyle pomysłów wymienionych, a i tak większość studentów wykłada się na pytaniu "czy planuje pan/pani pracować również w ciągu roku akademickiego?".

PS Ja was bardzo przepraszam, ale temat studiów jakoś zawsze sam się wszędzie wplącze...

Jak można bać się niemieckiego? Będąc od X lat płynnym w angielskim w mowie i piśmie i pracując już od ponad roku dla firm tylko z UK (gdzie komunikacja siłą rzeczy odbywa się tylko i wyłącznie po angielsku) odnoszę wrażenie, że mimo wszystko niemieckiego się łatwiej nauczyć.

Jak robicie coś szczególnie ciekawego, to odezwij się kiedyś

Wierz mi, ja już prawie 3 lata mieszkam w Hamburgu i nie raz przerabiałem temat szukania pracownika. Szczególnie nasi rodacy unikają tego kraju. Do UK to każdy chętnie, ale do DE to już nie. A żeby było śmiesznie, to zarobki/koszty życia wyglądają o wiele lepiej w DE niż w UK.

A co do samego języka, to wydaje mi się, że jednak jest trudniejszy niż angielski. Może mniej czasów, ale za to przypadki, które często ni jak mają się do polskich a do tego pozycja czasownika. Musi być odpowiednia bo inaczej brzmisz jak jakiś głupek. Ale to może tylko moje odczucie

Jak jesteś zainteresowany pracą w biurze w Hamburgu (na pełen etat, tylko praca na miejscu) to wal śmiało na priv



Tutaj ludzie nie mają takich problemów. W tej chwili mamy dwie osoby w QA, studentów. Generalnie z tym nie ma problemów, bo każdy rozumie, że staż jest ważny i trzeba zacząć już na studiach, żeby po móc pójść do pracy a nie dopiero na staż.

no właśnie rozważałem już raz prace w Berlinie [mieszkam w Aberdeen], ale ten język... kurde no nie chciał bym aby moje dziecko mówiło lepiej po niemiecku niż po polsku, za to nie mam takich uprzedzeń do angielskiego...

Niemiecki do najprzyjemniejszych języków nie należy. Szczególnie w IT, gdzie angielski na dobrym poziomie to po prostu "must have". Do tego w pracy masz na codzień angielski, w domu polski i weź tu się przestaw na niemiecki... Po 3 latach dalej twierdzę, że proste to nie jest. Ale póki co nie przewiduje wyjazdu do UK, za dobrze mi tutaj

serio 70 lat po wojnie jeszcze masz uprzedzenia do tego kraju? zyjemy tu i teraz, dla siebie i naszych dzieci.

„Język wroga trzeba znać!‟

tzm. Czemu zakładasz, że jego niechęć do języka niemieckiego wynika z historii ?
Również mnie język niemiecki odrzuca. Nie z powodu historii, ale po prostu z powodu jego brzmienia. Podobnie, język chinski, tajski czy japoński nie zachęca mnie do jego nauki, z powodu alfabetu.
W moim przypadku historia nie ma tu nic do rzeczy. Chciałbym by Niemcy rozmawiali w języku hiszpańskim, angielskim... albo polskim , bo wtedy miałbym łatwiej by w razie czego tam pracować.
Być może to uprzedzenie jest głupie, być może trzeba było nie patrzeć na "fajność" języka, tylko zacisnąć zęby i uczyć się niemieckiego za szkolnych czasów, zamiast języka latynosów.