Jak dostałem się do ThinkWorks czyli przykładowa rozmowa kwalifikacyjna

Jak dostałem się do ThinkWorks czyli przykładowa rozmowa kwalifikacyjna

Czy nie wydaje Ci się dziwne, że gdy masz zamiar zmienić pracę i pojawia się konieczność zdania rozmowy kwalifikacyjnej, pierwszą rzeczą, o której myślisz, jest „trzeba przygotować się do rozmowy kwalifikacyjnej”. Rozwiązuj problemy w HackerRank, przeczytaj wywiad o kodowaniu, zapamiętaj, jak działa ArrayList i czym różni się od LinkedList. O tak, mogliby również zapytać o sortowanie i oczywiście nieprofesjonalnym byłoby stwierdzenie, że szybkie sortowanie byłoby najprawdopodobniej najlepszym wyborem.
Ale czekaj, programujesz 8 godzin dziennie, rozwiązujesz ciekawe i nietrywialne problemy, a w nowej pracy będziesz robić to samo, plus lub minus. Niemniej jednak, aby przejść rozmowę kwalifikacyjną, musisz się jakoś dodatkowo przygotować, a nie nawet doskonalić swoje codzienne umiejętności, ale nauczyć się czegoś, czego nie potrzebujesz w obecnej pracy i prawdopodobnie nie będziesz potrzebować w następnej. Na Twoje zarzuty, że informatykę mamy we krwi i jeśli obudzisz nas w środku nocy, będziemy zmuszeni pisać z zamkniętymi oczami na poszewce na poduszkę spacer po szerokości drzewa, nie odzyskując nawet przytomności, odpowiem, że jeśli dostanę pracę w cyrku, a moją główną rzeczą będzie właśnie ta sztuczka - to może tak, zgadzam się. Tę umiejętność trzeba przetestować.

Ale po co testować umiejętności, które nie mają związku z Twoją obecną pracą? Tylko dlatego, że stało się to modne? Ponieważ Google to robi? Albo dlatego, że Twój przyszły lider zespołu musiał przed rozmową kwalifikacyjną nauczyć się wszystkich metod sortowania i teraz wierzy, że „każdy dobry programista musi znać na pamięć implementację znajdowania palindromu w ciągu znaków”.

Cóż, nie jesteś Google (c). Na co Google może sobie pozwolić, zwykłych firm nie. Google po przeanalizowaniu danych swoich pracowników doszedł do wniosku, że inżynierowie mający za sobą olimpijską przeszłość dobrze radzą sobie z jej specyficznymi zadaniami. Co więcej, projektując proces selekcji, mogą sobie pozwolić na ryzyko, że nie zatrudnią kilku dobrych inżynierów, ponieważ nie potrafią łatwo rozwiązać problemów matematycznych. Ale to nie jest dla nich problem, jest wiele osób, które chcą pracować w Google, stanowisko zostanie zamknięte.
A teraz wyjrzyjmy za okno i jeśli przed Twoim biurem inżynierowie chcący dla Ciebie pracować nie rozbili jeszcze obozu namiotowego, a Twoi programiści coraz częściej szukają na stackoverflow, jaka kolejna adnotacja Spring ma zostać zainstalowana, zamiast zawiłości algorytmów rankingowych, najwyraźniej nadszedł czas, aby zastanowić się, czy warto kopiować Google.

Cóż, jeśli tym razem Google zawiódł i nie udzielił odpowiedzi, co powinieneś zrobić? Sprawdź dokładnie, czym programista będzie się zajmował w pracy. Co cenisz u programistów?
Stwórz kryteria określające, kogo chcesz zatrudnić i opracuj testy sprawdzające dokładnie te umiejętności.

ThoughtWorks

