Wywiad Crack the System Design: wskazówki od inżyniera oprogramowania na Twitterze

Niedawno pisałem o tym, jak trafiłem na oferty wielu czołowych firm technologicznych. Podczas procesu przygotowywania wywiadu przeczytałem wiele materiałów i przygotowałem zestaw notatek na temat rozwiązywania problemów z projektowaniem systemu. W tym artykule chciałbym podzielić się z wami wszystkimi wskazówkami.

Jeśli jesteś świeżo upieczonym absolwentem, bez doświadczenia w dużych systemach rozproszonych, a nawet doświadczonym inżynierem z wieloletnim doświadczeniem, ten artykuł będzie dla Ciebie przydatny.

Aktualizacja (24.03.2019): Jeśli chcesz dołączyć do grupy uczniów, aby dowiedzieć się więcej o projektowaniu systemu, organizuję razem małą klasę! Możesz przejść do tego linku, aby dowiedzieć się więcej, lub odwiedzić moją stronę internetową: zhiachong.com, aby uzyskać więcej informacji.

Jak zaprojektować system: Wskazówki od inżyniera oprogramowania na Twitterze

Ten artykuł jest podzielony na następujące cztery sekcje:

  • Zadawaj pytania wyjaśniające
  • Użyj swojego tła
  • Systematycznie rozwiązuj problem
  • Zachowaj własne notatki

Zadawaj pytania wyjaśniające

Głównym celem wywiadu dotyczącego projektowania systemów jest umożliwienie kandydatowi wykazania się wiedzą.

Nie ma ściśle poprawnych lub błędnych odpowiedzi. Dobre pytanie projektowe systemu zwykle brzmi bardzo niejednoznacznie, a powodem tego jest to, że powinien dać ci szansę wykazania, co następuje:

  • Jak byś pomyślał o przestrzeni problemowej
  • Jak myślisz o wąskich gardłach
  • Co możesz zrobić, aby usunąć te wąskie gardła.
Jak zaprojektować tę czarną skrzynkę

Wyobraź sobie, że jesteś proszony o zaprojektowanie czarnej skrzynki. Jak poradziłbyś sobie z tym problemem? Nie ma jasnych wskazówek na temat tego, co musisz tutaj zbudować, poza tym, że pudełko może pomieścić w nim niektóre przedmioty.

Jedną z najbardziej przydatnych strategii, które osobiście stosuję, jest zadawanie pytań wyjaśniających. Jakie są „dobre” pytania wyjaśniające?

Dobre pytanie wyjaśniające pomaga osiągnąć jedną lub więcej z kilku rzeczy:

  1. Pomaga zawęzić zakres tego, co powinieneś zrobić
  2. Pomaga wyjaśnić, czego oczekuje użytkownik od systemu
  3. Wskazuje kierunek, w którym należy kontynuować
  4. Informuje o możliwych wąskich gardłach / obszarach problemowych

W przykładzie z czarną skrzynką możesz zapytać: „co zawiera skrzynka? Ile zawiera przedmiotów? A kto jest zamierzonym użytkownikiem? ”

Mogę powiedzieć, że zbudujmy żółte pudełko z buźką, które powinno pomieścić maksymalnie 1 piłkę tenisową. Nie jest to jednak zwykła piłka tenisowa. Będzie miał promień co najmniej 0,5 m i waży około 1 kg. Ma być przytulany, a nie trzymany, więc nie chcę mieć z tym nic wspólnego.

Proszę bardzo, to jest pudełko.

Moje idealne pudełko z uśmiechniętą twarzą

Zawsze zadawaj pytania wyjaśniające. Nie jesteś oceniany na podstawie tego, czy zadałeś konkretne pytanie podczas wywiadu, ale oceniasz, jak myślisz o przestrzeni problemowej.

Na przykład, jeśli miałbym teraz poprosić Cię o zaprojektowanie Twittera, jak byś to zrobił? Zastanów się przez chwilę, a może nawet naszkicuj na kartce papieru. Przejdź tak głęboko i szeroko, jak to możliwe, a następnie wróć do tego artykułu. Co więcej, możesz zostawić swoje uwagi w komentarzach poniżej, a my możemy omówić dalej.

