Kan ik AI gebruiken om systeemontwerpinterviews te oefenen?

Als AI meteen een voltooide architectuur aanlevert, mis je de kans om het nemen van beslissingen te oefenen. Met de onderstaande opzet blijf jij verantwoordelijk voor het antwoord, dankzij een concrete opdracht voor de interviewer en regels om hints uit te stellen.

Gebruik deze opdracht in een AI-tool die gespreksinstructies accepteert:

Treed op als interviewer voor systeemontwerp voor een senior functie als backend-engineer. Vraag me een dienst voor de levering van webhooks te ontwerpen. Laat me de vereisten verduidelijken voordat ik componenten voorstel. Stel telkens één vraag en wacht op mijn antwoord. Daag mijn aannames over verkeer, leveringsgaranties en storingen uit. Toon geen referentiearchitectuur en geef geen hints, tenzij ik erom vraag. Benoem nadat ik klaar ben omissies en twijfelachtige beweringen aan de hand van specifieke voorbeelden uit mijn antwoorden.

Vervang de functie en het probleem door jouw doel. Als AI het ontwerp voor je begint af te maken, vraag dan om terug te keren naar de vragen. Antwoord hardop en teken tijdens het gesprek, zelfs als je een samenvatting in de tool moet typen.

Ga voor het oefenaanbod van SubcueAI naar de pagina voor proefinterviews.

Stel vóór aanvang een tijdsbudget voor de oefening vast. Deze voorgestelde structuur van 40 minuten is een oefenplan en geen bewering over de interviewopzet van een werkgever:

• Vereisten, 5 minuten: Bepaal de gebruikers, essentiële handelingen, uitgesloten functies en aanvaardbare vertragingen. Verduidelijk voor webhooks of de volgorde ertoe doet en wat een geslaagde levering inhoudt.
• Schattingen, 5 minuten: Vermeld het aantal events, de payloadgrootte, het aantal bestemmingen per event en een aanname voor de piekbelasting. Houd de eenheden zichtbaar.
• Eerste ontwerp, 15 minuten: Schets de eventinvoer, duurzame opslag, een leveringswachtrij, workers en endpoints van klanten. Volg één event door het systeem en leg elke bevestiging uit.
• Verdieping, 10 minuten: Kies een risico, zoals dubbele levering, overbelaste bestemmingen of het uitvallen van een worker. Leg een reactie en de kosten ervan uit.
• Samenvatting, 5 minuten: Vat het ontwerp, de zwakste aanname en wat je vervolgens zou onderzoeken samen.

Laat de vereisten de componenten rechtvaardigen. Leg bijvoorbeeld uit wat een procescrash moet overleven voordat je kiest hoe je events duurzaam opslaat. Als het proefinterview een kennislacune blootlegt, rond je poging dan af, bestudeer die lacune en oefen de uitleg opnieuw.

Stel je een backend-engineer voor die zich met een proefinterview over webhooklevering voorbereidt op een senior platformfunctie. De hypothetische werklast bestaat uit 10 miljoen events per dag, één bestemming per event en een payload van 1 KB. AI vraagt wat er gebeurt wanneer het endpoint van een klant een uur lang niet beschikbaar is.

Begin met een berekening die je kunt uitleggen: 10,000,000 gedeeld door 86,400 is gemiddeld ongeveer 116 events per seconde. Een afzonderlijk gekozen piekaanname van tien keer het gemiddelde levert ongeveer 1,160 eerste leveringspogingen per seconde op. Retries veroorzaken extra verkeer bovenop die eerste pogingen.

Met decimale eenheden bedragen de eventpayloads in totaal ongeveer 10 GB per dag, vóór metadata, indexen, replicatie en andere overhead. Dit zijn aannames voor een oefening, geen productiemetingen. Om de achterstand van de niet-beschikbare klant te schatten, moet je eerst vaststellen welk deel van de events voor die klant bestemd is.

Vraag AI vervolgens om deze gevallen afzonderlijk te onderzoeken:

• Verloren bevestiging: De ontvanger verwerkt een event, maar de verzender ontvangt het antwoord nooit. Leg uit hoe een retry een neveneffect kan herhalen en waar deduplicatie thuishoort.
• Trage bestemming: Eén klant gebruikt capaciteit van workers. Leg uit hoe limieten voor gelijktijdigheid, uitstel tussen retries en isolatie andere klanten kunnen beschermen.
• Crash van een worker: Een worker stopt tijdens de levering. Bepaal wat duurzaam opgeslagen blijft, wanneer het werk voor een nieuwe poging in aanmerking komt en hoe duplicaten worden afgehandeld.

Bekijk voor een ander oefenprobleem de gidsen met interviewvragen.

Vraag om bewijs voordat je een score accepteert. Een nuttige beoordeling benoemt iets wat je hebt gezegd of weggelaten, legt het gevolg ervan uit en geeft je een specifiek punt om opnieuw te bekijken.

• Vereisten: Behandelde je ontwerp de afgesproken reikwijdte en leveringsverwachtingen?
• Getallen: Waren de eenheden consistent en maakte je onderscheid tussen gemiddelde belasting, piekbelasting en retries?
• Architectuur: Kon je zowel een geslaagd verzoek als een storing door het diagram volgen?
• Afwegingen: Legde je een aannemelijk alternatief uit en wat de gevolgen zijn als je het afwijst?
• Communicatie: Legde je uit waarom een component nodig was voordat je de implementatie ervan besprak?

AI kan niet-bestaande mogelijkheden van diensten verzinnen, schattingen verkeerd berekenen of een component aanbevelen die het genoemde probleem niet oplost. Bereken de cijfers zelf opnieuw en controleer betwiste technische beweringen aan de hand van gezaghebbende documentatie. Vraag de beoordelaar onderscheid te maken tussen een geschonden vereiste en een voorkeur tussen geldige ontwerpen.

Blijf tekenen tijdens het oefenen. Feedback op basis van alleen tekst kan een diagram dat niet is ontvangen niet beoordelen, en feedback die afbeeldingen ondersteunt kan nog steeds inconsistenties missen. Controleer of je pijlen, gegevensopslag, bevestigingen en mondelinge uitleg met elkaar overeenkomen.

Herhaal het zwakste onderdeel zonder hints en probeer daarna een verwant probleem met een gewijzigde beperking. Houd bij of je jouw beslissingen zelfstandig kunt uitleggen. Een collega of ervaren interviewer kan onduidelijke redeneringen aanvullend controleren; alleen een AI-score kan niet bepalen of je er klaar voor bent.