Umiejętności potrzebne na pierwszą pracę jako Junior Java.

Hej od jakiegoś czasu uczę się samodzielnie javy i chcę w niedalekiej przyszłości próbować aplikować na juniora. Niestety jestem takim człowiekiem który uważa, że zawsze jeszcze nie czas i za mała wiedza (można powiedzieć, że jestem surowy wobec siebie). Może ktoś mi powiedzieć kiedy jest najlepszy czas aby zacząć starać się o prace, co konkretnie musi potrafić taki junior? Obecnie mam za sobą kilka projektów bardziej do szuflady może jeden nadaje sie do portfolio. Na dziś moje umiejętności to: podstawy javy w miarę ogarnięte, OOP tak samo, SQL podstawy, maven podstawy, GIT podstawy, styczność z testami w JUnit 5 mam i coś tam ogarniam podstawy i kilka testów napisałem. Ciągle się uczę wiec możliwe, że wiedza i umiejętności wzrosną jeszcze, wiem, że do ogarnięcia mam jeszcze Springa i Hibernate. Czy takie umiejętności wystarczą na szukanie pierwszej pracy?
Polecam patrzeć tylko na projekt LibraryManager reszta słabo wygląda.
https://github.com/LukaszCh233?tab=repositories

johnny_Be_good napisał(a):

Napiszesz sklep internetowy albo forum?

Czytasz mi w myślach chyba bo akurat już zacząłem projekt sklepu internetowego co prawda w samej javie i sql ale zawsze coś.

johnny_Be_good napisał(a):

A jak przeglądarka się łączy z tą javą? Aplikacje masz specjalną?

Nie bardzo wiem o co chodzi, to bedzie zwykły projekt konsolowy nie na stronie ani nic takiego.

Wrzuć repozytorium swoje z tym co już udało Ci się naskrobać a ludzie Ci powiedzą czy się nadajesz.

W 2023 roku bez podstawowej znajomości Springa na juniora raczej słabe szanse. Podstawa to jest umiejętność zrobienia CRUDa i ogarnianie co tam się dzieje.

Do tego dochodzi solidna znajomość Java SE. To jest nawet ważniejsze niż frameworki.

kixe52 napisał(a):

Wrzuć repozytorium swoje z tym co już udało Ci się naskrobać a ludzie Ci powiedzą czy się nadajesz.

W 2023 roku bez podstawowej znajomości Springa na juniora raczej słabe szanse. Podstawa to jest umiejętność zrobienia CRUDa i ogarnianie co tam się dzieje.

Do tego dochodzi solidna znajomość Java SE. To jest nawet ważniejsze niż frameworki.

Dodałem githuba.
Dzięki za rady, wiem, że spring to konieczność ale nie chce skakać po wszystkim na raz.

Na Twoim miejscu nieustannie bym aplikował na wolne stanowiska juniorskie i stażowe aż w końcu ktoś Cię wybierze. Im szybciej zaczniesz pracę, tym lepiej. Oblewając kolejne rozmowy i dostając czasem feedbacki możesz wiele się nauczyć i łatwiej będzie Ci na każdej kolejnej rozmowie. Ale kto wie, może po pierwszej rozmowie dostaniesz pracę?

Drzewiec napisał(a):

Na Twoim miejscu nieustannie bym aplikował na wolne stanowiska juniorskie i stażowe aż w końcu ktoś Cię wybierze. Im szybciej zaczniesz pracę, tym lepiej. Oblewając kolejne rozmowy i dostając czasem feedbacki możesz wiele się nauczyć i łatwiej będzie Ci na każdej kolejnej rozmowie. Ale kto wie, może po pierwszej rozmowie dostaniesz pracę?

Problem jest tylko taki, że trzeba sensowne CV a ja go nie mam a portfolio z jednym projektem to za mało no i jednak spring musi być chciaż podstawy i projekt z użyciem go.

1. Nie używałem nigdy SQLite ale tak się tego nie powinno robić. Jak nie chcesz używać frameworków to lepiej stworzyć swój skrypt tworzenia tabel i ich wypełniania w oddzielnym pliku sql i go ładować na starcie aplikacji.
   https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/database/Database.java

