Wasze pytania do potencjalnego pracodawcy

Przed rozmową szukam info o firmie - wchodzę na ich stronę, patrzą opinie na glassdoor i gowork, szukam githuba, commitów w kernelu. Moja obecna lista której użyłem między innymi na dzisiejszej rozmowie wygląda tak:

1. Do jakich projektów szukacie teraz ludzi? W jakim projekcie bym
   był?

2. Czy są to nowe projekty czy utrzymanie?

3. Jak wygląda proces review, jakiej metodologii prowadzenia projektów
   używacie?

4. Jak się raportuje czas?

5. Czy macie ustalony coding style i reguły commit message'y?

6. Czy macie wiki i szkolenia wewnętrzne?

7. Jak wygląda wdrożenie nowego pracownika?

8. Czy poza gwiazdą embedded C używacie też innych języków?

9. Jakie są proporcje juniorów do seniorów w zespole? Od ilu lat
   pracują oni w firmie?

10. Czy jest możliwość zmiany projektu?

11. Czy kontrybuujecie do open source?

12. Czy są podróże służbowe?

13. Dostanę laptopa czy desktop? Czy dostanę 2+ monitory?

14. Czy mogę używać dowolnej dystrybucji Linuksa czy macie jakieś
    wymagania? Czy trzeba będzie używać do czegokolwiek Windowsa?

15. Pracujecie na open space czy w pokojach? Czy jest klimatyzacja?

16. Jakie są godziny pracy?

17. Czy jest otwarty internet - potrzebny może być Git, FTP, rsync?

18. W jaki sposób prowadzicie ocenę pracownika - czy są cele roczne,
    oceny kompetencji?

Większość pytań zamkniętych nie da ci prawdziwego obrazu pracy w danej firmie.

> Czy są to nowe projekty czy utrzymanie?
Oczywiście większość nowych.

> Czy macie wiki i szkolenia wewnętrzne?
Tak (pytanie zakłada "jakieś" wiki i historycznie odbyte szkolenie).

itd...

Zamiast pytań zamkniętych radziłbym pytać w sposób otwarty czyli właśnie Do jakich projektów szukacie teraz ludzi? W jakim projekcie bym był? albo Jaki macie system rozliczania nadgodzin (zamiast pytać wprost czy jest potrzeba pracy "po 16").

1. Jak wyglada sprawa z mozliwoscia pracy zdalnej?

2. Czy organizowane są szkolenia cykliczne

3. Czy można zgłąszać swoje propozcyję ulepaszania struktur w firmie

4. Czy jest równouprawnienie

5. Czy jest możliwość umowy o pracę

Chodząc na szkolenia coraz częściej rezygnuje sie ze zdjęcia... tak przynajmniej mowia specjalisci, ale to zalezy tez do jakiej firmy na jakie stanowisko aplikujesz bo w niektorych branzach liczy sie wyglad (np. recepcja)

Jaki jest stosunek zadłużenia firmy do dochodów firmy.

Czy placicie za czas stracony na sprawdzenie mojej wiedzy w przypadku nie przejścia do kolejnego etapu?

1. Jak wygląda rozwiązywanie problemów interpersonalnych w zespole - jeśli pada odpowiedź, że takich problemów nie ma (a pada często), to znaczy, że menedżment polega na poganianiu wyrobników, a nie zarządzaniu zespołem. Ogarnięty menager ma przynajmniej teoretyczne scenariusze na takie okazje.
2. Jak wygląda onboarding (szczegółowo) - jeśli pada odpowiedź ogólnikowa i wymijająca, to znaczy, że dostanę laptopa i zostanę zostawiona sama sobie.
3. Czy mogę porozmawiać z członkami zespołu (jeśli rozmowa była tylko z menedżerem/osobami spoza zespołu) - jeśli dociekają "a dlaczego, a po co", to znaczy, że panuje syfiasta atmosfera. Z tym że po takim pytaniu do kolejnej rozmowy pewnie nie dojdzie.

