What Years of Interviewing Developers Taught Me • Debjit's Digital Home

The last person I hired was rejected by the earlier panel, they couldn’t write basic programs. We still brought them on for a frontend role. It didn’t work out in that position, but instead of letting them go, we found a different role where they could contribute. It was a gamble I was willing to take. I believed in them and gave them all the support I could, and I’m happy to say that today, a few years later, they’re doing really well, even learning programming in their own way.

A few years ago, I never would have hired them. Back then, my interviews were heavily weighted toward knowledge and skills. Now, I see the most important ability is the capacity to learn. This person had one standout strength: they could take a problem, dive deep, and learn whatever was needed to solve it. For me, that’s non-negotiable, and in some cases, like this one, it’s also sufficient.

This decision wasn’t luck, and it wasn’t a sudden change in my thinking. It was the outcome of years of learning, experimenting, and refining how I interview. Along the way, I made mistakes, adjusted, and slowly arrived at a style that works for me, my team, and the candidates.

Here are the principles that now guide me whenever I interview a developer.

Part 1: The Principles

1. Question Design

Always test theoretical knowledge using practical examples, rather than asking the question directly.
Use real world problems from your experience but create minimal examples from them.
For DSA questions:
- Only ask ones directly related to your current or past codebase.
- Use real utilities or scenarios your team has encountered.
- If you’ve never used it in your work, you have no right to ask it.

2. Evaluating Learning Ability

Find out what they know, not what they don’t know.
Prioritise checking for both learning and unlearning capability.
Ask about what they have tried on their own, projects, problems faced, solutions attempted.
Discuss their approach, perspective, and what they learned.
Extend their problem scenario to push them into rethinking their approach.
It is fine if the whole discussion is around just one thing they have tried to do.
Check if they can extend or adapt their knowledge in real-time when given new constraints.

3. Atmosphere & Experience

Keep the discussion friendly, engaging, and conversational.
Never assert superiority, even if you’re far more experienced.
Make the session a learning experience, so they take back knowledge even if not selected.
The candidate must leave with a positive experience regardless of the outcome.
Offer unlimited water and/or refreshments during the discussion.
Give them a tentative timeline for when they’ll hear back from the organisation.

4. Live Coding Policy

Avoid live coding if possible or keep it minimal.
If necessary:
- Provide the same resources you would use yourself, laptop, proper editor, internet access, and AI tools if you use them.
- Allow them to work alone for a while if the task is complex.

5. Time Management

Try not exceed 1 hour for the core interview.
For juniors and freshers, aim for 30 - 45 minutes.
Don’t be impatient, it’s just 60 minutes.

6. Post-Interview Reflection

Do not evaluate or decide during the discussion, just gather information.
Spend time alone afterwards thinking:
- “Will my team be able to work with them?”
- “Can this person learn and grow with us?”
Avoid talking to others before your own reflection.
Immediately after the interview:
- Write down your gut feeling in a few key points.
- Score them on broad categories agreed upon by the team (e.g., problem-solving, adaptability, communication, collaboration).
- For each parameter, note both the score and the reason for it.
- The purpose is not objectivity (which is impossible), but to understand where your overall yes/no feeling comes from.
This reflection should be done immediately after the interview.

7. Overall Goals

Maintain awareness of the context: the role, your team, your organisation.
End with:
- A clear sense of how the candidate will operate in the team.
- How they will handle the kinds of problems you face.
- Clear signals on problem-solving, adaptability, communication, and collaboration style, with reasons for each.

Part 2: My Journey

All the insights you read above were not something I developed in one sitting. I did not wake up one day and think that I must improve my interviewing skills. These insights come from years of practice, and for most of that time, I was not doing it right, nor was I efficient.

The First Time

I don’t remember much about my first time, but I do remember that the person we thought performed really well turned out to be the weakest hire, and the one who struggled the most turned out to be much better. The good news was that all three people we hired that day were hardworking, dedicated, and wanted to learn, even though the interview was not well designed for these parameters.

A Learning Moment

The next interview I did was around 1.5 to 2 years after the first one, and it was most probably a telephonic one with another colleague. Afterwards our architect asked us, “What did you like about them?” I was at a loss for words. Since that day, I have focused on what the candidate knows, rather than what they don’t. This shift has worked well.

As I gained more experience, the interviews started becoming longer and more elaborate, sometimes running for hours. I would keep going as deep as I could, and not only for one topic, but many of them. Then, I began giving candidates coding exercises, starting with paper and later providing laptops for them to use. As time progressed and my job responsibilities increased, I found myself unable to extend the interviews. Others started doing the initial rounds, but often there was just a single round of interviews, and it was me who had to decide. This meant I had to change my style; I had to optimize the process. Long problem-solving and coding sessions were not possible.

A New Approach

That’s when I began a new approach. Begin with their previous job or any personal projects, then ask more probing questions. I wanted to understand how well they could learn on their own, how deeply they had explored their work, and how curious they were. Working in a small team, the ability to self-learn was more important than prior knowledge or raw coding skills. I optimized for that one quality.

One area where I am still working to improve is documenting my decisions along with the reasons for them immediately after the interview.

Empathy First

Finally, be empathetic. You don’t know what their day has been like or what other problems they are facing in life. Do not add to their stress. If they don’t fit the role, it’s fine not to hire them, but make it a positive experience they’ll remember.