Here is the lesson before the story, because it is the only part that will help you: in a job interview, when you don't understand what someone is actually asking, ask. Ask for context. Ask for an example. Ask what they do day to day that made the question worth asking. I lost a job I wanted in 2019 because I answered a vague question literally instead of finding out what was behind it. Everything else had gone perfectly. That one question is the reason I am writing this.
A recruiter, a serious security company, and a job I actually wanted
Back in 2019 a recruiter reached out and said they had a role they thought I was a strong fit for. I wasn't job hunting. But the company was a computer security firm, a real one that dealt with actual threats and turned up in the local press more than once. Security has always been one of my interests, and at the time I wasn't working in it. So the idea of getting paid to do something I genuinely love to do landed hard. I put a resume together just for this.
I was Security+ certified at that point and had a lot of background in the space, but I hadn't published any of it yet. This blog already existed. What didn't exist was the body of writing that's on it now. If I'd put those articles out before that interview instead of in the years after it, there would have been a public trail of security and engineering work to point to, and that alone might have tipped things. Lesson inside the lesson: publish your work, and publish it before you need it. The recruiter submitted me, the company wanted to move forward, and the first gate was a take-home coding test.
The take-home: build a dashboard from incident log data
The job description wanted someone who could program in PHP, Go, TypeScript, or other open-source technologies. The test fit that: here is some data, log data from an incident report, build a dashboard that presents it so an analyst can read and understand it quickly. I had about three days from getting the test to the interview, and I had to code it at home and send it in for review.
This was the part I was built for. Hand me a problem and I can usually give you the architecture and the technology choices on the spot. Presenting security data so a human can actually reason about it is a thing I have opinions about, so I knew what an analyst would want to see.
Learning Go in two days
I could have shipped it in PHP in an afternoon. PHP was my primary language and had been for the better part of two decades by that point, so the dashboard itself was never going to be the hard part. But the job listed Go, and I wanted this job. So I decided to do something slightly unreasonable: write it in both PHP and Go, and submit both.
I had never written a line of Go. I knew of it, that's all. So I learned it in two days. It is a genuinely approachable language once you already know how to program, and it clicked fast. The part that made me work was the regex, and that is exactly where being a heavy regex user paid off. I lean on regex constantly in my code, and this log parsing was full of it: pulling fields out of web-log lines is bread-and-butter pattern matching. Go's engine behaves differently from what I was used to (its RE2 implementation deliberately drops things like backreferences and lookarounds in exchange for guaranteed linear-time matching), so a pattern I'd reach for elsewhere wasn't always a straight port. Knowing regex deeply is what let me adapt fast: I knew which of Go's regexp functions fit each case, and, just as important, when to drop regex entirely and reach for plain string operations instead. That last part is the real tell. Being a regex expert means knowing when not to use it.
I want to be clear about the year, because it matters. This was 2019. There was no AI writing this code for me, no model to lean on. I learned a new language and shipped a working web service in it over a weekend, by hand. You ran the server, opened the page, and the incident data was laid out the way a security person would want to read it.
If you want to see where the Docker thread in this story eventually went, the Docker cheat sheet, the container lifecycle walkthrough, how to install Docker, and even how to Dockerize a Go app (the exact Go-plus-Docker pairing from that take-home) are a small slice of what I've since written about the thing I froze on.
The best submission they got
I walked into the interview and the senior engineer who had reviewed the code more or less led with it: my submissions were the best they'd received, and the code was excellent. Two languages, both clean, the Go one written by someone who supposedly didn't know Go. That carries weight in a room full of people who take this seriously, and these people did. I'm fairly sure everyone there held an OffSec certification. I didn't, and still don't (I probably should), but I wasn't there to out-security a room of security professionals. I knew better than to try. I was there to answer their questions honestly.
Three people sat in the room. A fourth was remote, on the phone. For roughly an hour they asked, and I answered, and almost every answer landed. The people in the room kept glancing at each other and smiling, the way interviewers do when a hire is quietly becoming a decision. The person on the phone gave nothing away. I couldn't read him at all. Everything else told me this was basically done.
Then came the wrecking ball
We were at the end. Everyone was a little tired, the hour nearly up, the kind of moment where you can feel the interview wrapping. The voice on the phone, the one I couldn't read, asked the last question.
"What is your experience with Docker and Kubernetes?"
Here is the cruel part. If you look around this blog now, Docker is everywhere. I run my sites on it, I've written a shelf of articles about it, and I haven't even gotten to the interesting parts yet. But in 2019 my honest Docker experience was specific and small: I used it to stand up websites and run them. I had never touched Kubernetes. I had no reason to and no cluster to learn on. I was a web developer, and that is the work web development needed.
So when the question hit, I froze. I gave the literal, true, and thin answer: I have experience setting up and running websites in Docker. Accurate. Almost certainly not what they were looking for. And I knew it the moment it left my mouth.
What they were probably asking
Looking back, I think the question was never really "do you know the docker run flags." This was a security auditing company. What they likely wanted to know was whether I could stand up a fleet, dozens or hundreds of machines, to process data at scale or spin up infrastructure for testing, with the orchestration and automation that implies. That is what Docker and Kubernetes meant to them, in their work. It was a completely fair question for that company.
It was also foreshadowed by the take-home itself. That dashboard was a deliberately small sample: parse one batch of incident logs on a single machine. The production version of that exact work is the same parsing fanned out across many workers, chewing through data at scale, which is precisely the territory where container orchestration and Kubernetes live. The question was just asking about the scaling layer of the problem they had already handed me.
But I had to reconstruct all of that months later, from the outside. In the room the connection was sitting right in front of me and I missed it. I froze, couldn't bridge the single-machine sample to the fleet it implied, and I was genuinely tired by then, an hour deep into a steady run of questions. So I heard the literal words and answered the literal words. I never found out what was actually behind them, because I never asked.
What I should have said
What I should have done was ask one question back.
"Can you give me some context on how you mean? I use Docker daily, but I want to make sure I'm answering the thing you actually care about. Is there something specific in your workflow that this needs to support?"
That is it. That is the whole fix. Because once they'd told me "we need to orchestrate large numbers of containers for testing and data processing," I'd have had something real to work with. I could have said, plainly, that I'd done the Docker side extensively and hadn't yet needed Kubernetes, but that I pick things up fast, and offered the obvious proof: I learned the language your test was written in over a weekend and submitted the best code you received. Bring me a laptop and I'll show you right now.
Instead I let a broad question get a narrow answer, and a narrow answer reads as a small ceiling.
If you don't understand the question, ask
So that is the thing I want to hand you.
You got into that room on the strength of your skills. Someone already decided you were qualified enough to spend an hour with. When a question lands that you don't fully understand, or that feels broader than it sounds, that is not the moment to guess and hope. That is the moment to ask a qualifying question. "Can you give me an example?" "What does this look like in your day to day?" "Are you asking about X, or more about Y?"
Asking does not make you look unsure. It makes you look like someone who clarifies requirements before building, which is exactly what you'd want from anyone you hire. It buys you the context to give the answer they're actually fishing for, and if you're already most of the way there, context is often all you need to close the gap.
A couple of things I'd add to that:
- Take your time. A short pause to think is not a failure. Answering the wrong question quickly is worse than answering the right question after a beat.
- It's fine to ask for more than a beat. If a question genuinely sits outside what you've done, you can say so and offer to close the gap on your own time: "I haven't done that piece at scale yet. Let me do some reading on it and come back to you tomorrow with specifics." That is not dodging. It shows you took the requirement seriously enough to go and learn it, which is the exact behavior they're hiring for. When you're already 90 percent of the way to an offer and this is the one hang-up, one honest follow-up is often all that stands between you and yes.
- Don't bluff. There's a school of thought that says invent the experience, say yes to everything, and figure it out once you've signed. I don't buy it. If you lie your way in, you get stuck on day one and you make everyone around you miserable. I'd rather bet on real skill and the honesty to say "I haven't done that specific thing, here's the closest thing I have, and here's how fast I learn." Earning the role on what you can actually do is the only version that holds up.
It worked out anyway
I didn't get that job. For a while I was genuinely sad about it, because the work would have been fun and the people were sharp.
A few months later I took a different role. I'm now the CTO of that company. So in the long arithmetic, the rejection was a gift. I don't get to do as much pure security as I'd like in this seat, but I get to weave it through everything we build, which is its own kind of satisfying. And I picked up a habit from that lost interview that has paid for itself many times over.
If you don't understand the question, ask. If you think there's more behind it than the words, ask. The questions you ask in an interview can make you look smarter than the answers you rush, because they show you'd rather get it right than get it over with. I learned that the expensive way. You don't have to.
Sources
Authoritative references this article was fact-checked against.
