Jak Trudna Jest Rozmowa w Amazon?

Jeśli ćwiczyłeś zadania algorytmiczne i wciąż czujesz się nieprzygotowany, ten instynkt jest słuszny. Ta sekcja wyjaśnia, z czego składa się dodatkowa trudność, bo nie chodzi o same zadania, a rozwiązanie kolejnych ich nie rozwiąże.

Amazon prowadzi ustrukturyzowaną rozmowę. Osobom prowadzącym przydziela się konkretne Leadership Principles do zbadania, robią one szczegółowe notatki podczas rozmowy, a te notatki są potem porównywane na debriefie. Wynikają z tego dwie konsekwencje. Historia, która brzmiała nieźle w pokoju, na papierze wygląda ubogo, jeśli nie ma w niej decyzji ani wyniku, a ta sama historia opowiedziana dwukrotnie z innymi szczegółami w dwóch rundach od razu widać przy porównaniu notatek.

Drugim źródłem trudności jest to, że poprzeczka behawioralna obowiązuje również w rundach technicznych. Kandydat, który sprawnie rozwiąże zadanie z kodu, ale nie potrafi opisać sytuacji, w której nie zgodził się z menedżerem, oblał element, którego czysto techniczna rozmowa nigdy by nie zmierzyła.

Bar Raiser to osoba prowadząca rozmowę spoza zespołu rekrutującego, przeszkolona do tej roli, której zadaniem jest ocena, czy podnosisz średnią osób już na tym poziomie. Nie ocenia, czy zespół potrzebuje kogoś w tym kwartale, i może zablokować zatrudnienie, którego chce hiring manager.

W praktyce oznacza to, że osoba decydująca o twoim wyniku nie ma żadnego interesu w obsadzeniu stanowiska. Pilność sprawy ci nie pomoże, podobnie jak dobra relacja z menedżerem. Pomaga natomiast dowód, który broni się po zapisaniu i przeczytaniu przez kogoś, kto nigdy cię nie spotkał.

Zwykle nie wiesz, kto jest tą osobą, i to nie ma znaczenia. Odpowiadaj w każdej rundzie tak, jakby miał to później przeczytać obcy człowiek, bo tak właśnie jest.

Podziel pracę na dwie części. Część techniczna jest znajoma: struktury danych, algorytmy, a dla poziomu średniego i wyższego projektowanie systemów. Większość kandydatów, którzy oblewają, nie oblewa właśnie tutaj.

Część behawioralna wymaga od ośmiu do dwunastu historii rozłożonych na Leadership Principles, każda z sytuacją, tym, co osobiście zdecydowałeś, i mierzalnym wynikiem. Jeden projekt może dostarczyć dwie lub trzy historie z różnych perspektyw. Zapisz wynik jako liczbę, jeśli tylko istnieje, bo pytanie pogłębiające zwykle prosi właśnie o to.

Potem przećwicz je na głos. Inżynierka back-endu z dziewięcioletnim doświadczeniem napisała świetne notatki, a mimo to zacinała się przy pierwszej próbie, bo czytanie historii i opowiadanie jej pod pytaniem pogłębiającym to różne umiejętności. Dwa tygodnie ustnej praktyki na /mock-interview zmieniły sposób podania historii bardziej niż kolejny miesiąc czytania. Obraz przebiegu rozmowy krok po kroku znajduje się na /answers/topic/company-interviews.

Za większość przypadków odpowiadają cztery wzorce i żaden z nich nie dotyczy inteligencji.

• Historie bez decyzji. Opisywanie tego, co zrobił zespół, zamiast tego, co wybrałeś ty. Notatki kończą się bez dowodu przypisanego do twojego nazwiska.
• Brak wyniku. Historia, która kończy się w momencie wdrożenia projektu, bez informacji, czy zadziałał.
• Wyczerpanie materiału. Wykorzystywanie tego samego projektu w czterech rundach, co widać na debriefie, mimo że żaden pojedynczy rozmówca tego nie zauważył.
• Ciche rozwiązywanie problemów. Przechodzenie przez zadanie z kodu bez opowiadania toku rozumowania, przez co rozmówca nie ma nic do zanotowania.

Warto też jasno powiedzieć, że zdolni inżynierowie są tu odrzucani z powodów niezwiązanych z kompetencjami, w tym dopasowania do zespołu i składu panelu danego dnia. Przygotowanie zmienia szanse; nie przesądza o nich, a odrzucenie nie jest wyrokiem na temat twoich umiejętności.