Blokada w rozwoju kariery

Cześć,

Jest to mój pierwszy post na tym forum, ale przyznaję się, że dość często tu zaglądałem w poszukiwaniu odpowiedzi. Także chciałem Was wszystkich bardzo serdecznie powitać, mam nadzieję, że moje posty i wpisy będą merytorycznie wzmacniać ten portal :)

Przechodząc do problemu:
Chciałbym się Was poradzić co zrobić, bo się mocno zagubiłem w aktualnej mojej ścieżce kariery. Z perspektywy wydaje mi się, że miałem o wiele więcej szczęścia niż rozumu w tym wszystkim i teraz dotarłem do klifu, a za sobą czuję ścianę zbliżającą się do mnie i jak nie wybuduję mostu, albo nie znajdę spadochronu to spadnę.

Od początku:
Studia:

• Inżynier Inżynieria biomedyczna spec. Informatyka medyczna - dużo rzeczy z informatyki, ale mniejszy nacisk na teorię programowania - tutaj nauczyłem się programować
• Magisterka: Informatyka - tutaj już w sumie mało było z teorii samego programowania, więcej algorytmiki, trochę ML i innych

Praca:

1. ASP.NET 5 MVC - zespół tworzący rozwiązania na potrzeby firmy, nikt się nam nie patrzył na ręce, mogliśmy robić co chcieliśmy. Problem był taki, że zespół był "młody i dynamiczny", każdy praktycznie po studiach i nie mieliśmy technicznego lead-a - 3 lata
2. .NET Framework - do teraz prawie 5 lat. Praca niby lajtowa, mieliśmy produkt, który był sprzedawany do klientów, a nasz zespół robił dedykowane customizacje. Niestety sama aplikacja nie była pisana w zgodzie z jakimikolwiek zasadami dobrego programowania. Zasady SOLID? Brak. Praktycznie brak użycia interfejsów, klas abstrakcyjnych... No bida. Ale człowiek się tym nie przejmował. Pracowało się fajnie, problemy bardziej z poziomu algorytmiki i samej logiki bez zaawansowanych problemów projektowych. Wszystkie rozwiązania były dostosowywane do pierwotnego produktu, więc ciężko było zrobić cokolwiek więcej. Nawet testów jednostkowych brak. Aktualnie niestety projekt przeszedł w stan utrzymania i programuję tylko co kot napłakał. Czasami zmienię jedną linijkę, gdzieś poprawie jakiś wyświetlany tekst, albo piszę testy automatyczne w AutoIT.

I teraz mam wielki problem. Z programowania jestem głównie samoukiem, na studiach było bardzo mało teorii. Programowałem sam, więc fachowe nazewnictwo gdzieś uciekało (a na kawie raczej nie rozmawia się o boxingu i unboxingu).

Aktualnie próbuję zmienić pracę, jednak się za każdym razem odbijam na rozmowie. Za każdym razem jestem dopytywany o jakieś szczegóły z technologii, typu co to właśnie ten boxing i unboxing, czym jest stos i sterta, jakie mamy problemy, ryzyka przy pracy na wątkach, czy klucz w słowniku może być typem referencyjnym czy może być tylko prostym, jeśli może być typem prostym do w jaki sposób na nich pracować, jakie znam mechanizmy i biblioteki do testów, jakie znam rodzaje testów, czym testuję UI itd. Ostatnio często i gęsto pytają o technologie dodatkowe typu JavaScript, TypeScript i Angular (z którymi nie miałem do czynienia i nie ukrywam tego na żadnym etapie rekrutacji)

Po każdej rozmowie staram się zapamiętać jak najwięcej pytań, by potem je zweryfikować i zapamiętać. Tylko nie ważne ile tych pytań przerobię to na rekrutacjach pojawiają się może trzy takie same (i to zazwyczaj SOLID, Interfejs vs klasa abstrakcyjna). Przyznam się Wam, że czuję się psychicznie okropnie. Już nie wiem jak podchodzić do tej nauki i poszukiwania pracy.

Próbowałem inaczej i kandydowałem do pracy z zadaniami do zrobienia. Np. WebApi w .NET 5. Zrobiłem, ale nie wykorzystałem najnowszych zdobyczy .NETu i kiszka.

