Here is a list of handpicked technical interview questions with progressive difficulty, for screening backend developer candidates. They cover all fundamental skills of a backend developer. Each question is annotated with the difficulty level, its purpose and the expectations for the answer.
I have used the questions in the past interviews with considerable success. Feel free to use my collection to build your own custom list of interview questions, by following this guide.
Because every company’s tech stack is different, most of my questions are phrased in a technology-agnostic way. Do set the questions according to the specific technology that the job requires, by changing my questions or selecting new ones from the references listed at the bottom of the article.
There is usually a coding test for the backend developer candidates, which will require them to write code in a programming language. Therefore, I suggest you test for fundamental knowledge of the language during the interview.
- (entry-level) What is <a programming language internal>? How does it affect programming in <language X>?
- I would start with important internal constructs or essential features of the language. e.g. Global Interpreter Lock for Python/Ruby, JVM for Java, event loop for Node.js, etc.
- Expect the candidate to have working knowledge of the language internals.
- This question can be expanded to touch on key programming constructs, such as thread, process, type system, etc.
- (intermediate) Explain <programming paradigm> to me?
- It is likely your team is using certain programming paradigm for the project. If the candidate isn’t familiar with that, it will take him/her a long time to get up to speed. e.g. OOP, functional programming, event-driven programming, etc.
- Expect the candidate to know the key philosophies and ideas behind the paradigm.
- (advanced) What do you know about <a popular library> in <language X>?
- This question is relevant only if your project makes heavy use of the library, e.g. Akka Actors in Scala, Asyncio in Python, etc.
- Expect experienced candidate to relate his experience with the library and talk about some key concepts and design patterns in it.
- How many types of JOINs in <sql db> are you familiar with?
- In the time when ORMs (object relational mappers) or FRMs (functional relational mappers) are popular, developers are getting increasingly lazy at writing and using raw SQL. Those who know SQL well are often better engineers because certain complex queries are best written in SQL.
- Expect entry-level engineers to mention INNER, LEFT and RIGHT JOINS, intermediate-level engineers to also mention FULL and CROSS JOINS (if <sql db> in question supports them), expert engineer to also mention LATERAL JOIN.
- what is ACID?
- ACID stands for Atomicity, Consistency, Isolation and Durability. These are the basic properties of a database transaction.
- Expect the candidate to know the concepts well.
- Bonus: if the candidate also understands the limited support for them in some NoSQL databases.
- what are the main components of <nosql db> data models? how are they different from table and columns in SQL?
- If your tech team uses a NoSQL database such as MongoDB, or Cassandra, your backend hire should know the basics of it.
- Expect your candidate to be able to explain them. e.g. collection, fields, BSON objects in MongoDB.
I suggest skipping any questions that involve database queries, as they are too technical to answer without writing. If you want to test the candidates on those things, you can arrange a coding exercise that involves the database.
If you are using NoSQL database at large scale, and require your hire to understand the challenges at that scale, do consider asking advanced questions:
- (advanced) Explain the different read/write consistency levels for <noql db>?
- How do you scale out linearly with <nosql db>?
- NoSQL technology has been around for not more than 10 years and is constantly evolving. How to tune the cluster to achieve a certain trade-off between consistency and availability is thus a skill learned from experience. Therefore, do ask the candidate about his/her past working experience with the database.
- (entry-level) How many HTTP request methods can you name? When to use each of them?
- The basics of REST.
- Expect the candidate to name at least GET, POST, PUT, DELETE and know what kind of operations on a resource are mapped to them.
- A pro will also mention HEAD and PATCH, the lessor known ones.
- How would you design the API endpoint to create this <resource>?
- Give the candidate an example of a simple resource.
- This question is to see if the candidate has ever designed any REST API by him/herself.
- Expect the candidate to suggest the request and response format.
- Expect the candidate to handle different kind of errors with proper HTTP codes.
- (intermediate) What is OAuth2?
- OAuth2 is a very common protocol used by many 3rd party APIs for authorization.
- Expect the candidate to explain the protocol with the help of a diagram.
- There are many different types of OAuth2 implementation. The candidate can explain one he/she knows.
- How to optimize a slow API query?
- There are many ways to profile and improve the performance of an API.
- Expect the candidate to discuss common bottlenecks, and the methods to overcome them. E.g. indexing, reducing number of trips to db, caching, etc.
- How do you send a response to the client on an event that originated from the server?
- A tricky question to test the candidate’s knowledge of what lies beyond HTTP.
- Expect the candidate to discuss possible techniques, the pros and cons of each.
- (advanced) Name and describe as many HTTP request headers as you can?
- This is an advanced question to test the candidate’s knowledge of the HTTP protocol.
- Normally only senior software engineers who have worked on open-source projects related to web frameworks will memorize the details.
- Expect the candidate to know some of the common ones on top of his/her head: e.g. Accept, Cache-Control, Cookie, Content-Type, User-Agent.
- How should you store users’ login passwords in your db?
- This is about a basic security practice that all web application developers should know.
- Expect the candidate to mention a secure hashing algorithm. Experienced candidate will mention random salting, or having a separate server and data store just to handle authentication.
- Red flags: the candidate does not care about this and trusts the web framework will handle it correctly. The truth is, passwords do get cracked and leaked to the open after hacks, in spite of the prevalence of web frameworks nowadays.
- What common web application vulnerabilities do you know?
- These concerns are unfortunately easily neglected during the early stage of product development. They will become very difficult to catch in the later stage. It is advisable if your developers know about them early.
- Expect entry-level engineers to mention cross-site request forgery. Intermediate engineers will know more, such as cross-site scripting, SQL injection, broken authentication or authorization for resource access, etc. Advanced engineers will know the measures to reduce or prevent these vulnerabilities.
- What will you do to secure a Linux/Windows server?
- The above two questions are about public-facing web application servers. If you are hiring someone to work on backend services instead, you can use this question.
- Expect the candidate the discuss the good practices, e.g. SSH authentication, password policy, firewall, regular security updates, etc.
- This discussion can be extended to cover the VPC setup in the cloud.
- (advanced) Look at <your competitor>/<a key feature of your product> for a few minutes, tell me how would you architect the backend system/feature?
- I recommend adding a system design question near the closing end of the interview, after the candidate has shown promising potential in answering all the other questions. A good system designer is in line to be promoted to software architect role of your team.
- This is an open-ended question and the candidate is expected to lead the discussion. Expect him/her to gather requirements and scope the problem, ask questions to clarify use cases and constraints, discuss assumptions.
- Give him/her a whiteboard to sketch the high-level design which contains the main components and their connections.
- If you have time, give him/her a hypothetical bottleneck in the design, ask him/her to provide a solution to scale up/out.
- Daniel Miessler, Information Security Interview Questions.
- donnemartin, Github, The System Design Primer.
- kamranahmedse, Github, Backend Roadmap.