Cześć,
jestem właśnie na etapie kończenia książki Michaela Hartla Ruby on Rails Tutorial, uczę się RoR pod kątem znalezienia swojej pierwszej pracy jako junior developer, jednak zastanawiam się jaką aplikację najlepiej wrzucić na swojego GitHuba dla potencjalnego pracodawcy.
Czy przykładowa aplikacja “Sample App” z tutoriala - oczywiście nie na zasadzie kopiuj/wklej a modyfikując apke po swojemu dodając swoje własne elementy i funkcje - wystarczyłaby dla potencjalnego pracodawcy, żeby dostać jakąś rozmowę, tudzież pracę? Ewentualnie co jeszcze dobrze by było dodać do apki by nie została wyśmiana z samego początku?
Na stanowisko juniora wystarczy że pokażesz że przerobiłeś Hartla (który jest rozbudowany) i jesteś w stanie zastosować to co zostało w książce pokazane. Sample App z książki o ile wykonany samemu stanowi bardzo fajną bazę.
Weź pod uwagę że juniora zwykle nie bierze się za umiejętności które aktualnie posiada a za potencjał który reprezentuje. Junior z założenia jest stanowiskiem na którym jesteś osobą do przyuczenia. Najgorsze co można zrobić na początku swojej kariery to mityzować wymagania odnośnie entry-level stanowisk.
Ok, dzięki wielkie za odpowiedź. Mam jeszcze pytanie co do kodu. Ktoś kto powiedzmy zaczyna, cały kod klepie z palca czy można się wspomagać wujkiem Google i np. Stack Overflow? Oczywiście nie mam tutaj na myśli procesu uczenia się, bo jasne że skądś tą wiedzę trzeba brać, ale później po przyjęciu do pracy czy nawet teraz robiąc stronę dla pracodawcy z książką na bok kombinując po swojemu.
Chodzi mi tutaj bardziej o to, że zrobię jakąś stronę wg. mojego pomysłu jako apka rekrutacyjna, wspomogę się Stack Overflow a na rozmowie ktoś mnie zapyta żebym wytłumaczył ten kawałek kodu a ja wielkie oczy
Jak najbardziej możesz a nawet powinieneś korzystać z Google i StackOverflow. Z doświadczeniem nauczysz się po prostu oceniać rozwiązania które ludzie podrzucają.W pracy twoim celem jest dostarczenie działającego produktu. To nie szkoła i nikt nie będzie sprawdzał czy na pewno sam wpisałeś każdy znak na klawiaturze.
Na rozmowie kwalifikacyjnej moim zdaniem najważniejsze to nie ściemniać. To jest tak że jak przyznasz się że masz jakieś braki albo po prostu wykorzystałeś kawałek kodu z SO to potencjalny pracodawca po prostu to przeskoczy i przejdzie dalej, zawsze można się douczyć. Nikt nie wie wszystkiego. Natomiast jeżeli złapie cię na kręceniu to zapali mu się lampka ostrzegawcza.
Ja nie do końca się zgodzę, w moim Githubie był Hartl + 7 innych aplikacji + 2 rekrutacyjne projekty z różnych firm i to wciąż i wciąż było za mało. Niestety entry-level jest moim zdaniem wysokiiii ale to może zależy od miasta
Dobrym nawykiem jest zaglądanie w pierwszej kolejności do dokumentacji a potem google, stack overflow. Na live coding ma to znaczenie, rerkuterzy często zwracają uwagę na to gdzie szukasz pomocy i jak szybko jesteś dane informację znaleźć.
Ja z kolei bardzo nie lubię jak ktoś ocenia moją pracę po tym jak piszę. O wiele bardziej wolę kiedy sprawdzany jest gotowy już kod. Zadanie do rozwiązania i ocena na podstawie code review to jest moim zdaniem najlepsze rozwiązanie dla kandydata jak pracodawcy. Bo kogo tak naprawdę interesuje czy 3/4 kodu przepisałeś z internetu, a nie “z głowy”. Jeżeli jesteś w stanie tak dobrze wyszukiwać rozwiązania problemu, to tym lepiej dla pracodawcy. Ja rozumiem, że od seniora można wymagać ogromnej wiedzy w głowie, ale temat jest o juniorach
Natomiast sesje live coding to jest po prostu dla mnie jakaś porażka. Raz miałem taką sytuację, że pracodawca wymyślił sobie dzielenie pulpitu przez google hangouts, w połowie okazało się że nie widzi w ogóle co ja robię, bo ja pracauję na dwóch monitorach a on widzi tylko jeden. Musiałem w ogóle odłączyć jeden monitor, całe skupienie szlag trafił i do tego musiałem się męczyć na jednym monitorze (a byłem zupełnie do tego nie przyzwyczajony). Skończyło się na tym, że nie dokońyłem tego co było do zrobienia i pracy nie dotałem. W sumie dobrze, bo co to za frajda pracować w firmie w której Ci dyktują jak masz sobie środowisko pracy ustawić. Jeszcze brakowało tylko żeby mi mówili z jakiego edytora mam korzystać
Dlatego moim zdaniem, jeżeli szukasz pracy jako Junior w Rubym, to najlepiej wysyłać oferty tam gdzie jest szansa że oceniać Cię będą na podstawie jakiegoś zadania do wykonania (nawet jeżeli to nie jest stricte juniorska pozycja), bo wtedy w najgorszym wypadku po prostu nie poradzisz sobie z zadaniem, albo będzie ono napisane w sposób nie przystający do standardów danej firmy. Ale przynajmniej cały czas będziesz szlifował swój warsztat developerski i prawdopodobnie będziesz miał do czynienia z realnymi problemami z którymi w pracy się możesz spotkać, a to naprawdę dużo daje.
Myślę, że wiekszość devów nie lubi jak się patrzy im na ręce. Zgadzam się, że to najbardziej stresująca część interview, przynajmniej dla mnie. Jednak najczęściej trzeba coś napisać przy publiczności i zostać ocenionym przez milczący głos u uważne oko z drugiej strony monitora.
Rezygnowanie z ciekawego projektu lub firmy tyllko dlatego, że jest live coding mocno zawęża możliwości pracy. Większość rozmów na jakich byłem, niezależnie od tego czy dostałem oferte czy nie, była kombinacją zadania w domu i rozwiązywania problemów na żywo lub jedynie zadanie na żywo (“ruby + minitest”). “Part of the job” i nie da się tego uniknąć na poziomie junior/mid. Jedyna rada to chodzić na rozmowy rozwiązywać zadania i wynosić z każdej wnioski. Później robi się mniej stresująco