Na żadnym etapie nie ukrywałem, że nie jestem omnibusem z tego tematu. Siedzę, programuję i robię co do mnie należy, ale widzę, że to za mało. Powinienem chyba być jakimś gościem, który sam postawi system u klienta w miesiąc :(

Pożaliłem się i teraz pytanie:
Koledzy, co radzicie, w jaki sposób uzupełnić swoją wiedzę teoretyczną, by przejść przez te nieszczęsne "egzaminy". Czy zrobić kurs i uzyskać certyfikat MS z zakresu programowania? Co mogę zrobić, by mieć szansę zmienić pracę. Bo czuję, że jeszcze rok, najdalej dwa i zapomnę jak się programuje.

Na jaki stanowiska uderzasz? Może warto obniżyć próg wejścia i aplikować na juniora/mida? Wtedy rekruterzy powinni być w stanie więcej wybaczyć, z kolei z doświadczeniem na tle innych kandydatów masz większe szanse na papierze.

Poza tym warto po prostu wyszukać w google pytania rekrutacyjne w .Net i wykuć je na blachę- oczywiście tak żeby faktycznie rozumieć odpowiedzi, bo to widać kiedy ktoś nie wie co odpowiada.

@Aventus: Zawsze na .NET Developer. Pomijam już sytuację, gdy na rozmowie się dowiaduję, że rozmawiam na stanowisko FullStack -.-
Właśnie najgorsze jest to, że mnie mocno trzymają finanse :( aktualnie jestem jedynym żywicielem rodziny, na kredycie i nie mogę obniżyć swojej stawki :( Przy zmianie już przestałem nawet ją podnosić - idę na tą samą stawkę.

Dlatego zależy mi na dokształceniu, jakimś kompendium wiedzy.
Gdybym był sam i nie byłoby osob zależnych ode mnie do bym pewnie ze swojej wypłaty obciął z 2 tysiące...

Nie przyszło Ci do głowy by wygooglować te pojęcia? Bo czytając o nich, można spokojnie dojść do masy kolejnych informacji i tak się uczyć. Jeśli chcesz być .NETowcem to czytaj sobie https://docs.microsoft.com/en-gb/dotnet/. Idź też na kilka rozmów do jakiś randomowych firm, by nabrać wprawy.

Współczuję, też mam doświadczenie z tego typu rekrutacjami.
Zadają pytania np. czym się w js różni splice od slice, albo jakie są cykle życia komponentu w vue.
A Ja mam np. taką zasadę (albo konstrukcje), że nie pamiętam rzeczy, których nie używam na co dzień, dlatego nawet jak sprawdziłem, czym się różni splice od slice to po miesiącu i tak o tym zapomnę, a żeby to sprawdzić w necie to zajmuje 1-2 min. Akurat przeważnie usuwam w tablicy, a rzadko kiedy muszę ją filtrować, a do tego używam prędzej filter().
Tak samo z cyklem komponentów, przeważnie używam dwóch, mounted i beforeDestroy i nie pamiętam wszystkich, a, żeby je sprawdzić, to też zajmuję 1-2 min.
I taki gość co zadaję jakieś pytania pamięciowe, później wyciąga wniosek, że słabo piszesz kod czy coś, co jest po prostu bzdurą totalną.
Miałem w życiu kilka sytuacji, że też zadawali jakieś głupie pytania, ale akurat przeszedłem rekrutację, a później okazuje się, że kod to jakieś bagno.

A w ogóle najlepsze jest jak oceniają na postawie swoich głupich pytań, a nawet nie zajrzą do projektów w portfolio.

Czyli wygląda na to że rynek Ci mówi że chce FullStacków. Najprościej będzie nauczyć się w czasie wolnym kombo Angular + TypeScript. Nie musi być super zrób ToDo list z backendem + REST (nie spodziewam się jeszcze GraphQL w korpo). Dowiedz się co to Bootstrap lub Material (czyli jak tworzyć formatki jak się nie zna CSS i nie chce się uczyć). Do ogarnięcia w 3 miechy, wieczorami.

Co do pytań, boxing unboxing to pytanie jest fair, bo pozwala sprawdzić czy osoba wie o fundamentalnych różnicach między value types i reference types w C# i ogólnie na platformie .NET. Taką wiedzę najłatwiej uzupełnić i usystematyzować sięgając po dobrą książkę, ja polecam C# 9.0 in a Nutshell. 1 - 3 miesięcy na naukę w zależności od czasu.

Z postu wnioskuje że SOLID i DesignPattern znasz, o testach też piszesz że wiesz o co chodzi. Zastanawia mnie więc dlaczego wyłożyłeś się na pytaniu "jakie znam mechanizmy i biblioteki do testów", nie piszę w C# od 4 lat ale potrafię rzucić nazwy NUnit, XUnit, NSubstitute, Moq, NFaker, Selenium oraz np. Sonarqube (do mierzenia pokrycia). Najlepiej to zacznij w obecnej pracy dodawać testy, skoro zmieniasz jedną linijkę od czasu do czasu to znaczy że możesz dodać 1k linii unit-testów a przy okazji poczytać jak dobrze testować.

Ja Ci nie przeszkadza łamany angielski i drętwy styl to możesz poczytać trochę postów na moim blogu z kategorii .NET i Architecture: https://blog.marcinchwedczuk.pl/
Radzę też zaczynać dzień od nabożnego czytania https://blog.cwa.me.uk/ :D

Przede wszystkim to masz fajny background specjalistyczny (wiedza domenowa), a brzmi ten post jakbyś próbował uderzać do Janusza na walenie CRUDów. Pewnie, można tak, ale zastanów się czy Ty tego chcesz :P

Barqtos napisał(a):

Studia:

• Inżynier Inżynieria biomedyczna spec. Informatyka medyczna - dużo rzeczy z informatyki, ale mniejszy nacisk na teorię programowania - tutaj nauczyłem się programować
• Magisterka: Informatyka - tutaj już w sumie mało było z teorii samego programowania, więcej algorytmiki, trochę ML i innych

Aktualnie próbuję zmienić pracę, jednak się za każdym razem odbijam na rozmowie. Za każdym razem jestem dopytywany o jakieś szczegóły z technologii, typu co to właśnie ten boxing i unboxing, czym jest stos i sterta, jakie mamy problemy, ryzyka przy pracy na wątkach,

co ro za studia że takich rzeczy nie wiesz?

Dzięki wszystkim za odpowiedzi.
Postaram się codziennie zaglądać na podane strony, szczególnie na https://blog.cwa.me.uk/ wydaje się być bardzo interesujące :)

@Miang: jeśli chodzi przykładowo o Boxing i unboxing to był to wstyd jakich mało. Mechanikę znam i używam, ale problem było, że nie wiedziałem, że to się tak nazywa. Sterta i stos - szczerze? W przypadku .NET pozwoliłem sobie by tym zajmował się GC. Może gdzieś na studiach było to wspominane, ale zwyczajnie człowiek o tym zapomniał, a z wątkami... Szczerze? Do tej pory nie było mi to potrzebne w pracy zawodowej, bo miałem to "szczęście", że nie pracowałem nad elementami które korzystają z wątków prócz paru wyjątków (np. metody w WebApi przy wywołaniu).

A co myślicie w aspekcie szkoleń/certyfikatów MS? Warto iść tą drogą, by: 1) uzupełnić wiedzę, 2) odsapnąć lekko od "egzaminów" na rozmowach? Czy jednak dać sobie z tym spokój?

Inżynier Inżynieria biomedyczna spec. Informatyka medyczna - dużo rzeczy z informatyki, ale mniejszy nacisk na teorię programowania - tutaj nauczyłem się programować

A myślałeś o pracy w branży medycznej? Tam też potrzebują programistów, a takimi studiami pewnie byś zapunktował.

A poza tym... to wygląda trochę jakbyś miał mniejszą wiedzę niż można wywnioskować po latach doświadczenia (szczególnie ta druga praca, gdzie wynika, że pracowałeś 5 lat w jakimś JanuszSofcie, czyli 1 rok powtórzony 5 razy?).

Koledzy, co radzicie, w jaki sposób uzupełnić swoją wiedzę teoretyczną,

W praktyce. Jak cię pytają o testy, to możesz się nauczyć robić testy (w jakimś konkretnym projekcie, czy to w pracy czy w swoim wolnym czasie). Jak cię pytają o wątki, to możesz poćwiczyć pracę na wątkach (i przy okazji załapiesz też teorię). Jak cię pytają o SOLID, to spróbuj stosować zasady SOLID we własnym pisaniu (albo je łamać i zobaczyć, czy to dobry pomysł). Na serio to wygląda tak jakbyś dopiero zaczynał programować, pomimo niby wieloletniego doświadczenia.

No ale w takim układzie po prostu musisz nadrobić braki. Nie ma jakiejś magicznej recepty, złotego kursu. Jest mnóstwo materiałów w necie, ale co z nich wyciągniesz, to już będzie zależało od ciebie.

Powiem ci wprost, trafiasz na h.... rekrutacje. Aplikuj i wyluzuj. Wiedze sprawdzaja czesto, ale nie zawsze. Tam gdzie sprawdzaja wiedze i mecza cie pytaniami to zazwyczaj jest h.. dupa i cycki. Z wlasnego doswiadczenia ci powiem, ze nawet jak bedziesz dobrze odpowiadal to cie moga odrzucic. Ostatnio mialem taka rekrutacje, gdzie odpowiadalem perfekcyjne i byl jeden h.. Nie pytalem dlaczego mnie odrzucili, ale nie zrobili tego ze wzgledu na poprawnosc odpowiedzi, ewentualnie moglem czegos nie dopowiedziec, tylko po prostu komus sie nie spodobalem ja, moje zachowanie albo h.. wie co innego. Jak masz kilka osob na rekrutacji to szansa, ze cie odrzuca jest jeszcze wieksza. Z praca jest jak z szukaniem odpowiedniej kobiety, szukasz dlugo i pelno cie odrzuci. Im bardziej wyluzujesz tym w zasadzie zwiekszasz swoje szanse. Ostatnio mialem kilkanascie rozmow na ktorych mnie odrzucili i jakos zyje. Odrzucili mi podwyzke ostatnie 3 razy, mimo ze koledzy dostawali. Takie zycie.

LukeJL napisał(a):

Inżynier Inżynieria biomedyczna spec. Informatyka medyczna - dużo rzeczy z informatyki, ale mniejszy nacisk na teorię programowania - tutaj nauczyłem się programować

A myślałeś o pracy w branży medycznej? Tam też potrzebują programistów, a takimi studiami pewnie byś zapunktował.

Nigdy nie trafiłem na takie ogłoszenia. Po prawdzie nigdy nie szukałem ogłoszeń tylko w tej branży, by coś odnaleźć, może i to byłoby warto... Niestety wszystko rozbija się o pieniądze :( Gdybym mógł zrobić to bym zrobił krok wstecz i poszedłbym do firmy, która programuje w najnowszych zasadach nawet na stanowisko juniora.

LukeJL napisał(a):

A poza tym... to wygląda trochę jakbyś miał mniejszą wiedzę niż można wywnioskować po latach doświadczenia (szczególnie ta druga praca, gdzie wynika, że pracowałeś 5 lat w jakimś JanuszSofcie, czyli 1 rok powtórzony 5 razy?).

Zgadzam się z Tobą. Najśmieszniejsze jest to, że firma międzynarodowa (USA), która oddziały i filie ma na całym świecie i klientów ma praktycznie na całym globie. Jak miałem rozmowę kwalifikacyjną, to miałem test + zadanie praktyczne - te było bardzo dobrze opisane + napisane testy jednostkowe, które miało przejść. Wyglądało na to, że firma korzysta i wspiera się najnowszymi rozwiązaniami i praktykami... Potem przyszedł kod.

LukeJL napisał(a):

W praktyce. Jak cię pytają o testy, to możesz się nauczyć robić testy (w jakimś konkretnym projekcie, czy to w pracy czy w swoim wolnym czasie). Jak cię pytają o wątki, to możesz poćwiczyć pracę na wątkach (i przy okazji załapiesz też teorię). Jak cię pytają o SOLID, to spróbuj stosować zasady SOLID we własnym pisaniu (albo je łamać i zobaczyć, czy to dobry pomysł). Na serio to wygląda tak jakbyś dopiero zaczynał programować, pomimo niby wieloletniego doświadczenia.

Właśnie takie podejście sprawiło, że jestem tu gdzie jestem... Po każdej rozmowie starałem się praktycznie przeskoczyć do zadanego tematu i takie skakanie uzmysłowiło mi, że znam wszystko, ale jednak nie do końca. A sama praktyka też nie pomaga w zapamiętaniu terminologii. I właśnie dlatego tu napisałem... Każda moja rozmowa kwalifikacyjna sprowadza się do tego iż jestem przepytywany z wycinka wiedzy z .NET na poziom wręcz eksperta. Nigdy z tego samego.

LukeJL napisał(a):

No ale w takim układzie po prostu musisz nadrobić braki. Nie ma jakiejś magicznej recepty, złotego kursu. Jest mnóstwo materiałów w necie, ale co z nich wyciągniesz, to już będzie zależało od ciebie.

Spróbuję zrobić co mogę... Dzięki za odpowiedź :)

zgrzyt napisał(a):

Powiem ci wprost, trafiasz na h.... rekrutacje. Aplikuj i wyluzuj. Wiedze sprawdzaja czesto, ale nie zawsze. Tam gdzie sprawdzaja wiedze i mecza cie pytaniami to zazwyczaj jest h.. dupa i cycki. Z wlasnego doswiadczenia ci powiem, ze nawet jak bedziesz dobrze odpowiadal to cie moga odrzucic. Ostatnio mialem taka rekrutacje, gdzie odpowiadalem perfekcyjne i byl jeden h.. Nie pytalem dlaczego mnie odrzucili, ale nie zrobili tego ze wzgledu na poprawnosc odpowiedzi, ewentualnie moglem czegos nie dopowiedziec, tylko po prostu komus sie nie spodobalem ja, moje zachowanie albo h.. wie co innego. Jak masz kilka osob na rekrutacji to szansa, ze cie odrzuca jest jeszcze wieksza. Z praca jest jak z szukaniem odpowiedniej kobiety, szukasz dlugo i pelno cie odrzuci. Im bardziej wyluzujesz tym w zasadzie zwiekszasz swoje szanse. Ostatnio mialem kilkanascie rozmow na ktorych mnie odrzucili i jakos zyje. Odrzucili mi podwyzke ostatnie 3 razy, mimo ze koledzy dostawali. Takie zycie.

Dzięki, jak okazuje się, że inni również tak mają jednak trochę pociesza, ale nadal muszę uzupełnić wiedzę :)