Co ThinkWorks ma z tym wspólnego? Tutaj znalazłam przykład wywiadu modelowego dla siebie. Kim są ThinkWorks? W skrócie jest to firma konsultingowa High-End z biurami na całym świecie od Chin, Singapuru po kontynenty amerykańskie, która od około 25 lat doradza w zakresie rozwoju, posiada własny dział Science, na którego czele stoi Martin Ptasznik. Jeśli szukasz listy 10 książek, które każdy inżynier oprogramowania musi przeczytać, to być może 2-3 z nich zostaną napisane przez chłopaków z ThinkWorks, np. Refactoring autorstwa Martina Fowlera i Building Microservices: Designing Fine-Grained Systems autorstwa Sama Newmana czy Budowanie architektur ewolucyjnych
autorstwa Patricka Kua, Rebeki Parsons i Neala Forda.

Działalność firmy opiera się na świadczeniu dość drogich usług, jednak klient płaci za fenomenalną jakość, na którą składa się wiedza, wewnętrzne standardy i oczywiście ludzie. Dlatego zatrudnienie odpowiednich ludzi jest tutaj kluczowe.
Jacy ludzie mają rację? Oczywiście dla każdego są inne. Firma ThinkWorks ustaliła, że ​​najważniejszymi kryteriami ich modelu biznesowego dla programistów są:

  • Możliwość rozwoju w parach. To zdolność, a nie doświadczenie i umiejętności. Nikt nie spodziewa się, że przyjdą ludzie, którzy od 5 lat zajmują się programowaniem w parach, jednak umiejętność słuchania i otwierania się na opinie innych jest niezbędna.
  • Umiejętność pisania testów, a najlepiej praktyka TDD
  • Zrozumienie SOLID i OOP i umiejętność ich zastosowania.
  • Przedstaw swoją opinię. Jako konsultant musisz współpracować z programistami klienta, z innymi konsultantami i nie ma zbyt wielu korzyści, jeśli dana osoba wie, jak coś zrobić dobrze, ale zupełnie nie jest w stanie przekazać tego reszcie zespołu.

Teraz ważne jest, aby ocenić te konkretne umiejętności kandydata. I tutaj chcę opowiedzieć o moich doświadczeniach z rozmów kwalifikacyjnych w ThinkWorks. Od razu powiem, że pojechałem do Singapuru i zdałem, ale proces rekrutacji jest ujednolicony i nie będzie się zbytnio różnić w zależności od kraju.

Etap 0. HR

Jak to często bywa 20-minutowa rozmowa z HR. Nie będę się nad tym rozwodzić, powiem tylko, że nigdy nie spotkałam osoby z HR, która potrafiłaby przez 15 minut porozmawiać o kulturze rozwoju w firmie, dlaczego używają TDD, dlaczego programuje się w parach. Zwykle HR-owcy wzdrygają się na to pytanie i twierdzą, że ich proces jest normalny: programiści opracowują, testerzy testują, menedżerowie prowadzą.

Etap 1. Jak dobry jesteś w OOP, TDD?

Na 1.5 godziny przed rozpoczęciem rozmowy dostałem zadanie wykonania symulatora łazika marsjańskiego.

