Backend Interview Questions for Junior and Mid Developers

THE QUESTIONS

Real questions, senior answers

1. 01

   What makes an API RESTful, and what does a non-RESTful API look like?

   Build the API around resources. Every URL is the plural noun of a resource — /payments, not /getPayments or /deletePayments — and the HTTP verbs define the actions: a POST to /payments creates a payment. Once you put verbs in the URL, you have left REST and built a random collection of endpoints.

   RESTHTTPAPI design
2. 02

   What are the advantages of making an API RESTful?

   It is a standard, so it is predictable. Consumers know the shape of every request and response before they read a single line of docs. A non-standard API forces you to explain and document everything, because it looks like nothing anyone has seen before.

   RESTAPI design
3. 03

   What is content negotiation? Can you give an example?

   Content negotiation is an HTTP mechanism: the client tells the server which shape of a resource it accepts. Example: the browser requests a CSS file with an Accept-Encoding header saying it also takes gzip; the server sends the compressed version and flags it with Content-Encoding. Same resource, different format — twenty years ago the same mechanism served web pages in different languages based on the browser's language header.

   HTTPAccept-Encodingcontent negotiation
4. 04

   How does HTTP compression translate into an advantage for the backend?

   Compressing, sending, and decompressing is faster than sending the raw asset — gzip cuts the size by roughly 70%. Less data over the network means better performance and better scalability. Browsers do this by default: every CSS request already carries a header saying gzip or Brotli is fine.

   gzipperformanceHTTP
5. 05

   What is the difference between SQL and NoSQL databases?

   SQL databases store tabular data with a schema — well-defined drawers where only certain things fit, and the data must conform. NoSQL stores documents or graphs with few relationships between the data; think of it as a drawer where you throw everything. The schema is the real difference: SQL is opinionated about how data looks, NoSQL mostly is not.

   SQLNoSQLdatabases
6. 06

   New service storing categorized products — SQL or NoSQL, and why?

   Products with categories means relationships that people will query and that will grow. That is a relational database: MySQL or PostgreSQL. You can fake it in MongoDB with an ORM, but evolving those relationships stays much easier in SQL down the road — and if you already run an SQL database, use SQL as the general rule.

   PostgreSQLMySQLdata modeling
7. 07

   When would you use a NoSQL database?

   When the records are independent events, not related business data. An analytics service logging clicks and purchases is the classic case: events are mostly unrelated, extra fields show up per event, and a fixed schema would only get in the way. That is why log storage is usually a NoSQL document database.

   NoSQLanalyticsevent logging
8. 08

   What are the differences between GraphQL and REST, and when would you use GraphQL?

   REST gives consumers a fixed schema around resources, so frontends over-fetch (the whole product when they wanted title and price) or under-fetch (extra requests for the product variations). GraphQL exposes a data layer the frontend queries however it wants — everything a view needs comes back in one request. The biggest advantage is exactly that: fewer round trips to the server.

   GraphQLRESTover-fetching
9. 09

   What are the disadvantages of GraphQL?

   Caching is the first — much harder than caching a REST endpoint. Then complexity: defining the schema and writing resolvers is real backend work, and authorization gets harder because a query can touch fields a user is not allowed to see, forcing field-level checks. Testing needs specialized tooling too. You are trading query flexibility for backend complexity.

   GraphQLcachingauthorization
10. 10

    Why is it easier to cache a REST response than a GraphQL one?

    A REST endpoint maps to one specific resource, so checking freshness and invalidating the cache is trivial. A GraphQL query is nested — caching can happen at any field, at any level, and even debugging where the caching happens gets hard. Tooling exists, but the complexity is structural.

    cachingGraphQLREST
11. 11

    What is the N+1 problem in GraphQL, and how do you solve it?

    A resolver fetches a list, then fires one more database query per item: three products with 20 languages each means 60 queries for a single request — effectively a denial of service attack on your own database. The fix is batching: collect all the IDs, send one query, and distribute the results back to the resolvers. Libraries like DataLoader do exactly this.

    N+1DataLoaderGraphQL
12. 12

    Can you name three SOLID principles and one you have used in your code?

    S is single responsibility, O is open-closed, L is Liskov substitution, I is interface segregation, D is dependency inversion. The one I use most is dependency injection: pass a dependency as a constructor or function argument instead of importing it directly, so at test time you can provide a mock. NestJS, .NET, and Spring Boot ship it by default.

    SOLIDdependency injectiontesting
13. 13

    Can you give another example of a SOLID principle in practice?

    MVC is the single responsibility principle applied to architecture. Model, view, controller — each layer owns one job. It is what you get when you take spaghetti backend code and split it by responsibility.

    MVCsingle responsibilityarchitecture
14. 14

    What are microservices? Name three advantages and three disadvantages.

    You split a monolith into small independent services, each with its own database, calling each other over the network via REST or GraphQL APIs. Advantages: scale services independently, deploy independently, and let separate teams own them — it is how you grow the team. Disadvantages: network latency on every call, security between services (certificates, mutual authentication, service discovery), and the cost of maintaining all those pipelines — the microservices tax. The number one law of distributed systems: do not distribute your systems.

    microservicesmonolithdistributed systems
15. 15

    When would you recommend transitioning to microservices?

    When the team outgrows the monolith — Conway's law says the system mirrors the team, and a 15-person standup does not work; split so feature teams can deploy independently. When one part of the system takes most of the traffic and you are scaling the whole monolith just to serve it — split it and scale only that service. And when you cannot afford a single point of failure: in microservices, failure stays isolated to one service.

    microservicesConway's lawscaling
16. 16

    Are companies switching to microservices too early? What would you recommend?

    Yes — splitting too early is the most common mistake: teams create so many services that no one maintains them. If your team cannot build a modular monolith, it definitely cannot build microservices — prove you can separate services inside the monolith and understand the actual problem first. It is an expensive decision and hard to roll back, so be conservative; monorepo tooling has made staying on a monolith much easier.

    microservicesmodular monolithmigration