Home

Pytania, które programista powinien zadać swojemu potencjalnemu pracodawcy, part 5 – technologia

Piąta część serii pytań, które warto zadać pracodawcom podczas rozmowy o pracę. Tym razem część technologiczna.

Pozostałe części cyklu:

Jakie technologie używane są w firmie? Jakie technologie używane są w projekcie do którego trafisz?

Na początek — pamiętajmy że technologia to tylko narzędzie, które dobiera się na potrzeby rozwiązania określonego problemu. Jednak tych narzędzi istnieje ogrom, a Ty też masz takie które lubisz lub wręcz przeciwnie.

Firmy mogą (ale nie muszą) specjalizować się w określonych technologiach, np. wybierając ekosystemy Microsoftu lub Oracle (korporacje), a mniejsze firmy często wybierają na backendzie Pythona, Ruby czy Node.js.

W przypadku projektu technologia jest najważniejsza, bo właśnie jej będziesz używać na codzień. W przypadku front-endu będzie to np. bazowy framework, język (js/ts) czy sposób tworzenia css. Na backendzie język, rodzaj bazy danych czy sposób hostingu (AWS, Azure, self hosted).

Warto zapytać jakie zespół ma podejście do obecnej technologii, czy są z niej zadowoleni, czy są otwarci na zmiany (ja np. nie wyobrażam sobie wrócić z TypeScriptu na JavaScript — reakcja firmy w tej kwestii jest dla mnie istotna), a finalnie samemu odpowiedzieć sobie czy technologia jest zgodna z naszymi planami rozwoju.

Wiedza na temat technologii używanej w firmie i innych projektach może mieć dla nas dodatkowe znaczenie. Przykładowo będąc front-endowcem znam JS, a ten pozwala mi pisać aplikacje w Node.js, za to całkowicie obce jest mi np. Ruby i nie chcę się go uczyć. Wtedy firma z Node będzie dla mnie mieć ekstra atut.

Czy w projekcie do którego trafisz jest legacy code?

Pytanie niewygodne, ale raczej niewiele osób będzie w stanie skłamać prosto w oczy bez widocznych oznak (przynajmniej nie programista). Możemy popytać jak długo trwa już projekt, czy był/jest na coś przepisywany, jak oceniają obecny dług technologiczny (da się to oszacować). Jak wiadomo chyba każdemu, praca nad kodem zastanym jest przeważnie straszna, stresująca i generuje dużo przekleństw. Ja sam wolę pracować za mniejsze pieniądze, ale w projekcie o dobrej jakości.

Czy są pisane testy? W firmie, w projekcie i jakie jest podejście biznesowe?

Dobre pokrycie testami ma cały szereg zalet. Nie tylko kod jest wyraźnie lepszej jakości i łatwiej na nim pracować, ale też dużo przyjemniej i szybciej wdrożymy się do obecnego kodu. Testy mówią nam co kod powinien robić, zamiast czytać implementacje, a ponadto daje nam poczucie bezpieczeństwa, że nie zepsujemy czegoś zbyt łatwo.

Mimo oczywistych zalet, pisanie testów często jest omijane, czy to z lenistwa (lub braku umiejętności) programistów, czy z powodu managerów/biznesu, którzy pędzą z terminami i zasobami.

Z mojego doświadczenia najwięcej testów możemy spotkać w korporacjach i stabilnych start-upach — czyli firmach które tworzą swoje produkty lub utrzymują je przez długi czas. Wtedy ROI testów jest zauważalnie wyższe, a firmy mają więcej czasu zasobów by o nie zadbać. Po drugiej stronie medalu często stoją agencje i software house’y, które mimo zapewnień o “wysokiej jakości kodu”, często robią dużo krótkich projektów. Te szybko mają z głowy bo oddają je klientowi i to on (lub firma, która będzie to utrzymywać) musi się martwić.

Warto podrążyć temat jakie podejście do testowania w szczególności ma biznes. Dobry sprzedawca czy manager znajdzie sposób na przekonanie klienta, że czas poświęcony na testy się opłaci.

Ile zajmie Ci wdrożenie się w codebase, jak dużo czasu potrzebujesz by stać się produktywny?

W przypadku agencyjnych projektów raczej nie ma to większego znaczenia — jest spora szansa że dostaniemy “czysty” projekt lub o niewielkiej skali.

