Why a Weak API's Answer Doesn't Always Mean Rejection

Rejection Path:
Interviewer: "How would you design a rate
limiter for an API?"

You: "Uh... I'm not sure. I've never done
that before."

You go quiet. You don't try. You don't ask.
You don't reason.

What the interviewer thinks:
"Not ready for this level. Next."

What it signals:
- You give up when stuck
- You don't think out loud
- You don't collaborate

It gets 10 seconds of silence.

Recovery Path:
Interviewer: "How would you design a rate
limiter for an API?"

You: "I haven't built one at production scale,
but let me think out loud. At its core, a rate
limiter tracks requests per client per window.
The simplest version is a counter in Redis with
a TTL — INCR the key, expire it after the window.
That's a fixed-window approach.

If we needed smoother bursts, we could use a
sliding window or a token bucket. But fixed
window is a good first step.

Can I ask — is the limiter per-user, per-IP,
or per-endpoint? That would change the key
design."

What the interviewer thinks:
"Good reasoning. Asks useful questions. Can
build from first principles. I'd hire this
person."

What it signals:
- You think out loud under pressure
- You connect concepts to real systems
- You ask clarifying questions

It gets 10 minutes of conversation.

Think Out Loud Example:
Interviewer: "How would you handle idempotency
for a payment API?"

You: "Let me walk through how I'd approach
this. The goal is: if the client retries, we
shouldn't charge twice.

The simplest version is an idempotency key —
the client sends a unique key with the request,
and the server stores the result under that key.
If the same key arrives again, the server
returns the stored result instead of processing
again.

The interesting parts are: how long do we keep
the key? What if two requests with the same key
arrive at the same moment? That needs a lock
or a transaction."

Why it works:
- The interviewer can follow your reasoning
- You cover edge cases without being asked
- You show you understand the *why*

Anchor to What You Know Example:
Interviewer: "How would you design a
notification service that doesn't drop
messages?"

You: "I haven't built a notification service
at this scale, but I've worked with a similar
pattern in a job queue.

The core problem is the same: make sure a
message is delivered at least once, even if
a worker crashes mid-process. The usual answer
is a queue with ack/nack semantics — the
message stays in-flight until the worker
confirms it.

Then the question becomes: what happens on
retries? You need idempotency on the consumer
side, so duplicate deliveries don't double-send.

I'd start there. Does that match what you're
looking for?"

Why it works:
- You connect the unknown to something you know
- You show transferable thinking
- You keep the conversation moving

Weak Response:
Interviewer: "How would you design a
paginated API with cursor-based pagination?"

You: "I don't know what cursor-based
pagination is."

Interviewer: "Okay, have you done any
pagination before?"

You: "Just offset-based."

Interviewer: "And how did that go?"

You: "It was fine, I guess."

The conversation stalls here.

Strong Response:
Interviewer: "How would you design a
paginated API with cursor-based pagination?"

You: "I haven't implemented cursor-based
pagination, but I've done offset-based.

The problem I know is: with offset-based,
if rows are inserted or deleted between pages,
you can skip or duplicate results. That's the
mismatch cursor pagination solves.

My mental model is: the cursor is an opaque
pointer — often an encoded ID or timestamp —
that says 'give me everything after this'.
The server returns a page and a next cursor.
The client sends the cursor back.

I'd want to ask: does the data change often?
If not, offset is fine. If yes, cursor is
better.

Does that match your thinking?"

The conversation continues.