2. https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/library/BorrowBookRepository.java#L51
   Na takie coś powinieneś stworzyć oddzielne metody zajmujące się jedynie zapisem/odczytem do/z bazy danych. Może to być właśnie w repository. Ale reszta kodu robiąca coś przed/po zapisaniu do bazy powinna byś w jakimś serwisie (dodatkowa warstwa abstrakcji). Tam trzymamy logikę biznesową. A jak nie serwis, to na pewno rozdzielić to na kilka mniejszych metod.

3. https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/library/BorrowBookRepository.java#L51
   Staramy się nie pisać z lewej strony konkretnej implementacji interfejsu, a po prostu List<T> aby w przyszłości móc podstawić w razie potrzeby inną implementację.

4. Łapanie wyjątków tylko po to, żeby wyprintować coś na konsole to niezbyt dobre rozwiązanie.

5. https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/books/Book.java#L7 Używasz lomboka, dodałeś adnotację @Getter a resztę piszesz samemu? Nielogiczne.

6. Ogólnie w wielu miejscach robisz to samo, różnica jest jedynie w typie obiektu (nazwa klasy). Raz jest to ksiązka, raz user.

7. Jeśli nie chcesz się pakować od razu we frameworki ale chcesz używać SQLa w swojej aplikacji to porzuć SQLite i zainteresuj się np: jOOQ

8. Nie używamy camel casea w nazwach pakietów.

9. https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/test/java/booksTest/BookTest.java#L12 Co tutaj testujesz? @Getter z lomboka? :)

Tak szczerze to za dużo tutaj nie ma. Napisz to samo ale od nowa. Tylko tym razem lepiej to wszystko rozplanuj.
Zastosuj się do uwag powyżej i do innych której jeszcze pewnie otrzymasz w tym temacie.

Poza kodem w kontekście technicznym brakuje też funkcjonalności. Pusto jakoś w tym repo. Wymyśl coś więcej. A jeśli tematyka projektu na to nie pozwala, to zmień to :)

Swoją droga możesz to potraktować jako ćwiczenie i zrobić refactor w tym projekcie. Będziesz miał dzięki temu historię na gicie i potencjalna osoba techniczna podczas rekrutacji może zobaczyć jak wyglądała Twoja droga.

#############################################################

Drzewiec napisał(a):

Na Twoim miejscu nieustannie bym aplikował na wolne stanowiska juniorskie i stażowe aż w końcu ktoś Cię wybierze. Im szybciej zaczniesz pracę, tym lepiej. Oblewając kolejne rozmowy i dostając czasem feedbacki możesz wiele się nauczyć i łatwiej będzie Ci na każdej kolejnej rozmowie. Ale kto wie, może po pierwszej rozmowie dostaniesz pracę?

Tak tak, zamknij sobie drzwi do jedynych 10 firm na rynku przyjmujących juniorów, żeby za 6-12 misięcy jak poprawisz swoje umiejentości od razu wyrzucali Twoje CV do kosza.

kixe52 napisał(a):

1. Nie używałem nigdy SQLite ale tak się tego nie powinno robić. Jak nie chcesz używać frameworków to lepiej stworzyć swój skrypt tworzenia tabel i ich wypełniania w oddzielnym pliku sql i go ładować na starcie aplikacji.
   https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/database/Database.java

2. https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/library/BorrowBookRepository.java#L51
   Na takie coś powinieneś stworzyć oddzielne metody zajmujące się jedynie zapisem do bazy danych. Może to być właśnie w repository. Ale reszta kodu robiąca coś przed/po zapisaniu do bazy powinna byś w jakimś serwisie (dodatkowa warstwa abstrakcji). Tam trzymamy logikę biznesową. A jak nie serwis, to na pewno rozdzielić to na kilka mniejszych metod.

3. https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/library/BorrowBookRepository.java#L51
   Staramy się nie pisać z lewej strony konkretnej implementacji interfejsu, a po prostu List<T> aby w przyszłości móc podstawić w razie potrzeby inną implementację.

