Meta Systemdesign-intervjufrågor

Du kanske har förberett dig genom att memorera trivia om distribuerade system, men den här rundan belönar inte det. Det här avsnittet täcker de faktiska frågeformerna, som ligger närmare product engineering än infrastruktur. Det återkommande mönstret är en funktion i konsumentskala som du redan använder, given till dig som ett öppet problem.

• Designa ett nyhetsflöde. Ranking, fanout on write kontra fanout on read, och vad som händer för konton med miljontals följare.
• Designa ett meddelande- eller chattsystem. Leveransgarantier, ordning, presence och offline-synkronisering mellan enheter.
• Designa ett notifieringssystem. Deduplication, batching, rate limits per användare och leverans via push, e-post och in-app.
• Designa vänner i närheten eller en platsfunktion. Geospatial indexering, uppdateringsfrekvens och integritetsmodellen.
• Designa en sök- eller trendkomponent. Indexets färskhet mot frågelatens.

Vissa intervjuserier delar upp det här i en product architecture-variant som håller sig nära användarvänt beteende. Fråga din rekryterare vilken du får, eftersom förberedelsen skiljer sig.

Misslyckandet är att börja rita rutor redan i minut två. En fungerande uppdelning: förtydliga krav och scope, skissa API:et och datamodellen, rita arkitekturen på hög nivå, gå sedan djupt där intervjuaren pekar.

• Krav först. Vilka användare, vilka plattformar, read-heavy eller write-heavy, och vad du uttryckligen inte bygger.
• Sedan siffror. Ungefärliga dagligt aktiva, requestfrekvenser och payload-storlekar, så att senare avvägningar har något att stå på.
• Datamodell före diagram. Hur en entity ser ut och hur den frågas mot avgör oftast arkitekturen.
• En djupdykning. Räkna med att styras in i en enda komponent och få frågan hur den fallerar.

Uttala dina antaganden högt. En intervjuare som inte håller med om ett antagande kommer att rätta det, vilket är gratis information; ett outtalat antagande ser bara ut som ett hål.

Genomsnittliga svar beskriver en korrekt arkitektur. Starka svar namnger den avvägning de accepterat och det fel de är villiga att tolerera. Att säga "jag väljer fanout on write eftersom läsningar dominerar här, och jag accepterar långsamma skrivningar för kändiskonton, vilket jag skulle hantera med en separat pull path" gör mer än ett perfekt diagram.

Tänk dig en backend-ingenjör som intervjuar för en seniorroll. Hon ombeds designa ett notifieringssystem och lägger de första sex minuterna enbart på krav: om en användare kan få två notifieringar för samma händelse, om ordning spelar roll, vad retention-fönstret är. Intervjuaren säger senare att diskussionen om deduplication var den avgörande delen av rundan, och hon kom aldrig förbi ett diagram på en sida.

Att öva den här berättarrösten ensam vid ett skrivbord är den svåra delen. Du kan köra designfrågor mot en AI-intervjuare på sidan /mock-interview och vänja dig vid att prata medan du tänker.

I en talad videorunda transkriberar SubcueAI intervjuarens fråga och visar en föreslagen struktur på din sida, i desktopöverlägget på macOS och Windows eller i sidopanelen för Chromium-webbläsartillägget. Ingen meeting bot går med i samtalet, och inget injiceras i mötessidan. För en designrunda är det realistiska värdet en checklista du ständigt glömmer under press, som kapacitetsuppskattningen eller failure mode, snarare än ett svar du läser högt.

Gränserna är tydliga. Designrundor körs oftast på ett delat whiteboard-verktyg med din skärm delad, och allt på din skärm är synligt för panelen. Att läsa upp ett genererat svar kollapsar också omedelbart, eftersom intervjuarens nästa fråga är "varför inte den andra metoden?". Relaterade intervjuserier för andra arbetsgivare finns under company interviews topic.