1. Jak w ramach pracy zdalnej firma dba o integrację zespołu - to pytanie-pulapka z mojej strony, bo sprawdzam, czy menedżer ma w ogóle świadomość, że to ważne, czy ma plan, czy działa na czuja, i czy bawią się w wymuszone gry i zabawy po pracy (co dla mnie jest opcją "nay-nay", bo jestem dorosła i mam swoje życie)

Na pewno warto pytać o możliwości rozwoju. To korzystne dla nas informacje i do tego dobrze wypadniemy w oczach rekrutera

EwelinaW889 napisał(a):

Na pewno warto pytać o możliwości rozwoju. To korzystne dla nas informacje i do tego dobrze wypadniemy w oczach rekrutera

"oczywiście są szkolenia prowadzone cały czas, jest budżet szkoleniowy na każdego pracownika osobno" - taka jest odpowiedź i jest to zgodne z prawdą z tym, że są to głównie szkolenia z Agile xD tak miałem w przypadku obu firm. W jednej udało się wyżebrac szkolenie z wzorców projektowych. Zawsze coś, ale to maks xD

niektóre sugestie tutaj są przerażające :o

Staram się nie zadawać mimo wszystko masy pytań, bo mam blokadę jakoś siedzieć i z listy czytać 30 pytań jak w pierwszym poście , więc zadaję tylko kilka:

1. Czym będę zajmowała się przez następny rok, w jakich technologiach będę programowała? (bo czasem pracodawca uważa że pracownicy to takie pionki gdzie można je wstawić gdzie się chce, a treść ogłoszenia służy tylko przyciągnięciu kandydatów)
2. Z kim będę pracowała? (bo pracowałam raz gdzie było 15 osób bez doświadczenia na 1 seniora :))
3. Jak często robicie code review w projekcie? Ile macie pokrycia testami? Czy prowadzicie wiki do projeku?
4. Jak wygląda onboarding?
5. Jak często dajecie feedback i czy dajecie jakieś wskazówki w jakim kierunku rozwijać się przed rozpoczęciem nowego projektu? (bo lubię rozwijać się po pracy, ale miałam raz pracodawcę który wyskoczył nagle ze stackiemw nowym projekcie który wystartował który był mi nieznany. miałam też sytuację pracować z ludźmi którzy potem udawali pretensje mimo że przez 2 lata nie mówili że coś im nie pasuje :))

Po podpisaniu umowy:
Czego douczyć się przed pierwszym dniem pracy?

Ja w sumie zadaję to samo pytanie będąc po obu stronach: skąd wiecie, że Wasz soft działa?.

Czy będzie trzeba pracować z excelami? :/

Teraz się zadaje pytania? Przecież masz być posłusznym pracownikiem jak zadajesz za dużo pytań to na twoje miejsce jest 100 innych.

Lubię pytać o CI/CD, dobre praktyki, code review, testowanie. Uwielbiam konsternacje na twarzach rekruterów, którzy usilnie próbują przypalić jana, że wszystko mają na wysokim poziomie :D

Ja nie zadaje za dużo pytań bo i tak będą mi wciskać kit i kolorozywać.
To o co zawsze pytam:

1. Godziny pracy, od kiedy do kiedy, czy mogę zrobić przerwę w ciągu dnia. Jak jest rozliczany czas pracy.

2. Onboarding - kto będzie mnie wdrażać i w jaki sposób (chociaż i tak zawsze jest inaczej). Zwykle chwile ktoś coś tam pomoże a reszta to radź sobie sam. Dopiero gdy się pali to nagle znajdują się ludzie do pomocy bo menago panikuje i wszystkich zagania do roboty.