4. Łapanie wyjątków tylko po to, żeby wyprintować coś na konsole to niezbyt dobre rozwiązanie.

5. https://github.com/LukaszCh233/LibraryManager/blob/main/LibraryManager/src/main/java/books/Book.java#L7 Używasz lomboka, dodałeś adnotację @Getter a resztę piszesz samemu? Nielogiczne.

6. Ogólnie w wielu miejscach robisz to samo, różnica jest jedynie w typie obiektu (nazwa klasy). Raz jest to ksiązka, raz user.

7. Jeśli nie chcesz się pakować od razu we frameworki ale chcesz używać SQLa w swojej aplikacji to porzuć SQLite i zainteresuj się np: jOOQ

Tak szczerze to za dużo tutaj nie ma. Napisz to samo ale od nowa. Tylko tym razem lepiej to wszystko rozplanuj.
Zastosuj się do uwag powyżej i do innych której jeszcze pewnie otrzymasz w tym temacie.

Poza kodem w kontekście technicznym brakuje też funkcjonalności. Pusto jakoś w tym repo. Wymyśl coś więcej. A jeśli tematyka projektu na to nie pozwala, to zmień to :)

Swoją droga możesz to potraktować jako ćwiczenie i zrobić refactor w tym projekcie. Będziesz miał dzięki temu historię na gicie i potencjalna osoba techniczna podczas rekrutacji może zobaczyć jak wyglądała Twoja droga.

#############################################################

Drzewiec napisał(a):

Na Twoim miejscu nieustannie bym aplikował na wolne stanowiska juniorskie i stażowe aż w końcu ktoś Cię wybierze. Im szybciej zaczniesz pracę, tym lepiej. Oblewając kolejne rozmowy i dostając czasem feedbacki możesz wiele się nauczyć i łatwiej będzie Ci na każdej kolejnej rozmowie. Ale kto wie, może po pierwszej rozmowie dostaniesz pracę?

Tak tak, zamknij sobie drzwi do jedynych 10 firm na rynku przyjmujących juniorów, żeby za 6-12 misięcy jak poprawisz swoje umiejentości od razu wyrzucali Twoje CV do kosza.

Nie wiem co powiedzieć, nad tym kodem siedziałem dużo czasu historie można sprawdzić jak sie zmieniał. Mam mentora który pomaga mi w nauce i nadzoruje to jak pisze. Nie wiem ile masz doświadczenia i na jakim jesteś stanowisku ale domyślam sie, że na wysokim. Każdy mówi co innego jeśli pytam, jeden mówi że kod jest okej i nadaje sie do portfolio a ty jednak masz inne zdanie i jest to takie zmieszanie aktualnie. Pewnie obaj macie racje i każda rada jest przydatna wiec postaram sie wziąć je do siebie.

LukaszCh233 napisał(a):

nad tym kodem siedziałem dużo czasu historie można sprawdzić jak sie zmieniał.

Excluding merges, 1 author has pushed 5 commits to main and 5 commits to all branches. On main, 9 files have changed and there have been 19 additions and 109 deletions.

Ok, myślałem że wrzuciłeś to w 1 commicie, a masz ich kilka. Ale to dalej za mało.

Mam mentora który pomaga mi w nauce i nadzoruje to jak pisze.

Nie chcę go krytykować, ale jeśli on mówi, że kod jest ok to dziwne. Domyślam się, że doświadczenie w latach ma niemałe, więc tym bardziej podejrzane.

Nie wiem ile masz doświadczenia i na jakim jesteś stanowisku ale domyślam sie, że na wysokim.

Nie, jestem przeciętnym midem.

Każdy mówi co innego jeśli pytam, jeden mówi że kod jest okej i nadaje sie do portfolio a ty jednak masz inne zdanie i jest to takie zmieszanie aktualnie. Pewnie obaj macie racje i każda rada jest przydatna wiec postaram sie wziąć je do siebie.

Wyraziłem swoją opinię. Do tej pory myślałem, że jesteś samoukiem, ale jeśli napisałeś to pod okiem mentora to słabo... Popracuj nad tym więcej i się nie poddawaj. Powodzenia

