Czy nie wydaje ci się dziwne, że kiedy zamierzasz zmienić miejsce pracy i pojawia się potrzeba pójścia na rozmowę kwalifikacyjną, to w pierwszej kolejności myślisz: „muszę przygotować się do rozmowy”? Rozwiązać zadania na HackerRank, poczytać Crack the Coding Interview, nauczyć się na pamięć jak działa ArrayList i czym różni się od LinkedList. A tak, mogą też o to zapytać, a chyba nieprofesjonalnie byłoby powiedzieć, że quick sort prawdopodobnie będzie najlepszym wyborem.
Ale poczekaj, przecież programujesz 8 godzin dziennie, rozwiązujesz interesujące i nietrywialne zadania, a w nowym miejscu pracy będziesz robić mniej więcej to samo. Niemniej jednak, aby przejść rozmowę, musisz jakoś dodatkowo się przygotować, nawet nie doskonalić codziennych umiejętności, a nauczyć się tego, co nie było ci potrzebne ani w obecnym miejscu pracy, ani, prawdopodobnie, w przyszłym. Na twoje zastrzeżenia, że informatyka jest w naszej krwi, i że obudź nas w środku nocy, powinniśmy napisać z zamkniętymi oczami algorytm przeszukiwania drzewa w szerokość na poduszce, nawet nie przychodząc do świadomości, odpowiem, że jeśli miałbym pracować w cyrku, a moim głównym trikiem byłoby właśnie to — to chyba tak, zgadzam się. Muszę sprawdzić tę umiejętność.
Ale po co sprawdzać umiejętności, które są nieistotne dla obecnej pracy? Tylko dlatego, że stało się to modne? Bo Google tak robi? Czy dlatego, że twój przyszły lider zespołu musiał nauczyć się wszystkich metod sortowania przed rozmową kwalifikacyjną i teraz uważa, że „każdy dobry programista powinien znać na pamięć implementację znajdowania palindromu w ciągu”?
Otóż, nie jesteś Google (c). Co może sobie pozwolić Google, zwykłe firmy nie mogą. Google, analizując dane swoich pracowników, doszedł do wniosku, że konkretne zadania dobrze wykonują inżynierowie z olimpijską przeszłością. Co więcej, budując proces rekrutacji, mogą sobie pozwolić na ryzyko, że mogą nie zatrudnić kilku dobrych inżynierów, ponieważ nie potrafią tak łatwo rozwiązywać zadań matematycznych. Ale to dla nich nie problem, chętnych do pracy w Google jest wielu, stanowisko się zamknie.
Teraz spójrzmy przez okno. Jeśli przed Twoim biurem nie stoi obozowisko inżynierów, którzy chcą u Ciebie pracować, a Twoi deweloperzy częściej szukają na stackoverflow, jakie kolejne adnotacje Springa trzeba dodać, zamiast skupiać się na subtelnościach algorytmów rankingowych, najwyraźniej czas pomyśleć, czy warto kopiować Google.
Co jeśli Google po raz kolejny zawiódł i nie dał odpowiedzi? Powinniśmy sprawdzić dokładnie to, co deweloper będzie robić w pracy. Co cenisz w deweloperach?
Określ kryteria, kogo chcesz zatrudnić, i opracuj testy sprawdzające te umiejętności.
ThoughtWorks
Jakie ma związek z ThoughtWorks? Dla mnie to przykład wzorcowej rekrutacji. Kim są ThoughtWorks? W skrócie, to firma doradcza klasy high-end z biurami na całym świecie, od Chin i Singapuru po Amerykę, działająca w obszarze doradztwa w zakresie rozwoju od około 25 lat, z własnym działem naukowym kierowanym przez Martina Fowlersa. Jeśli poszukasz listy 10 książek, które musisz przeczytać jako Inżynier Oprogramowania, prawdopodobnie 2-3 z nich będą napisane przez ludzi z ThoughtWorks, jak na przykład "Refactoring" Martina Fowlersa i "Building Microservices: Designing Fine-Grained Systems" autorstwa Sama Newmana oraz "Building Evolutionary Architectures".
by Patrick Kua, Rebecca Parsons, Neal Ford.
Model biznesowy firmy opiera się na świadczeniu stosunkowo drogich usług, ale klient płaci za fenomenalną jakość, która wynika z ekspertyzy, wewnętrznych standardów i, oczywiście, ludzi. Dlatego kluczowe jest zatrudnianie odpowiednich osób.
Kim zatem są odpowiedni ludzie? Oczywiście, dla każdego innych. ThoughtWorks zdefiniował, że dla ich modelu biznesowego najważniejsze kryteria dla deweloperów to:
- Zdolność do pracy w parze. To zdolność, a nie doświadczenie czy umiejętność. Nikt nie oczekuje, że przyjdą ludzie, którzy praktykują Pair Programming od 5 lat. Ale zdolność do bycia otwartym na opinie innych, umiejętność słuchania - to niezbędna umiejętność.
- Umiejętność pisania testów, a w idealnym przypadku praktykowanie TDD.
- Zrozumienie SOLID i OOP i umiejętność ich stosowania.
- Prezentowanie swojego zdania. Konsultant musi współpracować z deweloperami klienta, innymi konsultantami, i nie ma dużej korzyści, jeśli ktoś potrafi coś robić dobrze, ale nie potrafi tego przekazać innym członkom zespołu.
Teraz ważne jest, aby ocenić te umiejętności u kandydata. Chcę opowiedzieć o swoim doświadczeniu rozmowy kwalifikacyjnej w ThoughtWorks. Powiem od razu, że odbyłem ją w Singapurze i udało mi się, ale proces rekrutacyjny jest ujednolicony i nie będzie znacznie różnić się w zależności od kraju.
Etap 0. HR
Jak to często bywa, 20-minutowa rozmowa kwalifikacyjna z HR. Nie będę się nad tym zatrzymywać, powiem tylko, że nigdy wcześniej nie spotkałem HR, który potrafiłby przez 15 minut mówić o kulturze pracy w firmie, dlaczego stosują TDD, dlaczego programowanie w parach. Zazwyczaj w tym momencie HR-y gasną i mówią, że proces jest zwyczajny: deweloperzy tworzą, testerzy testują, menedżerowie kierują.
Etap 1. Jak dobrze znasz OOP, TDD?
Na 1,5 godziny przed rozmową kwalifikacyjną otrzymałem zadanie polegające na stworzeniu symulatora Mars Rover.
Zadanie Mars RoverZespół robotycznych roverów ma być zainstalowany przez NASA na płaskowyżu na Marsie. Ten płaskowyż, który jest ciekawie prostokątny, musi być nawigowany przez rovery, aby ich kamery pokładowe mogły uzyskać pełny widok otaczającego terenu do wysłania z powrotem na Ziemię. Pozycja i lokalizacja rovera są reprezentowane przez kombinację współrzędnych x i y oraz litery reprezentującej jeden z czterech głównych kierunków kompasu. Płaskowyż jest podzielony na siatkę, aby uprościć nawigację. Przykładowa pozycja może być 0, 0, N, co oznacza, że rover znajduje się w lewym dolnym rogu i jest zwrócony na północ. Aby kontrolować rovera, NASA wysyła prosty ciąg liter. Możliwe litery to 'L', 'R' i 'M'. 'L' i 'R' sprawiają, że rover obraca się o 90 stopni w lewo lub w prawo, odpowiednio, nie ruszając się z miejsca. 'M' oznacza przesunięcie do przodu o jeden punkt na siatce, i utrzymanie tego samego kierunku.
Zakładaj, że kwadrat bezpośrednio na północ od (x, y) to (x, y+1).
WEJŚCIE:
Pierwsza linia wejścia to współrzędne górnego prawego rogu płaskowyżu, a współrzędne dolnego lewego zakłada się na 0,0.
Pozostała część wejścia to informacje dotyczące roverów, które zostały rozmieszczone. Każdy rover ma dwie linie wejścia. Pierwsza linia podaje pozycję rovera, a druga linia to seria instrukcji mówiących roverowi, jak eksplorować płaskowyż. Pozycja składa się z dwóch liczb całkowitych i jednej litery oddzielonych spacjami, odpowiadających współrzędnym x i y oraz orientacji rovera.
Każdy rover będzie kończony sekwencyjnie, co oznacza, że drugi rover nie zacznie się poruszać, dopóki pierwszy nie skończy się poruszać.
WYJŚCIE:
Wyjście dla każdego rovera powinno zawierać jego końcowe współrzędne i kierunek.
NOTATKI:
Po prostu zrealizuj wymagania powyżej i udowodnij, że odkurzacz działa, pisząc dla niego testy jednostkowe.
Tworzenie jakiejkolwiek formy interfejsu użytkownika jest poza zakresem.
Preferowanym podejściem będzie rozwiązanie problemu stosując metodę TDD (Test Driven Development).
W ograniczonym czasie bardziej zależy nam na jakości niż na kompletności.
*Nie mogę opublikować zadania, które mi wysłano, to stare zadanie, które było zadawane kilka lat temu. Ale uwierzcie, zasady pozostają wciąż takie same.
Osobno chciałbym zwrócić uwagę na kryteria oceny. Ile razy zdarzyło ci się natknąć na sytuację, w której ważne dla kandydata aspekty są zupełnie nieistotne podczas weryfikacji i odwrotnie. Nie wszyscy myślą tak jak ty, ale wielu może przyjąć twoje wartości i je śledzić, jeśli zostaną wyraźnie sformułowane. Z kryteriów oceny od razu widać, że najważniejszymi umiejętnościami na tym etapie są
- TDD;
- Umiejętność korzystania z OOP i pisania kodu łatwego do utrzymania;
- zdolności do programowania w parach
W takim razie zostałem poinformowany, abym poświęcił te 1,5 godziny na przemyślenie, jak zamierzam zrealizować zadanie, a nie na pisanie kodu. Kod będziemy pisać razem.
Kiedy się połączyliśmy, chłopaki krótko opowiedzieli, kim są, czym się zajmują i zaproponowali rozpoczęcie prac nad projektem.
Podczas całego wywiadu ani razu nie miałem wrażenia, że jestem na rozmowie kwalifikacyjnej. Jest poczucie, że tworzysz kod w zespole. Jeśli gdzieś utkniesz — pomagają, doradzają, dyskutują, a nawet kłócą się między sobą, jak najlepiej to zrobić. Na rozmowie zapomniałem, jak w JUnit 5 sprawdzić, czy metoda rzuca wyjątek — zaproponowali kontynuowanie pisania testu, podczas gdy jeden z nich szukał, jak to zrobić.
Zaledwie kilka godzin po rozmowie otrzymałem konstruktywną opinię — co się spodobało, a co nie. W moim przypadku pochwaliłem użycie klas Sealed jako alternatywy dla null; za to, że przed napisaniem kodu napisałem pseudokod, jak chciałbym zarządzać robotem, a w ten sposób otrzymałem szkic klas, przynajmniej tych zaangażowanych w API robota.
Etap 2. Opowiedz nam
Na tydzień przed rozmową poproszono mnie o przygotowanie prezentacji na dowolny temat, który mnie interesuje. Format jest prosty i znany: 15 minut prezentacja, 15 minut odpowiedzi na pytania.
Wybrałem Clean Architecture autorstwa Uncle Boba. I znów przeprowadziła mnie para osób na rozmowie kwalifikacyjnej. To było moje pierwsze doświadczenie z prezentacją w języku angielskim, i, zapewne, gdybym znalazł się w stresującej sytuacji — nie poradziłbym sobie. Ale z drugiej strony, ani przez moment nie miałem wrażenia, że jestem na rozmowie kwalifikacyjnej. Wszystko jak zwykle — ja opowiadam, a oni słuchają z uwagą. Nawet tradycyjna sesja pytań i odpowiedzi nie przypominała rozmowy kwalifikacyjnej, było widać, że zadawane pytania nie mają na celu „utopienia” mnie, ale rzeczywiście interesowały ich aspekty mojej prezentacji.
Kilka godzin po rozmowie otrzymałem opinię — prezentacja była bardzo pomocna i czerpali szczere przyjemności z jej słuchania.
Etap 3. Kod o jakościach produkcyjnych
Informując, że to jest ostatni etap technicznych rozmów kwalifikacyjnych, poproszono mnie o przekształcenie kodu w stan gotowy do produkcji w domu, po czym miałem wysłać kod do przeglądu i wyznaczyć rozmowy, na których wymagania do zadania się zmienią i kod będzie wymagał modyfikacji. Przy okazji mogę powiedzieć, że przegląd kodu jest przeprowadzany w sposób ślepy, recenzenci nie znają ani stanowiska, na które ubiega się kandydat, ani nie widzą jego CV, nawet nie znają jego imienia.
Rozmowa telefoniczna, a z drugiej strony monitora znów para chłopaków. Wszystko jak na pierwszej rozmowie kwalifikacyjnej: najważniejsze to nie zapomnieć o TDD, opowiadać, co się robi i dlaczego. Jeśli wcześniej nie praktykowaliście TDD, to polecam natychmiast zacząć to robić, nie dlatego, że jest to wymagane w firmach, ale dlatego, że znacznie ułatwia to życie i obniża poziom stresu, jeśli chcecie. Pamiętacie, jak trudno było znaleźć błąd przy pomocy debuggera, który pojawiał się tylko w przeglądarce, a nie mogliście go odtworzyć testami? Teraz wyobraźcie sobie, że musicie złapać taki błąd podczas rozmowy kwalifikacyjnej – gwarantuję, że przybędzie wam kilka siwych włosów. Co natomiast zyskujemy dzięki TDD? Zmieniłeś kod i niespodziewanie odkrywasz, że teraz testy są czerwone, a zrozumienie, w czym leży błąd, nie udaje się za pierwszym razem? OK, mówimy rekruterom „Ups”, naciskamy Ctrl-Z i zaczynamy małymi krokami iść do przodu. Tak, umiejętność tworzenia kodu z wykorzystaniem TDD to coś, co trzeba w sobie wykształcić, umiejętność dążenia do celu tak, aby wasze testy były stale zielone, a nie czerwone przez pół dnia, bo „mieliście duży refaktoring”. To dokładnie taka sama umiejętność, jak pisanie kodu, który można utrzymywać, lub kodu wydajnego.
A zatem, jak dobrze twój kod poddaje się zmianom, zależy od tego, jaki design włożyłeś na początku, jak prosty jest i jak dobre są twoje testy.
Po rozmowie kwalifikacyjnej otrzymałem feedback w ciągu kilku godzin. Na tym etapie zrozumiałem, że praktycznie przeszedłem i pozostało tylko niewiele do „spotkania z Fowlerem”.
Etap 4. Finał. Wystarczająco technicznych pytań. Chcemy wiedzieć, kim jesteś!
Szczerze mówiąc, taka forma pytania trochę mnie zaskoczyła. Jak można zrozumieć, kim jestem, w ciągu jednej godziny rozmowy? A tym bardziej, jak można to zrozumieć, gdy rozmawiam w języku, który nie jest mi rodzony, i to, szczerze mówiąc, dość słabo i niezdarnie. Na poprzednich rozmowach kwalifikacyjnych osobiście łatwiej było mi opowiadać niż odpowiadać na pytania, a winę ponosił akcent. Przynajmniej jeden z rozmówców był Azjatą — a jego akcent, powiedzmy, jest dość specyficzny dla europejskiego ucha. Dlatego postanowiłem zastosować proaktywne podejście — przygotować prezentację o sobie i na początku rozmowy zaproponować opowiedzenie o sobie z tą prezentacją. Jeśli się zgodzą — przynajmniej będzie mniej pytań do mnie, jeśli odrzucą propozycję — cóż, 3 godziny mojego życia spędzone na prezentacji to nie taka wysoka cena. Ale co napisać w prezentacji? Biografię — Urodziłem się tam, wtedy, poszedłem do szkoły, ukończyłem uniwersytet, — kogo to interesuje?
Jeśli trochę poszukać w Internecie na temat kultury Thoughtworks, można znaleźć artykuł Martina Fowlera [https://martinfowler.com/bliki/ThreePillars.html], w którym opisane są 3 filary: Zrównoważony rozwój biznesu, Doskonałość oprogramowania i Sprawiedliwość społeczna.
Załóżmy, że Doskonałość oprogramowania została już sprawdzona. Pozostaje pokazać Zrównoważony rozwój biznesu i Sprawiedliwość społeczną.
Postanowiłem skupić się na tym ostatnim.
Na początek opowiedziałem, dlaczego ThoughtWorks — jeszcze na studiach czytałem blog Martina Fowlera, stąd moja miłość do Clean code.
Projekty również można przedstawić z różnych perspektyw. Opracowywałem oprogramowanie dla medycyny, które ułatwiało życie pacjentom, a nawet, według plotek, uratowało jedno życie. Opracowywałem również oprogramowanie dla banków, co również jest pewnym uproszczeniem życia obywateli. Szczególnie jeśli bankiem posługuje się 70% populacji kraju. Chodzi nie o Sberbank, ani nawet o Rosję.
Chcesz się o mnie dowiedzieć? Okej. Moje hobby — fotografia, tak czy inaczej trzymam aparat w rękach od około 10 lat, mam zdjęcia, które nie są wstydliwe do pokazania. Też przez pewien czas pomagałem w schronisku dla kotów: fotografowałem koty, które potrzebowały stałego domu. A z dobrymi zdjęciami łatwiej znaleźć dom dla kota. Prawdopodobnie uwieczniłem ze sto kotów 🙂
Ostatecznie 80% prezentacji wypełniłem kotami.
Zaraz po prezentacji napisał mi HR, że jeszcze nie zna wyników rozmowy kwalifikacyjnej, ale już cały biuro jest pod wrażeniem kotów.
Ostatecznie doczekałem się feedbacku — wszyscy byli usatysfakcjonowani moją osobowością.
Ale HR w trakcie finalnej rozmowy taktownie powiedział, że Social Justice to bardzo dobrze i potrzebne, ale nie wszystkie projekty takie są. I zapytał, czy mnie to nie przeraża. Generalnie, trochę przesadziłem z Social Justice, zdarza się 🙂
Podsumowanie
W rezultacie, już kilka miesięcy pracuję w Singapurze w Thoughtworks, widzę, że wiele firm przystosowuje 'najlepsze praktyki rozmowy kwalifikacyjnej' z Google, używając karteczek i tablicy do kodowania, mimo że znajomość czegokolwiek poza Springiem, Symfony, RubyOnRails (wymagana wiedza) nie jest potrzebna w pracy. Inżynierowie biorą tygodniowy urlop przed rozmową, aby się 'przygotować'.
W Thoughtworks, oprócz sensownych wymagań wobec kandydatów, na pierwszym miejscu stawiane są następujące zasady:
Radość z rozmowy kwalifikacyjnej. Przy czym dotyczy to obu stron. Naprawdę, jeśli chcesz zdobyć najlepsze talenty (a kto ich nie chce?), rozmowa kwalifikacyjna to nie rynek, na którym wybiera się niewolników, lecz przegląd, w którym zarówno pracodawca, jak i kandydat oceniają się nawzajem. A jeśli kandydat kojarzy firmę z przyjemnymi emocjami — jest bardzo prawdopodobne, że wybierze właśnie tę firmę.
Wielu rekruterów, aby zredukować stronniczość. W Thoughtworks programowanie w parach to standard de facto. I jeśli tę praktykę można zastosować w innych dziedzinach, TW stara się to robić. Na każdym etapie rozmowy kwalifikacyjnej bierze udział 2 osoby. W ten sposób każda osoba jest oceniana przez co najmniej 8 osób, a TW stara się dobierać rekruterów z różnym doświadczeniem, z różnych dziedzin (nie tylko technicznych) i płci.
Ostatecznie decyzja o zatrudnieniu zostanie podjęta na podstawie opinii co najmniej 8 osób, i nikt nie ma prawa decydującego głosu.
Rekrutacja oparta na atrybutach Zamiast podejmować decyzję na podstawie "lubię-nie lubię" kandydata, dla każdej roli i każdego etapu opracowano formularz, który zawiera oceniane atrybuty. Przy ocenie bardzo zaleca się, aby oceniać nie doświadczenie w danej umiejętności, ale zdolność do jej stosowania. W ten sposób, jeśli kandydat nie miał okazji stosować niektórych umiejętności, jak TDD, ale mimo to stara się je stosować i słucha rad dotyczących ich właściwego użycia — ma wszelkie szanse na przejście rozmowy kwalifikacyjnej.
Certyfikaty edukacyjne nie są wymagane TW nie wymaga od kandydata obowiązkowych certyfikatów ani wykształcenia w zakresie Informatyki. Liczy się tylko umiejętność.
To pierwsza rozmowa, na którą nie musiałem się przygotowywać, odbywając ją w zagranicznych firmach. Po każdym etapie nie czułem się jak wyciśnięta cytryna, wręcz przeciwnie, byłem zadowolony, że mogę stosować najlepsze praktyki, że osoby po drugiej stronie ekranu to doceniają i również stosują je na co dzień.
Po kilku miesiącach mogę powiedzieć, że oczekiwania zostały w pełni spełnione. Czym ThoughtWorks różni się od zwykłej firmy? W zwykłej firmie możesz znaleźć dobrych programistów i miłych ludzi, ale w TW ich koncentracja jest znacznie większa.
Jeśli chcesz dołączyć do ThoughtWorks, możesz zobaczyć otwarte oferty pracy
Zachęcam także do zwrócenia uwagi na interesujące oferty pracy:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
Infrastruktura: , ,
(Chcę szczerze ostrzec, że to jest link referencyjny, jeśli przejdziesz do TW, otrzymam przyjemny bonus). Wybieraj biuro, które Ci się podoba, nie ograniczaj się tylko do Europy, w końcu co dwa lata TW będzie szczęśliwy, mogąc przenieść Cię do innego kraju, ponieważ to część polityki ThoughtWorks, w ten sposób kultura się rozwija i uśrednia.
Nie wahaj się zadawać pytań w komentarzach lub prosić mnie o polecenie.
Jeśli temat wydaje się interesujący, napiszę o tym, jak się pracuje w ThoughtWorks i jak żyje się w Singapurze.
Źródło: habr.com
