Over Prepared for a Technical Interview and Still Bombed It

I recently interviewed for a software engineering role at a compliance company. I won't name them, but they're well-funded, growing fast, and building something genuinely interesting in the AI space.

I went all in on preparation.

I studied SOC 2, HIPAA, ISO 27001, PCI-DSS, CMMC, the frameworks, the common control codes, the trust service criteria. I researched the company thoroughly, read their case studies, understood their product positioning against competitors. I looked up every person I was going to speak with. I studied the languages and frameworks in their stack.

I built a working dashboard demonstrating how I'd architect a compliance platform, complete with AI integration to explain control failures in plain language. I designed an extensible integration system in TypeScript, modeled how compliance checks map to control frameworks, and thought carefully about how to run a customer through an end-to-end audit workflow.

I felt prepared.

The Interview

The technical interview asked me to design a workflow system using connected nodes in a directed acyclic graph (DAG) and traverse them in dependency order.

None of my preparation touched this.

To frame where I'm at: I've been writing software for over 25 years. I built a Binary Space Partition (BSP) renderer with Possibly Visible Sets (PVS) before AI-assisted coding existed, before Stack Overflow, even before Google. I was there when you figured things out from textbooks and manuals and sheer stubbornness. Data structures and algorithms were foundational to how I worked, but that was 20 years ago. In the heat of the moment, under interview pressure, I blanked. The knowledge was in there somewhere. I just couldn't reach it.

I bombed it.

What I Did After

I wasn't angry. The interviewers were not only sharp, and I mean genuinely sharp, but kind and respectful throughout. That matters more than people acknowledge.

After the interview I sat down with Claude and worked through the DAG problem from scratch. What humbled me most wasn't that I got it wrong in the interview; it was how straightforward the solution turned out to be once the pressure was off. Topological sort, cycle detection, parallel execution of independent nodes. Clean, elegant, not complicated.

I had overcomplicated it in my head, or more accurately, I had never given my head a chance to get there. Now looking back, even the interviewer was saying things like, "Don't worry about that; no need for this," really an obvious clue that I was overthinking this problem.

What I Took Away

Over-preparing in the wrong direction is still over-preparing in the wrong direction. I knew their domain cold. I understood their product better than some of their customers probably do. None of that helped when the question was a computer science fundamental.

The preparation I did wasn't wasted — I learned TypeScript patterns I hadn't touched in a while, sharpened my thinking on object-oriented design, and built something I'm genuinely proud of. But I learned a lesson about interview preparation that I should have already known: companies that hire engineers with high bars will test how you think, not what you know about their industry.

The dashboard was impressive to me. The DAG traversal is what they were interested in.

I'm not bitter about it. I walked away with more respect for their team than I came in with, a humbling reminder that 25 years of experience doesn't exempt you from the fundamentals, and a much cleaner mental model of directed acyclic graphs than I had last week.

On to the next one.