kixe52 napisał(a):

LukaszCh233 napisał(a):

nad tym kodem siedziałem dużo czasu historie można sprawdzić jak sie zmieniał.

Excluding merges, 1 author has pushed 5 commits to main and 5 commits to all branches. On main, 9 files have changed and there have been 19 additions and 109 deletions.

Ok, myślałem że wrzuciłeś to w 1 commicie, a masz ich kilka. Ale to dalej za mało.

Mam mentora który pomaga mi w nauce i nadzoruje to jak pisze.

Nie chcę go krytykować, ale jeśli on mówi, że kod jest ok to dziwne. Wystalkowałem go na Linkedinie i doświadczenie w latach ma niemałe, więc tym bardziej podejrzane.

Nie wiem ile masz doświadczenia i na jakim jesteś stanowisku ale domyślam sie, że na wysokim.

Nie, jestem przeciętnym midem.

Każdy mówi co innego jeśli pytam, jeden mówi że kod jest okej i nadaje sie do portfolio a ty jednak masz inne zdanie i jest to takie zmieszanie aktualnie. Pewnie obaj macie racje i każda rada jest przydatna wiec postaram sie wziąć je do siebie.

Wyraziłem swoją opinię. Do tej pory myślałem, że jesteś samoukiem, ale jeśli napisałeś to pod okiem mentora to słabo... Popracuj nad tym więcej i się nie poddawaj. Powodzenia

Może po prostu zbyt wiele oczekujesz od mojego kodu, jestem początkującym i nie wszystko będzie idealne. Na pewno zrobiłem jakiś postęp a taki mentor to nie jest nic złego, zawsze jakoś nakieruje coś podpowie. Poddawać się nie zamierzam i będę sie rozwiać dalej dlatego tu jestem, żeby poznać opinie innych bo się zawsze przyda. Dzięki za udzielenie się na pewno wezmę rady do siebie i popracuje nad jakością :)

Ja nic nie oczekuję. Zapytałeś
Czy takie umiejętności wystarczą na szukanie pierwszej pracy?

więc na podstawie Twojego repo odpowiedziałem Ci, że nie. Na pewno nie w 2023.

Wystarczy, że zobaczyłem tylko nazwy projektów i już nie fatygowałem się dalej. Sorry bro. Czasy kiedy wystarczające były: wisielce, kamienie papiery i inne nożyce, czy todo listy... Już minęły. W żaden sposób nie wyróżniasz się na tle konkurencji, bo 1000 innych osób zrobiła te same projekty. Nie wyróżniasz przynajmniej na tle githuba. Z takimi projektami nawet bym tego gita nie pokazywał dalej, bo bardziej zaszkodzi niż pomoże.

@LukaszCh233: Nie jestem javowcem, ale wydaje mi się że standardem w kodzie korzystającym z baz danych jest użycie ORMów.
Dlatego, polecam zastosować jakąś bibliotekę - czy jak to się tam w javie nazywa - która to implementuje, ręczne pisanie kwerend do baz danych
to bardzo zła praktyka, chyba, że potrzebujesz mega wydajnego zapytania do złożonego problemu, ale to raczej 0.0001% wszystkich przypadków wysyłania zapytań.

Najpoważniejszy problem jaki tutaj widzę jest taki, że nie potrafisz podejść na spokojnie do oceny własnego kodu. Życzę powodzenia z takim podejściem przy core review (jeśli kiedykolwiek dostaniesz pracę).

Ziomeczku....
Piszesz o sobie:

Niestety jestem takim człowiekiem który uważa, że zawsze jeszcze nie czas i za mała wiedza (można powiedzieć, że jestem surowy wobec siebie)

A potem wrzucasz jakiś konsolowy projekt, z którego wynika, że ledwo ogarnąłeś trochę programowania w Javie, liznąłeś nieco SQL i gita i chcesz szukać roboty jako Junior Java Dev?
Jakbyś był surowy, to byś nie pisał posta z takim kodem....

