What interviewers expect
Interviewers expect you to validate the API contract and then think about real production risks: who can create users, what data is stored, what happens on duplicates or concurrency, and whether sensitive information leaks.
QA interview guide
How would you test a Create User API?
A Create User API is a great interview prompt because it tests whether you understand contracts, validation, permissions, persistence, security, and downstream side effects like audit logs or invitations.
Checklist
What to include in your answer
Functional and contract
- Valid minimal and full payloads return 201 Created.
- Response schema includes generated id, email, role, status, createdAt, and expected flags.
- Created user can be fetched by GET user API.
- Status codes are correct for success and failures.
Request validation
- Missing, empty, malformed, duplicate, invalid email, invalid role, oversized, and Unicode inputs are handled.
- Malformed JSON returns a stable error schema.
- Field-level validation errors are safe and useful.
Authentication and authorization
- Missing, invalid, or expired token is rejected.
- Permission denied and non-admin users cannot create users.
- Role escalation and tenant-boundary violations are blocked.
Security and data persistence
- Password is hashed, not returned, and not logged.
- Mass assignment and injection-like values are handled safely.
- User is persisted in the database with generated id, default status, role, and createdAt.
Backend, consistency, and observability
- Duplicate email uniqueness is enforced in the database.
- Concurrent requests and idempotency behavior prevent duplicate users.
- Invitation email, user.created event, audit log, metrics, diagnostic logs, dependency failures, and SLA are tested.
“201 created and invalid email”
What it misses
This covers a basic success case and one validation case, but misses required fields, duplicates, authorization, role escalation, password handling, persistence, schema, events, and concurrency.
“I would test valid minimal and full payloads, 201 Created, response schema, generated id, default status, role, createdAt, GET user after creation, missing/empty/invalid/duplicate fields, malformed JSON, Unicode and oversized fields, missing/invalid/expired token, permission denied, non-admin users, role escalation, tenant isolation, password hashing, password not returned or logged, mass assignment, injection values, database persistence, unique constraints, transaction rollback, idempotency, concurrent same-email requests, user.created event, invitation email, audit log, safe error responses, correct status codes, metrics, diagnostic logs, dependency failures, and SLA.”
Ready to practice?
Write your own answer, get scored, see what you missed, and compare it with junior, middle, and senior QA thinking.