Rekrutacja IT z perspektywy programisty seniora

Cześć,

Mówi się na naszym programistycznym rynku, że dobry programista jest bezrobotny przez 15min. Nie jest to do końca prawda, aczkolwiek mamy bardzo dobrze.

Ofert jest dużo, widełki pensji pozwalają żyć na niezłym poziomie, mamy elastyczne możliwości pracy, możemy zarabiać na naszej pasji.

Nie wiem jak wy, ale mi zależy aby pracować z ambitnym ludźmi, wysoką kulturą organizacyjną, w miejscu gdzie mogę się realizować. Dla mnie czas, możliwości rozwoju, kultura organizacyjna są ważniejsze od pieniędzy podczas szukania pracy.

Research, liczne rozmowy, przechodzenie rozmów rekrutacyjnych jest angażujące, szczególnie w dużych firmach. Trwa to tygodnie, jest wiele etapów po drodze które wymagają zaangażowania.

Mam sporo przemyśleń w jaki sposób sprawdzać firmy, projekty, jak organizować sobie proces rekrutacji.

Najpierw musisz sobie odpowiedzieć na jedno zajebiście ważne pytanie. – "Gdzie chcę pracować?"

A dalej odpowiedz na inne pytania jak:

• na ile wyceniam swoją godzinę czasu?
• jakie benefity mnie interesują?
• jest ktoś z danej firmy z kim chciałbym szczególnie pracować?
• Dlaczego chcę tam pracować? Czego szukam? Co jest dla mnie ważne?
• Szukam firmy "sanatorium" – bezpiecznej przystani, w którym mogę się opieprzać czy miejsca gdzie będzie wymagająco i będę mógł się sprawdzić?

Rynkowo patrząc. Instytucje finansowe bardzo dobrze płacą i ich ofert jest sporo. Myślę o tych klasycznych, bo startupy fintech to inna para kaloszy. Ten typ organizacji mało mnie interesuje. Dlaczego?

Powodów jest kilka. Są to zazwyczaj bardzo skostniałe organizacje, z rozbudowaną polityką, topornym managementem . Co mnie dodatkowo wkurza, to bardzo liczne ograniczenia nałożone na prace te techniczne jak i organizacyjne. Wymagania korzystania z kilku VPN-ów, ograniczenia w instalacji oprogramowania.

Co do wielkich firm. Są niezłe na start kariery, bo pomagają się rozwinąć w komunikacji, współpracy z innymi. Projekty są często duże, operują na wielkich skalach. Firmy oferują spore możliwości awansu, dostajemy większą stabilność zatrudnienia. W zamian mamy często skomplikowane procedury, bardzo małe możliwości sprawcze. Decyzje są podejmowane długo, wiec przepchnięcie własnego pomysłu trwa długo i tak może być odrzucone z powodów tylko politycznych. Dla osób lubiących spokojną i "bezpieczną" pracę, to zazwyczaj korpo jest ok opcją.

Zupełnie inną parą kaloszy są startupy. Które można podzielić na kategorie w zależności od poziomu otrzymanego finansowania, czy wielkości firmy, rynku itd.. W małych robi się wszystko, często za minimalne pieniądze, pracując sporo więcej niż oklepane 8h. Nie ma poczucia bezpieczeństwa zatrudnienia. Za to można poczuć ideę, pracować z myślą, że można zmienić świat. Zapierdala się , ale w imię wyższego celu. Dostajemy największe możliwości i odpowiedzialność w porównaniu do innych rodzajów firm. Jest to ryzykowna opcja, ale potencjalnie najbardziej opłacalna.

O byciu freelancerem nie będę pisał, bo to post o rekrutacji. A przecież do własnej firmy nie będziemy aplikować 😛

Na co zwracać uwagę w ogłoszeniach?

Mam zasadę, że nie aplikuje do firm, gdzie nie ma podanych widełek pensji, ani szczegółów projektów czy nie ma nazwy firmy. Szkoda mi czasu i energii, aby tam aplikować. Raczej to nie będzie ciekawy projekt i miejsce, gdzie mogę się wzrastać.

