I’ve sat in on a lot of interviews from the recruiter’s side of the table, and here’s something I’ve seen more than once:
A hiring manager asks a candidate about something they don’t know. And you can almost watch the candidate decide what to do next. Some people start talking in circles. Some try to connect the question to something they do know. And some just start making things up.
I get it. Nobody wants to look like they don’t know something in an interview. But I’ve always thought there was something valuable about being able to say, “I don’t know.”
So when I spoke with Bruce, a QA leader, and he told me not only is that also his mindset but that he actually uses his interviews as a signal for what he should learn next. I thought that was pretty interesting.
I’ve heard plenty about people preparing for interviews. Study the company. Review the job description. Brush up on the technologies. Use AI to fill in gaps. But I hadn’t really heard someone describe the interview itself as the trigger for upskilling.
So naturally, I asked him why.
The Interview as a “Hot Wash”
Bruce is an Air Force veteran, and he connected his approach to something from his military experience called a “hot wash.”
The basic idea is pretty simple. After an operation, you review what happened. What went well? What didn’t? What could have been done differently? And what are you going to do differently next time?
Bruce has carried that mindset into interviewing. If he gets asked something he doesn’t know, he doesn’t see that as a failure. He sees it as a signal.
He told me that one thing that used to bother him in face-to-face interviews was watching candidates dream up answers when they didn’t know something.
His mentality is different: “I don’t know, but I can get that to you.”
And then he actually does.
One example he gave me was PostgreSQL.
Bruce recently had an interview where he was asked about PostgreSQL and didn’t have a good answer. That wasn’t because he didn’t understand databases. His experience goes back years and includes Oracle, Sybase, SQL Server and MySQL. PostgreSQL simply hadn’t been part of his working environment.
So instead of trying to pretend he knew it, he said he wasn’t sure. Then he went and started learning it.
And he didn’t just read a few articles so he could answer the question next time.
He installed PostgreSQL locally, set up pgAdmin, created a database and built tables. He worked through primary and foreign keys and even deliberately violated referential integrity to see how PostgreSQL would respond. Then he started comparing what he was seeing to the relational database concepts he already understood.
That part caught my attention because at some point, this stopped being about “learning PostgreSQL because I got asked about PostgreSQL in an interview.” It became about understanding the technology well enough to evaluate it.
Another ex: Bruce built a platform he calls CareerOps, a custom application he created with AI to manage and track his own job search. Bruce’s CareerOps platform currently runs on MySQL, and he isn’t suddenly throwing that away because he spent a week learning PostgreSQL. Instead, he’s looking at PostgreSQL as a potential architectural option. His plan is to build a PostgreSQL environment alongside the working MySQL implementation using the same business domain and a representative data model.
Then, if he gets to the point of considering a migration, he can validate it like an actual engineering initiative: data integrity, record counts, PK/FK relationships, API behavior, regression automation, performance and rollback.
And that, to me, is the bigger lesson.
Knowing what you don’t know isn’t the problem. Not knowing how to approach what you don’t know is. A strong QE doesn’t necessarily know every tool, framework or technology that might come up in an interview. They know how to investigate. They know how to experiment. They know how to validate. They know how to determine whether something actually fits the problem they’re trying to solve.
And that’s Quality Engineering.
If you’re on the job hunt I suggest checking out what he built: https://democareerops-platform.com/
Then I Started Thinking About the Interview Itself
The other part of our conversation got me thinking about something completely different.
What happens when the interview process itself isn’t giving the candidate enough context?
In Bruce’s PostgreSQL example, once he said he hadn’t worked with it, the conversation ended. And I couldn’t help but wonder: Why didn’t the recruiter ask any follow-up questions? Was PostgreSQL actually a hard requirement?
If it was, okay. That’s useful information. But if the goal was to understand his database experience, there were clearly other questions they could have asked. He had years of experience with relational databases. Why not explore that? Were they testing whether he had worked with a very specific technology? Or were they trying to understand how he approaches a technical problem?
Those aren’t necessarily the same thing.
He gave me another example he had based off an interview for a leadership role. The position was focused on leadership and mentoring a team. No coding exercise had been communicated ahead of time.
Then he gets into the interview, is asked to share his screen, and suddenly he’s writing code.
I can understand evaluating technical depth for certain leadership roles. But if you’re going to ask someone to write code, shouldn’t the candidate know that’s part of the process? What exactly are you trying to learn from the exercise? Does that exercise actually reflect what this person will be doing in the job?
To my recruiting peers please keep in mind that an interview can be “technically difficult” and still be a bad assessment.
Context Matters More Than We Give It Credit For
This actually reminded me of an interview I had for a recruiting position. One of the first questions I was asked was essentially, “How do you create recruiting strategy?”
And I remember thinking, that’s a loaded question. What are you actually trying to understand? Are you asking about sourcing? Workforce planning? Technology? Stakeholder management? Process?
How can I give you the most relevant answer when I don’t know how you run shop or what problem you’re asking me to solve?
I didn’t have enough context to truly answer the question. And clearly based off my conversation with Bruce, this happens within IT hiring too.
If you want to evaluate someone’s ability to solve a problem, you have to give them enough context to understand the problem.
Otherwise, you’re partly evaluating their ability to guess what you want to hear. And I don’t think that’s what most hiring managers actually want to measure.
What I Took Away as a Recruiter
This conversation gave me a few things to think about in my own work.
The first is probably the most obvious: understand what the company is actually asking for and put fences around it. Do I have a list of 30 items on it I need to check off that almost reminds me of hiring an entire IT dept? If my manager gives me list of “helpful, but not required”, what does that really mean? In what way would it be helpful and is it going to truly prevent the candidate from succeeding?
I think the more you understand about your clients project scope, what they want to accomplish and the current engineering team (makeup, strengths, any skill gaps etc) will really help you flesh out some of these questions. If we don’t understand what the company actually needs, we’re going to send candidates into interviews that don’t make sense either.
The second is that recruiters don’t need to pretend to be engineers.
We do, however, need to understand enough about the role to ask better questions, identify unrealistic requirements and know when we need an engineering leader involved in the evaluation. I would much rather partner with an engineering leader to properly understand a role than pretend I can independently assess technical depth I don’t have.
So…maybe having a candidate tell you, “I don’t know,” isn’t really a bad response after all.
A nod to Bruce for the all information he provided me. Check out his Github: https://github.com/MIBoy54