Przeciętny student z randomowej uczelni na drugim roku ma kilka razy więcej wiedzy od Ciebie, bo go już przymusili do oddania paru projektów + miał labory z jakiegoś frameworka...

Kod Ci wypunktował kixe

Co do gita:

git add *
git add *
git add *
git add *

[...]

Add files via upload
Add files via upload

Eleganckie nazwy commitów :)

https://initialcommit.com/blog/git-commit-messages-best-practices - sekcja General Commit Message Guidelines
(pierwszy link z google, takie materiały znajdziesz też na yt, albo po polsku)

Nie mówię, że ten link to jakaś wyrocznia, ale przynajmniej poczytasz o dobrych praktykach + lepsze to niż "git add *"
W 99% w pracy spotkałem się, że ktoś pisze sam porządny tytuł (bez dłuższego komentarza)

W README masz napisane, że się "dowiedziałeś co to Equals i HashCode". Nie pisz takich rzeczy jeśli chcesz się chwalić gdzieś tym projektem, bo to są podstawy... wygląda jak byś odpalił tutek z Javy i poświęcił 3h a potem postanowił szukać roboty

Napisałeś, że poświęciłeś dużo czasu - wydaje mi się że będziesz musiał jeszcze poświęcić wielekrotnie więcej czasu ;)

W 2023 projekt konsolowy nie wystarczy aby znaleźć pierwszą pracę, jest mnóstwo darmowych materiałów do framewórków. Ogarnij dobrze SQL, gita, jakiś framework - Spring jest najpopularniejszy dla Javovców. Razem ze Springiem - ORM. Napisz parę projektów i jak zrobisz jakiś porządny (taki gdzie jest jakieś większe API i trochę skomplikowanej logiki, gdzie masz dobre testy) to wtedy zacznij wysyłać CV

MirasZelentToMójStary napisał(a):

Ziomeczku....
Piszesz o sobie:

Niestety jestem takim człowiekiem który uważa, że zawsze jeszcze nie czas i za mała wiedza (można powiedzieć, że jestem surowy wobec siebie)

A potem wrzucasz jakiś konsolowy projekt, z którego wynika, że ledwo ogarnąłeś trochę programowania w Javie, liznąłeś nieco SQL i gita i chcesz szukać roboty jako Junior Java Dev?
Jakbyś był surowy, to byś nie pisał posta z takim kodem....

Przeciętny student z randomowej uczelni na drugim roku ma kilka razy więcej wiedzy od Ciebie, bo go już przymusili do oddania paru projektów + miał labory z jakiegoś frameworka...

Kod Ci wypunktował kixe

Co do gita:

git add *
git add *
git add *
git add *

[...]

Add files via upload
Add files via upload

Eleganckie nazwy commitów :)

https://initialcommit.com/blog/git-commit-messages-best-practices - sekcja General Commit Message Guidelines
(pierwszy link z google, takie materiały znajdziesz też na yt, albo po polsku)

Nie mówię, że ten link to jakaś wyrocznia, ale przynajmniej poczytasz o dobrych praktykach + lepsze to niż "git add *"
W 99% w pracy spotkałem się, że ktoś pisze sam porządny tytuł (bez dłuższego komentarza)

W README masz napisane, że się "dowiedziałeś co to Equals i HashCode". Nie pisz takich rzeczy jeśli chcesz się chwalić gdzieś tym projektem, bo to są podstawy... wygląda jak byś odpalił tutek z Javy i poświęcił 3h a potem postanowił szukać roboty

Napisałeś, że poświęciłeś dużo czasu - wydaje mi się że będziesz musiał jeszcze poświęcić wielekrotnie więcej czasu ;)

W 2023 projekt konsolowy nie wystarczy aby znaleźć pierwszą pracę, jest mnóstwo darmowych materiałów do framewórków. Ogarnij dobrze SQL, gita, jakiś framework - Spring jest najpopularniejszy dla Javovców. Razem ze Springiem - ORM. Napisz parę projektów i jak zrobisz jakiś porządny (taki gdzie jest jakieś większe API i trochę skomplikowanej logiki, gdzie masz dobre testy) to wtedy zacznij wysyłać CV

