Four-step technical rhythm

Want to hear the most liberating sentence in all of interviewing? Here it is: in a technical or case interview, the person across from you cares more about how you think than whether you're right. I've watched brilliant candidates give the technically perfect answer and get rejected, because nobody could see how they got there — they were a black box. And I've watched candidates land on a wrong-ish answer and still get the offer, because their reasoning was structured, honest, and out loud. So today we're flipping the script: you're going to stop acting like a calculator and start acting like a consultant. Here's the thing about these interviews. They feel like knowledge tests, so most people walk in trying to prove they know everything. But from the hiring side of the desk, what's actually being assessed is how you think under pressure — do you panic, do you bluff, or do you reason? And one modern wrinkle: plenty of first-round technical screens are recorded now, with software scoring the clarity and structure of your explanation before a human ever watches. Which means thinking out loud isn't a nice-to-have anymore. It's the whole game. So let me give you the four-step rhythm for technical questions. Step one: clarify. Before you touch a whiteboard or a keyboard, ask questions — what's the scope, what are the constraints, and my favorite: what does success look like for this problem? Jumping straight to a solution reads as junior, because it suggests you'd build the wrong thing on the job too. Step two: structure. Say your roadmap out loud — I'm going to take this in three parts — so that your interviewer can course-correct you before you burn ten minutes in the wrong direction. And that roadmap is your safety net: if you get lost in the weeds, you climb back to the plan. Step three: execute, and narrate the whole way. Why this approach and not that one, what this choice affects downstream. Because your interviewer can't evaluate what they can't hear — if you're silent, they can't help you, and they certainly can't hire you. And step four: validate. Don't just stop when something works. Check it against the constraints from step one and name the edge cases you'd still want to test, because that's what pride in sturdy work sounds like. Now, case interviews — the business puzzles. Same spirit, slightly different dance. You restate the problem so you're not solving the wrong one. You put an early hypothesis on the table — my first guess is the revenue drop comes from new competitors — because a hypothesis says you're hunting for an answer, not wandering through data. You build a simple structure, two to four categories that don't overlap and don't leave gaps. You work each branch, and when data's missing, you say your assumption out loud and keep moving. And then you synthesize: a clear bottom-line recommendation, supported by the trail of logic you just built. And what about the moment they push you past what you know? Because they will — it's by design. Here's the mantra I want you to carry in: honesty plus reasoning beats bluffing, every single time. Bluffing gets people fired in real jobs, and interviewers can smell it. Instead, try this shape: I haven't worked with that tool yet, but here's how I'd approach learning it, based on what I know from this related one. Or this one: I'm not certain of the mechanism, but based on how similar systems behave, here's my hypothesis. Does that make sense? You're showing them your thinking transfers, even where your knowledge runs out. Now let me tell you about a software engineer I worked with. He got hit with an architecture question he flat-out didn't know. And instead of guessing or going quiet, he narrated — his assumptions, his trade-offs, the steps he'd take to troubleshoot it. The interviewer told him afterward: your answer wasn't perfect, but your process is exactly what we need on this team. He got the job. Not on the answer — on the thinking. Now, the honest part. Narrating your own brain feels ridiculous at first, like being a sports commentator for your own thoughts. Do it anyway, because fluent narration only comes from reps. And the AI tools are wonderful for those reps: have one play the mock interviewer, drill your hypothesis openers, pressure-test your I-don't-know answers. But hear me clearly about the room itself. Employers and their software have gotten very good at spotting answers being fed from a second screen — and reasoning you didn't do is impossible to narrate anyway. So build the muscle at home, so that in the room it's just you and your thinking. And that's the good news, because your thinking is the product. So here's your assignment tonight. Pick one impossible question — how many piano tuners work in New York City is the classic — set a timer for three minutes, and solve it out loud. The number doesn't matter. The narration does. Go run that three-minute drill.