How to vet an AWS developer
AWS offers hundreds of services, so certifications alone say little about practical skill. Ask candidates to describe an architecture they built and operated: which services they chose, why, how they secured it and what it cost. Strong developers explain trade-offs between Lambda, containers and EC2, between DynamoDB and relational databases, and between managed services and self-managed software.
Security and account structure are essential. Look for experience with IAM roles and least privilege, multiple accounts per environment, encryption, secrets management and logging with CloudTrail. Infrastructure as code with CDK, CloudFormation or Terraform should be standard practice, not an afterthought, and our AWS development page outlines the patterns we follow.
Cost awareness separates mature AWS developers from beginners. Ask how they estimated and monitored costs, which services surprised them on the bill and how they designed for efficiency, such as caching, right-sized instances or serverless for spiky workloads. Cost tags and budgets should exist from the first deployment.
- Hands-on experience designing and running AWS architectures.
- Strong IAM and security practices.
- Infrastructure as code for every resource.
- Clear reasoning about compute and database choices.
- Monitors and controls costs actively.
- Communicates architecture decisions clearly in writing.
Interview questions we use for AWS developers
We ask scenario questions grounded in real AWS work. Candidates design solutions on a whiteboard or in writing, explain the services they would use and describe how they would operate and secure the result over time. We also ask about incidents they handled in AWS environments.
Good answers mention failure modes, such as throttling, cold starts or availability zone outages, and how to handle them. Candidates should also know when not to use AWS services, for example when a simple managed platform or an existing tool would serve the team better.
- Would you build this API with Lambda or containers on Fargate, and why?
- How do you give an application access to S3 without storing keys?
- How would you structure AWS accounts for development, staging and production?
- How do you handle DynamoDB access patterns that change over time?
- How do you design for an availability zone failure?
- Which AWS costs tend to surprise teams, and how do you prevent them?
- How do you roll back a failed infrastructure change?
Onboarding an AWS developer in the first two weeks
Week one starts with secure access through single sign-on and roles, never shared root credentials. The developer reviews the account structure, infrastructure code, network design, monitoring and the latest cost reports, and documents risks such as public resources, missing backups or overly broad permissions. Small fixes during this week build trust and familiarity.
In week two, they deliver a scoped improvement or feature, such as a new service deployed through infrastructure as code with monitoring and alerts. Teams weighing architecture options can read our serverless vs containers comparison and AWS vs Azure comparison for context.
AWS
Terraform
Docker
Kubernetes
Node.js