Taki tips dla rekrutujacych. Podawajcie od razu w ogłoszeniu jak najwięcej szczegółów jak:

• opis teamu.
• struktura zespołu (jeśli rekrutacja do zespołu).
• ostatnie projektu zespołu (jeśli rekrutacja do zespołu).
• Oczekiwany zestaw umiejętności technicznych.
• Obecność dyżurów (on-call) i ich zasad.
• lista etapów rekrutacji, wraz z opisami, czasem potrzebnym na każdy etap.
• szczegóły oferty:
  • widełki i rodzaj umowy
  • benefity
  • praca zdalna/hybrydowa/stacjonarna? Na jakich zasadach?

Na co dalej zwracać uwagę w ogłoszeniach jako specjalista?

Nazwa firmy:
W ogłoszeniu musi być podana nazwa firma. Dziękuje rekruterom, którzy tylko piszą że mają projekt Java za X cebulionów w branży fintech/telco w Javie itd.

Jest to kluczowa informacja, bo jestem w stanie szybko sprawdzić w Internecie opinie o takiej firmie w serwisach jak GlassDoor, GoWork, LinkedIn, rejestr KRS.

Mam firmy, które są na mojej czarnej liście – never, ever w których nie chcę pracować.

Głównie chodzi o mój czas i energię. Headhunterzy czy inni rekruterzy będą namawiać na spotkanie, aby sprzedać projekt. A czasem nawet na spotkaniu nie podają nazwy docelowej firmy w której miałbyś pracować.

Bardziej skomplikowana jest sytuacja z firmami, z którymi podpisujesz umowę i Ciebie wysyłają do klienta. Mogą mieć kilku klientów czy projektów, w których mógłbyś pracować. Warto przycisnąć, aby zdobyć jak najwięcej szczegółów.

Jeśli nie kojarzysz firmy, to warto sprawdzić jej strone, kanały social media, profil GlassDoor/GoWork, indeks KRS. Im więcej informacji zdobędziesz na początku, tym mniej czasu stracisz później.

Lokalizacja
Praca zdalna/hybrydowa, a może lokalnie?

Cenię swój czas. Jeśli firma oferuje tylko pracę lokalnie, to rozważam tylko opcje max 1,5h w obydwie strony komunikacją miejską.

Dla mnie jest ważna elastyczność czasu i miejsca pracy. Rozumiem przez to, że chcę mieć możliwość wyjechania np na Teneryfe i pracę zdalną stamtąd, czy po prostu móc iść do dentysty czy trening w ciągu dnia.

Szczegóły projektu
Jaki projekt? Greenfield, legacy?
Jakie są używane technologie?
W jakiej metodologii jest prowadzony projekt? Agile, scrum, kanban, waterfall?

Nie wchodzę w projekty z przestarzałymi, niszowymi technologiami np. Cobol ;). Dlatego, że zdobywając specjalizację w nich, tracę z oczu rynek. W międzyczasie mógłbym się rozwijać w ciekawszych i popularniejszych technologiach, które dadzą mi większe możliwości i satysfakcję. A w dłuższej perspektywie czasowe dadzą mi większą wartość na rynku.

Warunki finansowe i rodzaj umowy
Punkt wiadomix. Potrzebujemy pieniędzy, aby godnie żyć w społeczeństwie.

Na co zwracam uwagę?
Jakie warunki finansowe proponują i jakie rodzaje umowy wchodzą w grę? Kwota netto/brutto? Jaki procent kosztów kreatywnych jest wliczanych w przypadku UoP.

Przed podpisaniem umowy, warto ją skonsultować z prawnikiem, aby nie nadziać się na minę w stylu zakaz konkurencji w branży.

Warto dopytać się w jaki sposób jest się rozliczanym za czas i jak jest on raportowany. W jednym firmach wystarczy podać ogólnie np. 30h zadanie X, a w innym liczona jest każda minuta. Im bardziej restrykcyjne zasady, to tym bardziej bym uważał.

