Slagen voor het systeemontwerpinterview

Het is alweer een tijdje geleden dat ik voor het laatst heb geschreven, maar het afgelopen jaar heb ik veel interviews over systeemontwerp gedaan. Ik vind deze interviews erg leuk, ook al kunnen ze wat verbetering gebruiken, omdat ze sterk kunnen lijken op het werk dat ik echt doe en open genoeg zijn om kandidaten in staat te stellen hun sterke punten te benutten.

Op basis van het interviewen van veel kandidaten, heb ik een paar belangrijke tips verzameld om ervoor te zorgen dat je interviewers precies de signalen geeft die ze nodig hebben om je sterke punten te evalueren. Systeemontwerp is een vaardigheid die ervaring vereist, maar voor degenen die ervaren zijn, zou die vaardigheid toch iets moeten zijn dat ze in hun dagelijkse werk gebruiken. Wat volgt is een checklist om interviewzenuwen te bestrijden en je ervaring in dat ene uur te laten zien.

Verzamel functionele en niet-functionele vereisten

Ik heb het al eerder gehad over het verzamelen van vereisten , maar dit is vooral belangrijk voor systeemontwerpinterviews. In tegenstelling tot een beperkt algoritme, heeft een groot systeem veel meer gebieden waar u verschillende beslissingen kunt nemen op basis van uw vereisten. Er zijn twee soorten vereisten die u moet verduidelijken:

• Functionele eisen: wat zou het systeem eigenlijk moeten zijn doen? Bij het ontwerpen van een URL-verkorter is een belangrijke vraag die we bijvoorbeeld moeten stellen of we reverse lookups willen ondersteunen (van een lange URL naar een bestaande korte URL), of als u kunt verdragen dat dezelfde lange URL op twee verschillende manieren wordt ingekort. Dit is waar u begrijpt hoe gebruikers daadwerkelijk met het systeem zullen omgaan.
• Niet-functionele eisen: hoe het systeem zich technisch gedraagt. U wilt de schaal van het systeem begrijpen (aantal gebruikers, gelijktijdige verzoeken, hoeveelheid gegevens die wordt verwerkt of opgeslagen). Een andere gemeenschappelijke factor die moet worden verduidelijkt, is de verwachte latentie, met name end-to-end latentie voor het hele systeem, die consistentievereisten voor lezen na schrijven kan omvatten.

Het is prima om tijdens het ontwerp van uw systeem in een aantal van deze vereisten te duiken, terwijl u erachter komt welke afwegingen u moet maken. Hoe meer ervaring u echter heeft, hoe meer van deze vereisten u van tevoren kunt herkennen en daarom komt uw ervaringsniveau naar voren in dit deel van het interview.

Maar wat je ook doet, duik niet meteen in een ontwerp. Zoek eerst uit wat je ontwerpt.

Presenteer een end-to-end oplossing

Het grootste probleem dat ik zie, is wanneer kandidaten te veel in detail treden in sommige delen van hun architectuur, en aan het einde van het interview hebben ze geen end-to-end oplossing. Misschien hebben ze zich te veel gericht op de gegevensopslag en hebben ze met de hand gezwaaid over hoe de gegevens worden verwerkt. Of ze hebben het nooit gehad over hoe de data, of zelfs welke data, eigenlijk in hun systeem terecht komt.

Zorg er in ieder geval voor dat u een blokdiagram op hoog niveau hebt dat alle verschillende componenten van uw voorgestelde systeem duidelijk weergeeft. De meeste oplossingen zullen bestaan uit deze veelvoorkomende onderdelen:

• Gegevensbronnen: applicatieservers, clientapparaten, enz.
• Gegevensopslag: relationele, tijdreeks- en sleutel-waardedatabases, in-memory caches, enz.
• Datatransport: berichtenwachtrijen, REST API's, etc.
• Gegevensverwerking: waar de verwerking plaatsvindt, welke gegevens nodig zijn en wat de verwerking doet.
• Ondersteunende diensten als ze zinvol zijn: firewalls, load balancers, enz. In de problemen die ik geef, zijn deze meestal een gegeven en niet nodig om te vermelden, maar ze kunnen centraal staan in andere toepassingen.

