Backend Developer Interview Questions

This is the bread and butter of senior backend development and software architecture. Not every software or application needs to be built into a microservices architecture. A modular monolithic architecture can be highly scalable and work well for most applications, while microservices will demand huge, experienced teams in synchronization.

When to Use a Modular Monolith

• Growing Projects: When the system doesn’t yet require the full complexity of microservices, but needs a more organized architecture.
• Small or under-resourced teams: Monolithic architecture facilitates the creation and deployment process without requiring a complex infrastructure or a large number of specialists.
• Systems with Well-Defined Domains: The problem can be divided into distinct areas of responsibility, but they aren’t yet so large as to justify complete separation into services.
• Lower Latency and Infrastructure Complexity: There are no network or orchestration costs between internal modules, leading to simpler monitoring and deployment.

When to Use Microservices

• Large, Scalable Applications: Projects that require high scalability in specific components, with greater stability and resilience, as one service doesn’t affect the others.
• Large, Experienced Teams: Large, experienced teams can manage the complexity of having multiple independent services.
• Technological Independence: Demands the adoption of different technologies and tools for different services to optimize development.
• Rapid Updates and Innovation: Each microservice can be updated and deployed independently, facilitating innovation and rapid adaptation to changes.
• Resilience: If a microservice fails, it doesn’t bring down the entire application, allowing the other parts to continue functioning.

The distinction between the two scalability approaches is defined based on how resources are increased. 

Horizontal Scaling (Scaling Out) involves adding more servers (machines) to distribute the load. It is characterized by running multiple instances of the application behind a load balancer (often in the cloud). You can also purchase more servers and devices for more reliability and resources.

Vertical Scaling (Scaling Up) increases the power of existing servers and devices, adding more resources to existing machines. In other words, you can install more hardware in your computers and servers, upgrading CPU, memory (RAM), or disk space.

Zero Trust is a security policy that affirms no component should be implicitly trusted; no implicit trust is granted to assets or user accounts based solely on their physical or network location. Following Zero Trust policies implies that authentication and authorization (both subject and device) are discrete functions performed before establishing a connection to a company resource.

When choosing a data store for a high-throughput feature, a backend developer prioritizes criteria that align with the technical needs of the long-term operational and business context. Focusing solely on speed often leads to future complications.

Beyond the fundamental technical requirements such as high throughput, low latency, and data model fit (e.g., relational integrity vs. flexible schema), a senior backend developer must consider team expertise, ecosystem maturity, future data evolution, and total cost of ownership. In other words:

1. Can anyone use that store in our team?
2. Does that data store boast a suitable ecosystem and enough tools to work with?
3. Will the data store handle the data well across the following months?
4. How much will it cost to maintain? This includes infrastructure, staffing, and licensing.

This is a classic systems design question. I will detail the high-level and low-level design for a Large-Scale Video Upload and Sharing Application Backend, as this presents a rich mix of asynchronous processing, high-throughput writes, and globally distributed reads.

This is a high-level design of a complex system, designed around the principles of scalability, resilience, and eventual consistency to handle high-volume ingest (writes) and global content delivery (reads).

Component	Description	Technologies (Example)
API Gateway	Entry point for all client requests (Upload, View, Search). Handles rate limiting, authentication, and load balancing.	AWS API Gateway, NGINX
Ingest Service (Write Path)	Handles the initial file upload, metadata creation, and triggers asynchronous processing.	Microservice (Go/Java), Load Balancer
Storage Layer	Object Storage for the raw video files Metadata Store for video information.	Object Storage: S3, Azure Blob Storage Metadata: PostgreSQL/DynamoDB
Processing Pipeline	Asynchronous workers are responsible for media transcoding, thumbnail generation, and content analysis.	Kafka/RabbitMQ (Queue), Worker Pool (Kubernetes Jobs)
Content Delivery Network (CDN)	Caches transcoded video segments and serve them geographically close to the users. Essential for the Read Path.	Akamai, Cloudflare, AWS CloudFront
Analytics & Search	Separate data stores optimized for indexing and real-time consumption of data.	Elasticsearch (Search Index), Kafka Streams (Real-time Analytics)

