JavaRush /Blog Java /Random-PL /Jak stary humanista poszedł do IT
PieIsLie
Poziom 35
Санкт-Петербург

Jak stary humanista poszedł do IT

Opublikowano w grupie Random-PL
Sztuczne ognie! Właściwie długo zastanawiałam się, co dokładnie napiszę w tym poście i czy w ogóle go napiszę. Tak się złożyło, że w różnych okresach ostatnich dwóch lat różnie oceniałem swoje szanse na zdobycie stanowiska programisty Java: od „wcześniej czy później – zdecydowanie” do „nie mam szans w IT”. Jak stary humanista trafił do IT - 1Jednak minęły prawie dokładnie dwa lata, odkąd zarejestrowałem się w JavaRush. Kilka miesięcy temu otrzymałem pierwszą ofertę, chwilę później drugą, po czym rozpocząłem nową pracę. Historie sukcesu bardzo mi pomogły podczas kursu, więc zdecydowałem się opublikować własne. Ponieważ kurs odbył się w '18 roku, niektóre informacje mogą być nieaktualne. Od razu powiem, że tekstu będzie dużo, bo… Postaram się opowiedzieć Ci o szkoleniach i poszukiwaniach pracy (wymagania, odpowiedzi, specyfikacje techniczne, rozmowy kwalifikacyjne itp.). Napiszę też kilka ogólnych wskazówek, które pomogły mi osobiście i mogą pomóc innym. Krótko o mnie: 32 lata, 10 lat doświadczenia w zarządzaniu i sprzedaży, wykształcenie humanistyczne i całkowity brak wiedzy technicznej. Kilka lat temu próbowałem dostać się do C++, a potem do Pythona - tylko bolała mnie głowa. Dlatego trudno nazwać mnie utalentowanym programistą, wręcz przeciwnie.

ETAP 1. Szkolenie

Do JavaRush trafiłem świadomie: odpowiedni miesięczny cennik, przejrzysta struktura materiału, dużo praktyki i obecność własnej społeczności. Pierwsza kwestia jest jasna, ale nauka języka bez struktury jest dość trudna, a takie szkolenie z pewnością pozostawi osobę z poważnymi brakami w Java Core. Doświadczenia wynikające z wywiadów i specyfikacji technicznych pokazują, że pytania dotyczące „rdzenia” można wykorzystać do wszystkiego: od przesuwania bitowego i rzutowania typów generycznych po operacje wejścia/wyjścia i serializację. Praktyka jest koniecznością; Nadal rozumiem i pamiętam tylko połowę rzeczy, jeśli sam je napisałem. Cóż, społeczność: rozwiązałeś problem - pochwal się tym w komentarzach; Jeśli jeszcze się nie zdecydowałeś, możesz zadawać pytania, ale najprawdopodobniej nikt nie poda Ci gotowego rozwiązania. A do niestandardowych artykułów na darmowe tematy wracałem nawet po ukończeniu kursu, jest tam sporo dobrych rzeczy na początek (zwłaszcza pierwsze doświadczenia z frameworkami na przykładach krok po kroku + pytania do wywiadów). Ogólnie rzecz biorąc, jestem wdzięczny temu projektowi za otrzymaną bazę, ale nie polegałbym tylko na JavaRush - ten sam Shildt najlepiej „nakłada się” na badany temat i często ujawnia pewne punkty. W recenzjach powiedziano już wiele o zadaniach, które czasami wyprzedzają teorię i zmuszają do korzystania z Google. Dla mnie to raczej plus niż minus - i nie jest faktem, że teraz sytuacja jest taka sama jak wtedy, gdy studiowałem. Natychmiastowa rada dla tych, którzy tak jak ja rozpoczynają przygodę z Javą „od zera” : na pewnym etapie możesz się znudzić lub mieć trudności:
  1. Każdemu jest ciężko zaczynać od zera, nie daj Boże, tylko 5% osób dociera do końca kursu. Twoim zadaniem jest stać się jednym z nich.

  2. Moje zainteresowanie pojawiło się po miesiącu lub dwóch, kiedy zadania stały się trudniejsze i ciekawsze. Bądź cierpliwy.

  3. Najważniejsze są tygodniowe postępy. Po dwóch tygodniach odpoczynku powrót jest już trudny, a nie każdy jest w stanie pisać codziennie przez kilka miesięcy z rzędu. Ustal sobie limit godzin w tygodniu – na przykład 15. Możesz kodować przez 1,5 godziny w każdy dzień powszedni i kolejne 3-4 godziny w oba weekendy, albo możesz wziąć kilka wieczorów wolnych, ale „limit weekendowy” będzie zwiększyć. Dzięki temu harmonogram będzie elastyczny, ale regularny. Oczywiście wtedy będzie można mierzyć pracę zadaniami i projektami, ale na poziomie składni i jądra wystarczą godziny.
