Software Developer Interview Questions for Hiring Managers

Most teams do not lack software developer interview questions. They lack a structure. One interviewer asks puzzle questions, another asks about a favourite framework, a third chats about cricket for forty minutes, and at the end nobody can compare the candidates. This guide gives hiring managers in Indian companies a question bank organised by interview round, explains what a strong answer looks like for each, and shows how to score candidates so that the final decision is based on evidence rather than gut feel. It works for backend, frontend and full stack roles with small adjustments.

Plan the Interview Loop Before Picking Questions

Questions only make sense inside a loop where each round tests something different. A common and effective loop for a mid-level developer looks like this:

Round	Duration	What it tests	Who runs it
Recruiter screen	20 to 30 min	Basics, CTC, notice period, motivation	Recruiter
Technical fundamentals	45 to 60 min	Language knowledge, data structures, problem solving	Senior developer
Practical exercise	60 to 90 min or take-home	Writing real code, testing, structure	Two developers
System design or deep dive	45 to 60 min	Design thinking, trade-offs, past ownership	Tech lead or architect
Hiring manager	45 min	Collaboration, ownership, communication, fit with the role	Hiring manager

For juniors, drop the system design round and lengthen the fundamentals round. For senior engineers, the deep dive into past work usually tells you more than any puzzle. Before the loop starts, assign each round a short list of competencies so interviewers do not overlap. If you have not built a scorecard yet, start with our interview scorecard template.

Technical Fundamentals Questions

These questions check whether the candidate understands the tools they claim on their resume. Ask them in the candidate's primary language.

Language and runtime

1. Explain the difference between a process and a thread. When would you use each? Good answers mention shared memory, isolation and the cost of context switching, with a real example from their work.
2. In [Java / JavaScript / Python], how is memory managed? What causes a memory leak in a garbage-collected language? Look for references held longer than needed, caches without eviction, listeners that are never removed.
3. What happens between typing a URL in a browser and seeing the page? A classic, but still useful. Strong candidates cover DNS, TCP, TLS, HTTP request, server processing and rendering, and can go deeper wherever you probe.
4. Explain how async code works in your main language. For Node.js, the event loop. For Java, threads and futures. Watch for candidates who can describe it but have never debugged a race condition.

Data structures and problem solving

1. Given a list of 10 lakh orders, how would you find the top 10 customers by total spend? Look for hashing to aggregate, then a heap or sorting, and a sensible discussion of memory if the data does not fit.
2. How would you detect duplicate invoices uploaded by different users? Tests whether they think about normalising data before comparing.
3. When would you choose a hash map over a sorted structure? Good answers discuss lookup speed versus range queries and ordering.

Databases

1. What is an index and when can adding one make things slower? Strong answer: writes become slower, indexes take space, low-selectivity columns gain little.
2. Explain transactions and isolation levels with an example of what goes wrong without them. Look for a concrete example such as two users booking the last item in stock.
3. Write a query to find customers who ordered in January but not in February. Tests joins, subqueries or set operations.

Practical Coding Exercise Questions

A realistic practical exercise predicts job performance better than abstract puzzles. Keep it close to the work the developer will actually do.

Example exercises

• Backend: build an API that accepts orders, validates stock, and returns a clear error when stock is insufficient. Include tests.
• Frontend: build a searchable, paginated product list that calls a given API and handles loading and error states.
• Full stack: a small expense tracker with a form, a list and a monthly total.

Follow-up questions after the exercise

1. What would you change if this had to handle 100 times the traffic?
2. Which part of your code are you least happy with, and why?
3. How did you decide what to test?
4. If a user reported that totals were wrong by a few rupees, where would you look first?

The follow-up conversation is often more revealing than the code. A candidate who can critique their own work honestly is usually easier to work with than one who defends every line.

Take-home or live?

Take-home exercises reduce pressure and show realistic code, but they take candidates' evening time, and long ones cause dropouts. Keep take-homes to about two to three hours of effort and always discuss them live afterwards. Live exercises are faster but favour people who perform well under observation. Many teams offer the candidate a choice.

System Design and Deep Dive Questions

For mid and senior developers, design questions show how the candidate thinks about trade-offs.