High-Level Architecture Flow

1. Write Path (Blue): Client → API Gateway → Ingest Service → Object Storage → Queue → Worker Pool → CDN/Metadata Store.
2. Read Path (Red): Client → API Gateway → CDN (Primary) or Metadata Store → Ingest Service → Client.

Now the Low-Level Design (LLD). The write path is heavily asynchronous to prevent the client’s upload time from blocking the primary ingestion service. It focuses on durability and task parallelism.

Step	Detail	Key Considerations
1. Client Upload	The client first hits the Ingest Service to get a unique upload token and a pre-signed URL (e.g., from S3). The client then streams the raw video file directly to Object Storage.	S3 Pre-signed URLs are crucial to offload large file transfers from the service layer. Resumable uploads are implemented for large files.
2. Metadata Creation	Upon successful upload notification (e.g., S3 Event Notification), the Ingest Service creates a “Processing” status record in the Metadata Store (e.g., PostgreSQL for transactional safety).	A single transaction ensures the file exists in storage and the record exists in the DB.
3. Asynchronous Trigger	The Ingest Service drops a message onto the Message Queue (Kafka). The message contains the video ID, storage location, and desired transcoding profiles.	Using a queue decouples the ingest service from the processing workers, providing back pressure and fault tolerance.
4. Transcoding & Analysis	Worker Pool instances (stateless) pull messages from the queue. They download the raw video, perform tasks in parallel: Transcoding (to HLS/DASH formats), Thumbnail Generation, and Content Moderation/Analysis.	FFmpeg is the core tool. Workers use a retry mechanism (e.g., Dead Letter Queue) on failure.
5. Final State & Delivery	Workers upload all resulting segments and thumbnails to Object Storage. They then update the Metadata Store status from “Processing” to “Ready”. This state change makes the video viewable.	Cache Invalidation: The status update should trigger a cache invalidation for this video ID in the cache (e.g., Redis).

The read path is optimized for low latency and high availability using aggressive caching and geographical distribution.

Step	Detail	Key Considerations
1. User Request	User clicks a video link. The request goes through the API Gateway to the Ingest/Viewing Service.	Authentication is handled at the Gateway level to protect the backend services.
2. Edge Cache Hit/Miss	The service layer first checks the CDN for a cached manifest (HLS/DASH playlist). If available, the CDN serves the stream directly to the user.	Most reads should be served by the CDN (Cache Hit) for true low-latency scale. Geographical routing is key.
3. Metadata Retrieval	If a cache miss occurs (e.g., first view in a new region), the service fetches the video metadata (status, stream manifest URL) from the Distributed Cache (Redis).	Redis Cache-Aside: The cache is the first check before hitting the Metadata DB. TTL is set aggressively.
4. Database Fallback	If the cache is also a miss, the service queries the Metadata Store (PostgreSQL/DynamoDB). The response is then immediately written back to the cache for future requests.	Read Replicas are essential for scaling the database read load.
5. Stream Delivery	Once the manifest URL is retrieved, the URL is returned to the client. The client then streams the video segments directly from the CDN, not the application server.	Dynamic adaptive streaming (HLS/DASH) enables the client to select the optimal quality based on available bandwidth.

This question assesses a candidate’s understanding of modern Site Reliability Engineering (SRE) principles. It ensures the candidate can link technical metrics (availability, P95 latency, error rate) directly to business requirements and user impact.

Let’s take, for example, SLIs and SLOs for a core customer-facing API, such as a checkout service. We will prioritize the user experience around speed, reliability, and correctness. The measurement and response revolve around maintaining a strict error budget.

Defining SLIs and SLOs for a Checkout Service

For a mission-critical service like checkout, the key metrics are focused on the user’s ability to complete a transaction successfully and quickly.

Service Level Indicators (SLIs)

These are the quantitative measures of the service’s health, often expressed as a ratio of good events to total events.

