One of the most uncomfortable parts of interviewing isn’t rejecting weak candidates.
It’s rejecting good ones.
The kind who clearly worked hard.
The kind who solved coding questions confidently.
The kind you genuinely wanted to succeed.
Recently, I interviewed one such candidate.
When the interview ended, I remember thinking:
“This person knows how to write code.”
And yet…
I still couldn’t recommend a hire.
That decision stayed with me for a long time.
On Paper, Everything Looked Excellent
The candidate had what many students would consider an impressive profile.
Several technical projects.
Good understanding of programming fundamentals.
Comfortable with common coding interview questions.
Clean code.
Structured thinking.
When I asked them to solve a problem, they did it confidently.
There wasn’t much hesitation.
There weren’t many hints required.
If the interview had ended there, it probably would’ve been an easy recommendation.
But interviews rarely end there.
Then I Asked a Different Question
Once we had finished discussing the coding problem, I asked something that wasn’t particularly technical.
“Can you think of a real-world problem where you’d actually use this?”
There wasn’t a right answer.
I wasn’t looking for a billion-dollar startup idea.
I wasn’t expecting a business case.
It could have been anything.
Something that annoyed them in college.
A repetitive task at home.
An inconvenience during internships.
A problem they had personally experienced.
Anything.
Instead…
There was a long silence.
Eventually they said,
“I haven’t really thought about it.”
So We Looked at Their Projects Instead
That’s perfectly fine, I thought.
Surely the projects would tell the story.
There were quite a few of them on the resume.
A recommendation system.
A chatbot.
A machine learning model.
A web application.
A couple of other technical projects.
So I picked one and asked a simple question.
“Who would actually use this?”
The answer focused entirely on the technology.
The framework.
The model.
The architecture.
So I asked another.
“Imagine I’m your user. Why would I open this application?”
Again, the explanation revolved around implementation.
Not the problem.
Not the user.
Not the outcome.
After a few more projects, a pattern began to emerge.
The candidate had become very good at building software.
But they had almost never stopped to ask why that software should exist.
That’s When I Made My Decision
It wasn’t because the candidate lacked technical ability.
Quite the opposite.
I was convinced they could learn new frameworks.
I was convinced they could contribute code.
But I wasn’t yet convinced they naturally started with problems.
And over time, I’ve come to believe that’s the more valuable instinct.
Because here’s something you’ll discover very quickly after joining the industry.
Nobody walks up to an engineering team and says,
“Can someone implement Dijkstra’s algorithm?”
Or,
“We really need a balanced binary tree this quarter.”
Instead, they say things like:
- “Customers are abandoning checkout.”
- “This report takes three hours to generate.”
- “We’re seeing too many fraudulent transactions.”
- “Students keep missing assignment deadlines.”
- “Employees are filling the same form twice.”
Those are the problems.
Everything else comes later.
Somewhere Along the Way…
I think we unintentionally trains ourselves to work backwards.
We learn a new algorithm.
Then we look for somewhere to apply it.
We learn a framework.
Then we build a project using that framework.
We learn machine learning.
Then we ask,
“What dataset can I train a model on?”
Industry usually works in the opposite direction.
Someone brings you a messy, ambiguous problem.
Then you decide whether it needs machine learning.
Or a web application.
Or a database.
Or perhaps…
No software at all.
The technology is rarely the starting point.
It’s the consequence.
One Habit I Wish More Students Developed
Whenever you learn something new, don’t stop after understanding how it works.
Ask yourself one more question.
“Who would genuinely benefit from this?”
If you learn image recognition…
Could your college security team use it?
If you learn graph algorithms…
Could they help students discover alumni connections?
If you build a chatbot…
Who actually needs it?
If your answer is,
“I built it because it looked good on my resume.”
…that’s probably worth thinking about.
The Projects I Remember Most
I’ve interviewed candidates with incredibly sophisticated projects.
Distributed systems.
AI applications.
Complex architectures.
Some were genuinely impressive.
But do you know which projects I remember months later?
The simpler ones.
The attendance tracker someone built because professors still used paper registers.
The budgeting app someone created because they kept overspending every month.
The timetable generator that solved scheduling conflicts in their department.
Technically, they weren’t always the most advanced.
But they started with a real problem.
That made every engineering decision feel intentional.
A Small Shift in Thinking
If you’re still in college, here’s something I’d encourage you to try.
The next time you learn a new technology…
Don’t immediately ask,
“What project should I build?”
Instead ask,
“What problem around me keeps annoying people?”
Look around your hostel.
Your classroom.
Your family.
Your internships.
Your society.
Your own daily routine.
You’ll probably find dozens of problems long before you run out of technologies.
And once you’ve found a genuine problem…
The technology almost chooses itself.
Looking Back
I still remember that candidate.
I genuinely hope they went on to have a successful career.
Because they were smart.
Hardworking.
Capable.
This field note isn’t about them.
It’s about a lesson I wish someone had taught me much earlier.
Software isn’t valuable because it’s technically impressive.
It’s valuable because it improves someone’s life, saves someone’s time, reduces someone’s frustration, or helps someone make a better decision.
Everything else—frameworks, algorithms, architectures—is simply how we deliver that value.
The strongest engineers don’t fall in love with code.
They fall in love with solving problems, and code becomes one of the many tools they use to do it.
The best interview answers rarely begin with technology. They begin with a problem worth solving.