Interview questions in brief — API

Basics, methods and statuses

An answer in two sentences is exactly what an interviewer expects for a basic question. Then the conversation will go deeper by itself.

Question	Short answer
How does client-server architecture work?	The client sends an HTTP request, the server checks authorisation, runs the logic, works with the database and returns a response with a status. HTTP is stateless, so the token goes in every request.
What is REST?	An API style where data are resources at URLs, and actions are set by HTTP methods. Stateless, usually JSON.
PUT vs PATCH?	PUT replaces a resource entirely and is idempotent. PATCH changes individual fields.
What is idempotency?	A repeated identical request doesn't change the state beyond the first. GET, PUT, DELETE: yes; POST: no, so payments have an `Idempotency-Key`.
401 vs 403?	401: not authenticated. 403: authenticated, but without rights.
400 vs 422?	400: the request is incorrect in form. 422: the form is fine, but a business rule is violated.
The server returned 500 for invalid data. Is that a bug?	Yes. Invalid input must give a 4xx with an explanation; 500 means an unhandled exception.

In an interview: Short answers are the basics, but after them it is worth giving an example from a project, for example how I caught a 500 on invalid input or checked an Idempotency-Key. An example shows experience better than a definition.

Postman and automation

Question	Short answer
Variable scopes in Postman?	Global, Collection, Environment, Data, Local; with equal names the narrower scope wins.
How do you pass data between requests?	In post-response save a value with `pm.environment.set`, and in the next request use `{{name}}`.
Pre-request vs post-response?	Pre-request is preparation before sending (data, a token). Post-response is checks and saving values after the response.
How do you run a collection on CI?	Export the collection and environment, run `newman run` with a JUnit reporter; secrets through `--env-var`.
What do you check in a response besides the status?	The schema, field types and values, headers, response time, the absence of sensitive data and that the change was really saved.
Postman or code for API automation?	Postman is for exploration and quick checks. A large regression suite goes in code next to UI tests, with git review.

These questions often follow one another: from variables to chaining, from chaining to the Runner, from the Runner to CI. So it is useful to have one story in your head: how I build a collection, how I pass the token and ids between requests, how I run a data-driven set and how it gets into the pipeline.

In an interview: I talk about Postman as a chain: variables and environments, scripts and chaining, the Runner with data, Newman on CI. And to the question "Postman or code" I answer that for regression I choose code and keep Postman for exploration.