Java - pytania rekrutacyjne mid/senior

Przez ostatnie 3 miesiące byłem na wielu rozmowach rekrutacyjnych na Java Dev.
Poniżej przesyłam zestaw pytań, które zapamiętałem i spisałem może komuś się przyda ;)

1. Standardowe pyanie: Opowiedz w jakich projektach uczesniczyłeś, jakich technologii używałeś itp.
2. Jak działa JIT? Czy ma jakieś wady?
3. Do czego służy adnotacja @PostConstruct
4. Wymień sposoby wstrzykiwania zależności. Jakiego sposobu używasz i dlaczego?
5. Co to jest hermetyzacja?
6. Jakie rzeczy weszły z Java11. Jakich używałeś?
7. Kryptografia z kluczem publicznym vs prywatnym. Czym się różni i, która metoda jest używana w TLS?
8. Jak byś napisał metodę kontrolera do usunięcia wielu użytkowników?
9. Rest vs Soap
10. Mikroserwisy vs Monolity
11. Do czego służą indeksy i jakie znasz?
12. Zasady SOLID, IoC, Dependency Injection
13. Mamy 2 serwisy każdy z nich ma swoją bazę. Jak uzyskać spójność / transakcyjność
    gdy jeden wywołuje drugi jakie znasz patterny?
14. Dlaczego BigDecimal jest lepszy od double to przechowywania wartości pieniężnych?
    Dlaczego double nie jest precyzyjny?
15. Do czego służy BindingResult w Springu?
16. Wymień poziomy izolacji transakcji i wyjaśnij jak działa jeden z nich?
17. Adnotacja @Transactional jakie ma właściwości / co można ustawić?
18. Jak walidować przychodzące requesty w REST w Springu? Jaki błąd wystąpi
    gdy podamy stringa zamiast inta?
19. Jak zabezpieczyłbyś api restowe?
20. Jak przechowywać hasła w bazie danych? Jak działa bcrypt?
21. Jakie znasz zalety/wady stream api w Java?
22. Jak działa protokół HTTP? Jakie są metody?
23. Kiedy wybrałbyś rozwiązanie przechowywania danych
    w oparciu o relacyjną bazę danych a kiedy NoSQL? Jakie
    brałbyś kryteria pod uwagę?
24. Model pamięci w Java. Jakie znasz Garbage Collectory? Po co one są?
25. Jak działa HashMap/ConcurrentHashMap w środku?
26. Komunikacja z zewnętrznymi usługami. Podejście do obsługi błędów
27. Typy ataków webowych np. xxs,csrf wymień i objaśnij jeden z nich

Wszystkie tematy (poza Java 11 i rozproszoną baza danych w jednej aplikacji) mialem poruszone na studiach inżynierskich, i uważam że pytania naleza do puli juniora, który już samodzielnie potrafi robić taski.

Damian Pawelec napisał(a):

Wszystkie tematy (poza Java 11 i rozproszoną baza danych w jednej aplikacji) mialem poruszone na studiach inżynierskich, i uważam że pytania naleza do puli juniora, który już samodzielnie potrafi robić taski.

Na juniora zdecydowanie nie, na regulara są ok, na seniora te pytania to za mało.

Szkoda, że te pytania za wiele nie sprawdzają. Ktoś kto z tymi problemami nigdy nie pracował jest w stanie na te pytania odpowiedzieć, o ile powtórzy/uzupełni sobie teorię. Dlatego nie lubię takich rozmów. Tak samo teraz są bardzo popularne pytania z patternów mikroserwisowych. Kumpel co pracował kilka lat tylko i wyłącznie z monolitami bezproblemowo odpowiedział na pytania typu co to jest SAGA, co to CQRS, co to circuit breaker, rate limiter, ... Bo jest masa pytań z odpowiedziami dostępnych w internecie. Tylko co to ma sprawdzić - czy kandydat wykuł jakieś regułki, a na oczy tego nie widział?

Fajne są pytania na myślenie albo takie, które sprawdzają jak rozwiążesz problem lub jakie problemy spotkałeś w karierze. Wolę zapytać kogoś co zrobić, gdy SQL query wykonuje się bardzo długo (indeksy, excution plan, zmiana strategii lockowania, ...) niż zadać pytanie co to jest indeks - bo duża szansa, że ktoś nie ma z tym w ogóle doświadczenia i nie będzie wiedział w praktyce nic, ale wyśpiewa mi piękną regułkę...

