DevOps Engineer Test: Voorbeeldvragen en Beoordelingssjabloon
Waarom generieke infrastructuurvragen falen
De meeste DevOps-beoordelingen stellen leerboekennvragen: "Wat is een container?" of "Definieer CI/CD." Deze vragen meten triviale feitenherinnering, niet of iemand een robuust systeem onder druk kan ontwerpen of een productieincident om 2 uur 's nachts kan debuggen.
Een echte DevOps-test moet oordeel meten, niet feiten. Het moet testen of iemand snapt wat trade-offs tussen automatisering en operabiliteit zijn, weet wanneer horizontaal versus verticaal schalen, en kan redeneren over faalwijzen.
Hier is hoe een signaal-dragend DevOps-beoordelingsproces eruit ziet.
Categorie 1: Infrastructuurontwerp onder beperkingen
Scenario-gebaseerde vraag:
"Je hebt een applicatie op een enkele EC2-instance. Het verwerkt 1000 RPS, gebruikt 70% CPU, en heeft 4GB RAM met 60% bezetting. Je SLA is 99,9% uptime. De applicatie is stateless. Welke wijzigingen zou je aanbrengen, en in welke volgorde? Welke trade-offs maak je?"
Dit test:
- Begrip van schaalbaarheid vs. redundantie (beide nodig voor 99,9%)
- Kostenbewustzijn (of ze naar dure oplossingen springen)
- Sequenceringskennis (failover vóór optimalisatie)
- Trade-off articulatie (EBS gp3 vs. lokale NVMe, bijvoorbeeld)
Een kandidaat die zegt "voeg een load balancer toe en start twee meer instances in een ander AZ" denkt duidelijk. Een kandidaat die zegt "schakel naar Kubernetes" zou patroonmatchingdoen zonder de beperking te begrijpen (hoge beschikbaarheid, niet multi-tenancy).
Categorie 2: Incident response en troubleshooting
Scenario-gebaseerde vraag:
"Je CI/CD-pipeline mislukt willekeurig op builds. De fout is 'verbindingstimeout naar Docker-register.' Het probleem treedt op ruwweg één keer per 20 builds. Wat controleer je eerst, en welke instrumentatie zou je toevoegen?"
Dit test:
- Systematische debuggingmethodologie
- Begrip van netwerkisolatie en authenticatie
- Observabiliteitdenken (wat zou je instrumenteren om dit volgende keer te voorkomen?)
- Prioritering (ze hebben nu stabiliteit nodig, niet perfecte root cause-analyse)
Een kandidaat die zegt "controleer de Docker-register-statuspagina" is minder doordacht dan iemand die zegt "eerst: is het opnieuw probeerbaar en hebben we rate limiting toegevoegd? Tweede: controleer of het registry-token halverwege de build vervalt of of onze netwerkconfiguratie is gewijzigd."
Categorie 3: Code- en configuratiereview
Live oefening:
Geef een 30-regel Terraform-fragment of een Docker Compose-config met opzettelijke problemen. Vraag de kandidaat om problemen te identificeren en de fix uit te leggen.
Voorbeelden van Terraform-problemen:
- Beveiligingsgroep die 0.0.0.0/0 naar een databasepoort toestaat
- Ontbrekend backup-retentiebeleid op RDS
- Hardcoded databasewachtwoord in variabelen
- Geen labels voor kostenverdeelstuk
Voorbeelden van Compose-problemen:
- Geprivilegieerde containers zonder rechtvaardiging
- Ontbrekende health checks
- Logging naar stdout zonder limieten (diskfyllingsrisico)
- Geen resourcebeperkingen (CPU/geheugen)
Dit test of ze productiesystemen hebben uitgerold en geleerd wat breekt. Leerboekingeniëurs vangen deze niet; ervaren operatoren wel.
Categorie 4: Architectuur- en toolselectie
Gesprek:
"We moeten taken coördineren over 50 microservices. Elke taak duurt 2–30 minuten. We willen sterke ordeningsgaranties. Wat zou je gebruiken? Loop me door de trade-offs."
Geldige antwoorden:
- Temporal (workflow-orchestratie, sterke ordening, complex om te bedienen)
- Step Functions (beheerd, beperkt tot AWS, minder flexibel)
- Pub/Sub + consumentapp (lage koppeling, zwakke ordening, operationeel eenvoudiger)
- Kubernetes Jobs + custom controller (flexibel, meer operationele overhead)
De interviewer zou moeten terugvechten: "Step Functions klinkt eenvoudiger." De kandidaat zou moeten verdedigen: "Tot je een taak moet herhalen die al gedeeltelijk is geslaagd, of tot je een 2-minuut-taak hebt op een 10-minuut-SLA, dan heb je de toestandsmachine nodig. Maar dat is de echte kosten — de complexiteitsafweging."
Dit test oordeel en ervaring, niet kennis.
Categorie 5: Observabiliteit en monitoring
Kort scenario:
"Je hebt een wijziging uitgerold en je foutpercentage ging van 0,1% naar 0,5%. Latentie p99 is hetzelfde. De wijziging raakte logging en tracing, niet requestafhandeling. Waar kijk je?"
Zwak antwoord: "Controleer de logs." Sterk antwoord: "Eerst zou ik controleren of de tracing-instrumentatie of logging-level is gewijzigd — dat zou fout zichtbaarheid kunnen verhogen zonder werkelijke fouten te verhogen. Dan zou ik naar log-cardinaliteit kijken. Dan zou ik controleren of we nieuwe foutgevallen loggen die eerder niet werden gevangen."
Dit scheidt operatoren van ingenieurs die alleen de Kubernetes-documentatie hebben gelezen.
Hoe het beoordelingsproces op te structureren
- 30-minuten take-home: Infrastructuurontwerp scenario + configuratiereview. Vraag ze hun beslissingen uit te leggen.
- 30-minuten synchrone interview: Live troubleshooting gesprek + architectuurdiscussie. Registreer hun redenering.
- Koppel het beoordelingsproces aan keystroke-integriteitsignalen. DevOps-kandidaten die hele oplossingen van ChatGPT of StackOverflow kopiëren, zullen ongebruikelijke bewerkingspatronen tonen. ClarityHire legt dit standaard vast.
Het eerlijke tegenargument
Niet elke rol heeft deze diepgang nodig. Junior DevOps- of SRE-rollen profiteren van eenvoudiger filtering: kunnen ze Terraform lezen, kunnen ze een app uitrollen, kunnen ze een netwerkdiagram begrijpen? Voor senior+-werving geldt deze matrix. Voor mid-level rolt u de complexiteit omlaag maar behoudt u de scenario-gebaseerde structuur.
Volgende stappen
Klaar om je DevOps-kandidaten met echte tests te beoordelen? Bekijk onze DevOps- en Cloud Engineering-beoordelingshub voor sjablonen en richtlijnen over hoe je DevOps-engineers' vaardigheden beoordeelt.