Pytania Rekrutacyjne System Design w Meta

Mogłeś przygotować się, ucząc się na pamięć ciekawostek o systemach rozproszonych, ale ta runda tego nie nagrodzi. Ta sekcja opisuje faktyczne kształty pytań, które są bliższe product engineering niż infrastrukturze. Powtarzający się wzorzec to funkcja w skali konsumenckiej, której już używasz, przekazana tobie jako otwarty problem.

• Zaprojektuj news feed. Ranking, fanout on write kontra fanout on read oraz co się dzieje przy kontach z milionami obserwujących.
• Zaprojektuj system wiadomości lub czatu. Gwarancje dostarczenia, kolejność, presence i synchronizacja offline między urządzeniami.
• Zaprojektuj system powiadomień. Deduplication, batching, limity rate na użytkownika oraz dostarczanie przez push, e-mail i in-app.
• Zaprojektuj znajomych w pobliżu lub funkcję lokalizacji. Indeksowanie geoprzestrzenne, częstotliwość aktualizacji i model prywatności.
• Zaprojektuj komponent wyszukiwania lub trendów. Świeżość indeksu w zestawieniu z opóźnieniem zapytań.

Niektóre procesy rekrutacyjne dzielą to na wariant product architecture, który pozostaje bliski zachowaniom widocznym dla użytkownika. Zapytaj swojego rekrutera, który wariant dostaniesz, bo przygotowanie się różni.

Tryb porażki to rysowanie prostokątów już w drugiej minucie. Sprawdzony podział: doprecyzuj wymagania i zakres, naszkicuj API i model danych, narysuj architekturę wysokiego poziomu, a potem zejdź głęboko tam, gdzie wskaże rozmówca.

• Najpierw wymagania. Którzy użytkownicy, które platformy, read-heavy czy write-heavy oraz czego wyraźnie nie budujesz.
• Potem liczby. Przybliżeni dzienni aktywni użytkownicy, liczba żądań i rozmiary payloadów, żeby późniejsze kompromisy miały na czym się oprzeć.
• Model danych przed diagramami. To, jak wygląda entity i jak jest odpytywana, zwykle decyduje o architekturze.
• Jedno głębokie zejście. Spodziewaj się skierowania do jednego komponentu i pytania, jak on zawodzi.

Wypowiadaj swoje założenia na głos. Rozmówca, który nie zgadza się z założeniem, poprawi je, a to darmowa informacja; niewypowiedziane założenie wygląda po prostu jak luka.

Przeciętne odpowiedzi opisują poprawną architekturę. Mocne odpowiedzi nazywają kompromis, który zaakceptowały, i awarię, którą są gotowe tolerować. Powiedzenie "wybieram fanout on write, bo tutaj dominują odczyty, i akceptuję wolne zapisy dla kont celebrytów, co obsłużyłbym osobną ścieżką pull" daje więcej niż idealny diagram.

Weź pod uwagę backend engineerkę na rozmowie o rolę senior. Ma zaprojektować system powiadomień i pierwsze sześć minut spędza wyłącznie na wymaganiach: czy użytkownik może dostać dwa powiadomienia za jedno zdarzenie, czy kolejność ma znaczenie, jakie jest okno retencji. Rozmówca później mówi, że dyskusja o deduplication była decydującą częścią rundy, a ona nigdy nie przeszła poza diagram na jedną stronę.

Ćwiczenie tej narracji w pojedynkę przy biurku to trudna część. Możesz uruchamiać pytania projektowe wobec AI interviewera na stronie /mock-interview i przyzwyczaić się do mówienia podczas myślenia.

Podczas rundy wideo z mówioną rozmową SubcueAI transkrybuje pytanie rozmówcy i pokazuje po twojej stronie sugerowaną strukturę, w nakładce desktopowej na macOS i Windows lub w panelu bocznym rozszerzenia przeglądarki Chromium. Żaden meeting bot nie dołącza do rozmowy i nic nie jest wstrzykiwane do strony spotkania. Dla rundy projektowej realistyczną wartością jest checklista, o której wciąż zapominasz pod presją, jak szacunek pojemności czy failure mode, a nie odpowiedź, którą czytasz na głos.

Granice są jasne. Rundy projektowe zwykle przebiegają na współdzielonym narzędziu whiteboard z udostępnionym ekranem, a wszystko na twoim ekranie jest widoczne dla panelu. Czytanie wygenerowanej odpowiedzi też natychmiast się załamuje, bo kolejne pytanie rozmówcy brzmi "dlaczego nie inne podejście?". Powiązane procesy dla innych pracodawców znajdziesz w company interviews topic.