Na juniora zdecydowanie nie, na regulara są ok, na seniora te pytania to za mało.

Jakieś przykłady pytań na seniora?

lookacode1 napisał(a):

Na juniora zdecydowanie nie, na regulara są ok, na seniora te pytania to za mało.

Jakieś przykłady pytań na seniora?

To chyba od firmy zależy, bo można powymyślać cokolwiek. Jak brałem udział w rekrutacjach na seniora, to część pytań można równie dobrze zadać na rolę juniora/mida, niektóre pytania były zupełnie bez sensu, a niektóre rozmowy były chyba głównie po to, żeby zobaczyć jak się ze mną gada, czy będzie się dało ze mną normalnie współpracować i nie miały w ogóle zbyt wielu jakichś wybitnie technicznych pytań : D. Natomiast techniczne umiejętności były czasem weryfikowane poprzez przeglądanie moich wypocin w internecie (github/stackoverflow/blog/itp.)

Zadajemy niektóre z tych pytań na początku rozmowy. Jeżeli ktoś nie zna podstaw, to po co tracić czas na resztę tej przygody? Później pogłębiamy. Z ciekawości, w wielu wypadkach wystarczy lekko inaczej zadać pytanie i zaczynają się problemy. Przykładowo, po prostych pytaniach np. o wzorce projektowe jest całkiem nieźle. Po zadaniu pytania

Masz potrzebę monitorowania zmian w dowolnej implementacji List, przez jeden lub wiele obiektów, jak rozwiążesz taki problem?
Zaczyna się jazda.

Kolejny przykład, po popisie wiedzy na temat GC, edenach, survivors itp. pada pytanie

Jakie warunki muszą być spełnione, żeby GC nie mógł skasować obiektu, lub ich grupy trzymającej wzajemne referencje?

Okazuje się, że całkiem spora liczba kandydatów okazuje się nie wiedzieć o istnieniu GC roots

Z drugiej strony, jeżeli się zatrudnia seniora, to nie ma sensu iść w szczegóły. Programowanie nie polega na pamięciowym opanowaniu pełnej specyfikacji języka. Sensu pytania o jakieś szczegóły frameworka (np. Spring) kompletnie nie widzę.

Na juniora zdecydowanie nie, na regulara są ok, na seniora te pytania to za mało.

Na regulara ok, ale na seniora to akurat za duże wymagania. Zaufajcie, znam trochę seniorów.

Ja bym na pytaniu 3. zaczął toczyć pianę z ust i odpadł, a byłem kiedyś seniorem.

jarekr000000 napisał(a):

Na juniora zdecydowanie nie, na regulara są ok, na seniora te pytania to za mało.

Na regulara ok, ale na seniora to akurat za duże wymagania. Zaufajcie, znam trochę seniorów.

Ja bym na pytaniu 3. zaczął toczyć pianę z ust i odpadł, a byłem kiedyś seniorem.

O, to już mam pytanie na seniora: Co się stanie jak damy adnotację PostConstruct i PreDestroy na metodzie jednocześnie i co się stanie jak zamienimy te adnotacje kolejnością?
I pytanie bonus: Ile adnotacji na metodzie trzeba dodać, żeby podnieść ciśnienie userowi @jarekr000000, a ile adnotacji wyprowadzi go z równowagi? xD

Pytanie 11 zamieniłbym na "kiedy nie należy dodawać indeksów" ew. "co zrobić gdy Twoje zapytanie nie mieści się na 5 ekranach".
Pytanie 16 jest trochę za łatwe, zmieniłbym na "Co to jest phantom read i jak powinniśmy się przed tym zabezpieczać".

jarekr000000 napisał(a):

Ja bym na pytaniu 3. zaczął toczyć pianę z ust i odpadł, a byłem kiedyś seniorem.

Czekałem kto odpowie nia pytanie 3. jako pierwszy i się nie zawiodłem :D w zasadzie to po pytaniu 3. przestałem czytać listę ciesząc się że mnie to już nie dotyczy :P
BTW moja odpowiedź na pytanie 3. to Ta adnotacja służy do psucia kodu. Dziękuję, nie chce już u panstwa pracować (No chyba że mają naprawdę wysoki dodatek za pracę w szkodliwych warunkach, to mogę wytrzymać rok w

na seniora lista pytań nie ma zasadniczo sensu

senior ma "umieć zrobić wszystko samodzielnie" w obrębie tej firmy w której idzie rekrutacja, więc pytasz o technologie które są tu używane - senior powinien odpowiedzieć na pytanie o każdy szczegół in-house stacka (jeśli nie umi to nie jest to senior w obrębie tego housa, może gdzie indziej tak - np. w poprzedniej firmie, ale nie tu)

każdy senior wie też że nie wie wszystkiego (wie jak zajebiście szerkiem i głębokim tematem jest IT) i nie udaje wszystkowiedzącego - dlatego trzeba jeszcze sprawdzić jak reaguje na pytania trudne, najpewniej pytania o to "jak zrobiłby x mając y oraz będąc ograniczony z"

senior ma "umieć zrobić wszystko samodzielnie" w obrębie tej firmy

Raczej działa klasyka:

• junior musi wiedzieć wszystko to co jest w google
• mid musi umieć znaleźć wszystko co potrzebne w tym google
• senior musi wiedzieć jak otworzyć wyszukiwarkę
• a architekt musi wiedzieć jak znaleźć seniora

Czyli jak ktos nie zna Springa nie nadaje sie na Java Seniora? :O

Czyli jak ktos nie zna Springa nie nadaje sie na Java Seniora? :O

Czy ktoś w ogóle zna Springa (poza Juergenem Hoellerem)?

jak ktoś nie zna springa ale w tej firmie nie ma springa to wciąż może być seniorem

albo

jak ktos nie zna springa ale jest ogarniety (po 15 minutach z czlowiekiem na interview mozesz to ocenic) to i tak moze byc seniorem bo ogarnie szybciej i lepiej niz ktos kto "zna" springa

@WhiteLightning: to tak jakbyś zapytał czy jak ktoś nie zna Excela lub CSV to może być seniorem.

@vpiotr: ja przez kilkanascie lat pracy zasze trafiam do projektow w Javie gdzie Springa ani Spring Boota po prostu nie ma. (poza jednym projektem).

W Polsce Java Developer jak nie zna Springa to raczej naprawdę krucho i współczuję.

kevin_sam_w_domu napisał(a):

W Polsce Java Developer jak nie zna Springa to raczej naprawdę krucho i współczuję.

Jak jeszcze mnie to interesowało to 10% ofert było bez springa, EJB i hibernate. To dalej duża pula z której można wybierać

kevin_sam_w_domu napisał(a):

W Polsce Java Developer jak nie zna Springa to raczej naprawdę krucho i współczuję.

Mylisz pojecia "programista" i "operator annotacji" (wzglednie, jesli jeszcze ktos uzywa, "operator xml").

@eleventeen: No ale powoli tak wygląda programowanie w Javie, że musisz "sklejać" wiele technologii na raz adnotacjami i wiedzieć też jak to "posklejać". Sam robię w Javie i masz rację, tutaj nazwałbym się bardziej po 4 latach jako operator frameworka, ale no pieniądze są spoko. Druga kwestia jest taka, że rynek jest jaki jest i w cenie są wyrobnicy, a nie goście co potrafią w CPP robić competitive programming. Choć tym drugim, no właśnie bliżej do bycia "programistą".

@eleventeen: Bez przesady, to, że adnotacje są bardzo nadużywane i często wyzwalają jakąś bardzo dziwaczną magię nieosiągalną "normalnymi metodami", to nie znaczy, że to sperma szatana. Moim zdaniem problem leży nie w tym, że ktoś używa adnotacji, tylko w tym, że nie wie co one robią i to na poziomie samej dokumentacji. Fakt, że Spring wybitnie prowokuje takie olewanie, przez wprowadzenie do kilku sensownych adnotacji kilkudziesięciu innych, które jedyne co robią, to scalają kilka innych pod niewiele mówiącą nazwą.

U większości "programistów Spring" pytanie o opisanie mechanizmu działania DynamicProxy, powoduje wyjście oczu z orbit, czyli, często przez lata, piszą kod, którego nie rozumieją.

kevin_sam_w_domu napisał(a):

No ale powoli tak wygląda programowanie w Javie, że musisz "sklejać" wiele technologii na raz adnotacjami i wiedzieć też jak to "posklejać".

A to zalezy co sie robi. Mi sie zdazylo pisac ML, rozne serwery, wiekszosc nie dotykajace sie do springa, lata temu aplety, apki androidowe i pare innych rzeczy by sie znalazlo. Zgadza sie, wiekszosc pracy w javie to jakis paskudny web, i do tego w springu, ale nie zmienia to faktu ze java != spring.

piotrpo napisał(a):

Moim zdaniem problem leży nie w tym, że ktoś używa adnotacji, tylko w tym, że nie wie co one robią i to na poziomie samej dokumentacji.

Nie wiem co masz na mysli, ale przypomnialo mi sie jak cos probowalem zrobic w springu na podstawie dokumentacji. No i kompletnie nie dziala. Zagladam na stackoverflow i tam rozwiazanie kompletnie sprzeczne z dokumentacja. Dziala. I jaka ja mam gwarancje ze np. w nowszej wersji springa nie przestanie dzialac? Jaka ja mam w ogole gwarancje ze to dziala dla kazdej sytuacji poza ta ktora przetestowalem? To ma byc profesjonalizm? To tak jak by napisac aplikacje wielowatkowa kompletnie to olewajac, i mowic klientowi ktoremu sie wszystko sypie klasyczne "u mnie dziala" po przetestowaniu na 1 watku, albo nawet niech bedzie i na 100, ale akurat w testach lokalnych wyscigow nie ma.

No i oprocz tego "nie wie co one robią" tez moze wystepowac "nie wie ze kilka kiloplikow dalej od aktualnie edytowanego ktos wpisal annotacje ktora zmienila zachowanie calej aplikacji".

@eleventeen: Chodzi mi o podejście, w którym bez wiedzy o tym, co dana adnotacja faktycznie ma robić dostawia się ją (i ileś tam innych), aż osiągnie się efekt, który przejdzie testy.
Jak pisałem, dla mnie samo istnienie @whatever nie jest złe. Złe jest bezkrytyczne używanie frameworkowej "magii", często za wszelką cenę. Ja nawet cenię sobie, że zamiast pisać np. servlet z jakimiś tam filtrami na ścieżki można dostawić przy dowolnej metodzie @Endpoint, wpisać jaką ścieżkę ma obsługiwać i zrobione. Nie mam nawet problemu z użyciem jakiegoś wstrzykiwania zależności, chociaż oparte na refleksjach podejście springowe ma dużo wad. Gorzej kiedy korzystanie z narzędzia, jakim jest Spring staje się celem samym w sobie i muszę uczestniczyć w dyskusji typu:

• musimy dodać a+b
• (tydzień później) W Springu się nie da tego zrobić
• jak się nie da, skoro to proste sumowanie 2 liczb, wiemy jakie to liczby, na czym polega sumowanie, to gdzie problem?
• Bo spring nie ma takiej adnotacji, myślałem, że możemy użyć adnotacji X, ale nie możemy, bo używamy adnotacji Y, jest biblioteka która na to pozwala, ale ma konflikt z biblioteką, której użyłem do liczenia a * b i musimy wybrać, czy nasza aplikacja będzie dodawać, czy mnożyć, możemy tez podzielić to ma mniejsze serwisy jeden będzie dodawać, a drugi mnożyć.
• A co przeszkadza napisać return a+b a w drugiej metodzie return a*b?
• No może by i się dało, ale to nie będzie idiomatyczny kod, bo spring ma adnotacje do dodawania i taką do mnożenia i one są zajebiste, bo nie trzeba pisać kodu, ale nie mogą występować razem w projekcie.
• To dopisz nad klasą @Bean będziesz miał idiomatycznie, faktycznie trzeba będzie napisać 2 linijki kodu, ale to chyba wyzwanie, z którym jesteśmy w stanie się zmierzyć?

Tutaj w zależności od rozmówcy następuje kolejna iteracja, albo lekki foch i dostarczenie rozwiązania które "działa, ale jest brzydkie".

Bez przesady, to, że adnotacje są bardzo nadużywane i często wyzwalają jakąś bardzo dziwaczną magię nieosiągalną "normalnymi metodami", to nie znaczy, że to sperma szatana.

Właśnie odwrotnie, często można zupełnie to samo osiągnąć bez magii i adnotacji i przy tej samej ilości kodu. Tylko my w javie nie lubimy zbyt prostych rozwiązań.

@jarekr000000: Ale ja się zgadzam. Zwyczajnie sytuacje są różne i możemy sobie popisać, które częściej (chociaz sądzę, że tutaj mamy identyczną opinię). Wydaje mi się jednak, że nie masz nic przeciwko @Override, a jak by nie patrzeć, to też adnotacja, ok powinna być słowem kluczowym. To, że Spring doprowadził ich użycie do poziomu karykatury to oczywistość, podobnie jak całe wiadro bibliotek, które uznały tę magię za wspaniałość i poszły tym śladem. Co gorsza przesuwają moment wykrycia oczywistych błędów z etapu kompilacji na runtime.

Odrywając się od bibliotek, co sądzisz o np. takim problemie jak definiowanie zestawu endpointów w aplikacji, dla mnie "ideałem" było by coś co jest "przyjemne" w pisaniu i na etapie kompilacji sprawdza możliwie szeroko poprawność tej konfiguracji (np. czy nie zdefiniowano więcej niż raz tego samego endpointu. Możliwości są takie:

Springowe podejście:

@GetMapping("/hello")
public String hello(){return "hello";}

@GetMapping("/hello")
public String bye(){return "bye";}

Tylko oczywisty błąd nie zostanie wychwycony do startu aplikacji.

Można podejść do tego od strony Javy, czyli z grubsza tak:

Server.serverBuilder()
  .addEndpoint("/hello", controller::hello)
  .addEndpoint("/hello", controller::bye)
  .startServer()

Tylko błąd nadal nie zostanie wychwycony przed wykonaniem tego kawałka kodu

Wreszcie można pozwolić sobie na odrobinę magii i połączyć oba podejścia np. poprzez zmiany sposobu w jaki to GetMapping jest obsługiwane i przejście z tym z poziomu refleksji działających na refleksjach do poziomu kompliacji, czyli pozwolić napisać APTowi ten drugi kawałek kodu, przy okazji sprawdzając, czy np. ktoś nie próbuje podpiąć 2 różnych metod do tego samego endpointu.

@piotrpo:
Co do mapowania do najbardziej podobają mi się rozwiązania w stylu:
https://github.com/softwaremill/tapir

ale to scala, w javie i kotlinie nie ma lekko.

Jakkolwiek i tak wolę podejście funkcyjne - też się może wyrypać w runtime, ale jednak testowanie łatwiejsze, a do tego można jednak funkcja to funkcja, można o wiele łatwiej parametryzować to API, nawet budować w pętli, albo rekurencyjnie (czego adnotacjami nie da się w ogóle zrobić).

Żeby ominąć trochę błędów zrobiłem sobie nakładkę na Ktora i API robię tak Kotlin):
https://github.com/jarekratajski/damagerGame/blob/88f4fd27d20e3d403ace07f14fca71add6f89f0b/src/main/kotlin/damager/web/Server.kt#L64

Nakładka trochę mi pomaga w unikaniu "nieobsłużonych" ścieżek, czasami jak coś się nie zgadza to się nie skompiluje (ale tylko bardzo czasami).

rb.nested("/api/game") {
            rb.nested("/admin") {
                rb.get("/view") {
                    service.getView()
                } + rb.post("/reset") {
                    service.resetGame()
                }
            } + rb.nested("/player") {
                rb.nested("/command") {
                    rb.post {
                        val token = it.request.headers["token"]!!
                        runNee {
                            it.receive<Command>()
                        }.anyError().flatMap { cmd ->
                            service.postCommand(token, cmd)
                        }
                    }

                } + rb.post {
                    val name = it.parameters["name"]!!
                    service.registerPlayer(name)
                } + rb.get {
                    val token = it.request.headers["token"]!!
                    service.getOwnPlayer(token)
                }
            } + rb.get("/objects") {
                val token = it.request.headers["token"]!!
                service.getObjects(token)
            }

No niestety, nie znam odpowiedzi na sporo pytań, więc posiedzę sobie gdzie moje miejsce ;)

piotrpo napisał(a):

Masz potrzebę monitorowania zmian w dowolnej implementacji List, przez jeden lub wiele obiektów, jak rozwiążesz taki problem?
Zaczyna się jazda.

Z ciekawości - jakie to ma praktyczne zastosowanie? Jakby mi ktoś takie pytanie zadał, to bym odpowiedział, że zrobiłbym ją final. Wtedy każda jej zmiana by skutkowała trudnym do przeoczenia komunikatem.

@PanamaJoe:

Jakby mi ktoś takie pytanie zadał, to bym odpowiedział, że zrobiłbym ją final. Wtedy każda jej zmiana by skutkowała trudnym do przeoczenia komunikatem.

Eee, final przecież tego nie rozwiąże. Na liście możesz wywołać clear() i będziesz miał modyfikację.