Odnośnie samego CV to w sumie jakbym coś takiego dostał to nie wiedziałbym na jaką pozycję aplikujesz. Masz wpisane jakieś GIMPy, Sony Vegas, programowanie PLC, obslugę office, 7 języków programowania (zwykle jak coś takiego się dostaje to nie wiadomo który znasz produkcyjnie, raczej nie zdarzają się osoby które dobrze znają ekosystem więcej niż 2, 3 języków) - pierwsze co bym zrobił to po kolei:
- tytuł informatyk/programista - jak zaaplikujesz na konkretną pozycję to i tak będzie wiadomo
- wykształcenie niżej niż umiejętności, bo niesie niższa wagę
- język wrzucić w umiejętności
- wywalić te wszystkie rzeczy z edycją grafiki, video, kontrolerami PLC, office, eclipsea - praktycznie z niczym tutaj raczej się w branży nie spotkasz
- egzaminy i szkolenia w tej branży wnoszą tyle co nic, też wyjebać
- wybierz ze 2, 3 projekty które są związane z technologią związaną z pracą którą aplikujesz
- sam profil githubowy wrzuć gdzieś na górę
Co do projektów - jak patrzy się na kod kandydata, to szuka się powodów dla którego chce się takiej osobie pozwolić pisać produkcyjny kod:
- rozdziel osobne projekty na osobne repozytoria, tak jak bozia kazała
- jeśli używasz githuba, to nie traktuj tego jako snapshot swojej pracy tylko faktycznie go używaj przy pisaniu; taka historia commitów plus jedno repo i wersja w katalogach mówi mi tyle że praktycznie nie znasz gita ani githuba: https://github.com/BartoszKonkol/projects/commits/master
- projekty które ktoś chce zobaczyć powinny mieć README.md które mówi mi co to jest, po co to jest, jakie ciekawe smaczki można zobaczyć, jak to odpalić
- projekty powinno dać się zbudować jedną komendą którą jest w stanie wklepać osoba o ograniczonej zdolności mentalnej gdy jest najebana w trzy d**y. Do projektów javowych użyj mavena, gradle, cokolwiek. Odpalanie z IDE nie jest akceptowalne bo ludzie mają różne konfiguracje a i build servery zwykle nie mają Xów
- fajnie by było jakby projekt miał testy - wiadomo że projekty personalne nie będą mieć tak rygorystycznych testów jak kod produkcyjny, ale jakieś testy być powinny. Chociażby jakieś wysokiego poziomu e2e albo integracyjne, ot tak żeby było wiadomo że jesteś świadom ich istnienia i że jesteś w stanie kilka napisać.
- bonusem jest u juniora jak build i odpalenie testów dzieje się automatycznie przy pomocy jakiegoś build servera (np na githubie możesz podpiąć sobie travisa za free)
Co do samego kodu to wierzę że on jakoś działa, ale wygląda bardzo chaotycznie. Moim zdaniem powinieneś popracować trochę nad czytelnością, bo np za takie coś bym rozstrzelał: https://github.com/BartoszKonkol/projects/blob/master/EXP/2018/Explory.java#L72
Tylko na przykładzie powyższej metody - dzieje się zbyt dużo rzeczy jak na jedną metodę. Tak w c**** za dużo - ma ponad 400 linii!. Linia 340 ma 16 levelów indentu! 'case "3"' g**no mi mówi na temat tego co to ma robić. Niespójne użycie nawiasów, jakiś boolean z errorem, zhardkodowane ścieżki, magiczne splity. Gdybym zobaczył taki kod to bym się bardzo, bardzo zastanawiał, czy nie lepiej wziąć jakiegoś studenta.
Widać że dużo robisz we w miarę młodym wieku, ale spróbuj to uprofesjonalnić. Rozbić logikę na jakieś spójne części. Sądzę że jak poświęcisz na to chwilę czasu to będziesz lepszym kandydatem niż większość z uwagi chociażby na to że widać że w jakiś sposób programowanie cię interesuje. Postaraj się skupić na jakiejś jednej ścieżce (zamiast na wszystkim na raz) i dowieźć na niej jakieś kompletne i profesjonalnie wyglądające produkty.