AWS-intervjufrågor

Du har läst tjänstelistan men kan ändå inte säga hur intervjun kommer att kännas. Det glappet är normalt, och det här avsnittet tätar det: AWS-omgångar är byggda för att ta reda på om du har drivit något, inte om du kan namnge det.

Mönstret syns i följdfrågan. En intervjuare frågar vilken tjänst du skulle använda, du svarar rätt, och nästa fråga är varför inte den andra. Den som har kört arbetslasten svarar utifrån en faktura, ett driftstopp eller en migrering. Den som bara har läst dokumentationen kör fast. Det är den andra frågan, inte den första, som avgör AWS-intervjuer.

Tre typer av omgångar återkommer: en grundläggande omgång om nätverk, identitet, lagring och beräkning; en scenario- eller designomgång där du arkitekterar något under givna begränsningar; och en felsökningsomgång där du får ett symptom och ombeds säga vad du skulle kontrollera. Djupet i förväntningarna ökar med seniortitet, men formen håller. Andra roll- och ämnesbanker finns i hubben för intervjufrågor.

Det här är grundfrågorna som återkommer i AWS-intervjuer, grupperade på det sätt omgångarna brukar organiseras.

Nätverk och VPC

• Vad är en VPC, och hur skiljer sig publika och privata subnät åt?
• När behöver du en NAT-gateway, och vad kostar det dig?
• Hur skiljer sig security groups från network ACL:er?
• Hur skulle du koppla ihop två VPC:er, och när är peering fel val?

Identitet och säkerhet

• Förklara IAM-roller, policyer och användare, och när du skulle använda var och en.
• Hur får en EC2-instans autentiseringsuppgifter utan att lagra en nyckel?
• Hur ser principen om minsta möjliga behörighet ut i en verklig policy?
• Hur roterar och granskar du hemligheter i AWS?

Lagring och databaser

• Jämför S3-lagringsklasser och förklara när du skulle använda var och en.
• Vad är skillnaden mellan EBS och instance store?
• När väljer du DynamoDB framför RDS, och vad ger du upp?
• Hur skiljer sig read replicas från en multi-AZ-driftsättning?

Beräkning och tillgänglighet

• Förklara auto scaling-grupper och vilka mätvärden du skulle skala på.
• När är Lambda fel svar?
• Vad är skillnaden mellan en availability zone och en region?
• Hur skulle du designa för att en hel availability zone går förlorad?

Scenariofrågor är de som skiljer kandidater åt, eftersom det inte finns något utantillärt svar. Typiska frågor:

• Vår månadsfaktura fördubblades men trafiken gjorde inte det. Hur tar du reda på varför?
• Designa en uppladdningspipeline för filer som är för stora för en enda förfrågan.
• En tjänst är långsam bara i en availability zone. Vad kontrollerar du först?
• Flytta en lokal (on-premise) databas till AWS med minimal driftstopp. Beskriv hur du skulle göra.
• Hur skulle du få den här arkitekturen att överleva ett regionalt avbrott, och vad skulle det kosta?

Svara i samma ordning varje gång: upprepa den begränsning du tror är viktigast, säg ditt antagande högt, välj en tjänst och namnge sedan den avvägning du accepterade. Avvägningsmeningen är det intervjuare lyssnar efter, eftersom den bevisar att du vet vad valet kostade.

En backend-utvecklare som intervjuas för en plattformsroll på ett medelstort företag ombeds designa en uppladdningspipeline. I stället för att direkt namnge S3 frågar hon om uppladdningarna är användarvända och hur stora filerna blir, väljer sedan presigned URLs med multipart-uppladdning och förklarar att hon valde bort att routa via applikationsservrarna eftersom det skulle ha gjort genomströmning till ett skalningsproblem. Tjänstevalet var ordinärt; resonemanget var det som gjorde intryck.

Att läsa en frågelista är inte träning. Felmönstret i AWS-intervjuer är att kunna svaret men leverera det som en ostrukturerad monolog, och det syns bara när du pratar.

Gå igenom listorna ovan högt, en fråga i taget, och håll dig till ordningen i fyra delar: begränsning, antagande, val, avvägning. Spela in några och lyssna efter det ögonblick där ditt svar tappar sin form. Att köra samma uppsättning som en mockintervju lägger till följdfrågan, som är den del du inte kan öva ensam och den del AWS-intervjuare lutar sig hårdast mot.

En begränsning värd att säga rakt ut: vissa AWS-screeningar är automatiserade, inspelade eller övervakade bedömningar snarare än levande samtal. De ligger utanför räckvidden för alla former av live-assistent, SubcueAI inräknat. Förberedelse är det enda som hjälper där, och hubben för intervjutyper förklarar vilka format som beter sig på vilket sätt.