Tester oprogramowania / QA (Junior)
Zakres wiedzy. W przypadku początkującego testera oprogramowania (QA) zakres wymaganej wiedzy różni się od typowo programistycznych stanowisk. Tutaj kluczowe są podstawy testowania i jakości. Oto, co powinien wiedzieć junior tester:
• Proces testowania: Zrozumienie, że testowanie to nie tylko “klikanie po aplikacji”, ale proces składający się z etapów planowania, przygotowania przypadków testowych, wykonania testów i raportowania wyników. Kandydat powinien znać pojęcia takie jak plan testów, przypadek testowy, scenariusz testowy, raport błędu.
• Podstawowa terminologia: Warto znać definicje i różnice między rodzajami testów (funkcjonalne vs niefunkcjonalne, regresja, testy eksploracyjne itd.), a także poziomami testów (unit, integracyjne, systemowe, akceptacyjne). Np. często pytają o rozróżnienie testów manualnych i automatycznych, rodzaje testów (dymne, ad-hoc, bezpieczeństwa itp.).
• Cykl życia defektu (buga): Co się dzieje od wykrycia błędu do jego naprawy – zgłoszenie, triaż, naprawa, retest, zamknięcie. Tester musi wiedzieć, jak prawidłowo zgłosić błąd: opis, kroki reprodukcji, oczekiwany vs faktyczny rezultat, priorytet/severyt (krytyczność) błędu, wersja środowiska.
• Wiedza z podstaw IT: Tester, choć nie programuje dużo (w przypadku testera manualnego), powinien rozumieć kontekst technologiczny. Przyda się ogólna znajomość metodyk tworzenia oprogramowania (Agile/Scrum vs Waterfall), roli testera w zespole oraz narzędzi typu JIRA (do zgłaszania bugów). Coraz częściej mile widziane są też podstawy SQL (np. umiejętność sprawdzenia czegoś w bazie danych prostym selectem) oraz podstawy HTTP/API (bo testowanie API lub używanie Postmana to częsty element).
• Automatyzacja testów (podstawy): Nawet jeśli aplikujesz na testera manualnego, pytania o automatyzację mogą się pojawić, bo rynek idzie w tym kierunku. Dobrze przynajmniej orientować się, co to jest Selenium/WebDriver, do czego służą testy jednostkowe (pisane przez devów) i co to znaczy Continuous Integration z perspektywy QA. Jeśli masz za sobą jakieś kursy z automatyzacji (np. podstawy Pythona czy Javy pod testy), koniecznie o tym wspomnij. Pamiętaj jednak, że programowanie nie jest głównym wymogiem na stanowisku testera manualnego – to umiejętność “mile widziana”.
• Wrażliwość na jakość i szczegóły: Tester musi być dociekliwy. Rekruter może sprawdzić Twoją spostrzegawczość i podejście do szczegółów choćby pytając, jak przetestujesz prostą funkcjonalność (np. pole logowania). Tu potrzebna jest wiedza implicite – np. że należy sprawdzić różne ścieżki (poprawne dane, błędne dane, puste pola, znaki specjalne itp.), przetestować walidacje, komunikaty błędów, zabezpieczenia (czy hasło się maskuje). Ta umiejętność analitycznego podejścia często odróżnia dobrych kandydatów.
• Kompetencje miękkie w kontekście testera: Warto mieć świadomość, że w przypadku testerów rekruterzy bardzo dużą wagę przywiązują do komunikacji i współpracy. Tester współpracuje z programistami, managerami, często to od jego raportów zależą decyzje o jakości produktu – dlatego umiejętność jasnego przekazywania informacji, dociekliwość i asertywność (potrafi obronić znaleziony błąd, który deweloper bagatelizuje) są oceniane równie mocno co wiedza techniczna.
Podsumowując, przygotuj się głównie z teorii testowania i praktycznych aspektów pracy testera. Certyfikat ISTQB Foundation nie jest wymagany, ale jego syllabus stanowi dobry spis treści tego, co trzeba umieć. Warto też znać specyfikę domeny, w której działa firma – np. testowanie aplikacji bankowych różni się od gier, dobrze pokazać, że rozumiesz branżę (np. w finansowej dokładność jest kluczowa, a w grach – doświadczenie użytkownika).
Przykładowe pytania techniczne. Na rozmowie testerskiej padnie zapewne kilka pytań teoretycznych oraz scenariuszowych. Przykłady pytań, jakich możesz się spodziewać:
• Jakie wyróżniamy rodzaje testów i czym różnią się od poziomów testowania? – kandydaci często mylą te pojęcia. Poprawna odpowiedź to np.: rodzaje testów (z perspektywy celu) to funkcjonalne, niefunkcjonalne, strukturalne i związane ze zmianami (regresja, retesty) – a poziomy (z perspektywy zakresu) to testy jednostkowe, integracyjne, systemowe, akceptacyjne. • Jaka jest różnica między weryfikacją a walidacją oprogramowania? – weryfikacja sprawdza, czy produkt jest budowany właściwie (zgodnie z założeniami, robimy “rzecz dobrze”), a walidacja – czy budujemy właściwy produkt (spełnia wymagania użytkownika). To klasyczne pytanie na podstawy jakości.
• Czym jest test eksploracyjny i kiedy się go stosuje? – warto umieć wyjaśnić, że to nieszczęśliwie zaplanowany test, w którym scenariusz tworzy się w trakcie eksploracji systemu, a celem jest odkrywanie nowych ścieżek i błędów. Innymi słowy, tester bada aplikację bez szczegółowej procedury krok po kroku, notując swoje obserwacje na bieżąco.
• Na co zwrócić uwagę przy zgłaszaniu błędu? – tu sprawdzana jest praktyczna wiedza. Odpowiedź powinna zawierać elementy dobrego raportu błędu: unikalny tytuł, jasny opis, kroki reprodukcji, oczekiwany vs aktualny rezultat, środowisko (wersja aplikacji, urządzenie), załączniki (zrzut ekranu) etc.. Warto też wspomnieć o ustaleniu priorytetu i stopnia ważności (severity) błędu.
• Czy tester jest odpowiedzialny za jakość produktu? – to podchwytliwe pytanie na myślenie. Dobra odpowiedź to “w pewnym sensie tak, ale nie tylko on” – tester dba o wykrycie błędów, ale cała organizacja odpowiada za jakość. Możesz powiedzieć, że tester dostarcza informacji o jakości, ale nie on jeden podejmuje decyzje o wypuszczeniu produktu.
• Pytania dot. SQL lub API: Np. “Jakim zapytaniem SQL sprawdzisz, ile rekordów spełnia dany warunek?” – tu wystarczy znajomość SELECT COUNT(*) ... WHERE .... Albo “Jak przetestujesz usługę REST API bez interfejsu użytkownika?” – odpowiedź: użyję np. Postman lub curl, wyślę żądanie GET/POST i sprawdzę kod odpowiedzi oraz body.
• Scenariusze testowe: Możesz zostać poproszony: “Masz aplikację kalendarz – powiedz, jak przetestujesz dodawanie wydarzenia do kalendarza”. W takiej sytuacji powinieneś wymienić różne scenariusze: dodanie poprawnych danych, skrajne dane (bardzo długi tytuł wydarzenia, data w przeszłości), brak wymaganych pól, konflikt dwóch wydarzeń o tym samym czasie, uprawnienia (czy inny użytkownik widzi mój event) itd. Ważne jest logiczne podejście – np. zacząć od przypadków pozytywnych, potem negatywne, graniczne.
Jak widzisz, pytania mogą być dość opisowe. Część firm zamiast pytań zrobi mini-test praktyczny: np. da Ci wydruk interfejsu i poprosi “wypisz jak najwięcej błędów, które na nim widzisz” lub poprosi, byś przetestował na żywo prostą aplikację testową. Dlatego kluczowe jest praktykowanie myślenia jak tester – nie tylko znajomość definicji.
Rekomendowane źródła do nauki. Kilka pomysłów, skąd czerpać wiedzę przygotowując się na testera:
• Syllabus ISTQB Foundation Level: nawet jeśli nie zdajesz teraz certyfikatu, warto pobrać sobie sylabus (dostępny za darmo, także po polsku) i przerobić zawarte w nim pojęcia. To pigułka teorii testowania – idealna, by upewnić się, że rozumiesz terminy (jak właśnie testy funkcjonalne/niefunkcjonalne, techniki projektowania testów itd.).
• Książki o testowaniu: Klasyczna pozycja to “Testing Computer Software” (Kaner, ang.), ewentualnie polska “Zawód Tester” (R. Smilgin) – ta druga jest przystępna i osadzona w realiach polskiego rynku. Możesz też zajrzeć do “Certyfikowany Tester ISTQB. Podstawy” (M. Łukasiewicz) jeśli celujesz w gruntowne przygotowanie.
• Kursy i blogi testerskie: W sieci jest sporo darmowych kursów podstaw testowania – np. na Udemy często znajdziesz “Software Testing for Beginners”. Polskie strony warte uwagi to testerzy.pl (portal o testowaniu, mają artykuły o technikach testowania) czy blogi doświadczonych testerów (np. Jakub Paczkowski, Remigiusz Bednarczyk – znajdziesz ich wpisy o tym, jak zacząć). Na YouTube poszukaj nagrań meetupów testerskich – dużo materiału jest np. na kanale WrotQA czy test:fest.
• Praktyka na własną rękę: Choć trudno o portfolio testera, możesz poćwiczyć testowanie na dostępnych aplikacjach. Wybierz dowolną aplikację webową (np. prosty sklep internetowy, blog) lub mobilną i spróbuj wypisać dziesięć znalezionych w niej potencjalnych błędów czy usprawnień. Możesz nawet napisać dla siebie raporty błędów na 2-3 znalezione defekty. To ćwiczenie pozwoli Ci nabrać wprawy w obserwacji i dokumentowaniu.
• Narzędzia: Jeśli masz czas, zaznajom się z podstawami narzędzi, z jakich korzystają testerzy: np. JIRA (issue tracker) – dostępna jest darmowa wersja, możesz założyć konto i zobaczyć jak wygląda formularz zgłoszenia błędu. Zapoznaj się też z Postmanem (narzędzie do testowania API) i np. z Selenium IDE (to prosty rejestrator testów automatycznych w przeglądarce – nawet jeśli nie będziesz tego używać, da Ci pojęcie jak działa automatyzacja testów UI).
• Społeczność testerów: Zajrzyj na forum Testerzy.pl, dołącz do grup na Facebooku (“Testowanie Oprogramowania” itp.), gdzie początkujący zadają pytania i dzielą się doświadczeniami. Często inni juniorzy opowiadają tam, jakie pytania dostali na rozmowie – bezcenna wiedza! Możesz też poszukać wydarzeń testerskich online – wiele z nich jest darmowych.
Typowe błędy kandydatów (QA). Przy rekrutacji testerów pojawiają się pewne częste błędy po stronie kandydatów:
• Zbyt teoretyczne podejście: Niektórzy juniorzy wykuwają na pamięć podręcznik ISTQB i na każde pytanie odpowiadają suchą definicją. To nie błąd per se, ale rekruter może odnieść wrażenie, że brakuje Ci praktycznego spojrzenia. Staraj się każdą definicję podeprzeć przykładem z życia (choćby wymyślonym). Np. mówiąc o testach integracyjnych, wspomnij “przykładowo, połączę moduł logowania z modułem resetu hasła i sprawdzę ich współdziałanie”.
• Brak dbałości o szczegóły podczas rozmowy: Paradoksalnie, tester który na rozmowie jest niedokładny (np. myli terminy, nie potrafi uporządkować wypowiedzi), może budzić wątpliwości. Staraj się być precyzyjny w słowach – ćwicz wcześniej odpowiadanie na pytania pełnymi zdaniami, klarownie. Jeśli dostaniesz zadanie testowe na żywo, notuj skrótowo swoje obserwacje, żeby niczego nie pominąć omawiając wyniki.
• Negatywne nastawienie do programistów: Czasem kandydaci (zwłaszcza ci przebranżowieni z nietechnicznych zawodów) podkreślają, że “tester to ten, co wytyka błędy programistom”. Taka postawa “kontroli jakości jako policjanta” nie jest dobrze widziana. Lepiej pokazać się jako partner w dostarczaniu jakości – ktoś, kto współpracuje z devami, żeby wspólnie dowieźć dobry produkt. Unikaj sugerowania, że będziesz rywalizował z programistami – stawiaj na współpracę.
• **Brak pewności siebie / zbyt duża pewność siebie: **To znów balans do uchwycenia. Jeśli masz jakieś doświadczenia (np. z kursu, projektu uczelnianego), śmiało o nich opowiadaj – podkreśl swoje atuty. Nie umniejszaj sobie (“Ja się dopiero uczę, pewnie są lepsi…”), bo zniechęcisz do siebie. Z drugiej strony, nie popadaj w arogancję – przyznawaj się, że masz jeszcze braki i chęć nauki. Rekruter chętnie zatrudni osobę, która wierzy we własne możliwości, ale jest otwarta na naukę.
• Kłamstwo lub wprowadzanie w błąd: To dotyczy każdej pracy, ale warte powtórzenia – nie kłam. Jeśli np. wpiszesz w CV “SQL – średniozaawansowany”, to bądź pewien, że ktoś to sprawdzi. Lepiej szczerze powiedzieć “znam podstawy, uczę się dalej” niż zostać przyłapanym. Zaufanie jest kluczowe, szczególnie wobec testera, który ma raportować o jakości produktu. Nikt nie zatrudni kandydata, który zachowuje się nieuczciwie lub kręci.
• Brak przygotowania o firmie: Tester powinien wykazywać dociekliwość – również wobec potencjalnego miejsca pracy. Jeśli zapytają Cię “Co wiesz o naszej firmie/produkcie?”, a Ty nie będziesz umiał nic powiedzieć, wyjdzie na jaw brak przygotowania. To częsty błąd kandydatów w ogóle. Rozwiązanie: zawsze przed rozmową poczytaj o firmie, zastanów się, jakie może stawiać wyzwania jakościowe dany produkt. Możesz nawet wspomnieć, że wypróbowałeś ich aplikację i masz parę spostrzeżeń (tylko ostrożnie – jak już, to przedstaw je bardzo dyplomatycznie, by nie zabrzmiało to jak krytyka na rozmowie).
• Zero pytań na koniec: Tak jak w innych rolach – jeśli kandydat nie ma żadnych pytań do rekrutera, sygnalizuje to brak zaangażowania lub przygotowania. Jako przyszły tester możesz spytać np. “Jak liczny jest zespół testów i czy pracuje według jakiejś metodyki (Scrum/Kanban)?”, “Jakiego rodzaju testy są u Państwa najczęściej wykonywane manualnie, a co jest zautomatyzowane?”, ewentualnie o używane narzędzia (Jira, test management, CI). To pokaże, że myślisz o swojej roli konkretnie.
Porady praktyczne. Kilka praktycznych wskazówek dla kandydatów na testerów:
• Trenuj myślenie testera: W codziennym życiu zacznij zauważać “błędy” w otaczających Cię systemach. Korzystasz z aplikacji mobilnej – pomyśl, co byś przetestował. Na stronie internetowej znalazłeś literówkę – jak byś to zgłosił? Takie nawyki wejdą Ci w krew i na rozmowie łatwiej będzie Ci wejść w tryb wyszukiwania problemów. Możesz też pobawić się w testowanie niefunkcjonalne: np. sprawdź wydajność jakiejś strony (czy ładuje się szybko), albo użyteczność (czy łatwo znaleźć potrzebne informacje). Pokażesz wtedy w rozmowie, że pasjonuje Cię jakość oprogramowania.
• Przygotuj przykłady ze swojego doświadczenia: Jeśli przebranżawiałeś się i masz za sobą projekt kursowy, opowiedz np. jak testowałeś własny projekt (nawet jeśli sam go programowałeś, mogłeś potem sprawdzić poprawność działania). Albo jeśli w poprzedniej pracy w innej branży dbałeś o jakość (np. kontrola jakości w fabryce, obsługa klienta gdzie liczyła się skrupulatność) – podkreśl to jako analogiczne doświadczenie. Istotne jest, by pokazać, że masz naturalną skłonność do wyłapywania błędów i poprawiania rzeczy. • Zademonstruj umiejętność raportowania: Możesz przygotować (dla siebie) przykładowy raport błędu, np. na podstawie jakiegoś open-source’owego projektu. Gdy zapytają Cię “czy umiesz napisać raport błędu?”, możesz odpowiedzieć twierdząco i opisać pokrótce strukturę. Możesz też wspomnieć, że ćwiczyłeś pisanie zgłoszeń na własne potrzeby – to pokaże inicjatywę.
• Zachowaj spokój przy zadaniu testerskim: Jeżeli rozmowa obejmuje live testing (np. dostajesz aplikację webową do sprawdzenia w ciągu 5 minut), kluczem jest systematyczność. Nie próbuj na oślep klikać wszystkiego. Zamiast tego powiedz głośno swój plan: np. “Najpierw przejdę główną ścieżkę dodania elementu do koszyka, potem sprawdzę przypadek brzegowy z pustym koszykiem, na koniec spróbuję wprowadzić niepoprawne dane w formularzu zamówienia”. Taka organizacja zrobi wrażenie. Notuj sobie szybko punkty, żeby o niczym nie zapomnieć, a po teście zreferuj w logicznym porządku, co znalazłeś. Jeśli czegoś nie zdążyłeś sprawdzić, też to powiedz – szczerość i profesjonalizm przede wszystkim.
• Podkreślaj komunikację i współpracę: W swoich odpowiedziach możesz wpleść elementy świadczące o tym, że rozumiesz rolę testera w zespole. Np. na pytanie o trudną sytuację możesz opowiedzieć hipotetycznie: “Gdy programista mówi ‘u mnie działa’, najpierw spokojnie weryfikuję, czy testowaliśmy na tym samym środowisku, czy może jest różnica w danych. Staram się nigdy nie iść na konfrontację, tylko wspólnie dojść do przyczyny błędu.” Pokazanie, że potrafisz dbać o dobrą komunikację i masz podejście “my kontra błąd” (a nie “tester kontra dev”) będzie dużym plusem.
• Nastawienie na ciągłą naukę: Możesz zostać zapytany, jak zamierzasz rozwijać się jako tester. Warto wspomnieć, że planujesz np. nauczyć się podstaw automatyzacji lub że interesujesz się jakimś narzędziem do testów wydajności. Nie musisz już to umieć, ale pokazanie chęci rozwoju jest kluczowe. Testerzy powinni być ciekawi nowych technik i narzędzi – pracodawcy cenią osoby, które same z siebie się dokształcają. Jeśli czytasz blogi lub książki testerskie, śmiało o tym opowiedz (tylko rzeczywiście coś przeczytaj wcześniej, żeby móc skomentować).
DevOps (Junior)
Zakres wiedzy. Stanowisko DevOps Engineer jest dość specyficzne – łączy wiedzę deweloperską z administracyjną. Od juniora DevOps oczekuje się szerokiej orientacji w wielu obszarach IT, raczej na poziomie podstawowym, ale solidnym. Oto najważniejsze z nich:
• Systemy operacyjne (Linux): Praktycznie każda rola DevOps wymaga znajomości środowiska Linuxowego. Musisz umieć pracować w terminalu – podstawowe komendy (nawigacja po systemie plików, manipulacja plikami i katalogami, uprawnienia, procesy). Pytania mogą dotyczyć np. sposobu sprawdzenia adresu IP maszyny, znalezienia procesu po numerze portu, użycia komendy grep czy różnicy między procesem a wątkiem. Często w ofertach DevOps powtarza się słowo Linux – to jedna z najczęściej wymaganych umiejętności.
• Networking (sieci): Zrozumienie podstaw działania sieci komputerowych jest kluczowe. Warto znać model OSI na poziomie ogólnym oraz protokoły TCP/IP, UDP – czym się różnią, jakie mają cechy. Konkrety: DNS (do czego służy, co to rekord A/CNAME, TTL), HTTP/HTTPS (kody odpowiedzi, nagłówki, różnice między metodami GET a POST), FTP/SSH (podstawowe zastosowanie, porty). Mogą paść pytania typu: “Co to jest DHCP i do czego służy?”, “Wymień najważniejsze metody HTTP i opisz kiedy się ich używa”. Jako DevOps będziesz często diagnozować problemy sieciowe, więc rozumienie np. czym jest ping, traceroute, NAT, firewall jest bardzo przydatne.
• Bazy danych: Może nie w takim stopniu jak u backendowca, ale DevOps powinien wiedzieć, czym różni się baza relacyjna od NoSQL, jak robi się backupy i restore bazy, co to replikacja, sharding. Często DevOps pomaga zarządzać bazami od strony infrastruktury, więc pytanie np. “Jak zrobić kopię zapasową bazy MySQL?” może się pojawić.
• Języki skryptowe: Zdolność do automatyzacji zadań jest sednem DevOps. Nie obejdzie się bez znajomości przynajmniej podstaw skryptów bash oraz często jednego języka skryptowego wyższego poziomu (Python, Go, Ruby – najczęściej Python). Junior DevOps nie musi być programistą aplikacji, ale powinien umieć np. napisać skrypt bash do monitorowania logów albo prosty skrypt Pythona do przeniesienia plików. Pytania mogą być praktyczne: “Jak napisać pętlę w bashu?”, “Jak w Pythonie zaimportować bibliotekę i zainstalować zależności?”. Możesz też dostać mini-zadanie do napisania (klasyczny FizzBuzz w bashu pojawił się nie raz).
• Konteneryzacja i wirtualizacja: Bardzo modne obszary, ważne by rozumieć ich istotę. Wirtualizacja – na czym polega (hiperwizor tworzy wirtualną maszynę z własnym systemem). Kontenery (Docker) – lekkie “wydzielone” środowiska wykorzystujące jądro systemu hosta. Trzeba wiedzieć, czym się różni kontener od VM, znać podstawowe komendy Dockera (build, run, stop, dockerfile basics). Często pada pytanie: “Czy można uruchamiać kontenery wewnątrz maszyny wirtualnej i po co?” (odpowiedź: tak, to powszechne – kontenery i VM to komplementarne techniki). Kubernetes na poziomie juniora raczej nie jest wymagany głęboko, ale warto znać koncepcję orkiestracji kontenerów i wspomnieć, że słyszałeś o K8s, nawet jeśli nie używałeś.
• CI/CD (Continuous Integration/Continuous Deployment): DevOps często opiekuje się pipeline’ami CI/CD. Dobrze wiedzieć, co to jest Jenkins, GitLab CI, GitHub Actions – przynajmniej jedno z tych narzędzi w teorii. Zapytają Cię np.: “Co to jest pipeline CI/CD i po co się go używa?” – odpowiedz, że to automatyzacja procesu budowania, testowania i wdrażania aplikacji, dająca szybsze i częstsze releasy. Możliwe pytanie: “Jak byś zaprojektował pipeline dla aplikacji X?” – tu wystarczy logicznie opisać kroki: build, uruchomienie testów, deployment na środowisko testowe, itd.
• Systemy kontroli wersji: Tak jak w innych rolach – Git jest standardem. Jako DevOps możesz być kimś w rodzaju “strażnika repozytorium”, warto więc rozumieć pojęcia: commit, branch, merge, rebase, tag, conflict. Mogą paść szybkie pytania np. “Czym różni się merge od rebase?” lub “Jak cofnąć ostatniego commita, który został już wypchnięty (push)?”. • Monitoring i logowanie: Podstawy monitoringu systemów – np. czy wiesz, jakie metryki serwera warto monitorować (CPU, RAM, I/O, liczba requestów, itp.), oraz przykłady narzędzi (Prometheus, Zabbix, Grafana – wystarczy nazwy). Logowanie – dlaczego centralizacja logów (ELK stack: Elasticsearch+Logstash+Kibana lub Graylog) jest przydatna. Tu raczej nie będzie szczegółowych pytań, chyba że wspomnisz, że coś używałeś.
• Security basics: DevOps dotyka też bezpieczeństwa: pojęcia typu SSH (klucze publiczne/prywatne), szyfrowanie (TLS), zarządzanie hasłami i sekretami (np. w pipeline nie trzymać jawnie). Może paść pytanie w stylu: “Czy wolno zapisywać hasła użytkowników w bazie w postaci czystego tekstu?” (oczywiście nie – trzeba hashować, np. bcryptem). Albo “Co jest bezpieczniejsze domyślnie: kontenery czy VM?” – tu celem jest wywołać dyskusję (kontenery współdzielą kernel, więc mają większe ryzyko przenikania, VM daje lepszą izolację – ale to temat rzeka).
• Cloud (chmura): Coraz więcej firm korzysta z AWS/Azure/GCP. Junior DevOps nie musi mieć certyfikatów, ale warto znać podstawowe usługi chmurowe: że istnieje coś takiego jak EC2 (serwery wirtualne), S3 (storage), że chmura rozlicza się w modelu pay-as-you-go, i znać zalety chmury vs on-premise (skalowalność, brak konieczności własnej infrastruktury). Często pytają: “Wymień trzech głównych dostawców chmury” (AWS, Azure, GCP). Jeśli firma w ofercie wymaga np. “podstawy AWS”, to przygotuj się, by powiedzieć czym jest EC2, RDS, może Lambda – chociaż hasłowo.
• DevOps mindset: To miękki punkt, ale istotny – czy rozumiesz w ogóle ideę DevOps (współpraca dev i ops, automatyzacja wszystkiego co możliwe, usprawnianie procesu wydawniczego). Możesz nie dostać bezpośredniego pytania “Czym jest DevOps?”, ale na pewno dobrze jest emanować zrozumieniem, że Twój cel to usprawniać pracę zespołu, a nie administracja dla samej administracji. Różne firmy różnie definiują tę rolę, więc warto wcześniej wyczuć, kogo szukają (bardziej developera do pisania skryptów CI/CD czy admina do zarządzania infrastrukturą).
Uff, dużo tego 😊. Junior DevOps to wymagająca pozycja ze względu na szerokość wiedzy. Nie panikuj jednak – nie musisz być ekspertem w każdym z powyższych punktów. Twoim zadaniem jest pokazać, że masz solidne podstawy i potrafisz szybko uczyć się nowych rzeczy. Jeśli jakiegoś hasła nie znasz (np. “Terraform”, “Kubernetes”), powiedz szczerze, że nie miałeś jeszcze okazji, ale wiesz, do czego służy i chcesz się nauczyć. Ważne, byś podstawowe zagadnienia miał opanowane – bez tego ciężko będzie przejść pozytywnie rozmowę techniczną.
Przykładowe pytania techniczne. Rozmowy DevOps bywają bardzo różnorodne – od teoretycznych pytań kontrolnych, przez zadania praktyczne (np. napisz skrypt), po dyskusje architektoniczne. Kilka przykładowych pytań na poziom junior:
• Czym różni się maszyna wirtualna od kontenera? – należy wytłumaczyć, że VM (Virtual Machine) emuluje cały sprzęt i system gościa, podczas gdy kontener działa na współdzielonym kernelu hosta, izolując procesy. Kontener jest lżejszy (mniej zasobożerny), VM bardziej izolowana.
• Co to jest CI/CD pipeline i jaką daje korzyść w projekcie? – odpowiedz, że to ciąg zautomatyzowanych kroków (Continuous Integration/Continuous Deployment), pozwalający na częste i niezawodne wdrażanie zmian w aplikacji. Pipeline buduje kod, testuje go i wdraża, co minimalizuje błędy ludzkie i przyspiesza release. Możesz wspomnieć narzędzie, które znasz (np. “konfigurowałem prosty pipeline w GitLab CI do budowania aplikacji Node.js”).
• Wymień narzędzia do monitoringu, które znasz. – np. Prometheus + Grafana, Zabbix, NewRelic, Datadog – tu nie trzeba szczegółów, raczej sprawdzają czy wiesz po co monitoring (by śledzić wydajność i stabilność systemów).
• Czym różni się protokół TCP od UDP? – TCP nawiązuje połączenie (handshake), gwarantuje dostarczenie pakietów i kolejność, jest stanowiony; UDP jest bezpołączeniowy, szybszy, ale bez gwarancji dostarczenia. Możesz dodać, jakie typy aplikacji używają jednego vs drugiego (TCP – np. HTTP, UDP – streaming video, DNS). • Jak w systemie Linux sprawdzić, który proces nasłuchuje na danym porcie? – poprawna odpowiedź: użyć np. lsof -i :numer_portu albo netstat -tulpn | grep port. To sprawdzi Twoje praktyczne obycie z Linuxem.
• Co to jest DNS i jaką rolę pełni? – System Nazw Domen, tłumaczy adresy tekstowe (domeny) na adresy IP; możesz dodać, że używa portu 53 (UDP, czasem TCP). • Jak działa proces startu (bootowania) systemu Linux? – to trudniejsze pytanie, raczej dla bardziej obeznanych, ale warto znać hasła: BIOS/UEFI -> bootloader (GRUB) -> kernel -> init/systemd (uruchomienie usług).
• Jakie znasz systemy kontroli wersji i po co się je stosuje? – tutaj wystarczy wymienić Git (pewnie jedyny, który realnie używałeś) i np. SVN jako starszy, i powiedzieć, że służą do śledzenia zmian w kodzie i współpracy wielu osób nad projektem.
• (Git) Czym różni się merge od rebase? – merge łączy gałąź zachowując historię commitów z merge commit na końcu, rebase “przepisuje” historię, nakładając commity z jednej gałęzi na drugą, tworząc liniową historię.
• (CI) Co to jest pipeline (w kontekście CI/CD)? – to definicja zadań CI/CD, np. zbiór kroków w Jenkinsie lub plik .yml w GitLab CI określający fazy build/test/deploy.
• Czy miałeś styczność z chmurą (AWS/Azure/GCP)? – jeśli tak, przygotuj się do pytań typu “co to EC2/S3/VPC” (jeśli AWS) albo ogólnie: “Co bardziej się opłaca: własna infrastruktura czy chmura?”. Tu nie ma jednej odpowiedzi – można powiedzieć, że chmura redukuje nakład administracyjny i pozwala skalować w górę/w dół, ale przy stałym dużym obciążeniu własna infrastruktura może być tańsza. To pytanie bada raczej Twój tok rozumowania i znajomość argumentów za i przeciw.
Pamiętaj, że w DevOpsie często ważniejsze jest jak myślisz niż ile wykułeś. Możesz dostać pytania nieoczywiste, czasem z błędem w treści specjalnie (żeby sprawdzić, czy się zorientujesz). Mogą też spytać o Twoje doświadczenia: “Opowiedz o najtrudniejszym problemie technicznym, jaki rozwiązałeś”. Przygotuj sobie historyjkę, nawet z projektów prywatnych (“Miałem problem ze skonfigurowaniem serwera nginx do obsługi wielu domen – nauczyłem się wtedy o wirtualnych hostach”). Ważne, by pokazać pasję i zdolność do samodzielnego rozwiązywania problemów.
Rekomendowane źródła do nauki. Ścieżka DevOps jest szeroka, ale na szczęście społeczność dzieli się wiedzą obficie. Oto kilka typów źródeł, z których warto korzystać: • Oficjalna dokumentacja narzędzi: Dokumentacje Dockera, Kubernetes, Ansible, czy Azure/AWS – one bywają długie, ale świetnie ustrukturyzowane. Zacznij od wprowadzeń / tutoriali w tych dokumentacjach. Np. “Docker Get Started” pokaże Ci podstawy konteneryzacji praktycznie.
• Interaktywne laby: Wspaniałym źródłem są strony z interaktywnymi scenariuszami, np. Katacoda (obecnie część O’Reilly) – pozwala przećwiczyć w przeglądarce scenariusze typu “uruchom pierwsze pod’y w Kubernetes”, “skonfiguruj serwer CI”. Podobnie Linux Survival czy OverTheWire (Bandit) – to ostatnie to gra konsolowa ucząca Linuxa i bezpieczeństwa. Poprzez praktykę szybko opanujesz wiele umiejętności.
• Blogi DevOps i case studies: Warto czytać doświadczenia innych – np. blog DevOpsiarz.pl, gdzie znajdziesz artykuły o rekrutacji DevOps (z setkami potencjalnych pytań) i różne poradniki. No Fluff Jobs również publikuje wpisy dla junior DevOps (np. “Jak zostać DevOpsem”). Czytanie takich materiałów pomaga zrozumieć, na co jest kładziony nacisk.
• Społeczność i open source: Dołącz do grup “DevOps Polska” na Facebooku czy Slacku/Discordzie (są polskie i anglojęzyczne społeczności). Tam można znaleźć rekomendacje kursów, pytania od innych juniorów i odpowiedzi ekspertów. Spróbuj też pobawić się open source: np. projektami na GitHubie związanymi z DevOps – możesz sklonować repozytorium któregoś narzędzia i uruchomić u siebie, by zobaczyć jak działa.
• Certyfikacje (opcjonalnie): Niektórzy zastanawiają się nad zrobieniem certyfikatu (np. AWS Certified Cloud Practitioner lub Linux Foundation Certified SysAdmin). Certyfikat sam w sobie Cię nie nauczy, ale przygotowanie do niego może usystematyzować wiedzę. Jeśli masz czas i środki, można rozważyć – jednak nie jest to konieczność na starcie. Ważniejsze jest realne zrozumienie zagadnień i umiejętność researchu (umiejętność szukania informacji to także cecha dobrego DevOpsa).
• Kursy online: Platformy takie jak Udemy mają kursy typu “Complete DevOps Bootcamp”, które dają przekrojową wiedzę – od dockera, przez CI, po chmurę. Upewnij się, że wybierasz aktualny kurs, bo narzędzia szybko się zmieniają. Na YouTube znajdziesz kanały edukacyjne (np. “TechWorld with Nana” – świetne grafiki tłumaczące Kubernetes, Terraform itd. po angielsku). Możesz też odwiedzić strony typu roadmap.sh – jest tam “DevOps Roadmap”, interaktywna lista technologii do poznania (dobry punkt kontrolny, żeby zobaczyć, czego jeszcze nie znasz).
**Typowe błędy kandydatów (DevOps). Startując jako junior DevOps, uważaj na następujące potknięcia: ** • Wymienianie mnóstwa narzędzi bez wiedzy praktycznej: Czasem kandydaci wrzucają do CV wszystko, co tylko słyszeli (“Docker, K8s, Ansible, Terraform, AWS, GCP…”), a potem nie są w stanie odpowiedzieć na proste pytanie z tego zakresu. Taka taktyka się nie sprawdza – rekruterzy wolą kogoś, kto zna mniej rzeczy, ale dobrze. Lepiej powiedzieć “nie pracowałem z technologią X” niż iść w zaparte. W dodatku pytania bywają podchwytliwe – mogą Cię zapytać o nieistniejącą technologię (żeby sprawdzić, czy przyznasz że nie wiesz, czy zaczniesz improwizować). Przyznanie się do braku wiedzy to żaden wstyd – udawanie, że coś wiesz, może Cię zdyskwalifikować.
• Braki w podstawach (tzw. “pykanie w chmurze bez zrozumienia”): Jeśli nauczyłeś się np. obsługi AWS poprzez klikanie w konsoli webowej, ale nie rozumiesz, co się dzieje pod spodem, to jesteś w słabszej pozycji. Przykład błędu: ktoś umie kliknąć “Deploy to Cloud” z gotowego szablonu, ale nie potrafi wyjaśnić, jak działa DNS albo co to jest adres IP. DevOps musi rozumieć fundamenty – buduj swoją wiedzę od dołu. W szczególności sieci i systemy operacyjne – tu nie ma drogi na skróty, trzeba to opanować.
• Nieumiejętność szukania informacji: To może nie wychodzi bezpośrednio na rozmowie, ale jeśli dostaniesz otwarte pytanie, np. “Co byś zrobił, gdyby aplikacja działała wolno na produkcji?”, to rekruter oczekuje zobaczenia Twojego sposobu myślenia, jak byś dochodził do przyczyny. Błędem jest strzelanie pojedynczej odpowiedzi (“na pewno serwer jest za słaby”) – lepiej pokazać, że przeanalizujesz różne możliwe przyczyny, sprawdzisz metryki, logi, etc. Pokaż, że wiesz jak się uczyć i diagnozować – bo w pracy DevOps ciągle uczysz się nowych rzeczy.
• Lekceważenie kwestii bezpieczeństwa: Jeśli rozmowa schodzi na tematy security (np. zarządzanie dostępami, szyfrowanie, backupy), uważaj aby nie palnąć czegoś, co świadczy o braku rozwagi. Np. “Hasła trzymam w Evernote” – zła odpowiedź 😉. Lepiej przyznać, że wiesz, iż bezpieczeństwo jest ważne i zawsze trzeba stosować się do zasad (nie musisz znać wszystkich, ale świadomość jest ważna). Jeśli padnie pytanie w stylu “czy wolno robić X” (np. wspomniane przechowywanie haseł w plaintext), a Ty powiesz, że nie widzisz problemu, to poważny minus.
• Zbytnia pewność siebie lub sztywność technologiczna: Może się zdarzyć, że znasz dobrze jedno narzędzie (np. Docker na wylot), i chcesz zabłysnąć. Uważaj jednak, by nie wyjść na osobę, która “pozjadała rozumy” – chwal się umiejętnościami, ale okazuj też otwartość. Jeśli np. firma używa innego systemu CI niż znasz, powiedz: “Nie pracowałem z X, ale znam zasady CI, więc szybko się przesiądę – w końcu narzędzia służą do tego samego celu”. Unikaj kategorycznych stwierdzeń typu “tylko Kubernetes ma sens, reszta to przeżytek” – nie znasz jeszcze dobrze kontekstu firmy.
• Nieprzygotowanie do rozmowy w języku angielskim: Wiele firm wymaga znajomości angielskiego (dokumentacja, komunikacja w międzynarodowych zespołach). Często więc fragment rozmowy, szczególnie na role techniczne, przechodzi w język angielski. Typowy błąd to ogromny stres w tej chwili. Jeśli wiesz, że Twój angielski może być sprawdzony, poćwicz przed rozmową opowiadanie o sobie i o technicznych rzeczach po angielsku. Zrób sobie fiszki z tłumaczeniem kluczowych słów (np. load balancer, outage, pipeline, script). To doda Ci pewności, gdy padnie: “Could you describe how DNS works, in English?”.
Porady praktyczne. Jak podejść praktycznie do rozmowy na junior DevOpsa:
• Pokaż swoje projekty DIY: W świecie DevOps bardzo cenne jest “zamiłowanie do technologii”. Jeśli hobbystycznie stawiałeś serwer do gry, własnego bloga na VPS, bawiłeś się Raspbery Pi – koniecznie o tym wspomnij. Np. “Postawiłem w domu własny serwer NAS na Raspberry Pi i zautomatyzowałem backupy zdjęć” albo “Skonfigurowałem pipeline GitHub Actions do automatycznego budowania mojego projektu”. Takie rzeczy, nawet jeśli małe, świadczą o Twojej inicjatywie i pasji. A pasja często przebija formalne doświadczenie na poziomie juniora.
• Przygotuj się do zadań praktycznych: Możliwe formy to: napisanie prostego skryptu (bash/Python), analiza konfiguracji, lub rozwiązanie problemu logicznego. Przykładowo, mogą dać Ci fragment konfiguracji serwera nginx z błędem i spytać, co jest nie tak – wtedy dobrze, byś wcześniej przejrzał przykładowe pliki konfiguracyjne nginx/Apache, aby wiedzieć jak mniej więcej wyglądają. Jeśli to skrypt – poćwicz przed rozmową pisanie np. skryptu bash, który odczyta plik i wyświetli unikalne linie, albo który pętlą wypisze liczby 1-10. Może paść zadanie “napisz skrypt deploy.sh, który skopiuje pliki na serwer i uruchomi serwis” – nie musisz znać konkretnego środowiska, wystarczy pseudo-kod z komendami scp i systemctl restart. Ważne, żebyś pokazał umiejętność automatycznego myślenia.
• Myśl na głos przy diagnozowaniu problemu: Jeśli rekruter zapyta Cię hipotetycznie: “Wyobraź sobie, że nowa wersja aplikacji po wdrożeniu przestała działać – co zrobisz?”, nie rzucaj od razu jednej odpowiedzi. Zamiast tego powiedz: “Najpierw sprawdziłbym monitoring – czy rośnie zużycie CPU, pamięci? Potem zajrzałbym do logów aplikacji i systemu. Jeśli nic tam nie ma, spróbuję odpalić poprzednią wersję dla porównania. Być może to problem z zależnościami – sprawdzę też konfigurację serwera.” Taka metodyczna analiza bardzo zaimponuje, bo pokazuje dojrzałość. Pamiętaj – DevOps często musi gaszyć pożary i liczy się opanowanie oraz umiejętność krok po kroku zawężać obszar problemu.
• Podkreślaj kulturę DevOps (współpracę): Możesz być zapytany o doświadczenie pracy zespołowej. Jeśli masz za sobą projekt zespołowy (np. studencki) – opowiedz, jak dzieliście się zadaniami, czy korzystaliście z gita. Podkreśl, że lubisz pomagać innym w kwestiach technologicznych (np. “W poprzedniej pracy byłem 'osobą od IT' mimo że to nie było moje główne zadanie – lubię wspierać innych i usprawniać pracę całego zespołu”). Filozofia DevOps to przecież breaking silos, więc pokazanie, że nie masz mentalności “to nie moja sprawa, ja tylko robię swoje”, a raczej “chętnie pomagam i usprawniam wspólną pracę” – będzie sporym plusem.
• Zadbaj o formalności i transparentność: Na rozmowie DevOps mogą paść pytania o dyspozycyjność (czy jesteś gotów na on-call, czyli dyżury w razie awarii – jako junior raczej Cię to od razu nie spotka, ale warto przemyśleć odpowiedź). Mogą też spytać o preferowane środowisko pracy (Linux/Windows – wiadomo, Linux 😉). Odpowiadaj szczerze. Jeśli czegoś nie wiesz technicznie, przyznaj wprost – to często test, by zobaczyć, czy potrafisz przyznać się do niewiedzy (w branży, gdzie nikt nie wie wszystkiego, to cenna cecha). Jak powiedzieliśmy wcześniej – kłamczuchom mówimy stanowcze nie.
• Pokaż, że Ci zależy: Pod koniec rozmowy zadaj pytania, które dowodzą Twojego zaangażowania. Np.: “Jakie są najbliższe plany modernizacji infrastruktury w firmie? Czy jest okazja nauczyć się tu np. Kubernetes jeśli go nie znają Państwo jeszcze?” – to sygnał, że myślisz perspektywicznie. Albo zapytaj seniora DevOpsa (jeśli jest na rozmowie) o jego największe wyzwanie w firmie – pokażesz, że interesuje Cię rzeczywista praca, a nie tylko zdobycie posady. Takie rozmowy to też szansa dla Ciebie ocenić firmę, więc nie bój się pytać.