We've been getting it wrong for years, and I've complained about it for years—subjecting experienced software developers to our barbaric coding coliseums where the ink-starved whiteboard pens reveal less about talent than our collective professional delusions. 

The theater of technical interviews often becomes an empty ritual, demanding that seasoned developers contort themselves into algorithm-reciting acrobats while the real value of their expertise—the delicate balance of transforming business chaos into functional systems—goes unmeasured.

And look, to be fair, algorithm-based interviews weren't created out of malice. They can serve a reasonable purpose when evaluating fresh graduates with similar backgrounds and no professional experience. A standardized approach can help compare candidates with similar starting points, especially if you’re interviewing a lot of them. But as developers progress through their careers, their paths diverge dramatically—continuing to evaluate them with the same junior-focused, entry-level Mount Midoriyama of code memorization makes little sense at all. 

I've watched the tragedy unfold time after time: a talented senior developer whose name arrives wrapped in glowing recommendations from your most trusted colleagues, rejected not because their talent failed to materialize but because our imagination failed to recognize what shape excellence takes when it no longer fits our junior-developer templates. These elaborate evaluation ceremonies offer nothing but the comforting weight of false precision, the organizational equivalent of security theater – if someone asks you to throw out your water bottle and place your laptop and hoodie in a plastic bin before finding all paths in a directed acyclic graph, you would probably just bend over and take off your shoes.

If broken technical interviews weren't raising senior developers' blood pressure enough, here's another guaranteed trigger: "Vibe Coding" — that approach where people create applications without writing actual code, but instead by typing things like "write me an app that does X" into AI tools like Cursor or Windsurf or Claude Code. It's the latest hot topic and to a seasoned developer, vibe coding is the Roadrunner to their Wile E. Coyote—after years of meticulously engineering elaborate solutions with careful planning and technical prowess, someone comes along, scribbles a crude tunnel on the mountainside with AI, and somehow manages to run right through it while the "genius" with twenty years of experience slams face-first into solid rock (somewhat related link).

I think AI + Code is incredibly cool, powerful and undeniably transformative. I build with it every day, and I'm building a company with AI at it's core on every level. I have also seen vibe coders get worked into a corner, backed up against what seems like voodoo and some ‘make’ commands that try to do what you say but not what you mean.  But here's yet another point where AI changes everything—what if this alleged abomination against software craftsmanship could actually be repurposed to solve our senior developer interview evaluation paradox?

Robo-Tony Hawk on a Unicycle (Recraft.ai)

Generate Realistic Tech Debt With AI and Watch Real Problem-Solving in Action

Ok, so you read that subhead and thought "Jinkies, no, I don't need more tech debt." Hear me out: instead of interviewing senior developers with solving imaginary problems they’ll never face, we provide a simulation of the code catastrophes they'll inevitably inherit.

Here's an example prompt:

Create a Python web application backend that can handle a complex scheduling system using Fast API on a pre-filled SQLite DB. Use approximately 2000 lines of code, written by a inexperienced developer, that demonstrates common architectural problems including tight coupling, inconsistent error handling, and mixed programming paradigms. Include database designs and interactions where some queries and tables are wildly inefficient. Don't use caching. Add documentation on how to run it locally that's partially outdated, and include a few unit tests that only sometimes work.

You get the idea, tweak that prompt for your specific situation. And strongly consider having it use tools and libraries the candidate knows well — you want to see how they work and think, not merely how they fumble through foreign territory.

Then, in my mind, you have two practical options:

Option 1: Share this repo as a take-home exam, asking candidates to submit a PR addressing what they consider the most critical improvements.

Option 2: Skip the take-home (my recommendation) and watch them navigate this code in real-time. Let them use their own tools—forcing a Vim devotee to use Visual Studio is like judging Tony Hawk doing tricks on a unicycle. Pop it into a new repo, maybe add a Docker container to run it locally if you have more complex components to install.

Then, share screens and witness authentic problem-solving that no whiteboard question could ever reveal.

In this live encounter, look for:

  • The inevitable "What fresh hell is this?" expression when they first open the files. Horror, fascination, or a thousand-yard stare are all valid reactions—it's what comes next that matters.
  • How they excavate through layers of technical sediment. Do they zero in on meaningful problems or waste time on cosmetic fixes that a junior with a linter could solve? Do they struggle to query the endpoints, or go straight to the Swagger UI?
  • Their reaction to meh-tastic code. It shouldn't just run after they pull the repo, it should spew errors upon their first try (again, hat-tip to the real world).
    • Do they immediately reach for git blame like it's a witch-hunting tool rather than a documentation feature? ('Ah-ha! It was @TMcD! Again!')
    • Or do they say something like: "I see what they were attempting here, though I might approach it differently"? The latter signals someone who understands that behind every terrible implementation is a developer facing impossible deadlines or unclear requirements.
  • Their communication style. Are they condescending or illuminating? Do they make complex concepts accessible or deliberately obscure?
  • Who should be in on the interview? Again, mirror your own org – who would be on a meeting invite to discuss working on code similar to our simulation? Would that be a one-to-one with the CTO, or a group with more stakeholders?
    • If you're a small tech org, prioritize an engineering leader who has experience mentoring others and familiarity with your codebase. They'll be best positioned to evaluate both technical skill and the communication abilities that truly differentiate senior talent.
    • If you're a larger org, however, maybe go with three: Your engineering manager or tech lead who can assess architectural thinking and technical decision-making; a mid level developer who's been deep in your codebase and can evaluate how the candidate's approach would mesh; and I would definitely include your product manager to observe communication style and business priority alignment. If having three people show up for this round seems crazy to you, then do something wildly outside the box, for the love of all things sensible, drop one of your other rounds – this approach is worth it.

These observations translate directly to business outcomes and team dynamics. A developer who can navigate legacy code without judgment typically onboards faster, reducing costly ramp-up time. Those who can explain complex concepts clearly become force multipliers, mentoring junior staff and collaborating effectively with others throughout the company. And the ability to prioritize meaningful fixes over cosmetic ones? That's the difference between shipping customer value and getting stuck in endless refactoring cycles that business stakeholders never see.

The best and most valuable developers I've worked with weren't algorithm virtuosos—they were technological translators who could examine a Jenga tower of code held together by prayers and semicolons and say: "I understand why it evolved this way, and here's how we can carefully improve it without bringing down the entire system." It's the difference between someone who will alienate your team within a week and someone who will elevate everyone's skills while making the codebase better with each commit.

This simulation round tests not just technical ability but how candidates navigate the messier human elements of software development—the assumptions, compromises, and the decisions that devs make on questions no product manager has yet considered. And isn't that what technical leadership should really be about? Not live-coding in browsers, nor whiteboard skills, but the art of turning chaotic human requirements into functioning systems while keeping both the code and the humans who wrote it intact.

The beautiful irony? By using AI to generate the very kind of human generated codebase that your devs actually deal with daily, we've created an assessment approach that finally measures what matters. We've elevated "vibe coding" into a tool that could power up our hiring process instead of the performance theater of leetcode crunching that drives away experienced talent.

In the end, what threatens to make coding 'too easy' might be able to help technical interviews finally reveal what truly matters: the ability to navigate complexity with both technical skill and human understanding.

H/t to @justintravis for his always helpful POV and review.