Ogólnie rzecz biorąc, ukończenie kursu (przed przystąpieniem do stażu) zajęło mi około 5 miesięcy , mimo że mogłem sobie pozwolić zarówno na wakacje, jak i krótkie przerwy; ponownie, praca w pięciodniowym tygodniu pozostawiła wolne jedynie weekendy i wieczory w dni powszednie od 22 do 00. Zatem przy luźniejszym harmonogramie lub bardziej sztywnym reżimie treningowym możesz poradzić sobie znacznie wcześniej. Potem planowałem odbyć staż, ale ostatecznie nie wyszło.

ETAP 2. Samokształcenie

Więc nie dostałem się na staż: zostawiłem tylko kilka dni na wymaganiach technicznych do końca rekrutacji do grupy i nie miałem czasu na wymyślenie wymagań - było za dużo nieznanych słów. Ponieważ Nie chciałam czekać kolejnych trzech miesięcy, postanowiłam działać dalej. Na szczęście istnieją przewodniki i samouczki wideo dotyczące wszystkich popularnych frameworków. Przez kolejne kilka miesięcy zajmowałem się Spring MVC, Spring Boot + Data, Spring Security, Hibernate, jUnit, Maven, Git, RDBMS, opanowałem SQL i próbowałem złożyć to wszystko w jedną całość. Pół roku później miałem projekty, na które teraz aż strach patrzeć, ale zdobyłem praktyczne doświadczenie w korzystaniu z „dorosłych” frameworków i GitHuba, który można było pokazać na prośbę potencjalnego pracodawcy. Porada :
  1. Im szybciej dowiesz się o .gitignore, tym lepiej. ;)

  2. Wiele przewodników zawiera kilka frameworków jednocześnie; użyj tego i dodaj własne. Sklep internetowy napisaliśmy przy użyciu Maven + Spring Boot + Data - dodaj autoryzację, testy jednostkowe i logowanie.

  3. Do projektów webowych można pobrać darmowe szablony frontendowe z Internetu - przyjemniej się z nimi pracuje, lepiej wyglądają jako zrzuty ekranu w pliku README na Git. Jednocześnie będziesz w stanie zapamiętać HTML i CSS - prawdopodobnie będziesz chciał poprawić style i układ.

Najprostszym sposobem na stworzenie takiego planu rozwoju dla siebie jest przejrzenie HH w poszukiwaniu ofert pracy dla Junior\Middle Java Developer i sprawdzenie, które technologie i frameworki są najczęściej wskazywane. Zapisz je, wymyśl dla nich specyfikację techniczną, ustal sobie terminy realizacji. Chociaż może gdybym zaczął od lokalnego stażu, nie musiałbym spędzać kilku miesięcy na domowych projektach.

Czego mi brakowało (później spaliłem się podczas rozmowy kwalifikacyjnej)

  1. Algorytmy. Aby uniknąć moich błędów, od razu polecam krótką książkę w języku rosyjskim „Grocking Algorithms”. Jaka jest złożoność algorytmów, na czym polega, dlaczego szybkie sortowanie nie wystarczy, wprowadzenie do teorii grafów – wszystko jest tam i w jak najbardziej zrozumiałym języku.

  2. Kolekcje „pod maską”. Nie pamiętam, czy było to w JavaRush, ale warto wiedzieć, jak działa HashMap.get() i dlaczego HashSet nie gwarantuje zachowania kolejności elementów. Powtórzę jeszcze raz – które kolekcje są bezpieczne dla wątków i dlaczego.

  3. SQL-a. Potrzebujesz co najmniej JOIN - czym są, jak działają, możliwość zapisywania w locie SELECT na dwóch tabelach na papierze. Polecam www.sql-ex.ru: w ciągu jednego lub dwóch dni przeniesie Cię na pożądany poziom.

  4. Spring Core: jakie są adnotacje, jaki jest kontekst, jak powstają fasole, który Bean Scope jest bezpieczny dla wątków i jak rozwiązać wzajemne wstrzykiwanie - wszystkie pytania podczas rozmowy kwalifikacyjnej. Jak zwrócić stronę, jak zwrócić JSON itp. Aktualnie czytam „Wiosnę 5 dla profesjonalistów” po rosyjsku, ale ogólnie polecają „Wiosnę w akcji”.

ETAP 3. Poszukiwanie pracy