Na Twoim miejscu zacząłbym od przeczytania ze zrozumieniem: https://www.manning.com/books/c-sharp-in-depth-fourth-edition i problem z niewiedzą zniknie.Ewentualnie trochę już zakurzone: https://www.amazon.com/CLR-via-4th-Developer-Reference/dp/0735667454

Aktualnie próbuję zmienić pracę, jednak się za każdym razem odbijam na rozmowie. Za każdym razem jestem dopytywany o jakieś szczegóły z technologii, typu co to właśnie ten boxing i unboxing, czym jest stos i sterta, jakie mamy problemy, ryzyka przy pracy na wątkach, czy klucz w słowniku może być typem referencyjnym czy może być tylko prostym, jeśli może być typem prostym do w jaki sposób na nich pracować, jakie znam mechanizmy i biblioteki do testów, jakie znam rodzaje testów, czym testuję UI itd

Te pytania są powierzchowne, junior powinien znać na nie odpowiedź.

Nie ucz się na pamięć ani też będąc zaskakiwanym przez rekrutera.

Po prostu zacznij czytać dobre i interesujące książki, baw się nimi, eksperymentuj z kodem, a wiedza sama przydzie.

Jeśli to dla Ciebie zbyt wiele to zmień branżę. Nic na siłę.

Lukxxx napisał(a):

