Witam,
Pierwszy raz musiałem jakiś tydzień temu napisać aplikacje w procesie rekrutacji ( aż dziwne że wcześniej nie spotkałem się osobiście z czymś takim ).
I teraz pytanie z mojej na co trzeba zwracać szczególną uwagę pisząc jakiś prosty program dla celów rekrutacji ?
Moim zdaniem prym powinny wieść czytelność i wydajność ewentualnie wykorzystanie wzorców projektowych i STL ( cały czas mam na myśli C++ ).
Chętnie poznam wasze zdanie na ten temat.
Dodałbym również, aby zaprojektować aplikację przed jej implementacją. Może wydaje się to oczywiste, ale... różnie to bywa.
Do tego co napisał @somekind:
@Gjorni nie przesadzałbym. Przy małych aplikacjach za projekt wystarczy ci zwykle programowanie metodą top-down, szczególnie jak piszesz coś sam.
"Ogłada kodu". SOLID, testy, dokumentacja, nazwy nie z kosmosu, podział na klasy i metody w sensowny i spójny sposób. W mniejszym stopniu "ficzeryzm", czyli zastosowanie jakiś nieszablonowych rozwiązań (wyrażenia lambda na ten przykład), byle dobrze.
Szerokim łukiem omijaj za to pisanie rzeczy, które istnieją w powszechnie dostępnych bibliotekach. To jest biznes nie uczelnia. Bardziej liczy się umiejętność stosowania młotka niż umiejętność wykonania jego rysunku technicznego.
Pisanie aplikacji na testach wstepnych to nic nowego. Sam tez to mialem. Kiedy dostaje sie 2-3h na napisanie czegos, to niektore z tych rzeczy trzeba odpuscic. Na przemyslenie struktury poswiecisz 10 min a dalej siedzisz i kodzisz bo czasu malo. Dokumentacja? Jak starczy czasu a skonczy sie funkcjonalnosci to czemu nie. Mozna wygenerowac i dopisac na szybko. Clean code przede wszystkim. :) Testy jednostkowe? Raczej zastapione loggerem jesli chce sie zdazyc.
Niestety ale zawsze wszystko zalezy od czasu jaki sie ma na wykonanie ;) Klientowi potem nie powiesz, ze nie wyrobiles sie bo pisales mu testy, albo cos. Ma byc w terminie i koniec. Dlatego czesto sie niestety rezygnuje z niektorych rzeczy. Od tego jest proces bugfixingu ;))
@Krycho nie wiem jak ty, ale ja wolałbym zrekturować gościa który napisał porządny kawałek systemu, niż takiego który nasrał w kodzie ale teoretycznie wyrobił sie ze wszystkimi funkcjonalnościami. Tą drugą opcję to mógłby co najwyżej wybrać marketingowiec, ale to nie oni rekrutują programistów.
Nikt przy zdrowych zmysłach nie wziąłby tego drugiego gościa, bo co z tego że masz funkcjonalności na czas skoro zaraz się okaże że się wszystko sypie, albo że mała zmiana od klienta wymaga przepisania wszystkiego od nowa. Gdyby ktoś mi powiedział że komituje słaby kod bo "Od tego jest proces bugfixingu" żeby to naprawiać to byłby to albo koniec mojej, albo jego kariery w tej firmie, zależnie od tego jakie byłyby nasze pozycje ;)
Śmiałem się kiedy jeden z wykładowców powiedział nam na 1 roku że: "Kod niekoniecznie musi działać poprawnie, ale ma być napisany elegancko!", a z czasem doszedłem do tego że jest to prawda. Kod który jest dobrze napisany, ale ma buga i coś nie śmiga, łatwo naprawić a potem łatwo będzie go rozszerzać i modyfikować. Gówniany kod, nawet jeśli działa, jest bezużyteczny bo zaraz okaże się że jego modyfikacja albo rozszerzanie nie jest możliwe.
Krycho napisał(a):
Pisanie aplikacji na testach wstepnych to nic nowego. Sam tez to mialem. Kiedy dostaje sie 2-3h na napisanie czegos, to niektore z tych rzeczy trzeba odpuscic.
Ja przez "aplikację do celów rekrutacji" rozumiem program, który trzeba napisać w domu w ciągu kilku dni, a potem wysłać. Pisanie działającej aplikacji podczas rozmowy kwalifikacyjnej to zupełny bezsens.
Shalom napisał(a):
@Krycho nie wiem jak ty, ale ja wolałbym zrekturować gościa który napisał porządny kawałek systemu, niż takiego który nasrał w kodzie ale teoretycznie wyrobił sie ze wszystkimi funkcjonalnościami. Tą drugą opcję to mógłby co najwyżej wybrać marketingowiec, ale to nie oni rekrutują programistów.
Nikt przy zdrowych zmysłach nie wziąłby tego drugiego gościa, bo co z tego że masz funkcjonalności na czas skoro zaraz się okaże że się wszystko sypie, albo że mała zmiana od klienta wymaga przepisania wszystkiego od nowa. Gdyby ktoś mi powiedział że komituje słaby kod bo "Od tego jest proces bugfixingu" żeby to naprawiać to byłby to albo koniec mojej, albo jego kariery w tej firmie, zależnie od tego jakie byłyby nasze pozycje ;)Śmiałem się kiedy jeden z wykładowców powiedział nam na 1 roku że: "Kod niekoniecznie musi działać poprawnie, ale ma być napisany elegancko!", a z czasem doszedłem do tego że jest to prawda. Kod który jest dobrze napisany, ale ma buga i coś nie śmiga, łatwo naprawić a potem łatwo będzie go rozszerzać i modyfikować. Gówniany kod, nawet jeśli działa, jest bezużyteczny bo zaraz okaże się że jego modyfikacja albo rozszerzanie nie jest możliwe.
Stwierdzilem gdzies, ze kod ma byc napisany niechlujne i bez przemyslenia? Napisalem nawet wyraznie, ze kierowanie sie zasadami clean code to podstawa. Stwierdzilem ze mozna sobie pewne rzeczy odpuscic jesli jest malo czasu, a ze te uznaje pisanie test case'ow czy dokumentacje. Przemyslenie struktury, tak by byla czytelna i w miare rozszerzalna, wiec zeby kierowac sie pojeciami coupling i cohesion jest bardzo wazne. Jednak wiadomo ze spelnienie deadline'u jest najwazniejsze. Po to wczesniej sa estymacje, a i tak w 90% przypadkow dostaje sie wiecej czasu.
Co do procesu bugfixingu to jest on zawsze i jesli takiego nie przechodziles to wiedz, ze nie pisze sie wtedy nowych funkcjonalnosci tylko robi male zmiany w kodzie, w celu naprawy tego co zostalo pominiete w specyfikacji lub zle zrozumiane. U nas jesli ktos da cos innego, co jest nowym requirementem to od razu leci na jirze do nowego etapu implementacji i nie ma zabawy, ze nagle im sie odmienilo i chca to zamiast tego.
@somekind
Kazdy by tak wolal ale niestety tak sie nie dzieje. My dostalismy 3h na calkiem spora aplikacje z GUI i trzeba bylo sie spieszyc, wiec moimi testami byl log4j, a dokumentacja byla robiona w ostatnich minutach, co sie udalo to sie udalo dopisac.
Jednak wiadomo ze spelnienie deadline'u jest najwazniejsze. Po to wczesniej sa estymacje, a i tak w 90% przypadkow dostaje sie wiecej czasu.
Po to stosuje się krótkie sprinty i często spotyka sie z klientem. Pisanie niechlujnego kodu (powodzenia przy refaktorowaniu większego softu, takiego > 0.5mln linii kodu, bez testów jednostkowych, pochwal sie potem ile było regresji) nigdy nie kończy sie dobrze. Poza tym pisanie słabego kodu, bez testów i dokumentacji tylko pozornie kosztuje cię mniej czasu. No chyba że w projekcie studenckim który klepiesz dwa wieczory. W sofcie który klepie 100+ programistów od kilku lat to już nie działa...
Co do procesu bugfixingu to jest on zawsze i jesli takiego nie przechodziles
Przechodziłem pewnie znacznie wiecej niż ty, a na pewno więcej niż bym chciał ;)
to wiedz, ze nie pisze sie wtedy nowych funkcjonalnosci tylko robi male zmiany w kodzie, w celu naprawy tego co zostalo pominiete w specyfikacji lub zle zrozumiane.
To jakaś nowość dla mnie. Zwykle bugfixing polega na naprawianiu błędów w kodzie, ale tych które wynikają z pominięcia albo złego zrozumienia wymagań prawie nie ma. Są za to inne ;]
U nas jesli ktos da cos innego, co jest nowym requirementem to od razu leci na jirze do nowego etapu implementacji i nie ma zabawy, ze nagle im sie odmienilo i chca to zamiast tego.
A ktoś pisał że jest inaczej? Ja pisałem tylko że słabo napisany kod ciężko się rozszerza, nic więcej.
Ale znam ludzi którzy celowo komitują słaby / nie dzialający poprawnie kod, byleby tylko "zdążyć na deadline", zakładając że "jak klient / testerzy" zgloszą błąd to sie potem poprawi. Takich ludzi należy nabijać na pal, bo zwykle to nie oni muszą te błędy poprawiać ;]
Krycho napisał(a)
Co do procesu bugfixingu to jest on zawsze i jesli takiego nie przechodziles to wiedz, ze nie pisze sie wtedy nowych funkcjonalnosci tylko robi male zmiany w kodzie, w celu naprawy tego co zostalo pominiete w specyfikacji lub zle zrozumiane.
I po to właśnie wymyślono testerów. Osobników popsutych do szpiku kości i zarażających tym popsuciem innych, a w szczególności oprogramowanie. Bugfixing polegający na implementacji rzeczy niezaimplementowanych oznacza, że nie było testów. Zresztą testy wymyślono nie po to by sprawdzić kod, ale po to by zrozumieć co ten kod ma robić. Dlatego testy pisze się przed implementacją.
Krycho napisał(a):
Kazdy by tak wolal ale niestety tak sie nie dzieje. My dostalismy 3h na calkiem spora aplikacje z GUI i trzeba bylo sie spieszyc, wiec moimi testami byl log4j, a dokumentacja byla robiona w ostatnich minutach, co sie udalo to sie udalo dopisac.
Jak się nie dzieje? Mi się już parę razy przytrafiła praca domowa w ramach procesu rekrutacyjnego.
Napisanie jakiejś aplikacji na zawołanie, w kilka godzin, bez czasu na przemyślenie, jest tylko bezsensowną męczarnią. Człowiek jest zestresowany, nie może się skupić, do tego pracuje na nie swoim sprzęcie/systemie, nie ma ulubionej konfiguracji, itd. To nie są normalne warunki pracy, więc jak można w ten sposób coś sprawdzić?
Ja bym chyba podziękował, gdybym dostał takie zadanie podczas rekrutacji.
Shalom napisał(a):
Po to stosuje się krótkie sprinty i często spotyka sie z klientem. Pisanie niechlujnego kodu (powodzenia przy refaktorowaniu większego softu, takiego > 0.5mln linii kodu, bez testów jednostkowych, pochwal sie potem ile było regresji) nigdy nie kończy sie dobrze. Poza tym pisanie słabego kodu, bez testów i dokumentacji tylko pozornie kosztuje cię mniej czasu. No chyba że w projekcie studenckim który klepiesz dwa wieczory. W sofcie który klepie 100+ programistów od kilku lat to już nie działa...
A co powiesz na customizacje softu majacego kilkadziesiat tysiecy klas, i bedacego jednym z najwiekszych jesli nie najwiekszym w zakresie PLM? Nawet majac dostep do source nieraz widzialem ze test case'ow tam jak na lekarstwo a jakos jest to jeden z najlepszych produktow na rynku. Da sie? Da. Tylko trzeba pisac od poczatku porzadny kod z glowa. Wcale wiecej czasu to nie kosztuje potem. Test case owszem sa robione, ale zapewne nie takie jak macie na mysli typu (JUnit) tylko podstawowe z poziomu aplikacji, ktore klient sam dostarczy w celu sprawdzenia. Juz dawno sie nauczylem ze nawet klepiac kod na zaliczenie na uczelnie pisze go w sposob przemyslany i w miare generyczny od poczatku, bo zajmuje mi to zazwyczaj mniej czasu.
To jakaś nowość dla mnie. Zwykle bugfixing polega na naprawianiu błędów w kodzie, ale tych które wynikają z pominięcia albo złego zrozumienia wymagań prawie nie ma. Są za to inne ;]
No widzisz u nas ilosc typowych bugow jest mala, czesciej ten proces polega jednak na tym co napisalem. I nie mowie o zlym zrozumieniu wymagan przez nas, tylko zapisaniu ich w taki sposob przez klienta lub niedoprecyzowaniu, ze potem wymagane sa drobne poprawki. Ostatnio na codziennych meetingach zdarzylo sie im 4 razy zmienic zdanie odnosnie 1 funkcjonalnosci, a potem repo, revert, zmiana, revert. Tragedia.
Ale znam ludzi którzy celowo komitują słaby / nie dzialający poprawnie kod, byleby tylko "zdążyć na deadline", zakładając że "jak klient / testerzy" zgloszą błąd to sie potem poprawi. Takich ludzi należy nabijać na pal, bo zwykle to nie oni muszą te błędy poprawiać ;]
Jak sami sobie dol kopia i potem musza poprawiac to krzyzyk na droge. Oby tylko na kogos innego nie spadlo. Sprinty? Tak, przy dlugoterminowych projektach i wiekszej ilosci osob na projekcie. Przy malych raczej sie tych technik 'zwinnych' nie stosuje. Nadal podkreslam, ze nie mowie o sobie, tylko o tym jakie sa praktyki stosowane czesto. Ostatnio tez dostalem po kims projekt. Teoretycznie krotki 2-3 miesiace, ale jak zobaczylem shit kodu ktory na mnie spadl to wzialem wywalilem to i zaczalem wszystko od zera. Typowy kod studencki, ktorego sie nie dalo nawet rozszerzyc bez duzych zmian.
No ale takie krzaczki sie zdarzaja wszedzie. Nie jeden z nas dostajac kod po kims mial male WTF patrzac na te konstrukcje.
Jak się nie dzieje? Mi się już parę razy przytrafiła praca domowa w ramach procesu rekrutacyjnego.
Napisanie jakiejś aplikacji na zawołanie, w kilka godzin, bez czasu na przemyślenie, jest tylko bezsensowną męczarnią. Człowiek jest zestresowany, nie może się skupić, do tego pracuje na nie swoim sprzęcie/systemie, nie ma ulubionej konfiguracji, itd. To nie są normalne warunki pracy, więc jak można w ten sposób coś sprawdzić?
Ja bym chyba podziękował, gdybym dostał takie zadanie podczas rekrutacji.
Jest to swego rodzaju test wiedzy i doswiadczenia. Nikt nie daje jakichs bardzo skomplikowanych aplikacji. Co my tam mielismy 10-15 klas? Zaleznie od pomyslu. Dzieki temu mozna wybrac osoby, ktore sa pewne swoich umiejetnosci i potrafia kodzic, i przede wszystkim widac ze osoba zrobila sama. Skad maja pewnosc ze nie trafi sie cwaniaczek, ktory dostanie pomoc przy napisaniu czegos takiego, a potem mimo swojej niewiedzy zostanie zatrudniony zamiast kogos lepszego i bedzie sie jakos przeslizgiwal tam. Dla mnie jest to calkiem dobra metoda i mi sie bardzo podobalo.
A co powiesz na customizacje softu majacego kilkadziesiat tysiecy klas, i bedacego jednym z najwiekszych jesli nie najwiekszym w zakresie PLM?
To że coś działa i że jest najlepszym dostępnym produktem na rynku wcale nie znaczy że jest produktem dobrym albo łatwym w utrzymaniu. Przykładów takiego softu jest na pęczki. Taki Netscape miał niemalżce cały rynek przeglądarek, ale uznano że nie da sie dalej rzeźbić w brązie i przepisali przeglądarkę od 0.
Pisanie kodu "z glową" od początku to mit i bzdura. Kod ewoluuje i tego nie da sie zmienić. A robienie tylko testów akceptacyjnych i systemowych to słabe podejście. Takie testy są oczywiście potrzebne, ale do werfikacji czy soft robi to co miał robić. Nijak takie testy do refaktorowania się nie przydają.
Juz dawno sie nauczylem ze nawet klepiac kod na zaliczenie na uczelnie pisze go w sposob przemyslany i w miare generyczny od poczatku, bo zajmuje mi to zazwyczaj mniej czasu.
I chwała ci za to. Znam wielu ludzi którzy nawet i po studiach dalej uważają że jest inaczej ;]
No widzisz u nas ilosc typowych bugow jest mala, czesciej ten proces polega jednak na tym co napisalem. I nie mowie o zlym zrozumieniu wymagan przez nas, tylko zapisaniu ich w taki sposob przez klienta lub niedoprecyzowaniu, ze potem wymagane sa drobne poprawki. Ostatnio na codziennych meetingach zdarzylo sie im 4 razy zmienic zdanie odnosnie 1 funkcjonalnosci, a potem repo, revert, zmiana, revert. Tragedia.
Znaczy że macie słabych analityków biznesowych, nic więcej.
No ale takie krzaczki sie zdarzaja wszedzie. Nie jeden z nas dostajac kod po kims mial male WTF patrzac na te konstrukcje.
Z tym bym uważał ;) Nie raz zdarzyło mi sie już że widząc czyjś kod zaliczałem WTF, a potem po rozkminieniu problemu i dogłębnej analizie potencjalnych rozwiazań dochodziłem do struktury niemalże identycznej jak ta która wydawała mi się WTFem. Polecam przeczytać: http://www.joelonsoftware.com/articles/fog0000000069.html
Wydaje mi się że znacznie lepszym sposobem rekrutacji jest posadzenie gościa na 2-3 godziny obok developera z zespołu do którego rekrutujesz i danie im czegoś małego do napisania stosując peer-programming.
Krycho napisał(a):
Jest to swego rodzaju test wiedzy i doswiadczenia. Nikt nie daje jakichs bardzo skomplikowanych aplikacji. Co my tam mielismy 10-15 klas? Zaleznie od pomyslu. Dzieki temu mozna wybrac osoby, ktore sa pewne swoich umiejetnosci i potrafia kodzic, i przede wszystkim widac ze osoba zrobila sama.
A możesz podać przykład takiego zadania? Bo mi się wydaje, że na zrobienie aplikacji, która może być efektywnie rozwijana do czegoś w miarę sporego, to jednak za mało czasu.
Skad maja pewnosc ze nie trafi sie cwaniaczek, ktory dostanie pomoc przy napisaniu czegos takiego, a potem mimo swojej niewiedzy zostanie zatrudniony zamiast kogos lepszego i bedzie sie jakos przeslizgiwal tam. Dla mnie jest to calkiem dobra metoda i mi sie bardzo podobalo.
Jeśli ktoś oszuka w ten sposób i faktycznie nie będzie nic umiał, to najdalej za tydzień wyleci na zbity pysk z roboty. Poza tym projekt to nie jedyna część procesu rekrutacyjnego, jest też rozmowa, podczas której autor na pewno obroni swój kod.
Shalom napisał(a):
To że coś działa i że jest najlepszym dostępnym produktem na rynku wcale nie znaczy że jest produktem dobrym albo łatwym w utrzymaniu. Przykładów takiego softu jest na pęczki. Taki Netscape miał niemalżce cały rynek przeglądarek, ale uznano że nie da sie dalej rzeźbić w brązie i przepisali przeglądarkę od 0.
Pisanie kodu "z glową" od początku to mit i bzdura. Kod ewoluuje i tego nie da sie zmienić. A robienie tylko testów akceptacyjnych i systemowych to słabe podejście. Takie testy są oczywiście potrzebne, ale do werfikacji czy soft robi to co miał robić. Nijak takie testy do refaktorowania się nie przydają.
Akurat jest to napisane w sposob calkiem dobry. Ciagnie sie juz od javy 1.3 bodajze jest stale rozwijany i zyje w duze mierze bez tych test unitow. Dosyc latwa rozszerzalnosc. PLM jest raczej ukryty troche i malo kto siedzi w tym temacie. Jednak jesli firmy takie jak airbus, vw, renault czy apple z tego korzystaja i nam customizacja nie sprawia wiekszych trudnosci, to moge stwierdzic ze jednak pisanie test unitow nie jest kluczowe dla cyklu produkcji i potem cyklu zycia produktu, a jedynie pomocne.
Znaczy że macie słabych analityków biznesowych, nic więcej.
Nie tyle my co sama strona klienta. To oni jednak definiuja i dostarczaja wlasna dokumentacje z wymaganiami. To ze potem im sie odwidzi i zamiast wyswietlic w tabelce to chca tamto, albo nie chca wcale no to juz niestety pod "bugi" podchodzi. Niby funkcjonalnosc jest i wystarczy drobna zmiana.
Wydaje mi się że znacznie lepszym sposobem rekrutacji jest posadzenie gościa na 2-3 godziny obok developera z zespołu do którego rekrutujesz i danie im czegoś małego do napisania stosując peer-programming.
Pisanie na rowni z jakims wyzszym developerem czemu nie, jednak byloby to duuuzo bardziej stresujace dla swiezakow ;) Te techniki XP Programming sa calkiem fajne, ale jedyne kiedy widzialem(na szczescie nie osobiscie ;)) ich zastosowanie to na jakichs konkursach typu siadasz i kodzisz 24h.
A możesz podać przykład takiego zadania? Bo mi się wydaje, że na zrobienie aplikacji, która może być efektywnie rozwijana do czegoś w miarę sporego, to jednak za mało czasu.
Ojj slabo z pamiecia. Bylo cos prostego, jaka struktura powiedzmy zarzadzanie biblioteka, czy czyms w podobie. Wszystko oparte na strukturze xml. Prosty zapis/odczyt, dodawanie pozycji autorow, gatunkow, itp. Sortowanie po tym, usuwanie. Jakies podstawowe operacje. To wszystko w GUI opakowac. Jakies tam dodatkowe wymagania i funkcjonalnosci byly trudniejsze ale w tym momencie nie pamietam. Ogolnie cos takiego na 2-3h jak najbardziej akceptowalne.
Jeśli ktoś oszuka w ten sposób i faktycznie nie będzie nic umiał, to najdalej za tydzień wyleci na zbity pysk z roboty. Poza tym projekt to nie jedyna część procesu rekrutacyjnego, jest też rozmowa, podczas której autor na pewno obroni swój kod.
Pewnosci nigdy nie ma, moze uda mu sie przeslizgnac. Potem bedzie pisal kiepski kod i inni beda sie musieli uzerac. Nim go wywala juz zdazy ludzi wkurzyc ;) Dobrze trafi to sie nie beda az tak interesowac. Korporacje roznie podchodza do tego. Znam takiego co pojecie o programowaniu znikome posiadał(aktualnie nie wiem), kod ktory widzialem nie stosowal sie nawet do zasad typu camel case. Polskie nazwy klas i zmiennych juz przemilcze, a dostal prace w comarchu i pracuje tam nadal. Testy zamkniete to jednak zło ;)
Jako mlody student nie mialem jeszcze okazji bycia na takowej rozmowie, dlatego mnie ciekawi jakiego typu aplikacje do napisania mozemy otrzymac podczas rekrutacji. podzielcie sie waszym
doswiadczeniem
Aplikacje do zrobienia to tylko na spokojnie w domu - wysylasz ją potem do firmy - jak sie spodoba to prosza o cv itp
Nie dajcie sie wrobic w pisanie aplikacji na rozmowie w firmie, lol :)
Notatnik co najwyzej mozna tak napisac i to nie dzialajacy, bo w krotkim czasie mozna napisac albo cos ladnego i nie dzialajacego albo dzialajacego i brzydkiego. pozdro
W sumie trzeba jeszcze rozgraniczyć dwie rzeczy. Pierwsza to aplikacje, takie rozbudowane, które mogą po pewnych przeróbkach trafić "na produkcję" (serio, serio). Druga to rozbudowane zadania programistyczne bardziej przypominające zadania ze studiów lecz z trochę inną "fabułą". Ta druga grupa to przede wszystkim wszystko to co można spotkać na SPOJu czy Codility.
Możecie podać przykład jakieś aplikacji jaką mieliście do napisania jako zadanie rekrutacyjne ?
Podana byla jakas tabela z danymi w pliku csv. Trzebabylo zrobic baze (dowolna), aplikacje webowa z przegladaniem tej tabeli, filtrowanie po wszystkich polach, rozne kolory wierszy grida w zaleznosci od jakiegos tam warunku, eksport danych do excela. Ostatnio mialem wlasnie takie zadanko domowe podczas rekrutacji.
NBP udostępnia kursy walut na każdy dzień w formie xml pod danym linkiem (http://www.nbp.pl/home.aspx?f=/kursy/instrukcja_pobierania_kursow_walut.html). Trzeba było napisać program (Java) parsujący te xml'e, liczący średni kurs kupna/sprzedaży i odchylenie standardowe z przedziału dat. Zadanie (domowe) miało ustalony format wejścia i wyjścia (konsola, uruchamianie JAR'a z parametrem) i nazwę paczki, reszta dowolna. Rekrutacja ofc na Junior Javowca. Możesz sobie zrobić takie zadanko na próbę w swojej technologi, zawsze jakaś praktyka jak nie masz pomysłów na projekty :)
Hmm, testy jednostkowe napisałem, jakość kodu raczej zła nie była (czytałem kiedyś Clean Code). Szkoda zmarnowania tych paru godzin i nie otrzymania nawet maila z feedbackiem czy też z odmową zatrudnienia. Ciekawe czy to mogło pójść na produkcję?
Generalnie odradzam robienie zadań domowych dłuższych niż 30-60 min. No chyba że firma nie jest jedną z wielu do których aplikujesz i faktycznie chcesz tam pracować.
ZłyDyktator, wątpię żeby takie coś szło na produkcję. Też robiłem to zadanie stosunkowo niedawno, podejrzewam że dokładnie do tej samej firmy, bo jakie jest prawdopodobieństwo, że inna firma daje takie samo zadanie. Ja tam kontakt z panem z HRu miałem bardzo dobry. Po wysłaniu zadania po tygodniu dostałem informacje zwrotną i informację o tym, że mogą mnie zaprosić na rozmowę. Potwierdziłem chęć i fakt, była cisza przez tydzień. Wcześniej miałem ciszę z Motorolą, więc byłem przeczulony na tym punkcie, dodatkowo słysząc, że dobrą praktyką jest odpowiadanie w przeciągu tygodnia, po prostu napisałem do rekrutera, że proszę o potwierdzenie otrzymania maila itp. Odpisał od razu, że potwierdza i że proszą o jeszcze kilka dni cierpliwości. Po około 1,5 tygodnia zostałem zaproszony na rozmowę.
Ja wychodzę z założenia, że po drugiej stronie też jest człowiek i jeśli mam jakieś wątpliwości, coś jest dla mnie nie jasne, to piszę, pytam i dziękuję za wyjaśnienia. Fakt, Motorola niby zaprosiła mnie do kolejnego etapu po testach, ale potem była cisza i po 2 tygodniach napisałem z zapytaniem co i jak, nie dostałem żadnej odpowiedzi aż do wczoraj (po 3 miesiącach się mnie pytają, czy jestem dalej zainteresowany, bo mogą mnie na rozmowę w sprawie praktyk zaprosić :D).
Ile już czekasz na ten mail z feedbackiem?
Mrowa: Jakieś 9 miesięcy :) Na razie ani widu, ani słychu :P
Tak tylko wspominam, że nie warto się męczyć nad zadaniami testowymi dłuższymi niż 30 min, jeżeli ma się inne dobre opcje. No, chyba że dana firma jest naszą wymarzoną, to ok :)
ZłyDyktator napisał(a):
No, chyba że dana firma jest naszą wymarzoną, to ok :)
albo pierwszą
moje zadanie rekrutacyjne polegało na połączeniu kilku plików .csv w jeden. Pliki miały różne kodowania i rozłożenie danych. Zadaniem aplikacji było rozpoznanie formatu, kodowania, odrzucenie duplikatów, walidacja i odrzucenie błędnych rekordów, posortowanie i zapisanie do jednego, ujednoliconego pliku. Czasu było 90 minut
Zadanie zrealizowałem i po jakimś czasie też się zacząłem zastanawiać czy po prostu nie potrzebowali tego typu jednego prostego programiku na swój użytek więc zaprosili ludzi żeby im go zrobili za free, ale po dwóch tygodniach dostałem jednak telefon i pracę
Shalom napisał(a)
@Carl19 tylko że taki programik można w jakimś pythonie naklepać w pół godziny oglądając w międzyczasie zdjęcia z kotami, więc watpię żeby specjalnie organizowali rekrutację żeby dostać taki skrypt ;)
no właśnie o to chodzi że programista napisze to w pół godziny, a przeciętnej osobie w tej firmie mogłoby to zająć sporo czasu (główna działalność firmy nie miała nic wspólnego z programowaniem i można było przypuszczać że w ogóle nie mają programistów)