Top 10 Junior Backend Developer Interview Questions

1. Can you explain the difference between SQL and NoSQL databases and when you would use each?

SQL databases like PostgreSQL and MySQL are relational databases that use structured query language for defining and manipulating data. They have predefined schemas and organize data in tables with rows and columns. NoSQL databases like MongoDB and Cassandra don't require a fixed schema, making them more flexible for unstructured data. I'd choose SQL when data integrity is crucial, like in financial applications where transactions need ACID compliance. For example, at my university project, we used PostgreSQL for a banking application because we needed strong consistency when transferring money between accounts. NoSQL shines when dealing with large volumes of rapidly changing data or when the data structure might evolve. In my personal project tracking social media posts, I used MongoDB because post content varied widely and we needed to scale horizontally. SQL databases excel at complex queries and relationships, while NoSQL databases typically offer better performance for simple read/write operations at scale. The decision ultimately depends on your specific use case - if you need complex transactions and joins, SQL is probably better, but if you need flexibility and horizontal scalability, NoSQL might be the way to go. Neither is universally better; they're tools designed for different problems.

2. How would you handle error handling in a REST API?

Error handling in a REST API should be consistent, informative, and secure. I'd implement a global error handling middleware in Express.js that catches all exceptions and formats them appropriately. For expected errors, I'd use proper HTTP status codes - 400 for bad requests, 401 for unauthorized access, 404 for resources not found, and 500 for server errors. Each error response would include a standardized JSON structure with fields like "status," "message," and possibly "details" for debugging in non-production environments. For example, if a user tries to access a product that doesn't exist, they'd receive a 404 with a message like "Product with ID 12345 not found." I'd make sure sensitive information is never leaked in error messages - database connection strings or stack traces should be logged server-side but never sent to clients. For validation errors, I'd return detailed information about which fields failed validation and why, like "Email address is invalid format." I'd also implement logging for all errors to help with debugging and monitoring, using something like Winston or Pino to capture error details, request information, and timestamps. For third-party service failures, I'd implement circuit breakers using libraries like Hystrix to prevent cascading failures. Finally, I'd document all possible error responses in the API documentation so clients know what to expect and how to handle different error scenarios.

3. What is dependency injection and why is it important?

Dependency injection is a design pattern where a class receives its dependencies from external sources rather than creating them itself. It's a way to achieve inversion of control, making code more modular and testable. In practice, instead of a UserService creating its own database connection, the connection would be "injected" into the UserService when it's instantiated. I've used this approach in a Node.js application where I created a service that needed database access, email functionality, and logging. Rather than hardcoding these dependencies, I passed them in through the constructor. This made testing much easier because I could provide mock implementations of these dependencies. For example, when testing the user registration flow, I could inject a fake email service that just recorded what emails would have been sent without actually sending them. Dependency injection also makes it easier to swap implementations - we switched from MongoDB to PostgreSQL in one project, and because of DI, we only needed to change the code that created the services, not the services themselves. Many frameworks like NestJS have built-in DI containers that handle the wiring of dependencies automatically. This pattern is particularly valuable in larger applications where you have complex dependency graphs. It promotes the SOLID principles, particularly the Dependency Inversion Principle, by ensuring high-level modules don't depend on low-level modules but rather on abstractions.

4. How do you ensure the security of a backend application?

Security is a multi-layered concern that needs to be addressed throughout the application. I start with proper authentication and authorization - implementing JWT tokens with appropriate expiration times and refresh token rotation. For a recent project, I used Passport.js with JWT strategy and stored hashed passwords using bcrypt with a cost factor of 12. Input validation is crucial - I always validate data both client and server-side using libraries like Joi or express-validator to prevent injection attacks. For example, in an e-commerce API, I validated that product IDs were valid UUIDs and prices were positive numbers. HTTPS is non-negotiable for production environments to encrypt data in transit. I've configured Node.js applications with Helmet to set security-related HTTP headers that prevent clickjacking and XSS attacks. For database security, I use parameterized queries or ORMs like Sequelize that handle escaping to prevent SQL injection. I'm careful about implementing proper rate limiting using express-rate-limit to prevent brute force and DoS attacks - in one API, we limited login attempts to 5 per minute per IP address. Regular dependency audits using npm audit or Snyk help identify and fix vulnerable dependencies. I also follow the principle of least privilege when setting up database users and API permissions. For sensitive operations, I implement additional verification steps like email confirmation or two-factor authentication. Finally, comprehensive logging of security events helps detect and respond to potential breaches - I've used Winston to log authentication failures, permission violations, and other security-relevant events.

