One of the most memorable moments in my career wasn’t when I gave a brilliant answer in an interview.
It was when I admitted that I didn’t know something.
That probably sounds like the last thing you should do in a technical interview.
After all, most of us walk into interviews believing our job is to convince the interviewer that we know everything they’re about to ask.
For a long time, I believed that too.
Then one interview changed my perspective.
The Question I Couldn’t Answer
During a technical discussion, the interviewer asked me how I would implement an edge prediction solution using machine learning on Neo4j.
Now, the interesting part was this.
I knew graph theory.
I understood what edge prediction was trying to achieve.
I was familiar with the machine learning techniques that could be used.
I knew how I would engineer features and evaluate the model.
But there was one problem.
I had never worked with Neo4j.
Not once.
So for a brief moment, I had a choice.
I could try to bluff my way through.
Or I could simply say what was true.
I Chose the Slightly Uncomfortable Answer
I said something along the lines of:
“I haven’t worked with Neo4j before, so I don’t know its APIs or implementation details yet.”
And then I continued.
“But here’s how I would approach the problem.”
Instead of pretending I knew the software, I explained the problem from first principles.
I spoke about representing entities as nodes and relationships as edges.
I discussed why edge prediction is useful in recommendation systems, fraud detection, and knowledge graphs.
I described the features I would consider, the machine learning algorithms I’d evaluate, and how I’d validate the model.
Then I finished with something equally important.
“The graph concepts are already familiar to me. Learning Neo4j is primarily learning a new tool, and I’m confident I can pick that up quickly.”
I wasn’t trying to avoid the question.
I was separating what I knew from what I hadn’t learned yet.
Something Interesting Happened
The conversation didn’t stop.
In fact, it became more engaging.
The interviewer asked follow-up questions.
We discussed trade-offs.
We explored different approaches.
The discussion shifted away from whether I knew a specific software package and toward how I thought about solving problems.
That was the moment I realized something.
Interviewers are often evaluating your reasoning, not just your memory.
Knowing a tool is valuable.
Knowing why you’re using that tool is even more valuable.
The Trap Many Students Fall Into
I completely understand why students feel pressured to bluff.
You’ve spent months preparing.
You’ve solved hundreds of coding problems.
You finally get the interview you’ve been waiting for.
The last thing you want to say is:
“I don’t know.”
So people start filling the silence.
They vaguely mention technologies they’ve only heard about.
They guess APIs.
They invent terminology.
They hope confidence will somehow compensate for uncertainty.
Ironically, it usually has the opposite effect.
Experienced interviewers can often tell the difference between someone who genuinely understands a topic and someone who is trying to reverse-engineer an answer on the spot.
”I Don’t Know” Is Only Half the Answer
That doesn’t mean you should stop at:
“I don’t know.”
That is a weak answer.
A much stronger answer is:
“I haven’t used this particular software, but here’s how I’d think about solving the problem.”
Notice the difference.
One ends the conversation.
The other begins it.
You’re showing the interviewer two things at once:
- You’re honest enough to admit your gaps.
- You’re capable of reasoning through unfamiliar situations.
Those are qualities every engineering team values.
Tools Change. Fundamentals Last.
Looking back, Neo4j was almost incidental.
If it hadn’t been Neo4j, it could have been another graph database.
Or a cloud platform.
Or a new framework.
Or a library I’d never touched before.
The technology industry changes too quickly for anyone to know every tool.
What’s far more important is understanding the concepts underneath.
If you understand graphs, learning a graph database becomes much easier.
If you understand distributed systems, learning a new messaging platform is manageable.
If you understand machine learning, switching libraries is usually far less difficult than learning the underlying mathematics from scratch.
That’s why strong fundamentals compound throughout your career.
Something I Appreciate More Now
A few years later, after sitting on the other side of the interview table, I’ve come to appreciate honest answers even more.
When a candidate confidently claims expertise in something they clearly don’t understand, the interview usually becomes uncomfortable for everyone involved.
But when someone says:
“I haven’t worked with that before, but here’s how I’d approach it.”
…it immediately changes the tone of the conversation.
Now we’re discussing engineering instead of playing a guessing game.
And that’s a much better use of everyone’s time.
Looking Back
I don’t remember whether Neo4j appeared anywhere in the final role.
What I do remember is the lesson that interview left me with.
Confidence isn’t pretending to know everything.
It’s knowing where your knowledge ends without letting that stop your thinking.
The software I didn’t know eventually became something I could have learned in a matter of days.
The ability to think through an unfamiliar problem was the part that mattered.
And fortunately…
…that was already in the room.
You don’t need to know every tool before you apply for a job.
You do need to understand the ideas well enough to explain how you’d solve the problem—and be honest about the parts you haven’t learned yet.
The best candidates aren’t the ones who never say “I don’t know.” They’re the ones who know exactly what comes after it.