Misja łazika marsjańskiegoOddział robotycznych łazików ma zostać wylądowany przez NASA na płaskowyżu na Marsie. Łaziki muszą poruszać się po tym płaskowyżu, który jest dziwnie prostokątny, aby ich pokładowe kamery mogły uzyskać pełny obraz otaczającego terenu i wysłać go z powrotem na Ziemię. Pozycja i lokalizacja łazika jest reprezentowana przez kombinację współrzędnych x i y oraz literę reprezentującą jeden z czterech głównych punktów kompasu. Płaskowyż jest podzielony na siatkę, aby uprościć nawigację. Przykładową pozycją może być 0, 0, N, co oznacza, że ​​łazik znajduje się w lewym dolnym rogu i jest skierowany na północ. Aby sterować łazikiem, NASA wysyła prosty ciąg liter. Możliwe litery to „L”, „R” i „M”. „L” i „R” powodują, że łazik obraca się o 90 stopni odpowiednio w lewo lub w prawo, nie ruszając się z bieżącego miejsca. „M” oznacza przesunięcie o jeden punkt siatki do przodu i utrzymanie tego samego kursu.
Załóżmy, że kwadrat znajdujący się bezpośrednio na północ od (x, y) to (x, y+1).
WEJŚCIE:
Pierwsza linia danych wejściowych to współrzędne górnego prawego płaskowyżu, przyjmuje się, że współrzędne lewego dolnego rogu wynoszą 0,0.
Pozostała część danych wejściowych to informacje dotyczące rozmieszczonych łazików. Każdy łazik ma dwie linie wejściowe. Pierwsza linia podaje pozycję łazika, a druga linia to seria instrukcji informujących łazik, jak badać płaskowyż. Pozycja składa się z dwóch liczb całkowitych i litery oddzielonych spacjami, odpowiadających współrzędnym x i y oraz orientacji łazika.
Każdy łazik będzie kończony sekwencyjnie, co oznacza, że ​​drugi łazik nie zacznie się poruszać, dopóki pierwszy nie zakończy ruchu.
WYDAJNOŚĆ:
Wynikiem każdego łazika powinny być jego ostateczne współrzędne i kurs.
UWAGI:
Po prostu zastosuj powyższe wymagania i udowodnij, że odkurzacz działa, pisząc dla niego testy jednostkowe.
Tworzenie jakiejkolwiek formy interfejsu użytkownika wykracza poza zakres.
Preferowane będzie rozwiązanie problemu zgodnie z podejściem TDD (Test Driven Development).
W tak krótkim czasie bardziej skupiamy się na jakości niż na kompletności.
*Nie mogę opublikować zadania, które mi przysłano, jest to stare zadanie, które otrzymano kilka lat temu. Ale uwierz mi, zasadniczo wszystko pozostaje takie samo.

Szczególnie chciałbym zwrócić uwagę na kryteria oceny. Ile razy spotkałeś się z sytuacją, w której to, co dla kandydata jest ważne, podczas audytu jest zupełnie nieważne i odwrotnie. Nie wszyscy myślą tak samo jak Ty, ale wielu może zaakceptować Twoje wartości i podążać za nimi, jeśli są one jasno określone. Tak więc z kryteriów oceny od razu wynika, że ​​najważniejsze umiejętności na tym etapie to

  • TDD;
  • Umiejętność korzystania z OOP i pisania łatwego w utrzymaniu kodu;
  • umiejętności programowania w parach

Ostrzeżono mnie więc, żebym spędził te 1.5 godziny na myśleniu o tym, jak zamierzam wykonać zadanie, zamiast pisać kod. Kod napiszemy razem.

Kiedy zadzwoniliśmy, chłopaki krótko powiedzieli nam, kim są i czym się zajmują, oraz zaproponowali rozpoczęcie rozwoju.

Przez całą rozmowę ani razu nie miałam wrażenia, że ​​jestem udzielana na rozmowę. Masz 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 sprawdzić w JUnit 5, czy metoda zgłasza wyjątek - zaproponowali, że będą kontynuować pisanie testu, podczas gdy jeden z nich szukał w Google, jak to zrobić.

Dosłownie kilka godzin po rozmowie otrzymałam konstruktywną informację zwrotną – co mi się podobało, a co nie. W moim przypadku chwalono mnie za użycie klas Sealed jako alternatywy dla obiektu null; za to, że przed napisaniem kodu napisałem w pseudokodzie jak chciałbym sterować łazikiem i w ten sposób otrzymałem szkic klas, przynajmniej tych, które biorą udział w API robota.

Krok 2: Powiedz nam