5. Explain the concept of asynchronous programming in Node.js and how you handle it.

Asynchronous programming in Node.js allows operations like file I/O or network requests to be executed without blocking the main thread. Node.js uses an event-driven, non-blocking I/O model, which is why it can handle many concurrent connections with a single thread. I've worked with all three main patterns for handling asynchronous code in Node.js. Initially, I used callback functions, but they can lead to "callback hell" when nesting multiple async operations. For example, reading a file, processing its contents, and then writing to another file could result in deeply nested callbacks. Promises improved this situation by allowing for chaining with .then() and error handling with .catch(). In a recent project, I used promises when integrating with a payment API - I could chain the user validation, payment processing, and order creation steps in a readable way. Async/await, which is built on promises, is now my preferred approach because it makes asynchronous code look and behave more like synchronous code. For instance, in an e-commerce backend, I used async/await to handle a checkout process that needed to check inventory, process payment, and update order status. I'm also familiar with handling common async patterns like parallel execution using Promise.all() - I used this when needing to fetch data from multiple microservices simultaneously. For more complex scenarios, I've used libraries like async.js or RxJS. Error handling is crucial in asynchronous code - with async/await, I use try/catch blocks, and I make sure to handle promise rejections to avoid unhandled promise rejection warnings. Understanding the event loop is essential for writing efficient Node.js code - I'm careful about not blocking it with CPU-intensive operations, instead using worker threads for those cases.

6. What is the purpose of middleware in Express.js and can you give some examples?

Middleware functions in Express.js are functions that have access to the request object, response object, and the next middleware function in the application's request-response cycle. They can execute code, modify request and response objects, end the request-response cycle, or call the next middleware. I've used middleware for various purposes in Express applications. For authentication, I've implemented JWT verification middleware that checks for a valid token in the Authorization header before allowing access to protected routes. For example, function authMiddleware(req, res, next) { /* verify token */ req.user = decodedToken; next(); }. Logging middleware has been useful for debugging and monitoring - I created middleware that logs each request's method, URL, and timing information using Winston. Body parsing middleware like express.json() and express.urlencoded() are essential for processing request bodies in different formats. I've also created custom validation middleware that checks incoming data against schemas before it reaches route handlers. CORS middleware (cors package) has been crucial for handling cross-origin requests in APIs consumed by frontend applications hosted on different domains. Error handling middleware is particularly important - I've implemented middleware that catches errors thrown in route handlers and formats them consistently for clients. For a high-traffic API, I implemented rate limiting middleware to prevent abuse. Session management middleware (express-session) has been useful for applications requiring stateful sessions. I've also used compression middleware to reduce response size and improve performance. The middleware pattern makes Express powerful and flexible, allowing you to cleanly separate concerns and create reusable components for common functionality across routes.

7. How do you approach database schema design for a new application?

Database schema design starts with understanding the domain and requirements thoroughly. I begin by identifying the core entities and their relationships. For example, in an e-commerce application, I'd identify entities like Users, Products, Orders, and Reviews. I create an entity-relationship diagram to visualize these relationships - is it one-to-one, one-to-many, or many-to-many? For instance, a User can have many Orders, but an Order belongs to one User. I consider normalization principles to reduce redundancy while being pragmatic about denormalization for performance when needed. For example, I might store a product's current price in the OrderItem table even though it duplicates data from the Products table, because historical price information is important for orders. I carefully choose appropriate data types and constraints - using UUID instead of sequential IDs for security, setting NOT NULL constraints on required fields, and adding appropriate indexes for fields frequently used in WHERE clauses or joins. I implement foreign key constraints to maintain referential integrity - if a user is deleted, what should happen to their orders? Should they be deleted (CASCADE) or should the deletion be prevented (RESTRICT)? I consider the access patterns - how will the data be queried most often? This might influence decisions like adding denormalized fields or specific indexes. For time-series data or data that grows rapidly, I plan for partitioning strategies. I also think about soft deletion versus hard deletion - often using a "deleted_at" timestamp rather than actually removing records. Finally, I document the schema thoroughly with comments and create migration scripts that can evolve the schema over time as requirements change.