Ja nie mam zamiaru aplikować do żadnej roboty aktualnie, moja wiedza jest totalnie podstawowa. Regularnie ucze się może z 4 miesiące, wiec na pewno nie mogę sobie zarzuci, że się nie staram. Każdy jakoś zaczynał i nie wstydze się, że pokazałem tu swój kod bo przez ostanie miesiące zrobiłem jakiś progres. Jest dużo do poprawy i do nauki ale na to potrzeba czasu.

Escanor16 napisał(a):

Najpoważniejszy problem jaki tutaj widzę jest taki, że nie potrafisz podejść na spokojnie do oceny własnego kodu. Życzę powodzenia z takim podejściem przy core review (jeśli kiedykolwiek dostaniesz pracę).

Podbiję tą odpowiedź i zachęcam do wzięcia jej sobie do serca. Dostaję czasem na review ogrom komentarzy które czasem dotyczą np. zbędny white-space(np.enter) - i przez takie coś mój kod nie przejdzie i sporo mi zajęło przyjęcie do świadomości ze spokojem, że faktycznie - kod może wyglądać lepiej i jak się te komentarze złoży w całość to ma to zazwyczaj sens :)

Natomiast co do głównego wątku, ostatnie przechodziłem tą ścieżkę i zostałem java developerem, wypunktuję rzeczy które gdybym je umiał to moim zdaniem - wtedy nazwał bym się solidnym junior java developerem (ja się dostałem głównie przez to, że całkiem spoko ogarniam springa, core javy oraz bardziej niż spoko algo i struktury danych), ale to po kolei:

Do pisania kodu:

1. core javy z naciskiem na streamy, lambdy, collection framework i pochodne oraz przede wszystkim rozumienie tych struktur np. jak działa TreeMap oraz HashMap. Jak collection framework jest napisany (po co jest iterator, interfrajs Iterable jaką role to odgrywa a implementacji struktur), multithreading czyli runnable, callable, wyżej poziomowo ExecutorFramework oraz JoinForkFramework(w sumie to nie jestem pewien czy tak to się nazywa w JoinFork który wszedl od javy 8) (mnie sporo pytali chociaż nie używam...)
2. lombok aby nie pisać boilerplate kodu ale z umiarem, aby tych annotacji nie było więcej niż faktycznie kodu...
3. niemutowalność, zachęcam do zaprzyjaźnienia się z recordami
4. jak pracować z plikami w javie
5. warto coś wiedzieć o JDBC

Do testów:

1. jUnit
2. Mockito
3. Naucz się pisać dobrze testy i najlepiej stosując dobre praktyki, rozdzielaj poszczególne części testu na to co się w nich dzieje typu przygotowanie obiektów, wykonanie operacji, zrobienie assercji

Framework:

1. spring boot <- wiadomo, jak pisac backend, wstrzykiwanie obiektów
2. spring data jpa <- jak pracować z bazą danych + moim zdaniem obowiązkowo transakcje, warto w samo jpa wejść i zrozumieć co się tam dzieje, moim zdaniem rozwojowe
3. spring web <- jak napisać cruda ze wszystkimi ważnymi metodami HTTP i generalnie, nauczyć się o Rest ile się da oraz o samym protokole HTTP

Dookoła :

1. koniecznie docker + docker compose
2. koniecznie git

Dodatkowy plus:

1. jakis system do kolejkowania np. kafka bądź rabbitMq
2. jakaś baza nosql

Bazy danych:

1. poznać jak najwięcej o jakiejś bazie danych, postgres ma spoko dokumenację

MateInf napisał(a):

Escanor16 napisał(a):

Najpoważniejszy problem jaki tutaj widzę jest taki, że nie potrafisz podejść na spokojnie do oceny własnego kodu. Życzę powodzenia z takim podejściem przy core review (jeśli kiedykolwiek dostaniesz pracę).