Jeśli jeszcze tego nie zdałeś sobie sprawę, wynik końcowy powyższego ćwiczenia dałby znacznie inne wyniki. Na moim własnym tle mogę zagłębić się w projektowanie API i infrastrukturę zaplecza. Prawdopodobnie z powodu mojego doświadczenia odkryłbym również problemy związane z iPhonem. Opowiem o tym, jak klient wchodzi w interakcje z punktami końcowymi warstwy środkowej, o tym, jak będzie działać rejestrowanie, o tym, jak zaprojektować backend, aby zapewnić nieprzerwany czas pracy itd.

Są to dość interesujące dyskusje, które możesz przeprowadzić z kolegą i jest to bardzo silny sygnał, którego szuka ankieter.

Wykorzystaj swoje doświadczenie na swoją korzyść

Często widzę inżynierów próbujących dowiedzieć się, o co pyta ankieter, a następnie zaspokoić swoje odpowiedzi, aby spełnić oczekiwania.

Właściwie bardzo odradzam komukolwiek to robić z kilku powodów:

  1. Każdy ma unikalne tło. W wywiadzie dotyczącym projektowania systemów jest to okazja, aby zademonstrować swoje mocne strony. Nie marnuj okazji, aby dowiedzieć się, czego ktoś może od ciebie oczekiwać.
  2. Ankieter mógł kiwnąć głową na twoje odpowiedzi, ale mogli wiedzieć, że po prostu blefujesz i nie myślisz o problemie.

Twoje doświadczenie i pochodzenie mogą się znacznie różnić od następnego kandydata. Wnosisz do stołu zestaw wartości i wiedzy, których nikt inny nie może. To sprawia, że ​​jesteś cenny i niezastąpiony. Bez względu na to, w jakim obszarze jesteś, ludzie dbają o to, co możesz przynieść na stół.

Rozwiązuj problem systematycznie

Teraz, mając na uwadze moją wiedzę specjalistyczną, zastanawiam się nad kilkoma rzeczami, gdy mam do czynienia z nowym systemem. Zdecydowanie polecam również sformułowanie zestawu kryteriów lub kroków dla siebie.

Niektóre rzeczy, o których myślę, kiedy pracuję nad nowym systemem to:

  • Jaki jest cel systemu?
  • Kim są użytkownicy systemu?
  • Z jaką skalą współpracujemy?
  • Czy to nowy / stary system? Jak radzimy sobie z wersjonowaniem?

Pośród innych…

Widzisz, mój zestaw kryteriów będzie inny niż zestaw kryteriów front-endowego inżyniera. Używam tych kryteriów, aby sformułować obraz w mojej głowie, a one poprowadzą mój proces decyzyjny.

Uzbrojony w odpowiedzi na te pytania, mogę zacząć rozwiązywać dany problem, a następnie systematycznie rozkładać go na poszczególne elementy.

Dobrym ćwiczeniem, które lubię, jest zaprojektowanie systemu zamawiania kawy. Pomyślałem o tym, gdy pewnego dnia siedziałem w Starbucks, i zdałem sobie sprawę, że byłoby miło, gdybym mógł zamówić koktajl na telefonie i odebrać go w moim lokalnym Starbucks.

Mój umysł zaczął iść w różnych kierunkach:

  • Co robi ten automat do zamawiania kawy?
  • Jeśli go zbuduję, czy mogę go sprzedać Starbucks, czy mogę oznaczyć go białą etykietą i sprzedać jako usługę?
  • Ilu użytkowników muszę wspierać, jeśli sprzedam to Starbucks?
  • Ewentualnie, jeśli oznaczę go białą etykietą, czy mogę sprzedać interfejs mojej usłudze zamawiania kawy, a następnie pomóc klientom w zbudowaniu zaplecza, aby mogli przechowywać zamówienia na swoich lokalnych komputerach?
Jak podejść do tego problemu