Właściwie w ciągu pierwszych kilku miesięcy po ukończeniu projektów domowych wysłałem około 30 odpowiedzi na różne oferty pracy Junior\Trainee (za pośrednictwem HH, LinkedIn, agencji rekrutacyjnych), z niemal zerowym skutkiem. Skupiłem się wyłącznie na ofertach pracy bez doświadczenia, szczerze wskazałem znajomy mi stos i pisałem w listach motywacyjnych o moich wysokich zdolnościach uczenia się. Efektem są dwie rozmowy telefoniczne (jedna z nich od razu zakończyła się w moim średniozaawansowanym angielskim), dwie kolejne firmy przesłały specyfikacje techniczne, odbyło się tylko jedno „spotkanie”, a potem byłem tam sam, rozwiązując problemy dotyczące algorytmów na kartce papieru, po czym HR po prostu zabrał papiery i „Zadzwonimy do ciebie”. Starałem się o kilka staży (bezpłatnych i warunkowo płatnych): zrobiłem specyfikację techniczną, ale nie wyszedłem poza ostateczne zabezpieczenie społeczne; ale teraz mogę powiedzieć, że stażystów na pewno rekrutują T-Systems, CFT, Andersen i EPAM (mają mieszane recenzje, zdecyduj sam). Jeśli chodzi o mnie, jest to dobry sposób na wejście na pole, jeśli masz możliwość siedzenia bez dochodów przez kilka miesięcy i nie umrzeć =) Ogólnie rzecz biorąc, po tym doświadczeniu wpadłem w lekką depresję i wstrzymałem całą historię z poszukiwaniami przez prawie sześć miesięcy - kontynuowałem pracę na poprzednim profilu, pisałem kilka aplikacji dla zabawy, ale nawet nie umieściłem ich na Gicie. Aż spotkałem jednego znajomego, któremu mimochodem opowiedziałem o porażkach z wakatami: w tym czasie pracował już jako średni programista, ale zaczynał w ten sam sposób – od samokształcenia. Znajomy dał mi kilka rekomendacji , z których sam skorzystał i które bardzo pomogły mi w przyszłości w poszukiwaniu pracy. To, czy je zastosujesz, czy nie, zależy od Ciebie, ponieważ... w pewnym sensie nie są do końca szczerzy. Zatem dalsze cytaty:
  • W jakikolwiek sposób zapewnij sobie w swoim CV ponad 6-miesięczne doświadczenie komercyjne: staże, projekty dyplomowe, freelancing, praca zdalna – cokolwiek. Będzie to bardzo pomocne na etapie wstępnej selekcji CV przez HR;

  • usuń ze swojego CV słowo Junior i oczekiwane wynagrodzenie; po prostu zostaw to jako Java Developer i omów pieniądze indywidualnie z każdą firmą;

  • postaraj się, aby dział HR określił „widelec” proponowanej pensji, zanim określisz swoje oczekiwania. Jeśli firma oferuje 80-120 tys., a Ty szukasz 40 tys. i więcej, niektórzy selekcjonerzy potraktują Cię z pogardą;

  • Aplikuj na wszystkie oferty pracy, które odpowiadają Twojemu stosowi, nawet jeśli wymagają 1-3 lat doświadczenia komercyjnego.

Po zastosowaniu się do wszystkich tych zaleceń sytuacja wyszukiwania znacznie się poprawiła. Po pierwsze, z około 12 nowych odpowiedzi połowa niemal natychmiast zakończyła się spotkaniem, Skypem lub TK (co już bardzo różniło się od ignorowania w poprzednich miesiącach). Po drugie, zaczęli do mnie pisać ludzie z HR, na które nie odpowiadałem – na komunikatorach, mailowo, na LinkedIn. Po trzecie, wymagania dotyczące doświadczenia komercyjnego okazały się naprawdę niezbyt rygorystyczne – wiele firm było gotowych nawiązać współpracę z kandydatem, który nie mieścił się w określonym przedziale 1-3 lat praktyki korporacyjnej. W rezultacie - jedna oferta dla juniora, druga dla środkowego z okresem próbnym. W sumie poszukiwania trwały dwa miesiące. Porada :
  1. Uwzględnij w swoim CV cały stos języków, technologii i frameworków, z którymi pracowałeś.

  2. Zarejestruj się na LinkedIn – jest tam naprawdę dużo osób HR z różnych firm. Wypełnij dokładnie swój profil – tak naprawdę jest to także Twoje CV. Aby rozwijać swoją sieć kontaktów, dodaj LIONy odpowiednie dla Twojego profilu, akceptują one prośby od wszystkich użytkowników.

  3. Spróbuj swoich sił w bezpłatnych testach Java – często podawane są one w formie papierowej przed rozmową kwalifikacyjną Junior. Lepiej przygotować się wcześniej.

