Jak Microsoft prowadzi rozmowy z inżynierami danych

Microsoft publikuje zwięzły zarys rozmów zamiast scenariusza każdej rundy, dlatego poniższy opis łączy oficjalne informacje z kategoriami przygotowań stosowanymi na tej stronie (wstępna rozmowa, kodowanie, projektowanie systemów, pytania behawioralne, spotkanie na miejscu), które nie są nazwami rund używanymi przez Microsoft.

• Rozmowy. Większość rozmów rekrutacyjnych w Microsoft obejmuje 2-4 spotkania z potencjalnymi członkami zespołu i osobami z innych działów, z których każde trwa do godziny. Inżynier danych może oczekiwać rozmów z osobami, których pulpity i modele zależą od jego potoków danych.
• Miejsce rozmów. Rozmowy mogą odbywać się telefonicznie, przez Microsoft Teams lub osobiście. W przypadku niektórych stanowisk kandydaci są proszeni o napisanie kodu, przedstawienie kreatywnego portfolio lub dostarczenie próbek pracy; stanowisko związane z danymi zdecydowanie należy do grupy wymagającej kodowania.
• Rundy techniczne. Rozmowy techniczne opierają się na rozwiązywaniu problemów. Obejmują doskonałość techniczną i kluczowe kompetencje, a także pytania kompetencyjne i pytania dotyczące CV.
• Jak wygląda kodowanie. Kodujesz wyłącznie w języku, który dobrze znasz, nie wolno Ci używać pseudokodu, a pracujesz w zewnętrznym narzędziu do kodowania, w którym możesz uruchamiać i kompilować swój kod.

Microsoft nie podaje, ile trwa cały proces ani która z 2-4 rozmów jest poświęcona projektowaniu systemów na stanowisku inżyniera danych.

Według opublikowanych informacji nacisk kładzie się na rozwiązywanie problemów: doskonałość techniczną i kluczowe kompetencje sprawdzane za pomocą pytań kompetencyjnych oraz pytań dotyczących CV. W praktyce każdy projekt wymieniony w CV może zostać szczegółowo omówiony na poziomie poszczególnych decyzji, a każda odpowiedź programistyczna musi działać, ponieważ pseudokod nie jest akceptowany, a narzędzie kompiluje kod.

Rozmowy na stanowisko inżyniera danych zasadniczo oceniają cztery obszary, a podejście oparte na rozwiązywaniu problemów pasuje do każdego z nich:

• SQL i modelowanie danych. Zapytania, które już przy pierwszym uruchomieniu zwracają poprawny wynik, oraz schematy, których wybór potrafisz uzasadnić w kontekście zmieniających się wymagań.
• Potoki danych i orkiestracja. Zależności, idempotentne ponowne uruchomienia, uzupełnianie danych historycznych oraz obsługa spóźnionego lub nieprawidłowego źródła.
• Rozproszone systemy danych. Partycjonowanie, formaty plików, przetwarzanie wsadowe w porównaniu ze strumieniowym oraz koszt każdego wyboru.
• Jakość danych i odpowiedzialność. Jak wykrywa się błędne dane, kto zostaje o nich powiadomiony i co zapobiega ponownemu wystąpieniu problemu.

Podczas testów i rozmów musisz wykazać się własnymi umiejętnościami bez pomocy z zewnątrz, chyba że została ona wyraźnie dozwolona, dlatego zarówno działający kod, jak i tok rozumowania muszą być Twoje.

Microsoft opisuje jeden format rozmowy technicznej, a nie osobny dla każdego stanowiska, dlatego poniższe różnice odzwierciedlają ogólną praktykę dotyczącą tych ról, a nie zasady Microsoft.

• W porównaniu z rozmowami na stanowisko inżyniera oprogramowania kod, który masz uruchomić, częściej dotyczy przetwarzania danych, logiki transformacji i SQL niż szerokiego zakresu algorytmów, a pytania projektowe skupiają się zwykle na przepływie, przechowywaniu i aktualności danych.
• W porównaniu z rozmowami na stanowisko analityka danych spodziewaj się mniej rozumowania statystycznego i modelowania, a więcej pytań o systemy, które terminowo dostarczają wiarygodne dane.
• W porównaniu z innymi firmami przebieg dnia kształtują trzy opublikowane szczegóły: niewielka liczba godzinnych rozmów zamiast długiego panelu, kod, który musi się kompilować w prawdziwym narzędziu, oraz obecność osób z innych działów. Przygotuj się do wyjaśniania swojej pracy zarówno inżynierowi, jak i osobie bez wykształcenia technicznego.

Microsoft nie publikuje harmonogramu. Podaje jednak zakres rozmów: 2-4 spotkania, każde trwające do godziny. To mniej niż wielorundowe rozmowy na miejscu opisywane przez niektóre firmy, dlatego każde spotkanie ma większe znaczenie.

Trudność jest bardziej praktyczna niż teoretyczna. Ponieważ nie możesz używać pseudokodu, a narzędzie uruchamia Twój kod, drobne błędy są natychmiast widoczne. Pytania kompetencyjne i dotyczące CV oznaczają natomiast, że w ciągu jednej godziny rozmowa może przejść od zapytania przez wcześniejszy projekt do kompromisu projektowego. Dogłębna znajomość własnej pracy jest ważniejsza niż szeroka wiedza z podręczników.

Odtwórz opublikowany format: rozwiązywanie problemów, kompetencje i Twoje CV — wszystko w języku programowania, który dobrze znasz.

• Uruchamiaj rozwiązania podczas ćwiczeń. Rozwiązuj zadania z SQL i transformacji w środowisku, które je wykonuje, jednocześnie opisując swój tok rozumowania, ponieważ narzędzie używane podczas rozmowy kompiluje kod, a pseudokod nie jest akceptowany.
• Jeden język, dogłębnie. Wybierz język, który znasz najlepiej, i trzymaj się go; Microsoft zaleca kodowanie wyłącznie w tym języku.
• CV na poziomie decyzji. Dla każdego potoku lub każdej platformy wymienionej w CV przygotuj uzasadnienie decyzji projektowej, odrzuconą alternatywę oraz opis obsłużonej awarii.
• Odpowiedzi dla osób z różnych działów. Przećwicz wyjaśnianie incydentu związanego z jakością danych analitykowi i menedżerowi produktu, ponieważ w rozmowach uczestniczą osoby z innych działów.
• Przećwicz całą godzinę. Próbna rozmowa rekrutacyjna z SubcueAI pozwala podczas jednej sesji ćwiczyć przechodzenie między kodowaniem, pytaniami kompetencyjnymi i pytaniami dotyczącymi CV; podczas prawdziwej rozmowy pomoc z zewnątrz jest zabroniona, chyba że zostanie wyraźnie dozwolona.