Backend Developer Interview Questions

I start with the consumers of the API before thinking about implementation. The first questions I ask are: who will call this, what data do they actually need, and what operations make sense from a resource perspective? From there I design around resources and standard HTTP verbs, keeping URLs noun-based and using status codes consistently rather than burying error information inside 200 responses. I document as I go using OpenAPI because a schema that exists from day one prevents the API from drifting from its contract. I also version from the start: adding /v1/ to the base path costs nothing at the beginning and saves painful migration work later. Before finalising any API, I review it with the teams who will consume it, because the best signal that a design is right is whether the consumer can write their integration code without needing to ask me follow-up questions.

Security is a design concern, not a review step at the end. My starting point is the OWASP Top 10: SQL injection, broken authentication, excessive data exposure, and so on. These are not exotic attack vectors; they cause most real-world breaches. Practically this means parameterised queries everywhere, no secrets in code or logs, JWT validation with proper expiry, and input validation at the API boundary rather than trusting the client. For sensitive data I apply the principle of least privilege at the database level: services only have access to the tables they need. I also build in rate limiting on public endpoints to prevent abuse. I encourage team members to flag concerns early, because a vulnerability caught in code review costs far less than one caught in production.

I approach performance issues the same way I approach any debugging problem: measure before changing anything. The worst thing you can do is optimise something that is not the actual bottleneck. My first step is always to identify the slow path using profiling tools or APM data. In most cases the answer is the database: missing indexes, N+1 query patterns, or loading more data than the consumer needs are responsible for the majority of backend slowdowns I have seen. Once the bottleneck is clear I look at the lowest-cost fix first. Adding an index takes minutes and can improve a query by orders of magnitude. If the issue is structural I look at caching with Redis for read-heavy data that does not change frequently, and async processing for operations that do not need to be synchronous. I always measure before and after a change and document the result so the team understands what we gained.

AI has changed my daily workflow in concrete ways. For boilerplate: setting up a new service, scaffolding a test suite, writing migrations, AI gets me to a solid first draft in minutes that I then review and adjust. The value is not just speed; it reduces the cognitive overhead of switching between the logic I am designing and the syntax and scaffolding required to express it. For debugging unfamiliar codebases or tracing an error message I have not seen before, AI often surfaces the likely cause faster than a search. Where I am more careful is with security-sensitive code: I never paste secrets or PII into a public model, and I always review any AI-generated authentication or authorisation logic carefully because subtle mistakes in those areas have the biggest consequences. I also use AI to generate test cases, asking it to consider edge cases I might have missed, which has caught real bugs before they reached production.

Our payment processing service started throwing intermittent 500 errors on a Friday afternoon, affecting roughly 3% of transactions. I joined the incident call, pulled the logs, and within ten minutes identified that the errors clustered around a specific database replica that had fallen behind in replication. The root cause was a long-running query introduced in a deploy earlier that day. I coordinated with the on-call DBA to route traffic away from the lagging replica while we rolled back the offending query. The incident lasted 40 minutes from detection to resolution. Throughout, I gave updates every five minutes so the support team could manage customer communications in parallel. After the incident I wrote a post-mortem, added a replication lag alert we did not have before, and added query performance analysis to our pre-deploy checklist.

We needed to add real-time notifications to our platform. Two approaches were viable: polling from the client every few seconds, or a WebSocket connection per user. Polling was simpler to implement and easier to scale horizontally. WebSockets gave a better user experience but added significant complexity: connection state, reconnection logic, and load balancer configuration. Given our user base of around 50,000 active users at the time, polling would have added meaningful database load for a relatively small UX improvement. We chose WebSockets but scoped the initial implementation to a subset of high-value notification types only. This let us prove out the infrastructure before rolling it out everywhere. The key decision was to build a notification abstraction layer so we could switch the underlying mechanism without rewriting every consumer, which kept the decision reversible.

I inherited a reporting service that ran daily batch jobs and frequently timed out for our largest customers, sometimes running for four hours. I profiled the slowest queries and found two problems: one query was loading entire tables into memory and filtering in application code instead of in SQL, and a recurring job was running with no pagination and exhausting memory on large result sets. I rewrote the offending query to use database aggregates and index-backed filters, and added cursor-based pagination to the batch job. The result was a reduction in runtime from four hours to under 20 minutes for the largest accounts. I also added a timeout alert so we would know early if a future job was trending in the wrong direction, rather than discovering a failure at the end.

SQL is my default for most application data because relational integrity, ACID transactions, and ad hoc querying are valuable properties I do not want to give up without a good reason. I consider NoSQL when one of three things is true: the data is genuinely document-shaped and does not benefit from normalisation (a CMS with variable schema is a good example); the access patterns are simple and known upfront and I need horizontal scale that is easier to achieve with a key-value or document store; or I am building a time-series or graph use case that is a poor fit for relational tables. What I try to avoid is choosing NoSQL for performance reasons without first measuring whether the SQL solution is actually too slow. Premature database architecture decisions are expensive to reverse.

Caching is a trade-off between consistency and performance, so I start by asking whether the use case tolerates stale data, and if so, for how long. For data that changes infrequently and is read by many users such as config, reference data, or public profiles, a cache-aside pattern with a short TTL is usually the right choice and Redis is my default tool. For data where consistency matters such as account balances or inventory counts, I avoid caching at the application layer and focus on optimising the query instead. I am always careful about cache invalidation: when a write happens, how do we make sure the cache does not serve stale data? I keep invalidation logic simple and explicit rather than relying on TTL alone for data that gets modified. I also instrument cache hit rates: a cache hitting below 70% is usually not pulling its weight and may be hiding an index problem.

I approach this as a load analysis problem first. The question I want to answer before designing anything is: where does the system break under load, and what is the cost of each fix? I start by identifying the likely bottleneck: for most web applications it is either the database connection pool or a single synchronous operation in the critical path. For a spike scenario I think about three levers. First, horizontal scaling: can I add instances behind a load balancer without shared mutable state? This requires stateless services and session state stored externally. Second, queue-based decoupling: can I move work that does not need to happen synchronously into a queue so that API response time stays fast even under load? Third, read replicas and caching: can I absorb read traffic without hitting the primary database? A real architecture decision needs load test data to validate assumptions, but this is the shape of my reasoning before I commit to any particular solution.