SLI Name	Definition	Rationale
Availability (Success Rate)	Ratio of Successful HTTP Requests (2xx, 400-404) to Total Requests.	Measures the ability to handle requests. Excludes 4xx errors (like 401,403,404) that are typically client-side, but may include 429 (Rate Limit) as a service-side failure to serve.
Latency (Speed)	Percentage of Successful Requests served in under X milliseconds.	Measures user experience. We focus on the P95 (95th percentile) and P99 (99th percentile) to capture the experience of the majority of users, not just the average.
Durability/Correctness (Data Integrity)	Ratio of Successful Transactions that correctly persist data to Total Successful Transactions.	Measures the integrity of the core function. This often requires application-level metrics, such as a database write success rate or an order reconciliation check in the background.

Service Level Objectives (SLOs)

These are the target values for the SLIs, which translate directly into the Error Budget.

SLI	SLO Target (Example)
Availability	99.9% (Three Nines) over a 30-day rolling window.
Latency (p95)	95% of requests must return in under 300ms.
Latency (p99)	99% of requests must return in under 1000ms.
Durability/Correctness	99.99% of successful checkouts must generate a valid, persisted order record.

The Error Budget is a mechanism that operationalizes the SLO for Availability. It represents the maximum amount of “bad” performance (unavailability or unacceptably slow requests) the service can tolerate over a defined period while still meeting the SLO.

For our Availability SLO of 99.9% over 30 days:

1. Total Time/Events in Period: Assume 1,000,000 requests occur in 30 days.
2. Required Good Events: 1,000,000×0.999=999,000 good requests.
3. Error Budget (Events): 1,000,000−999,000= 1,000 error requests.
4. Error Budget (Percentage): 100%−99.9%= 0.1%.

The system is allowed to fail 1,000 requests (or 0.1% of total requests) over that month. When we track the number of failed requests, we are “spending” this budget.

Exhausting the error budget means we are on the verge of violating our SLO, which often results in a loss of customer trust and potential revenue. Our immediate plan is to invoke a Code Red Protocol that prioritizes stability over feature velocity.

Phase 1: Halt and Stabilize (Immediate) 

1. Freeze All Non-Essential Releases: Immediately stop all deployments, A/B tests, and non-critical configuration changes to prevent any further stability risk. This is a crucial, non-negotiable step.
2. Activate Incident Response: A dedicated SWAT team is formed. Their sole focus is troubleshooting.
3. Shift Engineering Focus (Feature → Reliability): All backend developers working on the checkout service are immediately reassigned to triage and reliability work until the budget is substantially recovered.
4. Implement Temporary Mitigation:
   • Rate Limiting/Traffic Shaping: Aggressively reduce traffic from non-critical clients or non-essential regions to offload the service.
   • Fail Fast/Degrade Gracefully: Temporarily disable non-core functionalities (e.g., promotional codes, complex logging) to conserve resources for the core payment transaction.

Phase 2: Root Cause Analysis and Recovery (Short-Term) 

1. Deep Dive Metrics: Use observability tools to quickly identify the specific cause of budget exhaustion (e.g., a sudden increase in 503 errors, or a slow database query causing Latency SLO breaches).
2. Targeted Fixes and Rollback: Implement a targeted hotfix or, if the issue is recent, an immediate rollback of the last change. These fixes are deployed under an accelerated, high-scrutiny deployment process.
3. Post-Incident Review (Blameless): Once the system stabilizes, a blameless post-mortem is conducted to understand the systemic failure.

Phase 3: Budget Replenishment (Long-Term) 

Since the error budget is often a rolling window (e.g., 30 days), the budget won’t recover until the high-error days roll out of the window. The long-term action is to invest in reliability work to prevent future burnout:

1. Dedicated Reliability Sprints: Schedule a 1-2 week engineering sprint dedicated to addressing the findings from the post-mortem, focusing on performance optimization, increasing testing coverage, and improving monitoring to prevent a recurrence.
2. SLO Review: Evaluate if the current SLO is correctly balanced. If the service is chronically close to the limit, the SLO might be too ambitious, or the underlying architecture is insufficient for the current business load. Adjusting the SLO is a business decision, not a technical one, and should only be done after architectural improvements are deemed too costly.

When faced with a high-impact technical debt that poses a compliance risk, the decision must be treated as a risk management problem, not just a technical one. The justification is translating the technical risk into quantifiable business impact (cost, legal liability, reputation).

