QA interview guide

How would you test Create User API?

Create User API is a classic interview prompt because it combines contract testing, validation, authentication, authorization, security, database persistence, and downstream side effects.

Practice this scenarioBrowse all questions

Write your own answer and compare it with senior QA coverage.

What interviewers expect

What interviewers expect

Interviewers expect valid create request coverage, required fields, schema validation, duplicate email, password rules, default role/status, forbidden protected fields, auth and permissions, tenant isolation, error responses, persistence, audit logs, idempotency, rate limiting, and security.

Checklist

Checklist

Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.

Functional and contract checks

  • POST create user with valid minimal payload returns 201 Created.
  • Valid full payload handles optional fields, defaults, generated id, default role, default status, and createdAt.
  • Response schema, content type, field types, required fields, nullable fields, enum values, and safe response body are correct.
  • Created user is persisted and can be fetched by GET user API.
  • Default onboarding, verification, inactive status, or welcome flow follows business rules.

Request validation and duplicates

  • Missing email, missing password, missing required fields, empty values, and whitespace-only values are rejected.
  • Invalid email, weak password, password rules, long values, Unicode values, wrong data types, and malformed JSON are handled.
  • Duplicate email, case-insensitive duplicate, unsupported content type, unknown fields, and extra fields return correct errors.
  • Error response format is consistent, safe, localized if needed, and useful for API clients.
  • Correct 400, 401, 403, 409, 422, and 500 status behavior is verified.

Authentication, authorization, and security

  • Missing token, invalid token, expired token, and insufficient permission are rejected if auth is required.
  • Users cannot set admin role, status, tenant id, owner id, password hash, emailVerified, or protected fields.
  • Mass assignment, role escalation, tenant isolation, request tampering, and permission boundaries are blocked.
  • Password is hashed, not returned, not logged, and not exposed in analytics.
  • Rate limiting, abuse prevention, user enumeration, safe error messages, and audit logging are checked.

Persistence, idempotency, and observability

  • Database transaction, rollback on failure, unique constraints, and data consistency are verified.
  • Concurrent create requests, duplicate submits, idempotency keys, and retry behavior do not create duplicate users.
  • Verification email, welcome email, user-created event, audit log, and downstream event behavior are correct.
  • Database error, dependency failure, queue failure, timeout, and partial failure states are handled.
  • SLA, diagnostic logs, metrics, alerts, correlation ids, and contract tests support production debugging.

Complete interview coverage checklist

Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.

POST create user with valid minimal payload returns 201 Created.
Valid full payload handles optional fields, defaults, generated id, default role, default status, and createdAt.
Response schema, content type, field types, required fields, nullable fields, enum values, and safe response body are correct.
Created user is persisted and can be fetched by GET user API.
Default onboarding, verification, inactive status, or welcome flow follows business rules.
Missing email, missing password, missing required fields, empty values, and whitespace-only values are rejected.
Invalid email, weak password, password rules, long values, Unicode values, wrong data types, and malformed JSON are handled.
Duplicate email, case-insensitive duplicate, unsupported content type, unknown fields, and extra fields return correct errors.
Error response format is consistent, safe, localized if needed, and useful for API clients.
Correct 400, 401, 403, 409, 422, and 500 status behavior is verified.
Missing token, invalid token, expired token, and insufficient permission are rejected if auth is required.
Users cannot set admin role, status, tenant id, owner id, password hash, emailVerified, or protected fields.
Mass assignment, role escalation, tenant isolation, request tampering, and permission boundaries are blocked.
Password is hashed, not returned, not logged, and not exposed in analytics.
Rate limiting, abuse prevention, user enumeration, safe error messages, and audit logging are checked.
Database transaction, rollback on failure, unique constraints, and data consistency are verified.
Concurrent create requests, duplicate submits, idempotency keys, and retry behavior do not create duplicate users.
Verification email, welcome email, user-created event, audit log, and downstream event behavior are correct.
Database error, dependency failure, queue failure, timeout, and partial failure states are handled.
SLA, diagnostic logs, metrics, alerts, correlation ids, and contract tests support production debugging.
Structure your answer: Start with POST create user happy path: valid payload, 201 Created, generated id, schema, default role/status, and persisted user.
Structure your answer: Add validation: required fields, invalid email, password rules, duplicate email, malformed JSON, and status codes.
Structure your answer: Add security: auth, permissions, tenant isolation, protected fields, mass assignment, password hashing, and safe errors.
Structure your answer: Close with database transactions, idempotency, concurrency, rate limiting, audit logs, downstream events, and observability.
Do not miss: Protected fields and mass assignment.
Do not miss: Password hashing and sensitive response data.
Do not miss: Fetch-after-create persistence verification.
Do not miss: Concurrent duplicate requests, idempotency, and rollback.

Ready to practice?

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario

Answer structure

Strong answer structure

  1. Start with POST create user happy path: valid payload, 201 Created, generated id, schema, default role/status, and persisted user.
  2. Add validation: required fields, invalid email, password rules, duplicate email, malformed JSON, and status codes.
  3. Add security: auth, permissions, tenant isolation, protected fields, mass assignment, password hashing, and safe errors.
  4. Close with database transactions, idempotency, concurrency, rate limiting, audit logs, downstream events, and observability.

Common missed areas

Common missed risks

Protected fields and mass assignment.
Password hashing and sensitive response data.
Fetch-after-create persistence verification.
Concurrent duplicate requests, idempotency, and rollback.

Answer template

Use this interview answer template

I would start with a valid create request and 201 response, then cover required fields, schema validation, duplicate email, password rules, default role/status, protected fields, auth, permissions, tenant isolation, error responses, database persistence, audit logs, idempotency, rate limiting, and security.

Use it as a structure, then replace the examples with specific checks for the feature you are discussing.

Common weak answer

“I would test valid and invalid cases.”

This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.

Examples

Weak answer vs stronger answer

Weak answer
“I would test 201 created and invalid email.”

This covers one happy path and one validation case, but misses duplicate users, required fields, auth, protected fields, security, persistence, idempotency, rate limiting, and auditability.

Stronger answer
“I would test POST create user with valid minimal and full payloads, 201 Created, generated id, default role, default status, createdAt, response schema, created user persisted and fetched by GET user API, missing email, missing password, invalid email, weak password, duplicate email, malformed JSON, unsupported content type, missing token, expired token, permission denied, forbidden admin role, protected fields blocked, tenant isolation, mass assignment blocked, password hashed, password not returned, safe error responses, rate limiting, database transaction, rollback, concurrent requests, idempotency key, verification email event, welcome email, audit log, dependency failures, status codes, metrics, alerts, and contract tests.”

FAQ

Frequently asked questions

What should I mention first when answering "How would you test Create User API?"

Start with POST create user happy path: valid payload, 201 Created, generated id, schema, default role/status, and persisted user.

Should I include negative and edge cases?

Missing email, missing password, missing required fields, empty values, and whitespace-only values are rejected. Invalid email, weak password, password rules, long values, Unicode values, wrong data types, and malformed JSON are handled.

Should I include security, API, or backend risks?

Missing token, invalid token, expired token, and insufficient permission are rejected if auth is required. Users cannot set admin role, status, tenant id, owner id, password hash, emailVerified, or protected fields.

What are common missed risks?

Protected fields and mass assignment. Password hashing and sensitive response data. Fetch-after-create persistence verification. Concurrent duplicate requests, idempotency, and rollback.

How can I practice this answer?

Use the interactive how would you test create user api? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.

Practice

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario