Rozmowa techniczna, czyli… jaka?
Bierzesz udział w rekrutacji w IT na wymarzone stanowisko testera automatyzującego. Wysłałeś CV, odbyłeś krótką rozmowę telefoniczną z działem HR i po pozytywnej ocenie dostałeś zaproszenie na dłuższą „rozmowę techniczną”. Dowiedziałeś się, że oprócz kompetencji miękkich obejmować ma ona swoim zakresem również weryfikację umiejętności technicznych. Czego konkretnie się spodziewać w trakcie takiej rozmowy? Jako lider techniczny w obszarze QA często jestem po tej drugiej stronie i dziś chciałbym opowiedzieć o rekrutacji z mojej perspektywy oraz ułatwić kandydatom przejście takiej rozmowy.
Analiza CV
Zanim kandydat zjawi się na rozmowie technicznej, analizuję nadesłane CV. Z racji pracy w firmie outsourcingowej patrzę na nie pod dwoma kątami:
- Czy doświadczenie i umiejętności kandydata pasują do wymagań danego klienta?
- Jaką wartość umiejętności kandydata wniosą w rozwój firmy i zespołu testerskiego?
Często jest tak, że profil kandydata jest sprecyzowany przez klienta i wtedy sprawa jest dość prosta. Mając listę wymagań (np. znajomość konkretnego języka i narzędzi, doświadczenie w testach danego typu itp.), analizuję CV, wynajduję w nim pożądane cechy, a następnie nawiązuję do nich w trakcie rozmowy, aby otrzymać szerszy kontekst. Przejdźmy więc do samej rozmowy.
CV – od ogółu do szczegółu
Jeśli przykładowo klient wymaga, aby kandydat miał doświadczenie w testach wydajnościowych, a w CV widnieje ogólny punkt: „testy manualne, automatyczne, wydajnościowe”, pytam o przebieg testów:
- Kto przeprowadzał testy i kiedy?
- Z wykorzystaniem jakich narzędzi?
- Po co testy były wykonywane?
- Jaki miały wkład w proces wytwarzania oprogramowania?
Z odpowiedzi kandydatów można wiele wywnioskować na ten temat:
- To były takie bardzo proste testy wykonywane Postmanem” – taka odpowiedź jasno sugeruje, że kandydat ma niewielkie doświadczenie w tym obszarze.
- Nasz produkt musiał spełnić określone wymagania. Testy były wykonywane po każdej wydanej wersji, aby porównać, czy zmiany nie pogorszyły wydajności. Ponadto pozwalały nam identyfikować miejsca, które w przyszłości mogłyby stać się słabymi ogniwami. Dodatkowo potwierdzaliśmy nimi skuteczność optymalizacji procesów przed wdrożeniem u klienta końcowego i stanowiły one podstawę do podejmowania decyzji biznesowych, jeśli chodzi o dalszy rozwój produktu” – taka odpowiedź przekonuje mnie, że kandydat ma doświadczenie w tym temacie i możemy szerzej rozmawiać o testach wydajnościowych.
Jak chcesz się rozwijać?
Rozmowa o określonych umiejętnościach to dla rekrutującego również dobry moment, aby określić, w jakiej dziedzinie kandydat chce się rozwijać. I tu odpowiedzi mogą być różne: „Chętnie rozwinę swoje umiejętności w zakresie testów wydajnościowych, bo moje obecne doświadczenie jest niewielkie” czy „Chciałbym nadal zajmować się automatyzacją testów, ale interesują mnie również zagadnienia związane z TestOps’em”
Dlaczego pytam o chęć rozwoju w danej dziedzinie? To ważne z punktu widzenia rozwoju całego zespołu testerskiego, do którego ma dołączyć nowa osoba. Od tego zależy, czy będziemy mieć w niedalekiej przyszłości specjalistę ds. testów wydajnościowych, czy może testera potrafiącego od zera skonfigurować środowisko testowe. Takie informacje są też istotne dla firmy m.in. podczas rozmów z klientami o nowych projektach czy też podczas planowania budżetów szkoleniowych. Kolejnym etapem rozmowy jest sprawdzenie umiejętności technicznych. Możliwości jest wiele - opiszę pokrótce te które uważam za wartościowe.
Opowiedz mi o Twoich doświadczeniach
Poza rozmową o przyszłości pytam też o dotychczasowe projekty i doświadczenia:
- Jakie były Pana / Pani zadania w projekcie?
- Jaki był Pana / Pani wkład w tworzony projekt testów automatycznych?
- Jak wyglądała współpraca z innymi członkami zespołu developerskiego?
- Kto wybrał taki zestaw narzędzi do testów automatycznych?
Tego typu pytania pozwalają rozszerzyć profil kandydata o aspekty, które w CV były ujęte bardzo skrótowo. Przykładowo zdarzyło się kiedyś, że jeden z kandydatów napisał w CV: „Tworzenie testów automatycznych”. Po kilku dodatkowych pytaniach okazało się, że nie chodziło wcale o samo pisanie skryptów. Ten kandydat przekonał nie tylko zespół, ale też klienta, do konieczności posiadania testów automatycznych, zaproponował narzędzia, stworzył odpowiedni projekt, a następnie go wdrożył i jeszcze dodatkowo wpiął w istniejący proces CI/CD.
Sprawdźmy, co potrafisz
Kolejnym etapem technicznej rozmowy kwalifikacyjnej jest sprawdzenie umiejętności technicznych. Możliwości jest wiele. Opiszę pokrótce te, które uważam za wartościowe.
„Kodowanie” na żywo
Słowo „kodowanie” celowo wziąłem w cudzysłów, ponieważ zadaniem kandydata nie jest napisanie poprawnego (tzn. kompilującego się) kodu testów, ale skorzystanie z pseudokodu. Takie podejście pozwala uniknąć problemów takich jak:
- Nie pamiętam, jak się nazywała ta metoda.
- Tę wartość ustawiało się gdzieś we właściwościach, ale nie pamiętam w którym okienku.
- Zapomniałem, że bez dodatkowych bibliotek to nie zadziała.
Celem zadania nie jest napisanie kodu z pamięci z zachowaniem wszystkich niuansów danego języka, lecz pokazanie swojego pomysłu na test. Mnie jako rekruterowi pozwala to zobaczyć, jak kandydat podchodzi do tematu tworzenia testów automatycznych, w tym do kwestii nazewnictwa testów, przygotowania danych wejściowych, wykonania akcji, weryfikacji ich skutków etc. Dlatego właśnie uważam tę metodę za tak wartościową.
Code review
Aby zweryfikować umiejętność posługiwania się konkretnym językiem programowania, chętnie stosuję zadanie polegające na wykonaniu przez kandydata code review przygotowanego wcześniej kodu testów automatycznych. Nie tylko pokazuje ono podejście danej osoby do tworzenia testów (w aspektach wymienionych wcześniej), ale pozwala również zweryfikować jej wiedzę techniczną. Zatem, sprawdzić:
- czy kandydat zna użyte w kodzie narzędzia,
- czy zaproponuje zmianę w wybranym miejscu kodu, gdyż ten celowo został napisany niepoprawnie itp.,
- czy zna dobre praktyk programowania (np. czy kod nie jest zduplikowany lub czy nie warto użyć jakiegoś wzorca projektowego np. Page Object Pattern),
- czy zwraca uwagę na istotne szczegóły (np. czy tytuł testu i asercja są tożsame, tzn. w teście faktycznie weryfikowane jest to, co powinno).
Zadanie do samodzielnego wykonania
Czy zadanie jest nieodłącznym elementem rozmowy technicznej? Wiele zależy od organizacji i tego, czy dana firma może sobie pozwolić na tego typu weryfikację. To tak naprawdę sprawdzian zarówno dla kandydata, jak i dla mnie jako rekrutera. Tę formę weryfikacji uważam z jednej strony za bardzo kompleksową, z drugiej zaś za bardzo wymagającą (dla obu stron!).
Jest ona kompleksowa, ponieważ sprawdza wszystkie aspekty tworzenia testów automatycznych – od analizy dokumentacji dołączonej do zadania, poprzez stworzenie projektu testów, jego konfigurację, aż po stworzenie samych testów.
Dlaczego jest wymagająca dla kandydata? Ponieważ rzadko kiedy takie zadanie można wykonać „od ręki”. Zazwyczaj potrzeba na to kilku godzin, co w praktyce może oznaczać poświęcenie kilku dni na jego realizację. Dodatkowo zadanie będzie oceniane surowiej i wnikliwiej niż pseudokod napisany na żywo w trakcie rozmowy.
Jako rekruter też jestem silniej zaangażowany w tego typu weryfikację. Po pierwsze – zadanie musi być przygotowane z głową. Kandydat powinien mieć jasną informację, czego się oczekuje, co jest dozwolone, a co nie, co ma być zawarte w projekcie, a także na czym, na jakim obiekcie zadanie ma być wykonane.
Sposób zdefiniowania zadania to także ważna informacja dla kandydata na temat firmy. Spotkałem się kiedyś z zadaniem, które brzmiało: „Proszę stworzyć testy automatyczne, uruchomić je, nagrać film z tego, jak się wykonują w przeglądarce, i wysłać go do nas” czy też „Proszę przygotować jakikolwiek projekt testów automatycznych dla dowolnie wybranej strony”. W mojej opinii tak zdefiniowane zadania nie świadczą dobrze o procesie rekrutacji.
Dobrze przygotowane zadanie powinno zawierać takie informacje jak:
- obiekt do przetestowania (np. API lub strona internetowa; najlepiej, żeby były przygotowane przez firmę rekrutującą),
- dokumentacja,
- oczekiwania, np. typ testów (API, GUI), ich liczba, w jakim języku mają być przygotowane, jakie narzędzia są dozwolone lub zabronione itp.,
- forma, w jakiej należy dostarczyć zadanie (np. projekt na GitHubie),
- czas wykonania / termin dostarczenia.
Ocena zadania
Ja, jako osoba przygotowująca zadanie, muszę mieć też zdefiniowany sposób jego oceny. Biorę pod uwagę, które wymagania zadania zostały spełnione, a które nie, co kandydat zrobił dobrze, co zostanie uznane za błąd, a o czym chciałbym dodatkowo porozmawiać itp. Taka analiza pozwala mi jako rekruterowi przygotować się do rozmowy o zadaniu lub udzielić informacji zwrotnej o powodzie zaakceptowania / niezaakceptowania zadania, a tym samym zaakceptowania / odrzucenia kandydatury. No i jeszcze jedna ważna kwestia związana z samym zadaniem: wielu kandydatów reaguje na ten etap rekrutacji zniechęceniem: „Zadanie do zrobienia w domu? A to nie. Szkoda na to czasu. Nic z tego nie ma”. Jako rekruter ze swojej strony staram się z góry poinformować o tym, iż po wykonaniu zadania dostarczona zostanie informacja zwrotna. W mojej ocenie warto decydować się na rozwiązywanie samodzielnych zadań. Nawet jeżeli dostaniesz negatywną odpowiedź, to dowiesz się, co poszło nie tak i co powinieneś poprawić w przyszłości.
Albo wiesz, albo…
Na początku kariery w branży zdarzyło mi się na kilku rozmowach usłyszeć pytania typu: „Jaki będzie kod odpowiedzi HTTP, gdy spróbuje Pan pobrać zasób bez praw do niego?” czy „Jakiej metody użyje Pan, aby poczekać, aż element będzie widoczny na stronie?”. Wówczas takie pytania uważałem za świetne narzędzie do weryfikacji technicznej. Dlaczego? Bo są niemalże zero-jedynkowe: albo się wie, albo nie.
Jednakże z upływem czasu oraz nabraniem nowych doświadczeń jako rekruter dochodzę do wniosku, iż tak naprawdę nie sprawdzają się one w procesie rekrutacji. Dlaczego? Kody odpowiedzi są ustandaryzowane, w związku z czym ustalenie ich znaczenia to kwestia sięgnięcia do dokumentacji. Metoda czekająca na element? W zależności od użytego narzędzia do automatyzacji będzie się nazywać inaczej i będzie wymagać innej implementacji w kodzie. W efekcie jedyne, co uzyskamy, to informacja, czy kandydat zna (lub nie) konkretne narzędzie lub technologie, a nie czy posiada wystarczającą wiedzę i umiejętności, aby być w stanie zrealizować stawiane przed nim zadania w czasie codziennej pracy.
Podsumowanie
W procesie rekrutacji istotne są zarówno ocena umiejętności miękkich, jak i technicznych kandydata. Z mojej strony staram się, aby rozmowa techniczna była jak najbardziej przyjazna, ponieważ jestem zdania, że to sprawdzian nie tylko dla kandydata, ale też rekrutera. Weryfikacja techniczna wiele mówi kandydatom o firmie, do której aplikują, oraz pozwala im zlokalizować obszary do poprawy. Mam nadzieję, że udało mi się pokazać rozmowę techniczną jako ważny element samorozwoju, a nie „jaskinię lwa”, której obawia się tak wielu kandydatów. Powodzenia na waszych rozmowach technicznych i wielu kreatywnych zadań do rozwiązania!
O autorze
Mariusz Skomra to Senior QA Engineer oraz Technical Leader w JCommerce. Żadna przygoda w jego życiu zawodowym nie zaczęła się od: „Potrzymaj mi sałatkę!”, ale wiele zaczęło się od: „Mariusz – mam problem. Pomożesz?” Z wykształcenia biotechnolog, z zawodu tester automatyzujący. Obecnie doskonali swoją wiedzę z Javy w kontekście testów automatycznych aplikacji webowych oraz API. Prywatnie fotograf.