Na Twoim miejscu zacząłbym od przeczytania ze zrozumieniem: https://www.manning.com/books/c-sharp-in-depth-fourth-edition i problem z niewiedzą zniknie.

Ta pozycja naprawdę wygląda interesująco! Widzę, że fajnie usystematyzowana wiedza, może rzeczywiście to będzie taka baza, która mi pomoże poukładać wszystko w głowie :)

pprog123 napisał(a):

Te pytania są powierzchowne, junior powinien znać na nie odpowiedź.

Nie ucz się na pamięć ani też będąc zaskakiwanym przez rekrutera.

Po prostu zacznij czytać dobre i interesujące książki, baw się nimi, eksperymentuj z kodem, a wiedza sama przydzie.

Jeśli to dla Ciebie zbyt wiele to zmień branżę. Nic na siłę.

Tak, wiem i najbardziej mnie boli to, że tego nie znam. W sumie od początku zabawy z programowaniem stawiałem na praktyczne rozwiązania i tak się też uczyłem nowych rozwiązań. Coś nowego wyskakiwało, to sprawdzałem, np. tak miałem z wykorzystaniem zapytań LINQ i ich wydajnością względem zwykłych pętli. Potestowałem pewne zapytania, które widziałem w sieci, trochę je modyfikowałem i wiem co i kiedy użyć, ale jeśli ktoś się zapyta "dlaczego tak się dzieje" no to już leżę.