Tydzień przed rozmową kwalifikacyjną zostałem poproszony o przygotowanie prezentacji na dowolny temat, który mnie zainteresował. Format jest prosty i znajomy: 15 minut prezentacji, 15 minut odpowiedzi na pytania.
Wybrałem Czystą Architekturę autorstwa Wujka Boba. I znowu udzieliłem wywiadu kilku osobom. To było moje pierwsze doświadczenie z prezentacją po angielsku i być może, gdybym znalazła się w stresującej sytuacji, nie byłabym w stanie sobie z nią poradzić. Ale znowu ani razu nie miałem wrażenia, że ​​jestem na rozmowie kwalifikacyjnej. Wszystko jest jak zwykle - mówię im, a oni uważnie słuchają. Nawet tradycyjna sesja pytań i odpowiedzi nie przypominała wywiadu; było jasne, że pytania nie były zadawane po to, aby „zatonąć”, ale takie, które naprawdę ich zainteresowały w mojej prezentacji.

Kilka godzin po rozmowie otrzymałem informację zwrotną – prezentacja była bardzo przydatna i naprawdę miło było jej słuchać.

Etap 3. Kodeks Jakości Produkcji

Po uprzedzeniu, że to już ostatni etap rozmów technicznych, poproszono mnie o doprowadzenie kodu w domu do stanu gotowego do produkcji, następnie przesłanie kodu do przeglądu i umówienie się na rozmowy kwalifikacyjne, na których zmienią się wymagania dotyczące zadania i kod będzie wymagają modyfikacji. Patrząc w przyszłość, mogę powiedzieć, że code review przeprowadza się na ślepo, recenzenci nie znają stanowiska, na które kandydat aplikuje, nie widzą jego CV, nie widzą nawet jego nazwiska.

Zadzwonił telefon, a po drugiej stronie monitora znów było kilku facetów. Wszystko jest tak samo, jak na pierwszej rozmowie: najważniejsze, aby nie zapomnieć o TDD, powiedzieć, co robisz i dlaczego. Jeśli wcześniej nie praktykowałeś TDD, to radzę zacząć od razu, nie dlatego, że jest to konieczne w firmach, ale dlatego, że znacząco ułatwia Ci to życie, zmniejsza poziom stresu, jeśli masz na to ochotę. Pamiętasz, jak musiałeś gorączkowo szukać za pomocą debugera błędu, który można odtworzyć tylko za pomocą przeglądarki, ale nie można go odtworzyć za pomocą testów? Teraz wyobraź sobie, że będziesz musiał złapać taki błąd podczas rozmowy kwalifikacyjnej - masz gwarancję kilku siwych włosów. Co zyskujemy dzięki TDD? Zmieniliśmy kod i nieoczekiwanie zdaliśmy sobie sprawę, że teraz testy są czerwone, ale jaki jest błąd, którego nie możemy zrozumieć za pierwszym razem? OK, mówimy „Ups” ankieterom, naciskamy Ctrl-Z i zaczynamy małymi krokami do przodu. I tak, trzeba rozwinąć w sobie umiejętność rozwijania się z wykorzystaniem TDD, umiejętność dążenia do celu, aby Twoje testy były trwale zielone, a nie czerwone przez pół dnia, bo „masz dużo refaktoryzacji”. Jest to dokładnie ta sama umiejętność, co pisanie kodu łatwego w utrzymaniu lub pisanie kodu produktywnego.

Zatem to, jak dobrze można zmienić kod, zależy od tego, jaki projekt masz na myśli na początku, jak prosty jest on i jak dobre są Twoje testy.

Po rozmowie kwalifikacyjnej otrzymałem informację zwrotną w ciągu kilku godzin. Na tym etapie zdałem sobie sprawę, że już prawie skończyłem i niewiele pozostało do „spotkania Fowlera”.

Etap 4. Finał. Dość pytań technicznych. Chcemy wiedzieć kim jesteś!