Let op de zware nadruk op gegevens. Dit komt omdat in de meeste grootschalige systemen, althans in mijn ervaring, de gegevens de kern van het systeem vormen. Alles over het systeem, de verschillende onderdelen en hoe ze met elkaar samenhangen, bestaat om ervoor te zorgen dat de gegevens door het systeem kunnen stromen en kunnen worden verwerkt op een manier die waardevol is voor uw gebruikers.

Gebruik industriestandaard terminologie

De specifieke technologieën en terminologie die uw bedrijf gebruikt, is soms uniek, vaak gedreven door de specifieke behoeften van zijn geschiedenis. Maar aan die uniciteit ligt een gemeenschappelijke reeks patronen ten grondslag die uw bedrijf toepast, en die patronen zijn de taal die u deelt met de interviewer. Verwijs naar die patronen.

Voel je bijvoorbeeld vrij om Kafka of Amazon SQS te noemen als je je daar prettig bij voelt, maar vermeld dat je een berichtenwachtrij wilt die is geconfigureerd als een pub/subsysteem. Deze aanpak heeft veel voordelen:

• Als de interviewer niet dezelfde technologieën kent als u (hoewel ze de groten zouden moeten kennen), heb je een gemeenschappelijke taal.
• U laat zien dat u precies begrijpt welke functionaliteit uw voorgestelde systeem nodig heeft, aangezien dezelfde technologie vaak om meerdere redenen kan worden gebruikt.
• En tot slot laat het zien dat je, ongeacht je achtergrond, voldoende algemene kennis hebt om je ervaring te vertalen naar je nieuwe rol, waar je mogelijk andere technologieën gebruikt.

Het benoemen van een specifieke technologie is geweldig om te laten zien dat je praktijkervaring hebt, maar zorg er toch voor dat je naar de onderliggende patronen verwijst.

Hetzelfde geldt voor bedrijfsspecifieke terminologie. Als jij en de interviewer dezelfde woorden interpreteren als verschillende concepten, krijg je veel miscommunicatie. (Interessant is dat dit allemaal van toepassing kan zijn bij het werken met andere teams bij een groot bedrijf!)

Leg uit welke problemen je oplost met je keuzes

Ik heb dit van oudsher gezien gezien als het presenteren van compromissen, maar ik merkte dat kandidaten vaak te veel tijd besteden aan het uitwerken van alternatieve oplossingen in plaats van zich te committeren aan een specifiek voorstel. Toch zijn compromissen een belangrijk onderdeel van het ontwerpen van grote systemen, dus het is belangrijk dat u uitlegt welke problemen elk van uw keuzes oplost.

Als u bijvoorbeeld hebt besloten om een berichtenwachtrij in uw ontwerp op te nemen, kunt u zeggen dat u bereid bent de verwerkingstijd op te vangen (De verwerking is niet langer on-demand, maar wanneer de wachtrijconsument bij dat stukje gegevens komt) om ervoor te zorgen dat elk stukje gegevens betrouwbaar wordt verwerkt, zonder dat u zich zorgen hoeft te maken over race-omstandigheden tussen de verwerking van gerelateerde gegevens. Of als u een winkel met een sleutelwaarde opneemt, kunt u zeggen dat u leesbewerkingen met een lage latentie voor afzonderlijke items wilt en dat u geen andere query's hoeft uit te voeren op basis van de functionele vereisten die u eerder hebt verzameld.

Als je zoveel zegt en verder gaat, laat je zien dat je je keuzes bewust hebt gemaakt en met een duidelijk begrip van zowel het probleem als de oplossingsruimte, terwijl je vasthoudt aan een uniform verhaal over je voorgestelde systeem.

Wees klaar om diep in uw expertisegebieden te duiken