8. What testing strategies do you use for backend development?

Testing is essential for maintaining code quality and preventing regressions. I implement a comprehensive testing strategy that includes several layers. Unit tests focus on testing individual functions and classes in isolation. I use Jest for Node.js projects and mock dependencies to ensure true unit testing. For example, when testing a service that sends emails, I'd mock the email sending library to verify the correct parameters are passed without actually sending emails. Integration tests verify that different components work together correctly. I might test that my user service correctly interacts with the database layer by using an in-memory database like SQLite or a test container running the actual database engine. API tests validate the endpoints from an external perspective. I use Supertest with Express to make HTTP requests to my API and verify the responses. For instance, I'd test that a POST to /api/users returns a 201 status code and the created user has the expected properties. I implement end-to-end tests for critical flows using tools like Cypress, though I keep these focused on the most important user journeys due to their higher maintenance cost. I'm a proponent of test-driven development when appropriate - writing tests before implementation helps clarify requirements and design. I set up continuous integration to run tests automatically on every pull request, preventing broken code from being merged. Property-based testing with libraries like fast-check has been valuable for finding edge cases in complex algorithms. I also use code coverage tools to identify untested code paths, though I focus on meaningful coverage rather than arbitrary percentage targets. Load testing with tools like Artillery helps verify performance under expected traffic conditions. All these testing strategies together provide confidence that the code works as expected and continues to work as the codebase evolves.

9. How do you handle database migrations in a production environment?

Database migrations in production require careful planning to avoid data loss or downtime. I use migration tools like Sequelize migrations, Knex.js, or Flyway depending on the project's stack. Each migration is versioned and contains both "up" and "down" methods to apply or roll back changes. Before applying migrations to production, I thoroughly test them in development and staging environments with production-like data volumes. For example, when adding a new required column to a large table, I discovered in staging that the migration locked the table for too long, so I rewrote it to add the column as nullable first, then update values in batches, and finally add the NOT NULL constraint. I always back up the database before running migrations in production - either a full backup or at least the affected tables depending on database size. For critical systems, I schedule migrations during maintenance windows with reduced traffic and communicate the potential downtime to users. I've implemented blue-green deployment strategies where possible, creating a new database with the updated schema, migrating data, and then switching the application to use the new database. For large tables, I've used techniques like creating new tables with the desired structure, copying data in batches using background jobs, and then renaming tables when complete. I'm cautious about migrations that can't be easily rolled back, like dropping columns or tables - these are deferred to a later cleanup migration after confirming the change was successful. I maintain a detailed migration history and document any manual steps that were required. After migration, I verify the application works correctly with automated tests and manual checks of key functionality. This methodical approach minimizes risk while allowing the database schema to evolve with application requirements.

10. How do you optimize the performance of a backend application?

Performance optimization is a systematic process that starts with measurement. I use profiling tools like Node.js's built-in profiler or clinic.js to identify bottlenecks rather than making assumptions. Database queries are often the first place to look - I've optimized slow queries by adding appropriate indexes, rewriting joins, and implementing query caching with Redis. For example, in an analytics API, I reduced a report generation time from 15 seconds to 500ms by adding a composite index and caching frequently requested reports. I implement application-level caching for expensive operations or frequently accessed data. In one project, we cached user permission sets in memory to avoid recalculating them on every request. For API endpoints that return large datasets, I implement pagination, filtering, and projection to reduce the payload size and processing time. Horizontal scaling is important for handling increased load - I design stateless services that can run across multiple instances behind a load balancer. I've used connection pooling for database connections to efficiently manage resources and implemented circuit breakers for external service calls to prevent cascading failures. Asynchronous processing is crucial for performance - moving time-consuming tasks like image processing or email sending to background jobs using queues like Bull or RabbitMQ. I optimize the Node.js event loop by avoiding blocking operations and using worker threads for CPU-intensive tasks. HTTP compression and response streaming can significantly improve perceived performance, especially for larger payloads. I've also implemented CDN integration for serving static assets and API caching for read-heavy endpoints. Regular performance testing with tools like Artillery helps catch regressions before they reach production. The key is to focus optimization efforts where they'll have the most impact, based on actual measurements rather than premature optimization.