Unikam firm, w których są systemy szpiegowania monitorowania pracy jak np. automatyczny screenshoot co kilka minut, czy konieczność korzystania z kamerki cały czas. Taka firma otrzymuje od razu wpis na moją blackliste. Bardzo pachnie mi to mobbingiem i toksycznym środowiskiem pracy.

Benefity
Jest to mniej ważny punkt niż warunki finansowe, ale zwracam na niego uwagę przy podejmowaniu decyzji. Nie mówię o karcie multisport, czy ubezpieczeniu, bo to jest standard. Owocowe czwartki są miłe, ale sam mogę kupić owoce. A młody i dynamiczny zespół to nie jest benefit 😉

Miło patrzę na benefity, które pozwalają mi się rozwijać czy będą inną firmą inwestycji np. budżet szkoleniowy, dostęp do platform e-learningowych, nielimitowany urlop na B2B, zniżki pracownicze, możliwość kupna taniej akcji itp. Pojawia się coraz więcej firm, które przechodzą na 4 dniowy tydzień pracy. Chciałbym pracować z takiej firmie w przyszłości.

W zależności od rodzaju umowy mogą się różnić benefity. W niektórych firmach UoP ma dużo większy zakres niż kontraktowiec. Jeśli jest tak, to daje mi do myślenia o kulturze organizacyjnej. Jeśli jednych współpracowników traktuje się lepiej niż innych to nie jest to dobry objaw.

Etapy

W większości firm jest kilka etapów rozmów. Każda firma podchodzi trochę inaczej do procesu. W niektórych przebiega to bardzo szybko, a w niektórych jest to kilka tygodni. Nie będzie raczej tajemnicą poliszynela, że im dłuższy proces rekrutacji, to tym mniejsza szansa na rekrutacje odpowiedniego specjalistę IT. Podobnie jest z ilością i trudnością etapów.

Na razie streszczę je, a później omówię, jak się do nich dobrze się przygotować.

• rozmowa z rekruterem o doświadczeniu zawodowym, o firmie, projekcie, o oczekiwaniach finansowych.
• rozmowa z menadżerem.
• rozmowa behavioralna.
• rozmowa techniczna z rekruterem technicznym/tech leadem zespołu.
• zadanie domowe / live coding.
• application / system design.

W każdej firmie wygląda to inaczej. Zazwyczaj jest rozmowa z rekruterem, techniczna, i z menadżerem liniowym.

Rozmowa z rekruterem

Widzę tutaj kilka podetapów:

Rozmowa o projekcie, firmie

Dowiadujesz się ogólnie o firmie, czasem o projekcie. Jakie są używane technologie, benefity itd.

Bardzo często pojawia się pytanie o przyczynę poszukiwania pracy.

Pytania dt. CV, doświadczenia, używanych technologii

Zazwyczaj kandydat jest proszony o opisanie aktualnego projektu. Jakie są używane technologie, ile osób w teamie.

Dla osób pokroju seniorów, tech leadów spotkałem się z pytaniami o mentorowanie juniorów, w jaki sposób przeprowadza się code review. Także się czasem pyta o to w jaki sposób rozwiązujesz konflikty, zdobywasz wymagania biznesowe do zadania czy delegujesz zadania. Pytania o miękkie zdolności, dt. charakteru są sprawdzane mocniej na etapie tzw. rozmów behawioralnych.

Warto przy każdym swoim projekcie opowiedzieć o największych wyzwaniach, jak sobie z nimi poradziłeś. Rób dobrą propagandę na liczbach 🙂

Bądź gotów na rozmowę w języku obcym – domyślnie angielskim. Zazwyczaj rekruter zadaje kilka pytań np. co robisz w czasie wolnym, opowiedz o swoim ostatnim projekcie. W niektórych firmach wszystkie etapy są po angielsku.

Oczekiwania finansowe, rodzaj preferowanej umowy

Przed spotkaniem zastanów się jaką chciałbyś zarabiać kwotę per godzina czy miesiąc. Podaj im większą o tak np. 10% 😉 Jeśli mają niższy budżet, to i tak czasem warto ponegocjować. Jeśli się dobrze sprzedasz, znasz swoją wartość to i tak może znaleźć się dodatkowy budżet 😉

W tej przestrzeni jest zawsze miejsce na negocjacje. Jeśli zaproponowana kwota jest powyżej budżetu, a się dobrze sprzedasz to i tak może znaleźć się rola dla Ciebie.
Tutaj kontrakt daje największe pole do negocjacji warunków jak realizacja umowy, czas pracy, sposób rozliczania. Umowa o pracę narzuca liczne prawne ograniczenia na model czasu i sposobu wykonywania pracy.

Podczas rozmowy z rekruterem pytam się, czy umowa jest tak skonstruowana, że można na jej podstawie wysłać wniosek o indywidualną interpretację IpBoxa.

Przed rekrutacją warto rozpisać sobie widełki kwoty jaka nas satysfakcjonuje w zależności od formy prawnej – B2B, UoP i waluty rozliczeniowej. Jeśli jesteś zainteresowany B2B i UoP to kwota powinna być inna dla każdej opcji, bo trzeba wziąć pod uwagę kwestie urlopów, opcje udziałowe, ciekawe benefity itd,

Co do sprzedaży, to rekrutacja to proces sprzedaży. Rekruter sprzedaje Ci firmę i projekt, a ty sprzedajesz siebie. Trochę analogicznie działa to podczas randkowania, obydwie strony starają się siebie przedstawić w jak najlepszym świetle.

Wywiad techniczny

W tej części rekruter techniczny zadaje Ci pytania dt. technologii używanej w projekcie. Jak rekrutujesz jako Javowiec to raczej cie zapytają o różnice pomiedzy TreeMap czy HashMapą, czy jak działa garbage collector.

Polecam poszukać artykułów w stylu "pytania rekrutacyjne Java". Spisać kilkadziesiąt najpopularniejszych. Zrobić notatki, fiszki do nauki. Powinno to wystarczyć na większość rozmów, bo zazwyczaj zadawane są bardzo podobne pytania.

Rozmowa behawioralna

Rozmowa z potencjalnym przyszłym menadżerem. Celem jest sprawdzenie, czy kandydat pasuje do zespołu, kultury organizacyjnej firmy. Tutaj się bada umiejętności miękkie – szczególnie komunikacyjne i odporność na stres.

Zauważyłem, że pojawia się w firmach, którym zależy na utrzymaniu wysokich standardów organizacyjnych. Nie ma raczej ich oczekiwać w janusz sofcie 😉

O co się pyta kandydata?

Generalnie:

• podaj przykład pozytywnego/negatywnego feedbacku jaki dałeś/otrzymałeś.
• podaj kilka przykładów błędów technicznych jakie popełniłeś. Jak je rozwiązałeś?
• Opisz kilka sytuacji, w których doszło do konfliktu/nieporozumienia z tobą i zespołem.
• Jak w kilku zdań mogą Cię opisywać twoi współpracownicy?
• Czym chciałbyś się zajmować w naszej firmie?

Kodowanie – coding interview

Kodowanko, czyli to co programistyczne tygrysy lubią najbardziej.

W 90% przypadków kandydat jest proszony o zakodowanie rozwiązania problemu algorytmicznego w stylu:

Write an algorithm that given a string containing any combination of the characters  
'(', ')', '{', '}', '[' and ']', determines if the input string is valid.  

An input string is valid when:  
 * Opening parentheses are closed by the same type of closing parentheses, and * Opening parentheses are closed in the correct order.  
No other characters are present in the string except those mentioned above.  

Examples:  

1. "()" -> true  
2. "()[]{}" -> true  
3. "(]" -> false  
4. ")(" -> false  
5. "([)]" -> false  
6. "{[]}" -> true  
7. ")" -> false  
8. "([]" -> false  
9. "{" -> false  
10. "([)])" -> false  
11. "(((((((((())))))))))" -> true  
12. "" -> true

Często można wykorzystać swoje IDE, napisać testy. Używane sa platformy jak Hackerrank, CodePad.

