Opiszę jeszcze rozmowę rekrutacyjną.
Podczas rozmowy obecne są dwie osoby z czego tylko jedna jest techniczna (bardzo ponura, szorstka i zarozumiała). Rozmowa trwa maksymalnie 1,5h. Niestety są mocno zacofani i rozmowa nie może się odbyć zdalnie (papierowy test jest blockerem). Na całe szczęście zapoznają się w CV, więc streszcza się szybko jedynie swoją naukę, pierwsze i ostatnie doświadczenie zawodowe. Następnie pokrótce zostanie opisany obecny system, nad którym pracują, po czym zaczną się pytania techniczne i miękkie.
Z pytań technicznych:
- Jak sprawdzić, że dwa wątki się zakleszczyły (treadump + jprofile)
- Po co dodano Optional (W celu lepszej obsługi nulli i unikaniu NPE)
- Czy korzystam z wzorców projektowych (nie było weryfikowane)
- Inne, równie proste, bardzo ogólnikowe, dotyczące wykorzystywanych technologii, które akurat zna lub słyszała osoba techniczna
Ogólnie ma tego całą kartkę, ale jak sprawnie i pewnie odpowiadacie, to raczej ich wszystkich nie zada.
Co się tyczy pytań miękkich, to jeżeli korzystaliście z szerokiego wachlarza technologi, to możecie zostać zapytani dosłownie o to: "W czym właściwie jesteś mocny?". Oprócz tego możecie się spotkać ze zdziwieniem, że: "Skoro faktycznie występują takie akronimy (jak Zookeeper czy Spock itp.), to trzeba się zastanawiać, czy jeszcze poruszamy się po obszarze IT". Takie zaskoczenie może świadczyć o głębokim zacofaniu technologicznym z ich strony i prowadzi do czegoś nieprzyjemnego. Zwyczajnie będą was szufladkować (w szczególności osoba "techniczna"). Przykłady:
- jeżeli pracowaliście gdzieś krócej niż 2 lata, to jesteście skoczkiem (i raczej mało realne jest, że jesteś na B2B i zwyczajnie projekt się skończył)
- jak korzystaliście z dużej liczby technologii, to pewnie macie sztucznie "wzbogacone" CV
- jak coś jest do wszystkiego, to ... - pewnie w niczym nie jesteście ekspertem
Wprost zaczynają od tego, że was zaszufladkowali, ale przynajmniej dają wam szansę się z tego wytłumaczyć. Zatem nie ma się czym przejmować, a na chamskie pytania, radzę odpowiadać równie chamsko.
Po pytaniach technicznych jest czas na twoje pytania i lepiej dobrze go wykorzystać zadając te właściwe, obnażające sposób pracy i wykorzystywane technologie. Uwaga zarozumiały Grek jest wrażliwy i jest go łatwo wyprowadzić z równowagi, jeśli się w czymś nie zgadzacie, więc uwagi radzę sobie darować. (usunięte przez administratora) czasami przerywa waszą wypowiedź, ale radzę się tym nie przejmować, odpowiedzieć na jego wtrącenie, wrócić do swojej wypowiedzi i obserwować jak mu żyłka pulsuje.
Później jest 7-mio stronnicowy test na kartce. Czysto akademicki, zawierający jedynie ze 2-3 praktyczne przykłady (uruchamianie wątku, czy grupowanie i filtrowanie strumienia osób). Niektóre pytania wymagają dokładnej znajomości API (subSet z TreeSet), znajomości EJB (adnotacji, położenia pliku ejb-jar.xml, które pola beana będą widoczne przez innego beana), czy plików (prawidłowy tag opisujący filtr w web.xml). Uwaga, tutaj koleś będzie wymagał czytelnego pisma, na co proponuje skontrować - że właśnie dlatego kod pisze się na komputerze wyposażonym w IDE (dzięki czemu, może kiedyś zaktualizują swoje procedury).
Na koniec macie szansę zobaczyć obecny zespół. Radzę skorzystać z tej propozycji. Zobaczycie wtedy czy zespół jest młody i dynamiczny, będziecie mogli zapytać o pracę i technologie.
Podsumowując, ponieważ firma ma w swoich szeregach byłych funkcjonariuszy, to chyba przełożyło się to na ich zachowanie. W skrócie jak wam mówią "Skacz", to wy macie jedynie prawo spytać "Jak wysoko?". Widać, że nie masz prawa do własnego zdania, z czym spotkałem się podczas rozmowy oraz odprowadzania do windy, gdy zakwestionowałem głupawe czekanie z pierwszą zmianą nowego developera. Manager, nie mając argumentów, kazał mi zmienić podejście, mimo, że przecież nie jest żadnym autorytetem. Czego dobitnym przykładem są różne środowiska developerskie i produkcyjne, które wypracował. W takim rozgardiaszu, faktycznie strach o jakąkolwiek zmianę.
Po rozmowie i wizycie na open space wygląda na to, że dominuje zero swobody, decyzyjności, a zmiany są chaotyczne. Na swoje zmiany w kodzie przyjdzie poczekać i dominuje klasyczne utrzymanie tego co jest. I panuje strach przed nieznanym (nowe technologie). Zaś po teście widać, że nadal nie wkroczyli do nowego stulecia, bo w sumie mógłby się odbyć online, a zadania praktyczne na realnym IDE.