Szczerze mówiąc, trochę zdziwiło mnie takie sformułowanie pytania. Jak po godzinie rozmowy możesz zrozumieć, jakim jestem człowiekiem? A tym bardziej, jak można to rozumieć, skoro mówię językiem, który nie jest moim językiem ojczystym i, szczerze mówiąc, bardzo kiepskim i ograniczonym językiem. W poprzednich wywiadach osobiście łatwiej mi było rozmawiać niż odpowiadać na pytania, a winę za to ponosił akcent. Przynajmniej jeden z ankieterów był Azjatą, a ich akcent, powiedzmy, jest w pewnym stopniu charakterystyczny dla europejskiego ucha. Dlatego zdecydowałem się przyjąć podejście proaktywne - przygotować prezentację o sobie i na początku rozmowy zaproponować opowiedzenie o sobie tą prezentacją. Jeśli się zgodzą, to przynajmniej będzie mniej pytań do mnie, a jeśli odrzucą ofertę, cóż, 3 godziny mojego życia spędzone na prezentacji to nie jest aż tak wysoka cena. Ale co napisać w swojej prezentacji? Biografia - Tam się wtedy urodził, poszedł do szkoły, skończył studia - ale kogo to obchodzi?

Jeśli poszukasz w Google trochę o kulturze Thinkworks, znajdziesz artykuł Martina Fowlera [https://martinfowler.com/bliki/ThreePillars.html], który opisuje 3 filary: zrównoważony biznes, doskonałość oprogramowania i sprawiedliwość społeczna.

Załóżmy, że Software Excellence zostało już u mnie sprawdzone. Pozostaje pokazać zrównoważony biznes i sprawiedliwość społeczną.

Co więcej, postanowiłem skupić się na tym drugim.

Na początek opowiedziałem mu, dlaczego ThinkWorks – przeczytałem blog Martina Fowlera jeszcze na studiach, stąd moja miłość do Clean code.

Projekty można również prezentować z różnych perspektyw. Stworzył także oprogramowanie dla medycyny, które ułatwiło życie pacjentom, a nawet – według plotek – uratowało jedno życie. Tworzyłem także oprogramowanie dla banków, które także ułatwiło życie obywatelom. Zwłaszcza jeśli z tego banku korzysta 70% populacji kraju. Tu nie chodzi o Sberbank, ani nawet o Rosję.

Chcesz wiedzieć o mnie? OK. Moim hobby jest fotografia, tak czy inaczej aparat trzymam w rękach już jakieś 10 lat, są takie zdjęcia, których nie wstydzę się pokazać. Kiedyś pomagałam też schronisku dla kotów: fotografowałam koty, które potrzebowały stałego domu. A przy dobrych zdjęciach znacznie łatwiej jest umieścić kota. Sfotografowałem chyba ze sto kotów :)

Ostatecznie 80% mojej prezentacji było wypełnione kotami.

Zaraz po prezentacji HR napisał do mnie, że nie zna jeszcze wyników rozmowy kwalifikacyjnej, ale całe biuro było już pod wrażeniem kotów.

Ostatecznie doczekałem się opinii - zadowoliłem wszystkich jako osobę.

Jednak podczas ostatniej rozmowy HR taktownie stwierdził, że Sprawiedliwość Społeczna jest bardzo dobra i konieczna, ale nie wszystkie projekty są takie. I zapytał, czy mnie to przeraża. Generalnie trochę przesadziłem z tą Sprawiedliwością Społeczną, zdarza się :)

Łączny

W rezultacie od kilku miesięcy pracuję w Singapurze w Thinkworks i widzę, że tutaj zbyt wiele firm przejmuje „najlepsze praktyki dotyczące rozmów kwalifikacyjnych” od Google, używając do kodowania liści i tablicy, mimo że ma większą wiedzę niż Spring, Symfony, RubyOnRails (podkreśl to, co konieczne) nie jest wymagane w pracy. Inżynierowie biorą tydzień wolnego przed rozmową kwalifikacyjną, aby się „przygotować”.