Podbiję tą odpowiedź i zachęcam do wzięcia jej sobie do serca. Dostaję czasem na review ogrom komentarzy które czasem dotyczą np. zbędny white-space(np.enter) - i przez takie coś mój kod nie przejdzie i sporo mi zajęło przyjęcie do świadomości ze spokojem, że faktycznie - kod może wyglądać lepiej i jak się te komentarze złoży w całość to ma to zazwyczaj sens :)

Natomiast co do głównego wątku, ostatnie przechodziłem tą ścieżkę i zostałem java developerem, wypunktuję rzeczy które gdybym je umiał to moim zdaniem - wtedy nazwał bym się solidnym junior java developerem (ja się dostałem głównie przez to, że całkiem spoko ogarniam springa, core javy oraz bardziej niż spoko algo i struktury danych), ale to po kolei:

Do pisania kodu:

1. core javy z naciskiem na streamy, lambdy, collection framework i pochodne oraz przede wszystkim rozumienie tych struktur np. jak działa TreeMap oraz HashMap. Jak collection framework jest napisany (po co jest iterator, interfrajs Iterable jaką role to odgrywa a implementacji struktur), multithreading czyli runnable, callable, wyżej poziomowo ExecutorFramework oraz JoinForkFramework(w sumie to nie jestem pewien czy tak to się nazywa w JoinFork który wszedl od javy 8) (mnie sporo pytali chociaż nie używam...)
2. lombok aby nie pisać boilerplate kodu ale z umiarem, aby tych annotacji nie było więcej niż faktycznie kodu...
3. niemutowalność, zachęcam do zaprzyjaźnienia się z recordami
4. jak pracować z plikami w javie
5. warto coś wiedzieć o JDBC

Do testów:

1. jUnit
2. Mockito
3. Naucz się pisać dobrze testy i najlepiej stosując dobre praktyki, rozdzielaj poszczególne części testu na to co się w nich dzieje typu przygotowanie obiektów, wykonanie operacji, zrobienie assercji

Framework:

1. spring boot <- wiadomo, jak pisac backend, wstrzykiwanie obiektów
2. spring data jpa <- jak pracować z bazą danych + moim zdaniem obowiązkowo transakcje, warto w samo jpa wejść i zrozumieć co się tam dzieje, moim zdaniem rozwojowe
3. spring web <- jak napisać cruda ze wszystkimi ważnymi metodami HTTP i generalnie, nauczyć się o Rest ile się da oraz o samym protokole HTTP

Dookoła :

1. koniecznie docker + docker compose
2. koniecznie git

Dodatkowy plus:

1. jakis system do kolejkowania np. kafka bądź rabbitMq
2. jakaś baza nosql

Bazy danych:

1. poznać jak najwięcej o jakiejś bazie danych, postgres ma spoko dokumenację

Dzięki wielkie, takiej odpowiedzi trzeba mi było :)

Tak jak napisał kolega MateInf wyżej. Niestety dla programistów wchodzących w tym roku na rynek nie jest obecnie kolorowo przez to, że w ubiegłym roku były rekordowe przyjęcia - firmy w panice o braki kadrowe naprzyjmowały tyle ludu, że zanim wykorzystają to co mają i będą znowu mocno zatrudniały może minąć z rok czy półtora.

Java to już przeżytek, zacznij uczyć się Pythona tak jak Robert ;)

A tak na serio, to po prostu zacznij uczyć się Springa i wszystko się wyjaśni. Nie przejmuj się tym, że jesteś "nie gotowy". Po prostu zacznij.

Było milion razy używaj opcji szukaj... a nie czekaj to nie elektroda xD

A na poważnie:

• java (z naciskiem na ficzery typu streamy itp)

• spring boot

• hibernate

• sql

• testowanie jednostkowe / integracyjne

• rest / soap

• docker

• git (z uwzględnieniem dobrych praktyk min. w kwestii pisania commit message jak już ktoś napisał)

• OOP (ale takie prawdziwe z naciskiem odzwierciedlania realnego świata za pomocą obiektów -> bogaty vs anemiczny model danych)

