AWS-sollicitatievragen

Je hebt de dienstenlijst gelezen en weet nog steeds niet hoe het gesprek zal verlopen. Die kloof is normaal, en deze sectie dicht hem: AWS-rondes zijn erop gebouwd om te achterhalen of je iets hebt beheerd, niet of je het kunt benoemen.

Het patroon komt naar voren in de vervolgvraag. Een interviewer vraagt welke dienst je zou gebruiken, je antwoordt correct, en de volgende vraag is waarom niet de andere. Iemand die de workload heeft gedraaid, antwoordt vanuit een factuur, een storing of een migratie. Iemand die alleen de documentatie heeft gelezen, hapert. Die tweede vraag, niet de eerste, is waar AWS-sollicitatiegesprekken worden beslist.

Drie soorten rondes komen steeds terug: een basisronde over netwerken, identiteit, opslag en compute; een scenario- of ontwerpronde waarin je iets ontwerpt binnen beperkingen; en een probleemoplossingsronde waarin je een symptoom krijgt en gevraagd wordt wat je zou controleren. De verwachte diepgang stijgt met senioriteit, maar de vorm blijft hetzelfde. Andere rol- en onderwerpbanken staan op de hub met sollicitatievragen.

Dit zijn de basisvragen die telkens terugkeren in AWS-sollicitatiegesprekken, gegroepeerd zoals rondes doorgaans zijn ingedeeld.

Netwerken en VPC

• Wat is een VPC, en hoe verschillen publieke en private subnets?
• Wanneer heb je een NAT-gateway nodig, en wat kost je dat?
• Hoe verschillen security groups van network ACL's?
• Hoe zou je twee VPC's verbinden, en wanneer is peering de verkeerde keuze?

Identiteit en beveiliging

• Leg IAM-rollen, policies en users uit, en wanneer je elk zou gebruiken.
• Hoe krijgt een EC2-instance credentials zonder een key op te slaan?
• Hoe ziet het principe van least privilege eruit in een echte policy?
• Hoe roteer en controleer je secrets in AWS?

Opslag en databases

• Vergelijk S3-opslagklassen en leg uit wanneer je elke zou gebruiken.
• Wat is het verschil tussen EBS en instance store?
• Wanneer kies je DynamoDB boven RDS, en wat lever je in?
• Hoe verschillen read replicas van een multi-AZ-implementatie?

Compute en beschikbaarheid

• Leg auto scaling groups uit en de metrics waarop je zou schalen.
• Wanneer is Lambda het verkeerde antwoord?
• Wat is het verschil tussen een availability zone en een regio?
• Hoe zou je ontwerpen voor het verlies van een hele availability zone?

Scenariovragen zijn degene die kandidaten scheiden, omdat er geen uit het hoofd te leren antwoord bestaat. Typische vragen:

• Onze maandelijkse rekening is verdubbeld en het verkeer niet. Hoe achterhaal je waarom?
• Ontwerp een uploadpijplijn voor bestanden die te groot zijn voor één verzoek.
• Een dienst is alleen traag in één availability zone. Wat controleer je eerst?
• Verplaats een on-premise database naar AWS met minimale downtime. Loop het met me door.
• Hoe zou je deze architectuur een regionale storing laten overleven, en wat zou dat kosten?

Antwoord elke keer in dezelfde volgorde: herhaal de beperking waarvan je denkt dat die telt, spreek je aanname hardop uit, kies een dienst, en noem dan de afweging die je hebt geaccepteerd. De zin over de afweging is waar interviewers naar luisteren, want die bewijst dat je weet wat de keuze kostte.

Een backend engineer die solliciteert voor een platformrol bij een middelgroot bedrijf wordt gevraagd een uploadpijplijn te ontwerpen. In plaats van meteen S3 te noemen, vraagt ze of uploads user-facing zijn en hoe groot de bestanden worden, en kiest dan voor presigned URL's met een multipart upload, waarbij ze uitlegt dat ze routering via de applicatieservers heeft afgewezen omdat dat throughput tot een schaalprobleem zou hebben gemaakt. De keuze van de dienst was gewoon; de redenering is wat werd onthouden.

Een lijst met vragen lezen is geen oefening. Het faalpatroon bij AWS-sollicitatiegesprekken is het antwoord kennen en het als een ongestructureerde monoloog afleveren, en dat komt pas naar boven als je gaat spreken.

Werk de lijsten hierboven hardop door, één vraag tegelijk, en houd jezelf aan de volgorde van vier onderdelen: beperking, aanname, keuze, afweging. Neem er een paar op en luister terug naar het moment waarop je antwoord zijn vorm verliest. Dezelfde set draaien als een mock interview voegt de vervolgvraag toe, het deel dat je niet alleen kunt oefenen en het deel waar AWS-interviewers het zwaarst op leunen.

Eén beperking is het waard om duidelijk te noemen: sommige AWS-screenings zijn geautomatiseerde, opgenomen of bewaakte assessments in plaats van live gesprekken. Die vallen buiten het bereik van elke live assistent, SubcueAI inbegrepen. Voorbereiding is daar het enige dat helpt, en de hub met interviewtypes legt uit welke formats zich hoe gedragen.