Po uzyskaniu odpowiedzi na te pytania mogę wreszcie uzyskać pełny obraz tego, co robi moja usługa zamawiania kawy. Oto jak wyglądałaby moja wersja usługi zamawiania kawy:

Moja usługa zamawiania kawy to oprogramowanie jako usługa (SAAS). Oferuje interfejs dla różnych partnerów do podłączenia.

  • Ma interfejs API o nazwie addCoffeeForMerchant, który wstawia nazwę kawy, cenę kawy i składniki kawy.
  • Ma GET API o nazwie getCoffeesForMerchant, który zwraca listę kaw dla danego identyfikatora sprzedawcy.
  • Identyfikator handlowca to unikalny identyfikator (UUID), który jest generowany przy użyciu jakiegoś mechanizmu mieszającego, który można dodatkowo wyjaśnić klientowi.
  • Oprogramowanie jest zoptymalizowane pod kątem operacji tylko do odczytu, ponieważ większość moich klientów tworzy swoje menu raz i czyta je wiele razy w ciągu dnia.
  • Ma mechanizm buforowania, który wykorzystuje strategię eksmisji Najmniej ostatnio używane (LRU), ponieważ jeśli element menu nie został zamówiony od jakiegoś czasu, mój klient nie dba o to, czy jego wyświetlanie w menu będzie nieco wolniejsze.
  • W przypadku wybuchu jednego z magazynów danych moja usługa zamawiania kawy powiela dane w różnych klastrach na zachodnim wybrzeżu USA i wschodnim wybrzeżu USA, ponieważ na razie kieruję reklamy na rynek amerykański.

Alternatywnie, każda inna usługa zamawiania kawy, o której możesz pomyśleć, byłaby wysoce prawdopodobna. To tylko kwestia tego, co optymalizujesz. Myślę, że są to bardzo interesujące problemy i jest to świetne ćwiczenie umysłowe, aby utrzymać zaangażowanie umysłu.

Zachowaj własne notatki

Jako inżynier oprogramowania jest to niekończący się proces uczenia się. Zdecydowanie zalecamy używanie Evernote lub Moleskin do robienia notatek. Osobiście noszę mały zeszyt do szybkich pomysłów, które muszę zanotować, i przechowuję różne inne rzeczy w Evernote, kiedy tylko mogę.

W moim Evernote mam notes o nazwie „Programowanie”. Ilekroć natknę się na coś nowego lub coś interesującego, zapisuję to w moim notatniku, aby uzyskać dodatkowe informacje.

Przeglądam i przypisuję etykiety do tych nowych notatek co miesiąc lub co kwartał, aby mieć pewność, że notatki są uporządkowane. Na przykład mam etykietę „Projekt” do wszystkiego, co ma związek z projektowaniem systemu. Może to być coś w rodzaju linku do filmu na YouTube, który uznałem za interesujący, lub interesujący argument, który mój współpracownik przedstawił, o czym nie myślałem.

Oto próbka tego, jak wygląda jedna z moich notatek:

Przepraszamy za złą gramatykę i literówki: str

Jedną z rzeczy, których dowiedziałem się ostatnio od współpracownika, jest to, że NoSQL świetnie nadaje się do prototypowania, ponieważ nie ma potrzeby prowadzenia dyskusji na temat schematu z innymi zespołami. Jeśli chciałbym zmienić schemat, mogę to zrobić naprawdę szybko z bazą danych NoSQL. To była kluczowa nauka z pracy, którą umieściłem w moim notatniku „Programowanie”.

Dzielę swoje notatki na:

  1. Projekty systemów
  2. Wywiad (doświadczenie + przegląd różnych wywiadów, które miałem w przeszłości, pogrupowane według nazwy firmy)
  3. Losowe tid-bity, znajomość CS, takie jak przydatne skrypty bash lub sztuczki z wiersza poleceń
  4. Odczyty / filmy z YouTube

Wszystkie powyższe uwagi znajdują się w części „Programowanie”. Z czasem okazało się, że mam pseudo zorganizowany zbiór rzeczy, które albo czytałem, albo eksplorowałem w przeszłości.