W przypadku dużych projektów, które trwają latami a przewinęło się przez nie dziesiątki programistów, wdrożenie może zająć nam nawet kilka miesięcy. Musimy wtedy być gotowi, że nie będziemy przez długi czas nic programować, a bardziej uczyć się wiedzy domenowej i czytać zastany kod.

Czy jest możliwy “first day commit”? Ile czasu minie do Twojego pierwsze produkcyjnego deploya?

First day commit jest symbolicznym “dowodem” na dobrze zorganizowany, skonfigurowany, czytelny i prosty projekt oraz proces.Jeśli odpowiedź kategorycznie brzmi “tak” (ewentualnie drugi dzień ;)), to dobry znak. Przychodząc pierwszego dnia powinniśmy mieć wszystkie dostępny, instalacja i konfiguracja projektu powinna być szybka i automatyczna, a proces zadaniowy elastyczny i zrozumiały, co pozwoli nam praktycznie natychmiast “coś zrobić” w projekcie.

Kolejnym krokiem może być pytanie o pierwszy produkcyjny deploy. Zadając je dowiesz się kto odpowiada za deploye, czy są jakieś ograniczenia związane z bezpieczeństwem, jak często releasują projekt itd.

Jak długo zajmie Ci setup projektu? Godziny czy tygodnie?

Idealną odpowiedzą jest kilka minut, czyli czas poświęcony na pull repozytorium i zainstalowanie (czyli npm git clone … && npm i && npm start). Cała reszta dobrze gdyby “robiła się sama”. Oznacza to, że projekt (i ludzie go tworzący) ja na tyle dojrzały, że zadbano o odpowiednie automatyzacje i konfiguracje.

Jeśli odpalanie projektu wymaga od nas dużo czasu, może to oznaczać duży coupling i zależności, monolitową architekturę i inne niefajne rzeczy o które warto dopytać.

Warto zapytać też o stan dokumentacji projektu.

Jak długo będziesz czekać na niezbędne dostępy, konta, uprawnienia?

Pytanie pokrewne do poprzedniego i częściowo z nim związane.

Szczególnie w środowiskach korporacyjnych, musimy posiadać masę dostępów do różnych, często topornych narzędzi, a te załatwiają odpowiedni ludzie w odpowiednich działach… Co potrafi trwać, a my będziemy siedzieć tygodniami i czekać na dostępy by móc zacząć pracować.

Dobrym znakiem jest, gdy wszystko co trzeba zostanie ustawione zanim jeszcze rozpoczniemy pracę, a ilość niezbędnych narzędzi będzie ograniczona. W jednej firmie miałem trzy różne narzędzia do samych urlopów…

Opieszałość w tych kwestiach może zapalać lampkę w kwestii sprawności procesów w firmie. Jeśli nie lubimy typowych “korpo” gdzie maszyna toczy się wyjątkowo topornie, możemy tutaj popytać nieco głębiej.

W jaki sposób projekt jest zautomatyzowany?

Zależnie od środowiska, mogą to być narzędzia do automatyzacji procesów (np. automatyczne generowanie commitów, PR, łączenie się z Jirą etc), budowania (CI tool), generatory kodu, skonfigurowane lintery, formatery kodu itd.

Jeśli automatyzacja tego typu jest rozwinięta, dobrze to świadczy o projekcie i o zespole.

Jak często są releasy? Czy jest continuous delivery/deployment?

Na koniec, pytanie o sposób (praktykę) w jaki projekt jest dostarczany. Absolutne minimum to skonfigurowany pipeline continous integration, który buduje projekt, odpala testy itd. Dobrym znakiem jest automatyzacja deploymentu. Continous delivery pozwala szybko i efektywnie releasować (i tutaj pytanie czy są jakieś procesy w tym aspekcie), a continous deployment świadczy o wysokiej jakości kodu i zaufaniu że nic na produkcji się nie powinno zepsuć.


To koniec części czysto technicznej. Zapraszam do zobaczenia pozostałych części tej serii oraz czystej listy pytań na moim GitHubie.

W przypadku technologii pamiętajcie o swoich własnych pytaniach, związanych z technologią w jakiej się poruszacie. Dla mnie technologie back-endowe będą mniej istotne niż front-endowe, bo to z nimi będę mieć styczność na codzień.