This backend developer interview question evaluates the candidates’ risk management and effective communication skills.

First step is deciding where to focus cleanup efforts; the second step is justifying resource allocation to leadership.

Cleanup efforts can be prioritized based on a matrix of Impact, Probability, and Remediation Cost.

A. Risk Quantification (Impact & Probability)

The first step is to assess the technical debt’s impact in business terms:

Risk Dimension	Description	Score (1-5)
Compliance/Legal Impact	What is the maximum fine, legal penalty, or loss of certification (e.g., PCI, HIPAA) associated with this specific risk?	High (5) if it could stop operations or result in huge fines.
Security Impact	What is the likelihood and scope of a breach? Focus on P-II (Personally Identifiable Information) or financial data exposure.	High (5) if customer data is at risk.
Blast Radius	How many systems/features/customers are affected? Does it affect the core revenue stream?	High (4) if it affects the critical path (e.g., checkout, login).
Time-to-Failure (Probability)	How likely is this debt to cause an outage or be exploited in the next 6-12 months?	High (5) if it’s an actively exploited zero-day or an impending end-of-life (EOL) system.

B. Remediation Cost and Sequencing

Compare the total risk score against the effort needed to fix it:

1. Prioritize the High-Impact, Low-Effort Fixes: Focus on “quick wins” first to immediately reduce overall risk and demonstrate value. This helps buy goodwill and time for larger projects.
2. Focus on the Compliance Critical Path: If the risk is an outdated library on a checkout page, address that before fixing an outdated internal reporting service, regardless of size, because the former poses an immediate legal and financial threat.
3. Chunk the Work: Break the large debt into smaller, independently deployable units. This allows for an incremental approach, potentially integrating 20−30% of the debt work into the feature sprint to maintain velocity while chipping away at the risk.

After that, the justification to the Product Manager cannot be “it’s old code” or “it’s technically cleaner.” It must focus on cost avoidance and safeguarding future revenue.

Product Managers care about the Product Roadmap and Total Cost of Ownership. So a senior backend developer knows how to demonstrate the Cost of Delay versus the Cost of Failure.

The Cost of Delay: “Yes, this will delay the new feature by X weeks, resulting in a Y% delay to projected revenue.”

However: “Ignoring this compliance risk (e.g., an outdated payment library) has a Z% chance of resulting in a major service outage or regulatory fine/brand damage that could cost us 10X the projected feature revenue and delay all features indefinitely.” (The Cost of Failure)

The question tests the depth of analytical skills and the ability to translate identified root causes into meaningful product or process changes. It also ensures that analytical expertise leads to systemic improvement.

A high-impact senior engineer views system failure and accrued technical debt not as mistakes to be hidden, but as critical opportunities for continuous improvement, often utilizing structured analysis like Failure Mode and Effects Analysis (FMEA).

Your goal here is to seek evidence of a structured incident process, clear communication pathways, and a commitment to a “blameless incident process” resulting in concrete, measurable follow-ups, which is crucial for seniority.

For senior candidates, code review functions as a leadership tool and a mentorship opportunity, not just a quality gate. The response must demonstrate a balance of technical rigor and interpersonal skills, showing a capacity to elevate team capabilities. Ask how they identify areas for growth, tailor guidance to learning styles, balance support with independence, and measure mentees’ progress.

Effective delegation is a prerequisite for scaling out the company. It increases team productivity and reduces burnout. This backend developer interview question assesses leadership potential, confirming the candidate can identify skill gaps and use delegation as a means of developing junior staff. Such candidate are scaling their own impact beyond their coding skills.

Is your candidate able to find common ground? To use data or proofs-of-concept (POCs) to resolve disputes and demonstrate technical humility? A senior must accept being wrong when evidence dictates. Technical disagreements are often only partially technical, involving social capital or non-obvious business constraints. Look for those candidates who focus on the process of mutual understanding (active listening, empathy) rather than simply asserting technical correctness.

Check the candidate’s diplomatic skills and ability to lead through technical disagreement. The assessment should focus on how the candidate balances listening to concerns with the need to maintain project momentum and strategic alignment.