Submission Standards

We don't grade you on code syntax. We grade you on Engineering Maturity. Here is the difference between a Junior "Task" and a Senior "Solution".

The Seniority Checklist

Junior Submission

  • • Draws generic boxes named "Database" or "Server".
  • • Assumes the "Happy Path" (everything works).
  • • Ignores cost ("Just use the biggest instance").
  • • Focuses only on features requested.

Senior Submission

  • • Specifies technology (e.g., "Postgres 15 on RDS db.t3.medium").
  • • Designs for failure (Retries, Dead Letter Queues).
  • • Estimates monthly bill (FinOps).
  • • Challenges requirements that don't scale.

1. Architecture Diagram Standards

A diagram should be self-explanatory. If you walked out of the room, would the team know what to build?

Scope Boundaries

Draw the VPC, Public Subnets (Load Balancers), and Private Subnets (Databases).

Data Flow

Use directional arrows. Solid line for synchronous (HTTP), dotted for async (Queue/Event).

Managed Services

Don't reinvent the wheel. Use S3 for files, standard Auth providers (Cognito/Auth0).

2. The HLD (High Level Design)

Your text explanation complements the diagram. It must cover the "Why".

Data Strategy

Relational vs NoSQL? Read-heavy or Write-heavy? Explain your Sharding or Replication strategy if dealing with high scale.

Cost Analysis (The "Bill Shock")

Provide a rough napkin math.
1M reqs * 500ms * 128MB Lambda ≈ $X.XX

API Design (Contracts)

Don't just say "REST API". Define critical endpoints:
POST /orders (Idempotent)

Scalability & Limits

Address the bottlenecks. Where does the system break?

  • "The database connection limit is X."
  • "We reach the Lambda concurrency limit at Y."

Security Considerations

How are you protecting data? Authentication, Authorization, Encryption (at rest/in transit).