Postman Backend SDE: 2021 Five-Round Rejection

The full Postman SDE Backend off-campus story (June 2021)

The candidate applied off-campus via LinkedIn and interviewed with Postman in June 2021 for a Software Engineer (Backend) role. After an initial HR telephonic screen, the process unfolded across 5 rounds spaced over approximately one month. The account was published on GeeksforGeeks and represents a single candidate's experience, which means it should be read as one data point, not a universal template.

The outcome is as useful as the round structure. The contributor wrote that the candidate progressed through the full loop but received a rejection. The source does not explain why. It would therefore be speculation to blame a particular answer, interview, hiring constraint, or fit assessment. The defensible lesson is narrower: reaching a final conversation does not itself establish that an offer will follow.

The candidate did not report any CTC figure, and the account does not mention specific eligibility criteria such as CGPA cutoffs or graduation year requirements. For 2026 hiring, these details would need to be verified on Postman's official careers page, since off-campus requirements can differ from campus placement criteria.

The account starts with an HR telephone call and then describes the five-round loop. It does not provide a complete transcript of the screening call, so candidates should not treat a generic list of HR topics as reported Postman questions.

Round-by-round breakdown

Here is the candidate-reported structure of each round, as published on GeeksforGeeks:

Round 1: Project deep-dive and JavaScript fundamentals

This round centred on the candidate's past projects. The interviewer asked about the approach taken, challenges faced, and decisions made. The account also reports JavaScript questions involving the event loop and asynchronous behaviour. That is evidence about this interview, not proof that every Postman backend interview uses the same language or topic mix.

Round 2: 45-minute REST API coding round

The candidate was asked to implement a REST API for a nested-comments feature on a social network. A useful way to prepare for that prompt is to define the comment and parent relationships, choose response shapes, decide how deletion affects descendants, handle invalid parent identifiers, and explain pagination. Those are preparation angles, not extra questions attributed to the interviewer.

Round 3: System design, URL shortener

The system-design round asked the candidate to design a URL shortener and discuss scaling and improvements. A complete practice answer should first clarify the expected behaviour, then cover identifier generation, collision handling, storage, redirects, expiry, abuse controls, observability, and failure modes. The source confirms the prompt and follow-up theme, but not a fixed evaluation rubric.

Round 4: Problem-solving without code

This round was unusual compared to standard SDE loops. The interviewer presented two problems but did not ask for working code. Instead, the candidate was expected to explain their approach and perform a manual dry run of the solution. This tests problem decomposition, logical reasoning, and the ability to communicate algorithmic thinking without relying on an IDE.

Round 5: Hiring manager conversation

The final round was a hiring-manager discussion covering the candidate's background, past internships, and working style. The account does not publish the interviewer's rubric or the reason for the eventual rejection. Prepare concise examples from real work, but do not infer that any one answer caused this result.

How to prepare from the skills this account exposed

Use the account as a map of skills, not as a promise of current rounds or repeated questions. Before applying, read the current role description and adjust the language, framework, and seniority depth accordingly.

Master JavaScript and Node.js internals

Because this account explicitly mentions the JavaScript event loop and asynchronous behaviour, practise tracing synchronous work, queued callbacks, promise reactions, timers, and error propagation. Explain the order of a short program before running it, then compare the prediction with the runtime. This tests understanding without claiming that a current interviewer will repeat the same topic.

Build and own at least one REST API project

The nested-comments task combines implementation with API judgement. Build a small version that creates replies, retrieves a thread, validates parent relationships, handles deletion, and returns errors consistently. Be ready to explain storage choices, recursion depth, query cost, pagination, authorisation boundaries, and test cases. These exercises derive from the reported task but are not presented as additional Postman requirements.

Prepare system design by trade-off, not memorisation

For the reported URL-shortener prompt, begin with requirements and traffic assumptions supplied by the interviewer rather than inventing them. Explain the write and redirect paths, identifier choices, collision handling, storage keys, cache behaviour, expiry, abuse protection, and recovery from dependency failures. State which assumptions would change the design. That makes the answer auditable even when the prompt is intentionally underspecified.

Practice dry-run problem solving

Round 4's no-code format shows why candidates need to communicate beyond an editor. For a practice problem, state the input contract, give a simple approach, improve it only when justified, name edge cases, and manually trace a small example. Finish with time and space complexity. The aim is a reviewable line of reasoning, not a memorised solution count.

Prepare your hiring manager narrative

Prepare truthful examples about a project decision, a mistake, feedback, an ambiguous task, and collaboration. For each, separate the context, your own action, and the observed result. Read the current job description and official company material before the interview so your motivation is tied to the actual role. The source does not establish a prescribed answer length or a particular reason for rejection.

Common mistakes and red flags to avoid

• Treating the historical sequence as a current guarantee. This is one June 2021 account. Use it to find skills to practise, then verify the current role separately.
• Surface-level project explanations. The source reports deep project questions. Prepare the requirement, architecture, database decision, trade-offs, limitations, and your own contribution for every listed project.
• Ignoring async JavaScript fundamentals. The account specifically names event-loop and asynchronous-behaviour questions in Round 1. Review those concepts without expanding them into an unreported company-wide syllabus.
• Memorising a system-design diagram. The interviewer followed up on scaling and improvements. Practise explaining how each design decision changes under clarified requirements.
• Inventing an explanation for the rejection. The contributor reports the outcome but not its cause. Do not convert guesses about headcount, fit, or one interview into facts.
• Assuming progression guarantees an offer. This account documents a rejection after the full reported loop. Keep other applications active until an offer is actually issued.

Real-world data points

• 5 rounds in the Postman SDE Backend off-campus loop, as reported on GeeksforGeeks (June 2021)
• ~1 month end-to-end duration for the full interview process
• 45 minutes was the reported duration of Round 2, the REST API coding round
• June 2021 was the interview month, as stated by the candidate
• LinkedIn was the application channel, off-campus
• 2 problems were discussed in Round 4's no-code problem-solving round
• A rejection followed the full reported loop
• No CTC figure was disclosed in the account

Sources & credits

• https://www.geeksforgeeks.org/postman-interview-experience-for-software-engineer-backend-off-campus-2021/