Zazwyczaj jest to livecoding, gdzie postępy w czasie rzeczywistym obserwuje rekruter techniczny. Zadaje pytania o złożoność wybranego podejścia, jak działają użyte struktury danych, jakie są wąskie gardła implementacji. Warto na bieżąco głośno opowiadać, co się robi, dlaczego podjęło się taką, a nie inną decyzję.

Nie lubie tego etapu. Miałem kilka razy tak, że napisałem większość, przeszło 90% scenariuszy testowych czy zabrakło mi czasu na dokończenie szczegółów implementacji. Przez automat czy rekrutera otrzymałem negatywną ocenę. Dużą wadą tego rozwiązania, jest to że wartościowi i doświadczeni programiści nie przechodzą dalej.

Bo tak naprawdę, jak często sięgamy do wiedzy typowo akademickiej? Większość naszej pracy to pisanie prostych rozwiązań, crudów, umiejętne kopiowanie ze stack overflow czy podpięcie biblioteki. Mamy czas na przetestowanie kilku rozwiązań, skonsultowanie ich.

Mniejszością były sytuacje, w których miałem przyjemność dostać zadanie oparte na rzeczywistym problemie czy zaprogramować małą aplikację.

Dobrze zapamiętałem sesję, gdzie miałem napisać aplikację która korzysta z wystawionego API i dokonać reverse engineeringu zasad jego działania. W innej firmie dostałem 1h na napisanie aplikacji która działa jak baza klucz-wartość jak np. redis trzymany w pamięci aplikacji z obsługą zagnieżdżonych transakcji.

Zasoby

Bardzo polecam książkę "%%Cracking the Coding Interview%%" autorstwa Gayle Laakmann McDowell, która jest świetnym wprowadzeniem do tematu. Przerobienie jej dało mi solidne podstawy merytoryczne i doświadczenie.

Platformy z zadaniami i do nauki algorytmiki:

• Leetcode j
• Codewars coding katas:
• Edabit coding challenges is
• SWECareers

Application / system design

Jest to dla mnie najtrudniejszy i najbardziej angażujący etap rekrutacji.

Zazwyczaj jest 1-3h spotkanie poświęcone projektowaniu. Czasem jest to tylko projekt aplikacji, czasem systemu, a w niektórych przypadkach tego i tego.

Dostajesz zadanie w stylu:
"Zaprojektuj system wynajmu rowerów" czy innego ubera.

Projekt aplikacji zazwyczaj polega na zaprojektowaniu modelu klas/tabel. A systemowy na opisaniu w jaki sposób byś podzielił system na poszczególne moduły, aplikacje, jakie rodzaje baz danych, jaki rodzaj komunikacji co byś wybrał do rozwiązania technicznego.

przykładowy projekt systemu:

źródło: Top 10 System Design Interview Questions

Nikt nie oczekuje, że będzie to gotowy do realizacji plan. Jeśli można, to polecam program Flowchart Maker & Online Diagram Software do narysowania diagramów, schematu tabel. Można używać UMLa, C4.

Tematowi jest już poświęcone wiele książek i jeszcze więcej artykułów. Przed spotkaniem warto się przygotować, odświeżyć zagadnienia projektowania systemów IT, baz danych, rodzajów komunikacji, problemów architektury rozproszonej. Dam ci kilka tipsów na początek jak ugryźć temat.

Projekt systemu

Krok 1. Zdobycie wymagań

Celem jest zebranie wymagań. Podczas tego kroku należy zadawać pytania, aby określić przypadki użycia, scenariusze działania i ograniczenia.

Po uzyskaniu informacji o zadaniu. Warto zadać pytania jak:

• Kto będzie używał rozwiązania?
• W jaki sposób rozwiązanie będzie użyte?
• Ilu jest użytkowników?
• Co powinien robić system?
• Jakie są wejścia i wyjścia systemu?
• Ile danych system powinien przetwarzać?
• Ile zapytań na sekundę system powinien obsługiwać?
• Jaki jest oczekiwany stosunek odczytów do zapisów?

Warto tej części, dać czas np. 10-15min, aby móc zrozumieć szerzej kontekst biznesowy i potrzeby techniczne. Jest to mocno punktowane.

Szybka estymata
Podczas rozmowy można zostać poproszonym o odręczne wykonanie estymat tzw. "back of the envelope calculations". Która polega na obliczeniu bardzo zgrubnego zużycia zasobów przez system, oczekiwanych requestów na sekundę itp.

Jeśli nie zostaniesz zapytany, możesz się zapytać, czy taką estymacje wykonać.

Krok 2: Projektowanie rozwiązania

Stwórz wysokopoziomowy projekt systemu zarysowując najważniejsze jego komponenty.

Postaraj się głośno omawiać na bieżąco, dlaczego dzielisz system na takie moduły. Jaki rodzaj bazy danych chcesz wykorzystać, w jaki sposób moduły będą się komunikować(rest, rpc, kolejka).

Skup się raczej na ogólnikach, nie ma sensu podawać, że użyjesz Kafki w wersji X, czy innego Rabbita. A może Postgressa czy MySql. Na tym poziomie taki poziom szczegółowości jest nie wymagany.

Zastanów się, jakie będą bottlenecki twojego systemu. Jakie są możliwe dziury bezpieczeństwa czy wąskie gardła wydajności.

Na przykład, jeśli zadaniem jest stworzenie projektu serwisu skracającego URL, do omówienia są następujące zagadnienia:

• Generowanie i przechowywanie hasha pelnego URLa
  • MD5 i Base62
  • kolizja hashy
  • SQL lub NoSQL
  • Schemat bazy danych
• Zamiana skróconego URLa na pełny URL
  • wyszukiwanie w bazie danych
• API i projekt klas

Przy wyborze architektury rozproszonej, raczej cię zapytają o typowe zagadnienia jak eventual consistency, CAP/BASE, generowanie unikalnego ID, rozproszone transakcje w kontekście twojego rozwiązania itd. Więc podejmując decyzje projektowe bądź pewien, że rozumiesz dane rozwiązanie.

Application design

W dalszej części możesz zostać poproszony o zaprojektowaniu modelu aplikacji czy bazy danych w ramach zadanego zagadnienia.

Dodatkowe materiały

System Design Primer
Najlepszy zasób na Githubie jaki znalazłem.
https://github.com/donnemartin/system-design-primer

Książka: "System Design Interview – An insider’s guide, Second Edition"

Dla mnie jest to must-have, świetne przygotowanie do rozmów technicznych. Autor opisuje kilkanaście różnych systemów i omawia wiele zagadnień.

Książka: "Designing Data-Intensive Applications. The Big Ideas Behind Reliable, Scalable, and Maintainable Systems" Martina Kleppelmana

Najlepsza książka jaką czytałem dt. projektowania aplikacji, systemów. Omawia plusy i minusy różnych technologii do przetwarzania i gromadzenia danych. Wyjaśnia sposób działania różnych modeli baz danych – relacyjne, dokumentowe, grafowe itd. Dotyka głęboko tematu transakcji.

Kurs System Desing Interview
https://www.educative.io/courses/grokking-the-system-design-interview/m2ygV4E81AR

Opóźnienia, wartości które musi znać każdy programista
Latency Numbers Every Programmer Should Know | stereobooster.github.io

Podsumowanie

Do rekrutacji można podejść jak do każdego projektu i wyzwania. Znając sposób myślenia rekruterów, standardy rynkowe można "hakować" rozwiązania, przez co optymalizować proces szukania pracy. Powodzenia!

Bonus #1! Pytania do rekruterów IT w celu weryfikacji firmy i projektu

1. Jaki będzie mój zakres obowiązków?
2. Jakie będą moje pierwsze zadania?
3. Jaka jest metodyka zarządzania projektem, zadaniami, jak wygląda rozliczanie z efektów?
4. W jaki sposób jest aplikacja jest testowana? Jakie są używane rodzaje testów: jednostkowe, integracyjne, kontraktowe, funkcjonalne itd. ?
5. Czy jest wykonywanie review kodu? Kto je wykonuje?
6. Na jakie oprogramowanie dostanę licencję firmową np. IntelJ, Enterprise Architect, iMindMap? Developer ma swobodę w wyborze odpowiednich narzędzi?
7. Czy jest dokumentacja do projektu? Kto ją utrzymuje? Jest aktualna? Jaka część dokumentacji jest generowana z kodu?
   a) Wysokopoziomowa biznesowa
   b) Modelu danych
   c)Techniczna