pprog123 napisał(a):

Jeśli to dla Ciebie zbyt wiele to zmień branżę. Nic na siłę.

Programowanie od zawsze mi się podobało i do teraz daje mi wiele radości jeśli robię coś nowego, tutaj troszkę bawię się dodatkowo w Unity (też w C#) tutaj desktop, a tutaj webApi. Cóż... może zacznę od pozycji C# in Depth, Fourth Edition i spróbuję uzupełnić wiedze do najnowszej wersji 9 i zobaczymy. Kto wie... może będę musiał zacisnąć cztery litery i przeboleć tyle by kredyt odpadł i zmienić branżę... Zobaczymy co przyniesie los.

Jeszcze raz dzięki @Lukxxx za pozycję :) Świecie przybywam ;)

jeśli ktoś się zapyta "dlaczego tak się dzieje" no to już leżę

i tu jest problem

O ile amatorowi to wystarczy to w pracy tak nie bardzo.

Jesli przykładowo nie umiesz wyjaśnić dlaczego tak progamujesz ani też wyjaśnić jak coś działa to jaki z Ciebie profesjonalista? Wtedy to bardziej artysta niż programista.

W pracy ludzie nie chcą niezrozumiałej sztuki. Oni chcą widzieć normalnego gościa, który zna się na temacie i który potrafi logicznie myśleć, bo z logiką da się dyskutować, bez niej to trzeba podziękować.