3. Testy - w jakis sposób kod jest testowany.
   Czy są testy jednostkowe i czy działają. Miałem w jednym projekcie paczkę "Junit" i gdy zapytałem seniora z zespołu o te paczkę z testami to dostałem odpowiedź "nigdy nie udało mi się ich uruchomić" xD. Czy jest zespół testerów, kto jest odpowiedzialny za testy i wiedzę domenową. W niektórych domenach tester musi mieć sporą wiedzę domenową bo potem wychodzą krzaki na produkcji.

4. Ile jest spotkań i z kim. Chociaż tutaj i tak będzie ściema ale przynajmniej można wyczytać coś z reakcji rozmówcy.

Gdy praca w biurze to pytanie o parking.

Wydaje mi się, (choć mój zawód jest całkiem inny) że pytanie o zarobki jest dobre. Często okazuje się, że całe zbędne gadanie i marnowanie czasu jest po porostu stratą czasu - jak na końcu dowiecie się, że zarobki są mniejsze niż wasze oczekiwania czy możliwości. Pierwsze o co pytać to zarobki bo idziecie do pracy dla zarobków a nie owocowych czwartków.
Brałem udział w wielu rekrutacjach różnych pracowników jako jeden z kolegium mimo że nie mam nic wspólnego z HR.

Pytanie o zarobki dla mnie wydaje się bardzo właściwe - jeśli jakiś pracowała go nie podał od razu. Dobre też jest pytanie - jeśli to UoP a nie B2B - czy pracujecie w open space - totalnie niefajna praca w czymś takim, nawet dobrze nie można podrabiać się po tyłku. Jak czasami byście coś takiego mieli, to odejmujcie sobie punkty od takiej oferty. A jak ta przestrzeń jest jeszcze za szkłem od strony korytarza to już całkiem.

Zanim coś podpiszecie też chciejcie zobaczyć miejsce swojej ewentualnej pracy. To Wam więcej powie niż wiele pytań do pracodawcy.

Dobrze pytać o swoje interesy i od razy być asertywnym.

A tak na serio wracając do meritum tematu to uważam, że dobrym sposobem na poznanie menadżera(zakładając że z menadżerem będziemy podpisywać i on będzie miał nasza umowę) czy ogólnie firmy z ktora będzie się współpracować jest próba negocjacji różnych zapisów w umowie. Cokolwiek, dobrą piaskownicą są te zapisy o zakazie konkurencji. Tam często można coś znaleźć.

Nawet nie musi wyjść na wasze, ale chodzi o sposób komunikacji, o podejście do Ciebie, o to czy jest gotowy pójść na kompromis nawet wiedząc, że nic nie może zrobić, czy jest odklejony od rzeczywistości itd.
No i mając obraz takiej osoby wiesz czy dasz radę z kimś takim współpracować "nacodzień".

Czy jest obowiązkowy on-call?

Ile jest komunikacji z zagranicą - szczególnie USA z uwagi na duży rozstrzał stref czasowych

Sam już nie wiem, o co pytać, jeśli chodzi o organizację zespołu, firmy czy developmentu, bo potem w pracy i tak jest często odwrotnie, niż powiedzą. Dajmy na to jak startowałem na juniora pracodawca zapewniał mnie np., jak ważna jest dla niego piramida testów, dokumentacja kodu, CI/CD, code review, dobra komunikacja i swoboda w organizacji pracy. Ale nie wspomniał, że te testy i dokumentacja jeszcze nie istnieją i to ja będę musiał je stworzyć od zera po godzinach, CI/CD nie działa, code review to ja mam robić innym, organizacyjnie zespół leży i to ja mam go wyprowadzić z gruzów, a swoboda kończy się w miejscu, w którym zarząd wymyśli sobie jakąś nierealną bzdurę, która rozwali całą pracę, ale jak masz wątpliwości, to nie jesteś proaktywny/multitaskingowy/komunikatywny, itd. Także chyba nie ma sensu zadawać tego typu pytań.