Kilka słów o wywiadach
  1. Zawsze pytają o kolekcje: jakie są, czym się różnią, kiedy najlepiej z nich korzystać.

  2. Zawsze na klasach abstrakcyjnych i interfejsach - czy mogą mieć metody, pola, jakie, czy można je dziedziczyć itp.

  3. Prawie zawsze na wielowątkowości - to, czego używałeś w swojej pracy, słowa kluczowe, metody, znasz util.concurrent.

  4. Często podczas pracy z pamięcią - sterta, stos i czy te ciągi będą równe, a te obiekty, dlaczego.

  5. Czasami o algorytmach - jakie znasz, jaką złożoność, dlaczego, możesz już napisać algorytm.

  6. Czasem na podstawie wzorców - które znasz, jakich używasz, napisz singleton lub fabrykę.

  7. Czasami w SQL - rodzaje JOIN, czym jest transakcja, jak ją przeprowadzić w JDBC, napisz krótkie zapytanie.

Tak naprawdę wszystko bardzo zależy od firmy : ktoś nie zadaje ani jednego pytania na temat Java Core, ale spędza 40 minut na rozmowach o frameworkach i SQL; Niektórzy w ogóle nie korzystają z popularnych frameworków i pytają jedynie o algorytmy, typy, kolekcje i pamięć. Około połowa spotkań rozpoczynała się od testów – czasem po rosyjsku, czasem po angielsku (20-30 pytań po 20-30 minut); Zwykle pytania na poziomie „tu jest kod, czy będzie działać, czy nie, a jeśli nie, to w jakiej linii” lub „tutaj jest kilka obiektów, czy po N operacjach będą równe”. Kilka słów o specyfikacji technicznej : 70% firm rozpoczynających komunikację przesłało mi specyfikację techniczną przed lub po spotkaniu. Zwykle realizacja podawana jest od kilku dni do tygodnia, jednak najczęściej terminy można nieco przesunąć. Jako specyfikacje techniczne można wykorzystać wszystko. Oto przykłady, które zrobiłem:
  • Strona kontaktów biznesowych profilu Salesforce z edycją i dodawaniem nowych rekordów;

  • symulacja windy w budynku wielopiętrowym z wykorzystaniem Spring State Machine ze sterowaniem konsolowym;

  • Aplikacja na Androida oparta na bibliotece LibGDX wyświetlająca tekst znak po znaku po naciśnięciu przycisku;

  • Imitacja REST carsharingu, z dodawaniem klientów poprzez żądanie HTTP i zwracaniem JSON;

  • problem sortowania grafu nieskierowanego przez wolną komórkę;

  • szukać trójkątów równoramiennych na podstawie współrzędnych z pliku;

  • refaktoryzacja gotowego kodu przy użyciu Stream API;

  • Kalkulator interfejsu użytkownika z obsługą wyrażeń trójskładnikowych;

  • wyścig wątków z zapisem wyników do pliku.

Czasami metody obliczeniowe należy uwzględnić w testach jednostkowych, a metody zapytań w testach integracyjnych. Porada :
  1. Staraj się nie tylko wykonać zadanie, ale także upewnić się, że kod jest zgodny z zasadami OOP.

  2. Sprawdź wydajność swojego kodu - raz zostałem odrzucony, ponieważ między innymi użyłem PrintStream zamiast BufferedWriter.

  3. Zaplanuj czas realizacji z marginesem 50% – lepiej zacząć i zakończyć wcześniej, niż robić git push o ósmej rano w wyznaczonym terminie.

Cóż, wszystko, co chciałem, myślę, że napisałem. Najważniejsze jest to, że woda niszczy kamienie. Nie da się pisać dużo, dużo w Javie, potem długo szukać pracy i w końcu nic nie wymyślić. Jeśli udało się to 30-letniemu humaniście, Ty możesz to zrobić jeszcze lepiej. Najważniejsze, żeby nie bać się pierwszych rozmów, zadań technicznych i rozmów kwalifikacyjnych: po każdym nieudanym czasie miałem gwarancję, że nauczę się czegoś dla siebie i udoskonalę - im dłużej, tym pewniej się czujesz. Jeśli gdzieś wyszło chaotycznie lub są błędy - z góry przepraszam, pisz, poprawię. Mam nadzieję, że moje doświadczenie choć komuś pomoże =)
Komentarze
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION