Junior vs mid

1

Pracuje około półtora roku jako Java developer. Pomijając fakt że to pewnie za szybko, myślałem o zmianie pracy i aplikowaniu na pozycję mid. O ile jednak, przykładowych pytań na pozycję juniora jest w Internecie pełno, to na wyższe stanowiska jest tego bardzo mało. Tak więc pytanie do Was, czego się spodziewać przy rozmowie na mida?

5

Zależy od firmy i od tego co dokładnie będziesz robić.. może się pojawić więcej pytań o Springa czy Hiberneta jeśli są w wymaganiach.
Z samej Javy z wysokim prawdopodobieństwem mogą pojawić się wzorce projektowe (dokładne wyjaśnienie, jakich używałeś w projekcie), koncepty OOP i SOLID, typy referencji, algorytmy GC czy pytania z wielowątkowości, implementacji HashMapy/innych kolekcji + jakieś zadanie.

1

Jak to by powiedział Tony Stark: Jeśli nie wiesz co powinien umieć mid, to nie powinieneś nim być.

@Shalom ostatnio napisał, że nie powinno się uczyć na rekrutację. Sam trochę sobie przypominam tylko, bo po co mnie mają gdzieś przyjąć, żeby okazało się, że wywalą po okresie próbnym, bo wydawałem się lepszy. Z drugiej strony rekrutacje to często pytania typu jeden z dziesięciu, co sprawdza czy ktoś wykuł na pamięć regułki z neta, bo jak powiesz, że coś tam wiesz, ale byś jeszcze coś sprawdził w internecie, to już źle. Najciekawiej jest jak dostajesz 100 pytań i nie wiesz czy dobrze, bo nie raczy odpowiedzieć.

5

Moim zdaniem nie ma czegoś takiego. Pisałem o tym kiedyś, że nie ma jakichś tajemnych technologii, frameworków czy mechanizmów języka "dla seniora". Już junior powinien znać technologię mniej więcej w tym samym stopniu, przynajmniej z punktu widzenia "użytkownika".
Różnica jest w doświadczeniu. W tym kiedy czegoś używać, jak sie sprawdza w praktyce, do czego się nadaje a do czego nie.
Różnica jest też w szerokości wiedzy -> nawet jeśli klepiemy coś w Javie w Springu to senior w teamie pewnie klepał też np. w Scali i Kotlinie i był w projektach z JEE i może jakimś alternatywnym stacku z Ratpackami i jOOQ itd. Dzięki temu jak sie pojawia w zespole dyskusja "jak zrobić XYZ" to taki człowiek może coś do niej wnieść. Z drugiej strony masz takiego juniora, który może i jest dobry, ładnie klepie kod, zna Javę i Springa, ale co on może zaproponować w kwestii architektury czy designu? Niewiele, bo niewiele zna. Troche na zasadzie "jak masz młotek to wszystko wygląda jak gwoździe".
W efekcie często w zespołach gdzie masz takich "seniorów" którzy realnie są juniorami, masz projekty klepane jak żywcem z 10-letniego tutoriala, no bo tak chłopacy się kiedyś nauczyli i tak klepią, a że są seniorami to oni decydują "jak" ;]

0

Dla mnie rekrutacja która sprawdza czy znasz dokumentacje na pamięć jest po prostu słaba, ja nie wiem jak firmy potrafią rekrutować na tej podstawie. To że wiesz jak wykorzystywać daną technologie powie mi tyle co nic, ale za to jeśli wiesz czemu się ją wykorzystuje, jakie ma zalety i wady, czy istnieją alternatywne rozwiązania. Z tego można wyciągnąć już mnóstwo wniosków.

0

Dla mnie jednak jest różnica w pytaniach i nie opiera się tylko o doświadczenie. Juniora nie będę pytał o benchmarki, debugowanie wycieków pamięci czy model pamięci, z potencjalnym midem już chciałbym o takich rzeczach pogadać.

1

Te dwie odpowiedzi:

mfabjanski napisał(a):

Zależy od firmy i od tego co dokładnie będziesz robić..

i:

JumpSmerf napisał(a):

Jeśli nie wiesz co powinien umieć mid, to nie powinieneś nim być.

:)

Ktoś kto aplikuje na mida, powinien już mieć na tyle rozeznanie, żeby wiedzieć, jakie są standardy w działce programowania do której aplikuje (a do tego wystarczy śledzić od czasu do czasu media społecznościowe i uaktualniać przy okazji wiedzę w wolnym czasie) i powinien czuć się na tyle pewnie w swoim języku i bibliotekach, żeby iść na rozmowy bez obaw, o co spytają. Mid (zakładając, że w ogóle istnieje coś takiego jak "mid", bo to szalenie umowne) powinien już się orientować, co jest modne, co niemodne, co jest ważne, co nieważne. Ktoś kto się nie orientuje, to właśnie poziom juniora.

Co nie znaczy, że nie można zaryzykować, równie dobrze możesz czuć się niepewnie, a i tak pójść na rozmowę, właśnie po to, żeby nabrać większego rozeznania, o co mogą pytać.

O ile jednak, przykładowych pytań na pozycję juniora jest w Internecie pełno, to na wyższe stanowiska jest tego bardzo mało.

Może dlatego, że potem pytania są łatwiejsze albo te same, co na juniora.

2

Ja tak z własnego doświadczenia mogę powiedzieć, że gdy uczestniczyłem w rozmowach na mida (jako kandydat), to dość często pojawiały się pytania w stylu: "A jakbyś zaprojektował / zaimplementował aplikację, która robi X?".

Jedno z pytań, które udało mi się zapamiętać:

Jest sobie jakiś klient Twojej aplikacji, który potrzebuje możliwie najszybciej odebrać odpowiedź - załóżmy, że masz jakiś timeout, np. 1 sekundę, na połączeniu i klient działa blokująco, cały czas oczekując na Twoją odpowiedź.
Twoja aplikacja, żeby odpowiedzieć na ten request, potrzebuje jednak wysłać coś na jakąś kolejkę i oebrać odpowiedź nasłuchując na jakąś inną kolejkę.
Jak byś to zaimplementował? Jakich frameworków byś użył?

No i do tego mnóstwo pytań pobocznych w stylu, "a co, jeśli by dodać X?", "a co, gdybyś nie mógł korzystać z Y?", "a co, jeśli wystąpi sytuacja Z?" itd.

Dość często pytali mnie o sposób pracy z systemami kontroli wersji w kontekście CI / CD. Np. jakbym zaprojektował flow dla projektu, w którym pracuje 10+ developerów, a aplikacja jest deployowna na produkcję ze średnią częstotliwością raz dziennie i chcemy w procesie umożliwić deployowanie wszystkich feature'ów automatycznie, o czym trzeba wtedy pomyśleć, na co zwrócić uwagę.

Plus mnóstwo pytań o frameworki i technologie z CV, trochę o technologie wykorzystywane w firmach / projektach, do których aplikowałem (np. monitoring, load balancing, w jednej z firm jakieś podstawy z AWS, często pojawiały się pytania o Spring Cloud Netflix OSS, o programownaie reaktywne, o jakieś podstawy programowania funkcyjnego, o cache, o przechowywanie danych, o event sourcing / CQRS, jakieś zagadnienia z wielowątkowości, coś z konteneryzacji).

Często, były podpytania - "a kiedy byś polecił wykorzystanie tego frameworka?", "a dlczego?". Czasem rekruterzy znali jakieś bolączki danych frameworków i o nie również dopytywali (najczęściej, nie wprost).

EDIT:
Od razu zaznaczę, że wcale nie musiałem znać odpowiedzi na wszystkie te pytania. Często wystarczyło, żebym logicznie i dobrze rozumował, to czasem rekruterzy udzielali jakichś podpowiedzi i patrzyli, w którym kierunku będę szedł dalej.:)

1 użytkowników online, w tym zalogowanych: 0, gości: 1