Doczytałeś ty może pierwszy post a mianowicie ten fragment -> "rok doświadczenia" ?
Jeżeli po osobie z rocznym doświadczeniem oczekujesz biegłości z sieci, przynajmniej dwóch systemów budujących pewnie jeszcze kwestie security + java, spring. Do tego dokładasz, że taka osoba powinna znać dobrze dockera, kubernetesa i do tego jeszcze zachowanie JVM na dockerze może jeszcze ma znać różnice w zachowaniu Azula od Oracla? A to dopiero początek bo nawet nie tkneliśmy frontendu gdzie jest drugie tyle kwestii.
Rok doświadczenia w zarządzaniu CI/CD utrzymywaniu build serwerów - nie przesadzajmy, że tylko wyklikanie najprostszego pipeline z gotowych klocków, Bo to jest do opanowania w parę godzin, na zasadzie znalezienia odpowiednich guzików w UI. Ale faktycznie sensowne zarządzanie pipeline as code (pamiętajmy, że różne wersje np. TeamCity mogą mieć nieco różne API, warto trzymać rękę na pulsie), do tego konfiguracja serwera (jeśli self-hosted), build agentów (może trzeba sobie napisać własny Dockerfile dla agenta - zahaczamy o znajomość Dockera), ogarnięcie jobów żeby nie było problemów z docker-in-docker
, idealnie dobrze by było mieć doświadczenie z pisaniem pluginów.
Rok doświadczenia z dockerem / docker-compose - nie, że napiszesz na pałę Dockerfile i już pchasz do Dockerhub / Artifactory / ECR jakby jutra nie było, tylko umiesz wybrać odpowiedni base image do zadania, żeby obraz nie był zbyt ciężki, potrafisz w razie czego trochę odchudzić finalny obraz (w końcu jak się uzbierają setki artefaktów to te megabajty się kumulują), ogarniasz koncepcję multi-stage build, networking, volumes, zarządzanie obrazami i kontenerami. Compose też musisz napisać jak należy, a nie w ciemno i trzymać kciuki żeby jeden kontener nie wstał przed drugim do którego ma zależność. Dochodzą oczywiście kwestie security - spróbuj tylko przepychać secrety i klucze przez env, to zaraz ktoś je wyciągnie inspectem.
Rok doświadczenia z k8s - wiadomo, nie wystarczy wrzucić "jakiś" pod, deployment, service i ingress do YAMLa i wypchnąć. Dobrze by było umieć pracować z konsolą, dashboardami, wesprzeć się dodatkowymi narzędziami (np. helm). Umieć to skonfigurować tak, żeby dało się przeprowadzić upgrade bez downtime i jednocześnie nie wyżreć wszystkich dostępnych zasobów - przede wszystkim wiedzieć, jak może przebiegać taki upgrade, znać kilka rodzajów, umieć je konfigurować. Umieć przydzielać zasoby, skonfigurować readiness / liveness probes, podpiąć do wszystkiego monitoring etc. Umieć w skalowanie np. poprzez HPA. Jak już zahaczamy o temat k8s, warto też znać jakieś podstawowe wzorce/pojęcia które mogą się przewijać, umieć ich użyć np. dostawić sidecar, wiedzieć kiedy to się może przydać.
Rok doświadczenia z co najmniej jednym cloud providerem - umieć skonfigurować zasoby pod aplikację, aspekty security, dostępy, monitoring, alerty, może funkcje / lambdy zależnie od tego czego się używa, wszystko tak żeby "klałd" nie żarł dziesiątek tysięcy dolarów za hostowanie dev
a, perf
a i prod
a dla CRUDowej apki z 10k userów (bo to oczywiste, że taka apka koniecznie musi być w klałdzie - takie mamy czasy). Mile widziane certyfikaty.
Rok doświadczenia z Java + Spring - tutaj oczywiście mamy do czynienia ze stricte kodowaniem, a nie ogarnianiem CI i k8s i udawaniem, że to też się liczy do doświadczenia w programowaniu w Javie. Wiadomo, co tu dużo mówić - znajomość samego języka i bebechów frameworka, narzędzi deweloperskich i do debugowania, przydatnych bibliotek (jak choćby Jackson / Gson etc), obycie z maven / Gradle, dobrze by było znać w miarę dobrze JPA i Hibernate (ewentualnie co inne - JDBCTemplates, jooq, ale to może dyskfalifikować tu i tam, bo jednak musi być Hibernate), umieć rozwiązywać typowe problemy (podbijamy wersję zależności i nagle kontekst aplikacji nie wstaje, AOP czegoś nie łapie). Oczywiście, podobnie jak w poprzednich punktach przewija się nam aspekt security, znać OWASP top 10, wiedzieć skąd się może wziąć SQLi albo XSS vuln w mojej aplikacji, umieć się przed tym zabezpieczyć, idealnie coś-tam potestować choćby z palucha, ograniczać dostępy do zasobów tak żeby nawet w razie wycieku tokenów minimalizować straty, skonfigurować autentykację i autoryzację, najlepiej na kilka sposobów, znać różnice między popularnymi OAuth providerami np. Okta, Azure. Plus dokumentacja - zarządzanie Swaggerami i innymi takimi, wersjonowanie API etc.
Rok doświadczenia z bazami danych, skoro już jesteśmy przy JPA/Hibernate - dobra znajomość SQL i smaczków danego DBMS to podstawa, do tego tematy takie jak optymalizacja zapytań, indeksy (wiedzieć, kiedy jakiego użyć, jaki jest koszt), normalizacja / denormalizacja, wersjonowanie schemy i zarządzanie wersjami, migracje, orientowanie się w tematyce replikacji i partycjonowaniu bazy (i z czym się to wiąże), transakcje, różne poziomy izolacji. Dobrze by było mieć doświadczenie bojowe z jakimś NoSQL do porównania.
Rok doświadczenia w testowaniu - to jest temat rzeka sam w sobie. Testy jednostkowe, integracyjne, trzeba umieć pisać je dobrze - i znać narzędzia do testowania, umieć je odpowiednio zastosować, a nie tylko JUnit, Mockito, mockujesz klasę za klasą i do przodu. Nie mówiąc o testach API / e2e / wydajnościowych i tak dalej. W temacie narzędzi do testowania i klałda, prawdopodobnie przydatna będzie znajomość np. Wiremock, TestContainers i tym podobnych.
Na front-end się nie znam, więc nie będę się tu rozmieniał na drobne, przyjmijmy asekuracyjnie że na froncie wystarczy rok doświadczenia sumarycznie - jako plan minimum.
Oczywiście dla niektórych zagadnień można by skrócić kadencję do np. pół roku albo 3 miesięcy rzeczywistej pracy (robota z doskoku?), ale jeśli mówimy o roku to niech już będzie rok na wszystko - kto miał do czynienia z odpowiedzią "no ale Pan ma rok i 11 miesięcy a nie 2 lata" ten wie. Druga sprawa, że cały front sprowadziłem do "jednego" aspektu do opanowania, także trochę się nam to równoważy.
Podsumowując, nie jest źle - wystarczy tylko ok. 8 lat pracy i już można być całkiem sensownym juniorem z rocznym doświadczeniem w najbardziej kluczowych kwestiach.