pprog123 napisał(a):

Jesli przykładowo nie umiesz wyjaśnić dlaczego tak progamujesz ani też wyjaśnić jak coś działa to jaki z Ciebie profesjonalista? Wtedy to bardziej artysta niż programista.
W pracy ludzie nie chcą niezrozumiałej sztuki. Oni chcą widzieć normalnego gościa, który zna się na temacie i który potrafi logicznie myśleć, bo z logiką da się dyskutować, bez niej to trzeba podziękować.

Masz rację, dlatego jestem wdzięczny za wszystkie porady i przede wszystkim pozycje, które umożliwią uzupełnienie i poukładanie wiedzy i może w wejście w to środowisko .NET jeszcze raz, tylko tym razem bardziej świadom :)

Bardzo się dziwię temu co tu niektórzy piszą w stylu "stosuję tylko tą funkcję i nie znam innych". Oczywiście nie chodzi o to byt znać każdą wbudowaną funkcję na blachę, mieć wszystkie frameworki w jednym palcu itp., ale jednak nie szczyciłbym się tym, że znam jedno rozwiązanie danego problemu, zawsze jest stosuję i jeszcze mi z tym dobrze.

Co do @Barqtos to mam wrażenie po tym co napisałeś, że nie jesteś pasjonatem (co nie jest niczym złym - nie każdy musi być pasjonatem w swoim zawodzie) i to sprawia, że nie masz "wbudowanej" chęci eksploracji. Znam kilku dobrych programistów, którzy tak mają i da się z tym żyć (zwłaszcza jak masz trochę talentu). Niestety faktycznie sprawia to, że na rekrutacjach wypadasz blado.

W krótkim terminie myślę, że najłatwiej to załatwić 2 rzeczami:

