What to Expect in the Postman System Design Interview

Postman tests design in two separate rounds, and candidates report both. The first is a machine coding round, where you build a small working program while the interviewer watches, and the second is a system design round of about 45 minutes, which is a discussion rather than a build.

Reported design questions include a URL shortener and a calendar style scheduling system, with follow up questions on asynchronous flows and API design. Prepare the build round first, because it is the round most candidates have never seen before.

The Machine Coding Round

A machine coding round grades working code rather than a diagram, and at companies that run it the session usually lasts 90 to 120 minutes. Postman reports do not agree on the length, and one candidate describes a 45 minute coding round conducted over screen share.

Candidates report these problems at Postman:

• A URL shortener. One candidate wrote it in Node.js, tested the endpoints, then discussed collision handling and HTTP status codes.
• A rate limiter. A rate limiter caps how many requests a caller may make in a period, and one candidate reports discussing a sliding window approach for most of the round while running short of time to finish the code.
• A file directory manager in React. A front end task with nested folders.
• A clone of a small key value store. The discussion afterward covered single responsibility, concurrency, race conditions, and expiry of stored keys.

The grading is consistent across these problems: your program must run, your classes must have clear responsibilities, and a new requirement must be addable without a rewrite. Finish a working smaller version rather than an unfinished larger one. The difference between this round and the discussion round is explained in machine coding versus system design and LLD.

The Design Question Types

Link shortening and key generation. The URL shortener appears in both rounds in different reports, and in the design round the discussion covers scale, storage, and cache behavior.

Scheduling and asynchronous work. One candidate reports a calendar style system, with the interviewer asking detailed questions about asynchronous flows, where asynchronous means the caller does not wait for the work to finish. Scheduled jobs are real Postman work, because the platform runs monitors that execute test collections on a schedule.

API design itself. This is the company's own subject, so expect questions on resource naming, versioning, idempotency, pagination, and error codes, where idempotent means repeating the same request does not change the result twice.

Multi tenant collaboration. Workspaces hold many teams' collections at once, so questions about isolating one customer's data from another are fair preparation, although reports do not name them as asked questions.

What the Interviewer Grades

State the requirements before any component, and name the read and write pattern early, because it decides the storage choice, and then say your trade offs out loud rather than presenting one answer as obvious. Candidates report that follow up questions continue until you reach the limit of what you know, so defend each choice with a reason, and when you do not know something, say so plainly.

A Walkthrough: Design a URL Shortener

This is the most reported question, so rehearse it until the structure is automatic.

1. Requirements, about 5 minutes. Create a short link for a long URL, and redirect a short link back to the original, while reads far outnumber writes, links may expire, and some customers want custom aliases.

2. The API. Two endpoints: one to create a link, one to resolve it, and the create endpoint should be idempotent for the same URL and owner, so a retry does not produce a second link.

3. Key generation. Either encode an incrementing counter into a short string, or hash the URL and take a prefix. The counter avoids collisions by design, while the hash needs a check for an existing key and a retry on conflict, so state which you chose and why.

4. Storage. A key value store fits, since every read is a lookup by short key, and the record keeps the mapping, the owner, the creation time, and the expiry.

5. Reads. Put a cache in front of the store, because a small number of links take most of the traffic. Use a 301 or 302 redirect, and explain the difference: a permanent redirect is cached by browsers, which reduces load but also means you record fewer clicks.

6. Scale and failure. Shard by the short key, write click events to a queue instead of updating a counter on the read path, and then say what the system does when the cache is unavailable.

Common Mistakes in This Round

• Designing before asking. Two minutes of requirements questions changes the whole answer.
• Skipping the API contract. This company sells API tooling, so a vague contract is a serious mistake.
• Treating the build round as a design round. Diagrams do not score in machine coding, because this round grades running code.
• Ignoring expiry and cleanup. Most candidates store links and never remove them.
• No failure story. Say what breaks first under load, and what happens next.

How to Prepare

• Rehearse the build round under a timer. Practice the common low level design problems described in what is a low level design interview, writing code that runs.
• Learn the building blocks. Grokking the System Design Interview covers caching, sharding, and queues, which the shortener question uses directly.
• Practice class design. Grokking the Object Oriented Design Interview teaches the structure the machine coding round grades.
• Learn where these rounds come in the loop. The design rounds are stages three and four in the Postman interview process, and your motivation answer is prepared separately in how to answer why Postman.
• Plan for the gap afterward. Results from these rounds take days rather than hours, as described in how long it takes to hear back.