Dlatego teraz jak mnie zainteresuje np. działka, którą się firma zajmuje, a pracodawca nie zakrywa się jakąś ochroną informacji niejawnych (co też mi się zdarzyło przy zupełnie ogólnym pytaniu, czego dotyczy właściwie projekt, do którego jestem rekrutowany - uznałem to za red flag obok gadki, że "pracujemy on-site, bo zdalnie nie można pracownika tak dobrze przypilnować"), to o to pytam. A generalnie skupiam się na konkretach do umowy, bo tylko to co na papierze, jest może niekoniecznie 100% pewne, ale przynajmniej częściowo egzekwowalne.

Czy będę miał local admin rights do sprzętu na którym pracuje?

Ja mam swoją listę pytań, i szczerze mówiąc jest coraz dłuższa, wraz z kolejnymi przygodami zawodowymi i kolejnymi rozczarowaniami. I proponuję Wam naprawdę pytać o rzeczy, które wydają się być oczywiste... Dopóki się gdzieś nie zatrudnisz, i się okaże, że jednak nie są.

Jako backendowiec, polecam zapytać, ile będziesz miał RAM na swoim komputerze - np w BBH mamy 16gb - co naprawdę jest dużym ograniczeniem naszej produktywności, biorąć pod uwagę olbrzymi projekt, samo indeksowanie trwa wiecznie, już nie mówiąc o puszczaniu testów integracyjnych na lokalnym środowisku. No ale nie da się z tym zrobić NIC.

Teraz, to bym się na pewno pytał, czy można używać narzędzi AI, bo np u nas nie można, poblokowane są takie rzeczy - jak np CoPilot czy ChatGPT - co sprawia, że jestem trochę do tyłu.

I jak jesteś w Javie, to warto zapytać, czy jest IntelliJ - żeby się nie okazało potem, że nie ma :)

A poza tym, to koniecznie bym zapytał, jak promują pracę zepołową - czyli co ludzie z tego mają, jeśli pomagają sobie nawzajem, zamiast skupiać się na zrobieniu swojego jak najszybciej. Jeśli nic, a do tego mają presję - duża szansa, że atmosfera nie będzie zbyt przyjazna / kooperacyjna.

Warto zapytać, kto estymuje taski - choć tutaj trochę różnie z tym bywa, bo mój manager uważa, że zespół - a robi to on, jako członek zespołu ;-)

A tak ogólnie, to strategię mam taką, żeby przede wszystkim moje pytania to nie było ostatnie 5 minut z rozmowy technicznej - tylko żeby umówić się z zespołem, managerem, na osobną pogawędkę, jeszcze przed podpisaniem umowy, ale już po przejściu procesu rekrutacyjnego - żeby być pewnym, na co się piszę. Raczej nikt z tego żadnego problemu nie robi, jest raczej w drugą stornę, potencjalny manager/kolega z zespołu/pracodawca cieszy się, że podchodzę do sprawy poważnie i chcę zmaksymalizować szansę na to, że obie strony będą zadowolone :)

Aha, i jeszcze jedna sprawa - kiedyś tak miałem, że rekrutował mnie spoko manager do spoko projektu - rozważając wszystkie za i przeciw, przyjąłem ofertę wiedząc, na co się piszę... A potem przyszła informacja, ze zostaję przeniesiony do innego zespołu/projektu - i on już taki spoko nie był... Więc warto się zapytać, czy istnieje takie niebezpieczeństwo.

Od siebie polecę zapytać się o to czym zajmuje się nasz zespół.
Raz wprost gość mi powiedział że robią narzędzie wewnętrzne, więc są wprost działem kosztowym, który w teorii nie przynosi zysków.
W razie cięć często bywają to działy które pierwsze są ucinane.

Druga sprawa to pytanie o to czy w ramach stanowiska będziesz zajmował się supportem (emergency calle itp)
Kto i jak estymuje taski oraz przed kim bezpośrednio odpowiadasz żeby się nie okazało że to jakaś choras struktura korpo gdzie mogą Cię cisnąć managerowie z dwóch działów zależy gdzie będzie problem.