• lista/kurs na Udemy z rekrutacji w Twojej technologii. Lista pytań jest raczej zamknięta i łatwo się przygotować do niej jeśli masz ogólne pojęcie.
• na liście pojawi się trochę tematów bardziej złożonych - tutaj pomoże 1-2 dobre książki, które w takie tematy wchodzą i/lub pogłębienie tematu w sieci

Na dłuższą metę polecam dodatkowo zaprenumerować 1-2 branżowe czasopisma + jakiś podcast. Poświęcisz na to 2-4h w miesiącu i będziesz z grubsza na bieżąco z nowościami.

Ja sam pracuję w PHP - u nas sam język jest bardzo prosty, ale ceni się osoby z umiejętnościami pracy w dużym kodzie + wszechstronne (co wynika z relatywnie małych zespołów). Dlatego ja swój rozwój opieram o rozpoznawanie wielu tematów, tak aby potrafić dobrać narzędzia do zadania, orientować się trochę w dokeryzacji, chmurze, różnych dodatkach typu ElasticSearch, Redis, główne frameworki, ORM'y itd, nawet trochę Reacta i Angulara liznąłem. Niekoniecznie jest to dobra droga dla Ciebie, ale w PHP lepiej znać dużo różnych tematów niż być ekspertem w jednym i dlatego tak to u mnie wygląda.

W praktyce soje cele realizuję tak że mam abonament w jednym z wydawnictw, czytam miesięcznik branżowy, słucham 2 podcastów i wplatam jak najwięcej tematów w bieżące projekty. Np. teraz trochę wchodzę w DDD, mikroserwisy więc robię sobie na boku projekt, który przy okazji też przyda mi się w pracy. Jest to serwis do autoryzacji SSO - mały temat, ale piszę go w duchu DDD, naginam do niego framework (przy okazji muszę zatem dobrze wgryźć się w sam framework), bawię się ORM aby uzyskać różne mapowania Entity na bazę, rozpoznaje OpenAPI, potem będę testował kilka zabawek typowo pod kontenery typu automatyzację health-check. Takie mikro projekty są moim zdaniem bardzo fajnym sposobem na przetestowanie różnych koncepcji - nawet jeśli ich nigdy nie skończysz to dużo dają w kwestii zrozumienia różnych zagadnień. Oczywiście to jest już temat na "kolejne rekrutacje" i moja strategia jak zostać w siodle na dłużej.

Zupełnie nieprawda, w php też można być ekspertem w jednym frameworku jak i w js.
Jak coś jest do wszystkiego to jest do niczego.

hadwao napisał(a):

Co do @Barqtos to mam wrażenie po tym co napisałeś, że nie jesteś pasjonatem (co nie jest niczym złym - nie każdy musi być pasjonatem w swoim zawodzie) i to sprawia, że nie masz "wbudowanej" chęci eksploracji.

Ha, pasjonatem byłem i w duchu jestem, ale od urodzenia dziecka czasu brakło. Kiedyś sprawdzałem rzeczy by je poznać, dziś przeczytam jako ciekawostkę i niestety takie "przeczytanie" szybko wylatuje z głowy. Od początku tygodnia wertuję książkę C sharp in depth i staram się jednocześnie każdą "nowość", której nie znam lub znam słabo przetestować :) Można odnaleźć w tym radość, ale w aktualnej sytuacji dla mnie to już jak studia wieczorowe :D

hadwao napisał(a):

W krótkim terminie myślę, że najłatwiej to załatwić 2 rzeczami:

• lista/kurs na Udemy z rekrutacji w Twojej technologii. Lista pytań jest raczej zamknięta i łatwo się przygotować do niej jeśli masz ogólne pojęcie.
• na liście pojawi się trochę tematów bardziej złożonych - tutaj pomoże 1-2 dobre książki, które w takie tematy wchodzą i/lub pogłębienie tematu w sieci

Na dłuższą metę polecam dodatkowo zaprenumerować 1-2 branżowe czasopisma + jakiś podcast. Poświęcisz na to 2-4h w miesiącu i będziesz z grubsza na bieżąco z nowościami.

Książka jedna już jest. Zobaczymy co będzie dalej :) Spróbuję poznać Angulara 2 i może przymierzę się na pozycję FullStacka... zawsze w odwodzie mogę zostać tym elektrykiem ;)