Praktyki w IT dla samouków

Witam, Zacznę od tego że najbliższe wakacje będą moimi ostatnimi. Od niedawna też zainteresowałem się językiem c++. Przerobiłem kurs z tej strony, było mi nadal mało więc kupiłem książkę Grębosza (a właściwie 3 bo najnowsza 'Opus magnum" składa się z 3 tomów) i staram się dzięki niej zdobytą wiedzę poszerzać i utrwalać. Niedawno dość przypadkiem szperając w internecie znalazłem kilka propozycji praktyk w IT od różnych firm związanych z programowaniem, niestety jeden warunek mnie skreśla, bo przyjmują najczęściej tylko studentów 1 albo 2 roku informatyki. Moje pytanie : Czy jakbym napisał do nich że jestem samoukiem c++, przyjęły by mnie takie firmy? Praktyki są za darmo (tzn. nic mi nie płacą) to co im w sumie szkodzi?

Jeśli chodzi o moje wykształcenie to skończyłem liceum na biol-chemie i teraz jestem na pierwszym roku studium(2 letnim) (zawód kompletnie nie związany z branżą IT :/ )

Zależy od firmy. Są takie, gdzie masz szanse nawet na płatne praktyki, ale musisz dobrze wypaść na rozmowie kwalifikacyjnej. Nawet jeśli nie idziesz ściśle w IT, to możesz spróbować szukać firm, których biznes kręci się wokół tego, co studiujesz - niewykluczone, że znajdzie się tam stanowisko, gdzie oprócz samego programowania będzie trzeba ogarniać jakąś konkretną dziedzinę związaną z tym, czym zajmuje się firma i wtedy możesz na tym polu mieć większe szanse niż ci, którzy umieją jedynie klepać kod. Na przykład jak masz jakąś korporację zajmującą się dojeniem krów, to możesz trafić na ludzi po technologii żywienia. Swego czasu stykałem się również z programistami, którzy się znali na hydraulice, stolarstwie czy nawet bartnictwie.

Jeśli jesteś w stanie przekonać ludzi, że się nadajesz, to wykształcenie może zejść na drugi plan (co nie zmienia faktu, że w różnych przypadkach ma znaczenie i niektóre drogi będą przez to zamknięte). Zdarzały się również przypadki, gdzie ktoś spoza dziedziny radził sobie całkiem nieźle jako programista, ale zrezygnował po jakimś czasie, bo okazało się, że to nie dla niego. Moja rada jest taka: próbować zawsze możesz. Składaj CV, bierz udział w rozmowach kwalifikacyjnych, wyciągaj wnioski z ewentualnych porażek i uzupełniaj swoją wiedzę. Przynajmniej wtedy dowiesz się, czy rzeczywiście chcesz być programistą. Na przykład niektórzy lepiej się odnaleźli jako testerzy, a byli też tacy, którzy dostali jakąśtam posadę w firmie, stopniowo nabierali doświadczenia i dopiero po pewnym czasie dołączyli do "klepaczy kodu".

A co do języka: są przypadki, gdzie to nie ma aż takiego znaczenia. Swego czasu trafiłem na gościa siedzącego od kilku lat w C++, który w testach zakwalifikował się do Javy, a ostatecznie pisał z nami w C# (i nawet dostał dłuższe zadanie z JavaScriptu dotyczące jakiejśtam webówki, z czym nie miał większych problemów). Pamiętaj, że zmiana języka nie musi oznaczać zmiany paradygmatu - jak nie przeskakujesz nagle z C++ do Haskella czy Prologa, to znając jakiś paradygmat (na przykład imperatywny) spokojnie sobie poradzisz z pewną grupą języków. Wtedy co najwyżej problem może stanowić solidne poznanie bibliotek.

Zazwyczaj samouk jest znacznie słabszy niż przeciętny absolwent studiów IT, bo na studiach IT student przez X lat musiał robić różnego rodzaju zadania algorytmiczne, aby zaliczać przedmioty. Sama znajomość języka to często za mało. Musisz znać różne struktury danych i umieć rozwiązywać zadania algorytmiczne. Wtedy masz dopiero solidne podstawy, aby walczyć o juniora w IT. Darmowe praktyki - to nie wygląda wcale tak fajnie z perspektywy firmy.

Wyjdź z założenia, że firma musi:
- rozpocząć jakiś proces rekrutacyjny
- wybrać potencjalnych kandydatów dla których warto poświęcić czas osoby, która będzie studenta wdrażała (potencjalne korzyści > czas nauki studenta)
- przygotować sprzęt
- poświęcić czas na wdrożenie
- liczyć na to, że czas poświęcony na wdrożenie nie jest czasem straconym tj. student zechce popracować chociaż przez kilka miesięcy.

Rywalizując o staż/praktyki/juniora licz się z tym, że firma będzie brała takie aspekty pod uwagę na stanowisko techniczne. Chyba, że chcesz trafić do zespołu np. jako tester, gdzie ktoś jest w stanie wdrożyć Ciebie w kilka dni, a resztę czasu będziesz wykonywał zadania, które są oczywiście edukujące, ale nie będziesz nabywał umiejętności IT (czyli umiejętności programistycznych).

Sama znajomość języka to często za mało.

Zdecydowanie, trzeba jeszcze poznać biblioteki. Tyle że w przypadku większych firm okazuje się, że mają jakieś własne frameworki, więc nawet jeśli znasz jakieś biblioteki, to oczywiście to się przyda, ale i tak dopiero po przekopaniu się przez większy kawałek projektu będziesz miał pojęcie, co się tam właściwie dzieje. A jeśli firma wytwarza jakieś własne urządzenia działające u klienta, to jest spora szansa, że będzie tam jakiś Unix/Linux, może nawet trafisz na dystrybucję rozwijaną wyłącznie przez daną firmę.

Jak projekt ma wiele linii kodu i po otwarciu repozytorium widzisz kilkaset projektów, to ogarnięcie tego może trochę zająć. Przy wieloletnich kobyłach zwykle firma ma własne narzędzia do wszelkich możliwych celów. Nie będąc pracownikiem prawdopodobnie nie uzyskasz dostępu do takiego kodu - doświadczenie się przydaje w ogarnięciu tego, ale zwykle i tak każdy startuje z pozycji osoby znającej język (i ewentualnie standardowe biblioteki), a całą resztę poznaje później. W takich sytuacjach zwykle trzy miesiące nie starczą na wdrożenie się w taki monolit i trzeba na to poświęcić jakieś pół roku (albo i dłużej, w zależności od bagienności kodu).

Musisz znać różne struktury danych i umieć rozwiązywać zadania algorytmiczne.

Co tak z grubsza jest niezależne od języka, a bardziej dotyczy paradygmatów. Oczywiście, inne będą nazwy klas, nieco inaczej będzie wyglądała biblioteka standardowa, ale tak czy inaczej to są rzeczy, które po solidnym jednorazowym ogarnięciu zostają na dłużej. Tablica, lista (jedno i dwukierunkowa) oraz ich wady i zalety będą podobne w różnych językach. Liczby zmiennoprzecinkowe z grubsza są implementowane podobnie. Składnia w językach imperatywnych mających jakieśtam korzenie w C też będzie bardzo podobna, te same priorytety operatorów, takie same reguły stawiania średników, zbliżone słowa kluczowe i wiele, wiele innych rzeczy też się powtórzy.

Co do zadań algorytmicznych, to możesz je ćwiczyć na SPOJu. Co prawda tam czasami bardziej liczy się żyłowanie wydajności, ale to też się spotyka w komercyjnym kodzie (przedwczesne optymalizacje są złe, ale umiejętność czytania takiego kodu bywa czasem przydatna), a przy dobrym algorytmie testy zwykle przejdą bez konieczności osiągania od razu szczytów rankingu. Ogólnie, jeśli na takim SPOJu napiszesz program w C++, to nie powinno być większych problemów z przerobieniem tego na Javę, C#, Python czy inne języki.

Jeszcze co do języka: to, że kod jest na przykład w C# nie musi oznaczać, że będzie pisany obiektowo i okaże się "ładny". Widziałem proceduralnie napisane monolity z rozszerzeniem *.cs, docelowo takie rzeczy mają zginąć, ale czasami trzeba naprawiać błędy z nimi związane (lub znaleźć kogoś, kto wie, co tam się właściwie dzieje). A jak okaże się, że autora już dawno nie ma w tej firmie, to nagle umiejętność czytania czegoś takiego jest na wagę złota. Refaktoryzacja kosztuje, oczywiście, ale jeśli czegoś nie da się czytać, to po prostu nie ma innego wyjścia (jak już znajdą się takie kwiatki, to prędzej czy później ktoś będzie musiał taplać się w takim bagnie).

resztę czasu będziesz wykonywał zadania, które są oczywiście edukujące, ale nie będziesz nabywał umiejętności IT (czyli umiejętności programistycznych)

U nas bywały pojedyncze przypadki, gdzie testerzy zostawali programistami. Oczywiście nie od razu, ale parę osób pokazało, że jest to możliwe. Wiele zależy również od tego, do jakiego działu trafisz i czym zajmuje się firma. Bo jeśli masz zespół, który robi coś, co być może zostanie dostarczone do klienta za parę lat, to tam atmosfera jest zupełnie inna niż wtedy, gdy działasz na żywym organizmie i naprawiasz błędy zgłoszone przez konkretnego klienta i całość ma działać na wczoraj.

Firmy są różne, jeśli uważasz, że się nadajesz, to śmiało bierz udział w rekrutacji. W najgorszym przypadku po prostu Cię nie przyjmą, a istnieje dość spora szansa na to, że dowiesz się, co musisz poprawić, czego się douczyć, jakie są pytania, jak działa firma i czy to jest kierunek, w którym chcesz dążyć. A i tak zanim zaczniesz pisać coś poważniejszego, to minie pewnie sporo czasu. W wielu przypadkach całość zaczyna się od naprawiania prostych błędów zgłaszanych przez testerów. Dorzucanie nowych funkcjonalności to nieco inna bajka, bo to musi być zgodne z wymaganiami, trzeba napisać do wszystkiego testy i ogólnie jak jest coś nowego, to musi rzeczywiście coś wnosić, bo inaczej może zostać wycięte jako zbędna funkcjonalność (a przy utrzymaniu wieloletniej kobyły cały kod jest zwykle wystarczająco pokręcony, więc to, co jest nowe, ma być jasne, czytelne i przejrzyste, nawet jeśli stary kod nie był zgodny z tymi nowymi wytycznymi - refaktoryzacja nie jest szybkim i chętnie stosowanym procesem).