How API Design Shows Up in Interviews

The failure specific to this format

The common mistake is treating the final question as a vocabulary test: "We would have create, read, update, and delete endpoints." That says nothing about the product. Most user jobs do not map to CRUD; a caller publishes, reserves, cancels, approves, or acknowledges. The operation model should express the job, not the database verbs.

4. Format Three: The API Critique Round

The contract already exists. Your job is to evaluate it, explain the consequences of its problems, and propose improvements. That is harder than designing a clean API from nothing, because this one already has callers.

You may receive a specification, documentation page, or code sample:

POST /api/doUserThing
Content-Type: application/json

{
  "action": "get",
  "userId": 42
}

{
  "success": false,
  "message": "User not found"
}

The failure is returned with status 200 OK. The operation is vague, the action field may choose between several unrelated behaviors, and the message is not stable enough for code to depend on. A strong critique still does not begin by rewriting everything.

Your opening

Before proposing changes, ask who calls this API today and whether you are allowed to make a breaking change. Then clarify the intended job: is the caller retrieving one user, searching for users, or performing several actions through one operation?

Those two questions prevent a common failure: proposing a better replacement that the company cannot deploy. If breaking changes are not allowed, you might add an operation, introduce a version, or improve the response additively. The same flaw can need a different repair, depending on what compatibility allows.

Critique in the right order

Review from highest impact to lowest:

1. Caller and job: is the intended task possible without unnecessary work?
2. Semantics: is it clear what the operation does and guarantees?
3. Failures: can programs distinguish validation, authorization, absence, conflict, throttling, and server failure?
4. Consistency: do names, shapes, pagination, and errors follow predictable patterns?
5. Evolution: can fields and behavior change without breaking callers?
6. Surface polish: are names and documentation clear?

This order keeps the critique connected to consequences. "I dislike this name" is an opinion. "This operation performs five unrelated actions, so permissions, retries, and errors change according to a string field" is a design argument.

Alongside the problems, give a revised design for the most important ones and a migration approach for current callers.

The failure specific to this format

Weak candidates search for violations of memorized rules: every noun plural, every update a PUT, no actions in URLs. Rules help consistency, but they are not the scorecard. Returning 200 OK for every outcome breaks retry logic and monitoring; singular against plural paths rarely matters. Treating both as equal shows you are checking style rather than caller impact.

5. Format Four: Interface Design Inside a Coding Round

API design does not always involve HTTP. The API may be a class, library, or typed interface used by another programmer, and you are asked to define it and then implement one part. You might hear "Design an interface for an in-memory cache, then implement put."

The interface is still a published contract: callers depend on method names, types, errors, and edge-case behavior. Do not spend the whole session designing. Leave time to write and explain working code.

interface Cache<K, V> {
    Optional<V> get(K key)
    void put(K key, V value, Duration ttl)
    boolean delete(K key)
}

The signatures look simple, but the contract is still open. Does put replace an existing value, and does replacement reset the expiration? What does a non-positive ttl mean? Does get remove an expired entry or only behave as if it is absent? Is the cache safe for concurrent callers?

Your opening

State the observable behavior before choosing the data structure:

"Before I implement put, I want to define replacement and expiration semantics because callers and tests will depend on them."

Then make a small set of explicit assumptions:

"I'll allow replacement, replacement will reset the TTL, a non-positive TTL will be rejected, and the first version will not promise thread safety unless that is required."

The interface leads; the data structure follows.

The failure specific to this format

Weak candidates immediately build a hash map, tree, or queue, then discover halfway through that they do not know what a duplicate, timeout, or missing value should do. This is the coding-round version of exposing the database schema as an HTTP API: the implementation is allowed to choose the contract. Strong candidates reverse that direction.

6. Which Companies Use Which Formats?

There is no universal rule, but the product and team predict the format better than the interview title.