Szukanie pracy w IT jako senior - jak szukać i aplikować + bonus

Na programistycznym rynku mówi się, że dobry programista jest bezrobotny przez 15 min. 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 zaczepiście ważne pytanie. - "Gdzie chcę pracować?"

A dalej odpowiedz na inne pytania jak:

• na ile wyceniam swoją godzinę pracy?
• 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 wymagającego, gdzie 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ą i 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, więc 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. Zapiernicza 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 rekrutujących. Podawajcie od razu w ogłoszeniu jak najwięcej szczegółów jak:

• opis teamu.
• struktura zespołu (jeśli rekrutacja do zespołu).
• ostatnie projekty 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ś/miałabyś 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 stronę, 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,5 h 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 Teneryfę 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 dalszej perspektywie 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ć, w jaki sposób jest się rozliczanym za czas i jak jest on raportowany. W jednym firmach wystarczy podać ogólnie np. 30 h zadanie X, a w innym liczona jest każda minuta. Im bardziej restrykcyjne zasady, tym bardziej bym uważał.

Unikam firm, w których są systemy monitorowania pracy jak np. automatyczny screenshot 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ą formą 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, 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 menedżerem.
• rozmowa behawioralna.
• 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 menedż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 z 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 czy delegujesz zadania. Pytania o miękkie zdolności, dotyczące 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.

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 dotyczące technologii używanej w projekcie. Jak rekrutujesz jako Javowiec to raczej Cię zapytają o różnice pomiędzy 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 i 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:

Często można wykorzystać swoje IDE, napisać testy. Używane są 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 lubię 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.
• Codewars coding katas.
• Edabit coding challenges.
• SWECareers.

Application / system design

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

Zazwyczaj jest 1-3 h 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:

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-15 min, 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". Polega na obliczeniu bardzo dużego zużycia zasobów przez system, oczekiwanych requestów na sekundę itp.

Jeśli nie zostaniesz zapytany, możesz się zapytać, czy taką estymację 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 niewymagany.

Następnie zastanów się, jakie będą słabe strony Twojego systemu. Jakie są możliwe dziury bezpieczeństwa czy miejsca słabej 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.
• 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 w temacie projektowania aplikacji i systemów. Omawia plusy i minusy różnych technologii do przetwarzania oraz 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,
• Opóźnienia wartości, które musi znać każdy programista - Latency Numbers Every Programmer Should Know

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 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?
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? Jest wliczona 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 produkcję?
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 managerami, data scientistami? Czy jest osoba pośrednia?

Bonus #2. Organizacja procesów

Jeśli się rekrutuje, to biorę udział w co najmniej kilku procesach rekrutacyjnych. Aby utrzymać porządek w notatkach, wykorzystuje taki szablon notatki do pobrania z mojego githuba: tutaj.