Jak każdy, kto zna mnie na poziomie osobistym, nie jestem osobą bardzo zorganizowaną. Dlatego zebrałem tylko 10-15% rzeczy, więc pozostało jeszcze wiele do zrobienia.

Wiedza i praktyka idą w parze z ulepszaniem projektów systemów. Jeśli uważasz, że twoja obecna praca nie daje ci możliwości projektowania systemów, powinieneś albo znaleźć taki, który to robi, albo spróbować zaprojektować jedną małą część istniejącej architektury, tak aby była albo szybsza, tańsza, bardziej niezawodna, lub łatwiejsze do modyfikacji w przyszłości.

Zasoby polecam

Wprowadzenie do: architektury i projektowania systemów - świetny samouczek Youtube od byłego inżyniera Facebooka na temat podejścia do problemów z projektowaniem systemów.

Projektowanie aplikacji intensywnie wykorzystujących dane - Kolejny dobry zasób do nauki projektowania w skali. Mówi o różnych rzeczach, które typowy inżynier oprogramowania bierze za pewnik - jak działają bazy danych (mySQL i noSQL), kiedy z nich korzystać, zalety i wady różnych technik obsługi skali itp. Gorąco polecam

Mock Interviews - Symulowane środowisko, które naśladuje rzeczywisty wywiad, jest niezwykle pomocne w przygotowaniu się do wywiadów. Jeśli możesz znaleźć przyjaciela, który by to dla ciebie zrobił, to bardzo go polecam. Prowadzę również fałszywe wywiady, więc jeśli jesteś zainteresowany, skontaktuj się ze mną na zhiachong.com!

Co każdy inżynier oprogramowania powinien wiedzieć o ujednolicającej abstrakcji danych w czasie rzeczywistym - Bardzo długa i techniczna dyskusja na temat dzienników, kompromisów. Jeszcze go nie ukończyłem, ale jest wysoce zalecane od współpracownika.

Evernote - najlepsza aplikacja do notowania, z której korzystałem. Istnieje wiele samouczków na temat najlepszego wykorzystania Evernote. Jeszcze ich nie przejrzałem, po prostu dlatego, że używam ich jako zeszytu. Rejestruję tam wszystko, czego się uczę, a następnie od czasu do czasu przeglądam je i reorganizuję.

Zeszyt Moleskin - naprawdę mi się podoba. Jego jakość jest niezwykle wysoka. Cena jest nieco wyższa, ale ponieważ używam jej na co dzień, uważam ją za dobrą inwestycję. Codzienne trzymanie w rękach pięknego notesu sprawia, że ​​jestem bardziej podekscytowany pisaniem kolejnych notatek.

Pilot G2 (czarny) - Łatwo najlepsze pisaki, jakich kiedykolwiek używałem i jedyne pisaki, których będę używać. Kupuję je hurtowo w Amazon i trzymam je wszędzie ze sobą. Mam jeden w plecaku, jeden w biurze i jeden w moim domowym biurze, więc zawsze mam przy sobie długopis. Pisze świetnie, atrament płynie gładko, a ja po prostu uwielbiam pisać z nim. W połączeniu z Moleskinem czasami po prostu chcę podnieść G2, aby zapisać tam losowe rzeczy, ponieważ te dwa są tak idealne razem.

Grokking the System Design Interview - ten jest rekomendacją od znajomych. Jest to kurs online, który uczy, jak szczegółowo zaprojektować system rozproszony. Jest to jednak kurs o wartości 79 USD. Istnieje wycena zespołowa. Jeśli są jakieś zainteresowania, skontaktuję się z nimi, aby sprawdzić, czy można utworzyć grupę z rabatem grupowym.

Obserwuj mnie na Twitterze, Facebooku i LinkedIn. Zapisz się na moją listę mailingową, na której regularnie przesyłam porady, wskazówki i informacje branżowe.

Jeśli podobał Ci się ten artykuł, skomentuj poniżej: jaka jest twoja wskazówka, jak zbudować skalowalny, niezawodny system?