8. Standardy kodu, jakość kodu.
   a) Czy jest wyznaczony standard nazewnictwa klas, zmiennych metod? Lub inny dokument który mówi jak programować.
   b) Jakie narzędzia statycznej analizy kodu są wykorzystywane?
9. Czy będę musiał przygotowywać dokumentację wymagań przed i po wdrożeniową?
10. Ile osób będzie w zespole w którym będę pracować? Jakie specjalności? Jaki jest rozkład starszy młodszy programista w zespole?
11. Na jakim komputerze będę pracować? Mac? Windows? Jakie parametry techniczne, lub model.
12. Czy będę miał uprawnienia administracyjne na komputerze?
13. Czy będę miał w biurze dostęp do min. 2 monitorów? Otrzymam słuchawki, stacje dokującą, inny sprzęt usprawniający pracę stacjonarną/zdalna?
14. Jak wygląda kwestia przerwy na obiad? Wliczana w czas pracy? W jakich godzinach?
15. Na jakim rynku działa system – fintech, marketing, crm itd.?
16. Ilu ma użytkowników system? Użytkownicy zewnętrzni czy wewnętrzni?
17. Jak duży jest system?
18. Jakie są dostępne benefity? Płatne urlopy, dostęp do platform e-learningowych, karty benefit, ubezpieczenia, przedszkole firmowe, kurs języków obcych itd.
19. Jak wygląda kwestia urlopów? Ile dni? Płatne/bezpłatne?
20. Czy istnieje możliwość wykorzystania miejsca parkingowego w biurowcu? Jeśli tak to w jakiej cenie?
21. Czy są wyjazdy do klienta (za granicę)? Ja tak to jak często i na jak długo.
22. Czy są szkolenia wewnętrzne techniczne, miękkie jak i biznesowe? Czy posiadasz przynajmniej dwa z trzech następujących elementów: a ) Program mentorski w firmie b) Stypendium na rozwój zawodowy w postaci książek/szkoleń c) Regularne rozmowy techniczne, podczas których pracownicy firmy uczą się od siebie nawzajem – lub od zewnętrznych ekspertów
23. Praca zdalna, stacjonarna, hybrydowa? Na jakich zasadach?
24. Jaki jest proces awansowania i otrzymywania premii? Jakie premie są dostępne? Czy są spisane kolejne szczeble awansu? Jest możliwość przejścia z roli technicznej na menadżerską? Jest możliwość zmiany projektu wewnątrz firmy tzw. turystyka projektowa?
25. W jaki sposób, jak często są wypuszczane aktualizacje aplikacji/systemu? CI czy CD? Kto może dokonać wypuszczenia aplikacji na produkcje?
26. Kto zarządza infrastrukturą IT? Wewnętrzny dział, developerzy, zewnętrzna firma?
27. Jak jest zarządzana konfiguracja środowisk? Skrypty jak Ansible, Terraform czy "z palca"?
28. Ile jest dostępnych środowisk (developerskie, uat/stage, produkcja)?
29. Jaka jest forma prawna firmy? Kto finansuje? Czy jako kontraktowiec mogę mieć udziały w firmie?
30. Czy inżynierowie pracują bezpośrednio z klientem, designerami, product manadżerami, data scientistami? Czy jest osoba pośrednia?

Bonus #2. Organizacja procesów

Jeśli się rekrutuje, to biorę udział w conajmniej kilku procesach rekrutacyjnych. Aby utrzymać porządek w notatkach wykorzystuje szablon notatki w moim "drugim mózgu".

Jest do pobrania z mojego githuba: tutaj

Plik jest w formacie Markdown, ale Github generuje podgląd pliku, który można skopiować do np. worda, obsidiana, notion.