Het zou acceptabel moeten zijn om geen diepgaande expertise te hebben op alle gebieden van het systeem (hoewel ik weet dat niet alle interviewers zo meegaand zijn), maar als de interviewer het probleem heeft gekozen op basis van uw achtergrond, moeten er gebieden zijn waarin u ervaring heeft. Je wilt er met name voor zorgen dat je intelligent kunt praten over elk onderdeel van het systeem dat aansluit bij je eerdere werk, vooral als dat stuk prominent op je cv staat.

Zei je dat je werkte aan een streamingarchitectuur voor het verwerken van data? Je moet in staat zijn om te praten over berichtenwachtrijen, technologieën zoals Apache Spark of Samza te noemen (of welke technologieën je ook eerder gebruikte), de afwegingen tussen stroomverwerking en online of offline gegevensverwerking, enz. Als je veel met gegevensopslag hebt gewerkt, zou je moeten kunnen praten over sharding, databasekeuzes, schijfgebaseerde persistente versus in-memory caching, enz.

Dit is een ander gebied waar van je kennis wordt verwacht dat ze breder zijn naarmate je meer ervaring hebt. Als je senior genoeg bent, zou je in staat moeten zijn om op zijn minst op hoog niveau over de verschillende gebieden te praten die ik hierboven noemde. Dat zijn vrij standaard concepten in software engineering die in veel grootschalige systemen terugkomen.

Praten over het produceren van het systeem

Tot slot - en dit is het deel waar onervaren mensen over struikelen - praten over het in productie nemen van het systeem. Hopelijk heeft uw interviewer hier duidelijk om gevraagd bij het presenteren van het probleem, maar zo niet, zorg er dan voor dat u duidelijk maakt of dit deel iets is waar u over moet praten.

Dit is waar je het hebt over monitoring en logging, foutafhandeling (Hoewel een deel daarvan misschien eerder naar voren is gekomen), geleidelijke uitrol om problemen aan te pakken zoals opwarmperioden van de cache, sierlijke degradatie in geval van onverwachte verkeerspieken, enz. Concreet zijn monitoring en foutafhandeling twee gebieden ieder systeem gaat over, dus ik zou leiden met die.

In dit deel van het interview laat je zien dat je niet alleen een theoretisch systeem kunt ontwerpen, maar dat je ook de praktijkervaring hebt om te weten welke problemen zo'n systeem in de productie zal tegenkomen. Als ik je een technische leider zou maken, zou ik dan het vertrouwen hebben dat je over deze zorgen zult nadenken voor Wij lanceren? Het is ook een reden waarom u gestroomlijnd moet zijn over het algehele systeemontwerp, zodat u tijd hebt om dit gedeelte aan te pakken.

De laatste tip die ik heb is klein, maar het is de moeite waard om snel te vermelden: wees klaar om je ontwerp te laten zien terwijl je het bouwt. Als je het interview persoonlijk doet, wees dan bereid om blokdiagrammen op het whiteboard te tekenen. Als het interview virtueel is, kies dan een tekengereedschap en oefen ermee. Dat kan zelfs betekenen dat je je eigen whiteboard voor jezelf moet kopen! Zorg er wel voor dat het zichtbaar is vanaf je camera.

Als het correct wordt uitgevoerd, biedt systeemontwerp u, de ervaren ingenieur, de mogelijkheid om te demonstreren (ten minste een subset van) Jouw vaardigheden als technisch leider voor een project. Omdat je echter probeert je ervaring in slechts één uur in te passen, betekent het hebben van een script voor het interview dat je precies de vaardigheden kunt laten zien die vertrouwen wekken in je capaciteiten.

Dit artikel is oorspronkelijk gepubliceerd op de website van Hiring For Tech. Als je meer inhoud van mij wilt lezen, abonneer je dan per e-mail of op LinkedIn. Als je een mening hebt over mijn inhoud, reageer dan hieronder. En vergeet niet om Volg me voor meer inhoud!