Stop Asking Engineers to Code Boggle

There's a style of question I've heard in engineering interviews for decades, and it never fails to make me cringe. A real life example of this is "How would you code the game of Boggle?"

The intent is good - the interviewer wants to see how a candidate thinks. But here's my problem with it: I genuinely don't know what a candidate's ability to whiteboard a word game on the spot tells me about whether they can do the job I'm actually hiring for. And in my experience, neither does the interviewer.

This is the central dysfunction of how most engineering teams hire - and it's one worth fixing.

The Two Interview Anti-Patterns Worth Naming

The first is what I call the quiz show question: something trivia-like that can be Googled in five seconds. "What's the big-O notation of a quicksort?" is a classic example. These questions test whether someone studied the right flashcards, not whether they can pragmatically engineer software using learned real world experience.

The second is the "let me see how you think" question - open-ended, abstract, disconnected from the role. Design a parking garage system. Code a chess engine. Build Boggle. The assumption is that watching a candidate work through a novel problem reveals something deep about their potential.

Maybe. But I'd argue there's a much more direct way to assess what you actually need to know.

Hire for the Job You're Filling

The principle sounds obvious, but it's surprisingly rare in practice: design your interview process around the actual work the candidate will be doing as an employee at your company.

If the role requires database design, give the candidate a small system and ask them to design the schema. Push on the requirements and see how deep their understanding runs. If the role requires writing Python code with unit tests, create a small subsystem and have them work within it - add a function, refactor something, verify a query result. Nothing tricky. Nothing abstract. Just a realistic slice of the job.

One thing I've found useful: keep the same system across both the whiteboard and coding portions of the interview. Asking a candidate to context-switch between two brand-new systems under interview pressure introduces unnecessary noise. You want to evaluate their engineering ability, not their ability to onboard quickly under stress.

The less direction you need to provide during this exercise, the more independently they're likely to operate as an employee. That's a signal worth paying attention to.

What You're Actually Looking For

I look for people who are smart and get things done - but I'm careful about how I define that. "Gets things done" has picked up some negative connotations over time, because it can imply a bias toward speed at all costs, where a rushed, half-baked result is treated as equivalent to something well-reasoned and well-executed. It isn't.

A better framing: look for candidates who actively remove impediments. People who make progress in the face of ambiguity. Who experiment, iterate, and don't wait for perfect information before moving forward. That quality is far more predictive of success than the ability to invert a binary tree on a whiteboard.

I also hire for cultural fit first, and technical skills as a close second. A team full of technically brilliant people with big egos is a team that will hemorrhage talent. Skill can be grown. A collaborative, intellectually humble disposition is harder to teach.

A Few Ground Rules for the Interview Panel

Over the years, I've landed on seven guidelines that I make sure every interviewer on a panel understands before we start:

1. Be kind to the candidate. Interviews are stressful. Create conditions where someone can show you their best work.
2. Align on the role's requirements before you start. If the panel isn't agreed on what you're hiring for, you'll get conflicting signals and inconsistent evaluations.
3. Know the signal your interview is checking for, and how to identify it when you see it.
4. Come prepared. Winging an interview is disrespectful to the candidate and produces bad data.
5. Express genuine interest in the candidate. The process is as much for them as it is for you. They're evaluating you too.
6. Create a feedback loop among interviewers, debrief, compare notes, calibrate.
7. Continuously improve the process over time. Your hiring bar and your interview design should evolve as your team and your needs change.

The Bar You're Shooting For

None of this means lowering the bar. Candidates still need a genuine baseline of technical ability, the specifics of which depend entirely on the role. What it means is that your evaluation should be precise rather than generic. A pragmatic, role-reflective interview process gives you a much cleaner read on whether someone can actually do the job than an abstract puzzle ever will.

And frankly, it respects the candidate's time and intelligence a lot more too.

The best interview processes I've been part of felt less like a test and more like a preview - a small, honest window into the work itself. That's the bar worth shooting for.