A good interview question is not necessarily a difficult question. Questions should test whether a candidate has memorized a definition or a standard answer. A better question starts a conversation. It gives the candidate an opportunity to explain how they think, why they made a particular decision, and how well they actually understand the technology they are working with.
This is especially useful when interviewing freshers. A fresher may not have years of production experience, but they should be able to explain the projects they have worked on, reason through a problem, and work their way through something they haven’t seen before.
Here are 10 good interview questions that can help reveal that.
Q: Tell me about a project you built. What part did you personally work on?
This is one of the simplest questions an interviewer can ask which can reveal surprising amount about a candidate.
Freshers often have projects listed on their resumes, but simply having a project on a resume doesn’t tell you how much the candidate actually understands about it. Asking what they personally worked on makes the conversation much more specific.
Once the candidate explains their part, the interviewer can follow up with:
Interviewer: “Why did you choose that approach?”
A candidate who genuinely worked on the project should be able to explain the decisions they made, the problems they encountered, and possibly what they would do differently today. Don’t expect it to be technically accurate. What matters is whether the candidate can clearly explain their own work and the reasoning behind it.
Q: What happens when you enter a URL in your browser and press Enter?
This is a common interview question, but it becomes much more useful when it is treated as the beginning of a conversation rather than a question with one expected answer.
A fresher might start by explaining DNS and how the browser finds the server associated with the domain. From there, the discussion can move toward the network connection, HTTPS, the HTTP request, the server response, and finally how the browser receives and renders the page.
The interviewer can then ask:
Interviewer: “Where could this request fail?”
That single follow-up can reveal much more than the original question. The candidate might talk about DNS problems, network failures, certificate issues, server errors, timeouts, or problems on the application side.
The point isn’t to see whether the candidate can remember every step perfectly. It is to understand whether they have a reasonable mental model of what happens when a web application is accessed.
Q: Suppose an API you built suddenly becomes slow. How would you find out what’s causing it?
This question is less about knowing a particular monitoring tool and more about understanding how the candidate approaches a problem.
A weak answer might immediately suggest increasing the server size or rewriting the API. A stronger answer starts by asking what changed and where the delay might be coming from.
- Is the problem happening for every request or only certain requests?
- Is a database query taking too long?
- Is another service responding slowly?
- Has the amount of data increased?
- Is the application using too much CPU or memory?
The interviewer can then ask:
Interviewer: “What would you check first?”
The interviewer isn’t expecting a fresher to have already operated a large production system. The goal is to see whether they can break an unfamiliar problem into smaller possibilities and investigate them logically rather than simply guessing at a solution.
Q: What happens if the same API request reaches your server twice?
This is a useful question because many candidates understand how to create an API but haven’t thought much about what happens when requests don’t arrive exactly once.
Imagine an API that creates an order. The client sends the request, but the response never reaches the client. The client doesn’t know whether the order was actually created, so it sends the same request again. Now there are two requests. Should the server create two orders?
This can naturally lead to a discussion about retries, duplicate requests, and idempotency.
The interviewer can make the situation more interesting by asking:
Interviewer: “What if the request creates a payment?”
The candidate doesn’t need to know every term immediately. What matters is whether they can reason about the consequences and think about how the system should behave when the same operation is attempted more than once.
Q: Your program works for 10 users but becomes slow with 10,000 users. What would you look at?
This is a simple way to introduce scalability into an interview without turning the discussion into a full system-design interview. It questions candidates on what might become a bottleneck. They might consider database queries, network calls, memory usage, CPU usage, inefficient algorithms, or too many requests being handled at the same time.
The interviewer can then ask:
Interviewer: “How would you find the actual bottleneck?”
That follow-up is important because it moves the conversation away from guessing and toward measurement and investigation.
A fresher isn’t expected to have personally handled an application with 10,000 users. What the interviewer wants to see is whether the candidate understands why software that works well at a small scale may behave differently when the workload increases.
Q: Your code works on your machine but fails in production. How would you debug it?
Almost every developer eventually encounters some version of the “works on my machine” problem.
The useful part of this question is not the phrase itself, but what the candidate does next. Do they immediately start changing the code, or do they first try to understand what is different between the two environments?
A good answer might start by comparing configuration values, environment variables, dependency versions, database connections, external services, and application logs.
The interviewer can follow up with:
Interviewer: “What information would you want before changing the code?”
This can reveal whether the candidate’s instinct is to investigate first or immediately start making changes. Even for a fresher, having a structured debugging approach is often more valuable than knowing a long list of debugging commands. Once again, don’t expect freshers to answer perfectly.
Q: Why did you use this technology in your project?
This is particularly useful when a candidate has listed several technologies on their resume. Suppose a project uses React, Node.js, PostgreSQL, and a cloud service. The interviewer can pick one and simply ask:
Interviewer: “Why did you use this?”
There isn’t necessarily one correct answer. The candidate might have chosen a technology because it was familiar, because it suited the project, or because they wanted to learn it. Any of those can be reasonable if the candidate can explain the decision honestly.
The interviewer can then ask:
Interviewer: “What would you use instead if you had to build it again?”
This follow-up is useful because it tests whether the candidate understands the technology well enough to compare it with alternatives, rather than simply adding a popular technology to a project because it appears frequently on job descriptions.
Q: What happens if an API depends on another service and that service goes down?
Modern applications rarely work completely on their own. An API might depend on a database, payment provider, authentication service, or another internal API. So what happens when one of those dependencies stops responding?
A fresher may start by saying that the API will fail. That’s a reasonable starting point. The interviewer can then ask what the application should do about it.
- Should it immediately return an error?
- Should it retry?
- How many times should it retry?
- Should it wait for the dependency to recover?
- What should the user see while this is happening?
The interviewer can take the discussion one step further:
Interviewer: “How would you prevent one failing service from causing problems for the whole application?”
This can introduce concepts such as timeouts, retries, and graceful failure without requiring the candidate to have already worked on a large distributed system. As an interviewer be ready to accept simple answer and as a fresher, remember that the interviewer understands your experience and will be understanding if your answer is not 100% accurate/technical.
Q: Here’s a small piece of code. What would you change?
Not every coding interview needs to begin with “Write a program to reverse a string.”
Showing a candidate a small piece of existing code can produce a very different and often more useful conversation. Instead of testing whether they can write something from scratch, the interviewer can see whether they can read code, identify potential problems, and explain possible improvements.
The code might contain duplicated logic, unclear variable names, unnecessary work, or an obvious performance issue.
The interviewer can then ask:
Interviewer: “Why would your change make it better?”
That second question matters. A candidate might suggest a change simply because they have seen someone else write code that way. Asking ‘why’ reveals the reasoning capabilities of the candidate.
Q: I don’t think your approach works well. Can you explain me why do this?
Use this question with Caution. This isn’t really a technical question. Might not be suitable for all freshers and all roles. But should be used sparingly when interview is going on well at a conversation pace. I included it because I have used this question while interviewing developers with few years experience. But as an interviewer, if you find a suitable candidate, please do ask and share your experience with me.
Developers regularly have to explain technical decisions to other developers, managers, and stakeholders. Sometimes another person will disagree with an approach even when the developer believes it is correct.
An interviewer can intentionally challenge the candidate’s answer and see what happens.
- Does the candidate explain their reasoning?
- Do they consider the other perspective?
- Can they acknowledge a weakness in their approach?
- Are they willing to change their position when presented with new information?
The interviewer can follow up with:
Interviewer: “What would make you change your mind?”
There is no value in trying to “win” the discussion. A strong candidate should be able to defend a technical decision without becoming defensive about it, while also being open to the possibility that another approach might be better.
Personal note
What makes these above questions good?
None of these questions requires the candidate to memorize a complicated definition. More importantly, most of them don’t really end with the first answer.
For freshers, this is also an important lesson about preparing for interviews. Start with self intro(read self intro for freshers) and don’t prepare only answers. Understand your projects.
Interviewer is just trying to understand you would react. I certainly watch candidates’ reactions to understand about them. Here are some more frequently asked questions in interview for freshers to learn more.
And when you don’t know something, don’t try to hide it with a memorized answer. Explain what you do know and show how you would approach finding the answer.
A good interview is not simply a test of how many technical questions a candidate can answer correctly. It is a conversation that helps the interviewer understand how the candidate thinks, and helps the candidate demonstrate what they actually understand.