A small software engineering intern exercise that tests real work

A good engineering intern exercise resembles a small unit of the job: read a contract, implement a bounded change, test important behavior, and explain an edge case. It does not require a candidate to build an entire product in a weekend. Give everyone the same starting code or language-neutral contract, realistic time budget, allowed resources, submission method, and scoring criteria.

This example is for a backend intern who will work on APIs. It can be adapted to TypeScript, Python, or another stack the team actually uses. If the role is frontend, use a form or component task instead; Badal's role playbooks include frontend and backend starting points.

Candidate brief: one reservation endpoint

Context: A restaurant team records reservation requests. Implement POST /reservations against the supplied starter project. The endpoint accepts customer_name, party_size, and requested_at. Store a valid request in the supplied in-memory repository and return an ID, the stored values, and a pending status.
Rules: Trim surrounding spaces from customer_name; reject an empty name, a party size outside 1–12, or a missing or invalid date-time. Return a clear client error for invalid input. Do not return another customer's reservation in this endpoint.
Submit: Your code, two or more meaningful tests, and up to 200 words explaining one decision or tradeoff.
Time budget: 45 minutes.
Tools: Documentation and AI assistance are allowed. Review generated code, disclose what you used, and be ready to explain your own implementation.
Scope: No database migration, authentication system, deployment, frontend, or production integration is expected.

The brief describes the behavior to be tested and explicitly rules out extra work. If the team needs authorization checks in the actual job, provide a user identity and a read endpoint in a different exercise. Do not secretly score a candidate on a feature the brief excludes. For production APIs, OWASP's API Security Top 10 is a useful source when designing later-stage security tasks; it emphasizes object-level authorization for endpoints that retrieve records by ID.

Example test cases

Provide one acceptance example, then let candidates design their own tests. The interviewer can keep a fuller private test list:

The exact HTTP status codes should be specified in the starter contract if your team cares about them. Do not grade candidates against an unstated status-code preference. A short exercise tests what it says it tests.

Score the submission

Use an anchored 0–5 scale for each criterion:

Review the code as a work sample. A candidate who catches an edge case but uses plain code may be a better fit than one who brings in a large framework without meeting the contract. Missing tests are evidence about this assignment, not proof of every aspect of future job performance.

Worked review: two plausible submissions

Submission A handles the happy path, trims the name, and returns an ID, but accepts party size zero and includes only a manual test note. The reviewer can credit basic implementation, note the validation and test gaps, and ask how they would correct them. Submission B rejects all stated invalid cases and includes tests but returns a generic error message. It is stronger on contract coverage, with a smaller clarity gap. A useful report names those specific observations rather than declaring A “bad” and B “excellent.”

In a follow-up interview, ask each candidate the same core questions: “Which failure case did you choose to test first, and why?” and “What would change if requests could arrive concurrently?” The second is a discussion question, not a retroactive hidden requirement. See the structured interview guide for shared score anchors.

Make the exercise fair to applicants

Supply a working starter project or a language-neutral contract. State whether candidates may use their preferred language. If a specific stack is essential to the first month, say so in the job description. Give a documented submission path and an accommodation contact. Avoid requiring an applicant to create accounts on multiple services or share private GitHub repositories with unknown reviewers. Review whether 45 minutes is enough by having a team member complete the task from the same starter project.

The EEOC's US guidance on selection procedures treats job-task simulations and work samples as selection methods; use one that measures relevant work and review your own jurisdiction's obligations. This is a design principle, not legal advice.

Put the exercise into Badal

Badal can send an assessment link to candidates who advance from Stage 1. In a campaign, define a role-specific assessment_spec with the title, candidate context, instructions, and response questions. For this exercise, ask for a repository or code link, test instructions, and the short explanation. The recruiter should verify that the candidate-facing message names the organization and role accurately. Scoring results are decision support; a recruiter makes the final keep/reject decision. Read Badal's current agent instructions for the exact workflow and limits.

Agent recipe

Ask the recruiter what language and framework the intern will actually use, whether a starter project exists, the first-month API tasks, permitted tools, and a realistic time budget. Propose one bounded contract and a 0–5 rubric. Ask for approval before adding it to a campaign. Use a private Badal MCP or API credential only for recruiter actions; never put it in starter code or candidate instructions. On review, quote tested behavior and visible gaps, and ask before finalizing a candidate decision.

Frequently asked questions

Should we use an algorithm puzzle instead?

Use it when algorithmic reasoning is genuinely central to the job. For an intern who will maintain API endpoints, a small API task may produce more directly relevant evidence.

Can candidates use AI coding tools?

You decide the policy, but publish it before the exercise. If allowed, ask candidates to explain and test the final code. If prohibited, define what counts as assistance and apply the rule consistently.

How many tests are enough?

For this short brief, one successful case and one meaningful invalid case meet the minimum. A stronger submission may test several boundaries. Do not use a hidden suite to enforce behavior that was absent from the instructions.

Next: Pair the assignment with an evidence-based first screen and a consistent interview.