Meta System Design-interviewvragen

Misschien heb je je voorbereid door distributed-systemstrivia uit je hoofd te leren, maar deze ronde beloont dat niet. Dit gedeelte behandelt de echte vraagvormen, die dichter bij product engineering liggen dan bij infrastructuur. Het terugkerende patroon is een functie op consumentenschaal die je al gebruikt, aan jou gegeven als een open probleem.

• Ontwerp een nieuwsfeed. Ranking, fanout on write versus fanout on read, en wat er gebeurt bij accounts met miljoenen volgers.
• Ontwerp een messaging- of chatsysteem. Bezorggaranties, volgorde, presence en offline synchronisatie tussen apparaten.
• Ontwerp een notificatiesysteem. Deduplication, batching, rate limits per gebruiker en bezorging via push, e-mail en in-app.
• Ontwerp vrienden in de buurt of een locatiefunctie. Geospatial indexing, updatefrequentie en het privacymodel.
• Ontwerp een zoek- of trendingcomponent. Versheid van de index tegenover querylatency.

Sommige interviewreeksen splitsen dit op in een productarchitectuurvariant die dicht bij gebruikersgericht gedrag blijft. Vraag je recruiter welke je krijgt, want de voorbereiding verschilt.

De veelvoorkomende fout is dat je in minuut twee al vakjes tekent. Een werkbare verdeling: verduidelijk requirements en scope, schets de API en het datamodel, teken de high-level architectuur, en ga dan diep waar de interviewer op wijst.

• Eerst requirements. Welke gebruikers, welke platforms, read-heavy of write-heavy, en wat je expliciet niet bouwt.
• Dan getallen. Ruwe dagelijkse actieve gebruikers, requestaantallen en payloadgroottes, zodat latere trade-offs een basis hebben.
• Datamodel vóór diagrammen. Hoe een entity eruitziet en hoe die wordt bevraagd, bepaalt meestal de architectuur.
• Eén deep dive. Verwacht dat je naar één component wordt gestuurd en gevraagd wordt hoe die faalt.

Spreek je aannames hardop uit. Een interviewer die het oneens is met een aanname, corrigeert die, en dat is gratis informatie; een onuitgesproken aanname lijkt gewoon een hiaat.

Gemiddelde antwoorden beschrijven een correcte architectuur. Sterke antwoorden benoemen de trade-off die ze accepteren en het falen dat ze bereid zijn te tolereren. Zeggen: "Ik kies fanout on write omdat reads hier domineren, en ik accepteer trage writes voor accounts van bekendheden, wat ik zou afhandelen met een aparte pull path" doet meer dan een perfect diagram.

Denk aan een backend engineer die solliciteert naar een seniorrol. Ze krijgt de opdracht een notificatiesysteem te ontwerpen en besteedt de eerste zes minuten alleen aan requirements: of een gebruiker twee notificaties kan krijgen voor één event, of volgorde ertoe doet, wat het retentievenster is. De interviewer zegt later dat de deduplicationdiscussie het doorslaggevende deel van de ronde was, en ze komt nooit verder dan een diagram van één pagina.

Dit verhaal alleen aan een bureau oefenen is het moeilijke deel. Je kunt designvragen oefenen tegen een AI-interviewer op de pagina /mock-interview en wennen aan praten terwijl je nadenkt.

Tijdens een gesproken videoronde transcribeert SubcueAI de vraag van de interviewer en toont een voorgestelde structuur aan jouw kant, in de desktopoverlay op macOS en Windows of in het zijpaneel van de Chromium-browserextensie. Er neemt geen meetingbot deel aan het gesprek, en er wordt niets in de meetingpagina geïnjecteerd. Voor een designronde is de realistische waarde een checklist die je onder druk steeds vergeet, zoals de capaciteitsschatting of het faalmodel, in plaats van een antwoord dat je hardop voorleest.

De grenzen zijn duidelijk. Designronden vinden meestal plaats in een gedeeld whiteboardtool met je scherm gedeeld, en alles op je scherm is zichtbaar voor het panel. Een gegenereerd antwoord voorlezen stort ook meteen in, omdat de volgende vraag van de interviewer "waarom niet de andere aanpak?" is. Vergelijkbare interviewreeksen voor andere werkgevers vind je onder company interviews topic.