W Thinkworks oprócz odpowiednich wymagań wobec kandydata na pierwszym planie stoją następujące zasady:
Radość z wywiadu. Co więcej, dla obu stron. Rzeczywiście, jeśli chcesz pozyskać jak najlepszy personel (a kto nie?), to rozmowa kwalifikacyjna nie jest rynkiem, na którym wybiera się niewolników, ale pokazem, podczas którego zarówno pracodawca, jak i kandydat oceniają się nawzajem. A jeśli kandydat kojarzy się z firmą przyjemnymi emocjami, jest prawdopodobne, że wybierze właśnie tę firmę

Wielu ankieterów, aby złagodzić stronniczość. W Thinkworks programowanie w parach jest de facto standardem. A jeśli tę praktykę można zastosować w innych obszarach, TW próbuje to zrobić. Na każdym etapie rozmowę przeprowadzają 2 osoby. Dlatego każda osoba jest oceniana przez co najmniej 8 osób, a TW stara się wybierać ankieterów o różnym pochodzeniu, różnych kierunkach (nie tylko technicznych) i płci.

Ostatecznie decyzja o zatrudnieniu zostanie podjęta na podstawie opinii co najmniej 8 osób i żadna nie będzie miała decydującego głosu.

Zatrudnianie na podstawie atrybutów Zamiast podejmować decyzję na podstawie upodobań kandydata, dla każdej roli i każdego etapu opracowywany jest formularz zawierający oceniane cechy. Jednocześnie zdecydowanie zaleca się, aby podczas oceny oceniać nie doświadczenie w określonej umiejętności, ale umiejętność jej zastosowania. Jeśli zatem kandydat nie potrafił zastosować żadnych umiejętności, np. TDD, a mimo to spróbuje je zastosować, wysłucha rad, jak je poprawnie wykorzystać, ma duże szanse przejść rozmowę kwalifikacyjną.

Certyfikaty edukacyjne nie są wymagane TW nie wymaga żadnych certyfikatów ani wykształcenia w zakresie informatyki. Oceniane są tylko umiejętności.

To moja pierwsza rozmowa kwalifikacyjna z zagranicznymi firmami, do której nie musiałam się przygotowywać. Po każdym etapie nie czułam zmęczenia, a wręcz przeciwnie, cieszyłam się, że mogę stosować najlepsze praktyki, że ludzie po drugiej stronie monitora to doceniają i stosują je każdego dnia.

Po kilku miesiącach mogę powiedzieć, że moje oczekiwania zostały w pełni spełnione. Czym ThinkWorks różni się od zwykłej firmy? W zwykłej firmie można znaleźć dobrych programistów i miłych ludzi, ale w TW ich koncentracja jest poza schematami.

Jeśli jesteś zainteresowany dołączeniem do ThinkWorks, możesz zapoznać się z naszymi otwartymi stanowiskami pracy tutaj
Sugeruję również zwrócenie uwagi na ciekawe oferty pracy:
Główny inżynier oprogramowania: Niemcy, Londyn, Madryt, Singapur
Starszy inżynier oprogramowania: Sydney, Niemcy, Manchester, Bangkok
Inżynier oprogramowania: Sydney, Barcelona, Mediolan
Starszy inżynier danych: Mediolan
Analityk Jakości: Niemcy Chiny
Infrastruktura: Niemcy, Londyn, Chile
(Chciałbym szczerze ostrzec, że link jest linkiem polecającym, jeśli wejdziesz na TW, otrzymam niezły bonus). Wybierz biuro, które Ci się podoba, nie musisz ograniczać się do Europy, wszak co 2 lata TW chętnie przeniesie Cię do innego kraju, bo... jest to część polityki ThinkWorks, zatem kultura jest rozpowszechniana i ujednolicana.

Zapraszam do zadawania pytań w komentarzach lub poproszenia mnie o rekomendacje.
Jeśli temat wydaje się ciekawy, napiszę o tym, jak wygląda praca w ThinkWorks i jak wygląda życie w Singapurze.

Źródło: www.habr.com

Dodaj komentarz