• podstawowe koncepcje związane z architekturą jak np. jej rodzaje typu architektura warstwowa, package per feature czy architektura heksagonalna.

  To dla mnie totalny must have jeśli chodzi o juniora.
  Wiadomo, te punkty to worki bez dna i należy wyczuć jak głęboko trzeba je poznać.

Jeśli jesteś na etapie aplikacja cli w czystej javie to imho dla mnie dużo zbyt wcześnie.

btw: @LukaszCh233 rzuciłem okiem na apkę dot. biblioteki i odpowiedź na Twoje pytanie brzmi: nie, to jeszcze nie ten czas abyś aplikował.
Jak chcesz iść dalej to rzuć okiem np. na to https://www.udemy.com/course/spring-pl/ a potem na to: https://www.udemy.com/course/architektura-java/

RequiredNickname napisał(a):

To dla mnie totalny must have jeśli chodzi o juniora.
Wiadomo, te punkty to worki bez dna i należy wyczuć jak głęboko trzeba je poznać.

Uśmiałem się :-) Ilu juniorów zatrudniliście w ostatnim czasie?

Ostatnio przepytywałem kandydatów do projektu (nie juniorów) i z moich doświadczeń trudno znaleźć gości spełniających poniższe wymagania:
o znajomość Javy na poziomie funkcjonalności Java 8+
o zrozumienie działania Executor Service, Futures
o Java Streams API ( map/reduce/collectors ), podstawowe rozumienie interfejsów funkcyjnych
o podstawowe rozumienie concurrent collections

@yarel: ja nie rekrutuje juniorów (tzn w ogóle nie rekrutuje) i bynajmniej nie wymagałbym od takiej osoby aby mi walnęła monolog o streamach ale jakieś podstawowe przypadki użycia jak map(), peek() czy wspomniany collectors w stylu toList() czy kojarzenie, że streamy są leniwe to czemu nie? To są podstawowe informacje z pierwszego lepszego tutoriala o streamach.

Dla kogoś kto się faktycznie interesuje jako tako programowaniem wydaje mi się, że (po łebkach bo po łebkach) można by na każdy z tych tematów pogadać i osobiście gdyby mi ktoś nakreślił taką listę tematów w czasach jak szukałem pierwszej pracy to byłbym wyłącznie wdzięczny.

A to, że midzi tego wciąż nię ogarniają to cóż xD

O juniora Java oczekiwałbym znajomości Java w pierwszej kolejności. Ogarnięcie języka na poziomie któregoś certified java developer daje dobre podstawy.
Przy starcie do korpo do języka trzeba sobie dołożyć Spring'a i Hibernate (JPA).
Warto też nie robić wielkich oczu jak ktoś zapyta o REST/JSON.

Każda firma ma inne standardy czego oczekują od Juniora ale podstawą jest chyba to że będą od Ciebie dostawali więcej wartości dodanej niż w Ciebie zainwestują. Nie może być tak że zadanie, które wykonujesz będzie zjadało więcej czasu na konsultacje z senior dev'em niż temu senior dev'owi zajęłoby wykonanie go samodzielnie.

U mnie junior java powinien być wstanie samodzielnie napisać jakąś małą prostą mikrą usługę w Spring wystawiającą REST API i łączącą się z jakąś bazą danych zgodnie z obowiązującymi standardami / konwencjami. Powinien też mieć jakąś podstawową wiedze o bazach danych, komunikacji sieciowej i wzorcach projektowych. Zazwyczaj takową wykazują ludzie, który 2-3 lata intensywnie programowali hobbystycznie / akademicko zanim zatrudnili się jako Junior.

Tylko jeden projekt ma testy automatyczne? Czemu nie wszystkie?

Bo dopiero na tym projekcie uczyłem się pisać testy :)

LukaszCh233 napisał(a):

Bo dopiero na tym projekcie uczyłem się pisać testy :)

To lepiej nie pisz ich od czapy, tylko znajdź kgoos kto da Ci dobry feedback czy testy które piszesz są okej, czy może jednak są inwalidą.

Co do testów to polecam tę pozycję:
https://lubimyczytac.pl/ksiazka/3861230/zle-testy-dobre-testy