1. Design a URL shortener for a marketing team sending 50 lakh SMS links a month. Look for ID generation, storage choice, redirect speed, analytics and abuse prevention.
2. Design the notification system for an app that sends order updates by SMS, email and WhatsApp. Good answers separate the business transaction from notification delivery, use a queue, and handle retries and provider failures.
3. How would you design billing for a store with 30 counters that must keep working when the internet drops? Tests offline-first thinking, sync and conflict resolution.
4. Tell me about a system you built or owned. Draw it. Then probe: why this database, what broke in production, what would you do differently.

In the deep dive, ask for specifics. "We improved performance" should become "the report went from 40 seconds to 3 seconds because we added a composite index and moved aggregation to a nightly job." Vague answers across several probes often mean the candidate was near the work but not doing it.

Debugging and Production Questions

Developers spend a large share of their time reading and fixing code, yet few interviews test this.

1. The API was fast yesterday and is slow today. Nothing was deployed. How do you investigate? Look for a method: check data volume, database load, external dependencies, logs and metrics, then narrow down.
2. Here is a 40-line function with a bug. Find it. Give them real code with an off-by-one error or a timezone issue.
3. Tell me about the worst production incident you were part of. Look for ownership, a calm process and lessons learned, not blame.
4. How do you make sure a fix does not break something else? Tests, staged rollouts, feature flags and monitoring are all good signs.

Behavioural Questions for Developers

Technical skill does not help if the developer cannot work with others. The hiring manager round should cover these areas with past-behaviour questions.

• Collaboration: "Tell me about a time you disagreed with a code review comment. What happened?"
• Ownership: "Describe a feature you shipped that did not work as expected for users. What did you do next?"
• Learning: "What is something technical you learned in the last six months, and how?"
• Estimation: "Tell me about a task that took much longer than you estimated. Why?"
• Communication: "How would you explain a database migration delay to a sales head?"

Use the STAR structure (situation, task, action, result) to probe. When a candidate says "we," ask "what did you personally do?"

How to Score Developer Interviews

Each interviewer should score only the competencies assigned to their round, on the same scale, before discussing the candidate with anyone else.

Score	Meaning	Example for "problem solving"
1	Strong no	Could not reach a working approach even with hints
2	Leaning no	Reached a solution with significant help, unclear reasoning
3	Leaning yes	Working solution, some inefficiency, explained reasoning
4	Strong yes	Clean solution, discussed trade-offs and edge cases unprompted

A four-point scale avoids the comfortable middle score. Weight the competencies that matter most for the role; for a backend role, system design and code quality might carry more weight than frontend knowledge. Fininvo Recruit supports structured interview scorecards with weighted criteria, which makes comparing finalists side by side straightforward.

Common Mistakes When Interviewing Developers

• Trick puzzles: brain teasers measure puzzle practice, not job performance.
• Testing memorised syntax: developers look things up every day. Test reasoning instead.
• Same questions in every round: repetition wastes the candidate's time and gives you less evidence.
• Unprepared interviewers: an interviewer reading the resume for the first time in the meeting signals disorganisation to the candidate.
• Slow feedback: when feedback takes a week, good developers accept other offers. Aim to submit scores within 24 hours.
• Personal questions: avoid questions about marriage plans, family, religion or age. They are not relevant and can create legal and reputational risk.

Run Your Developer Hiring Loop in One Place

Pair this question bank with a clear job post; our software developer job description template uses the same competencies. To schedule rounds, collect scorecards and track candidates in one pipeline, see Fininvo Recruit, check Recruit pricing, or read about recruitment in Fininvo HRMS.

Frequently Asked Questions

How many interview rounds should a developer go through?

Three to four rounds after the recruiter screen is enough for most roles. More rounds rarely add new information and increase dropouts, especially among experienced developers who have other offers.

Are online coding tests useful for screening?

They help when you receive a large number of applications, such as for fresher roles. Keep them short and relevant, and do not rely on them alone, because they cannot measure collaboration or design thinking.

Should the hiring manager attend every round?

No. Spread rounds across your team so that you get independent views and avoid overloading one person. The hiring manager should run one dedicated round and lead the final debrief.

How do I interview a developer in a stack my team does not know?

Focus on fundamentals, problem solving and a deep dive into their past work. Ask them to explain their stack's design choices to you; clear explanations are a strong signal on their own.

What is a reasonable take-home assignment length?

Two to three hours of focused work is a reasonable upper limit. Tell candidates the expected effort upfront and give them at least three to four days to submit.