I run technical screenings for Go developers. Someone comes in, we talk, I dig into what they know and how they think, and afterward I write up a recommendation with my own conclusions: pass this person to the next stage, or stop here. I don't make the final hire call. But at the technical screen I'm the gate, and what I weight in that hour decides who gets through.
What I weight now is not what I'd have weighted a few years ago. The strange part is that most of what changed didn't come from interviewing at all. It came from before that, from spending years on a small team, working next to engineers day after day, and watching who actually turned out to be strong. You learn a lot about what makes a good engineer when you're not asking them questions across a table but shipping alongside them for two years. By the time I started interviewing, I already had a fairly clear picture of what good looks like over the long run. Interviewing just became the place I try to detect it in one conversation.
So this is the gap between the two. The signals I used to trust and have mostly stopped caring about, and the ones I learned to weight heavily, mostly from watching real engineers play out over time rather than from any interview.
What I stopped caring about?
Answers that sound memorized
There was a time when a clean, confident, textbook-perfect answer read to me as "this person knows the material." Now it reads as almost nothing. At best it's a checkbox: okay, they've heard the question before, they have the standard answer ready.
The problem is that a polished answer to a common question tells you the person prepared for common questions. That's it. Plenty of people walk into an interview having rehearsed the usual Go rounds, goroutines, channels, interfaces, the difference between a slice and an array, and they can recite all of it. It sounds like knowledge. It often isn't.
So when an answer comes out sounding rehearsed, that's not where I stop. That's where I start. I begin digging into depth and into breadth. I take the thing they just said fluently and I push on it: okay, why, and what happens if, and when would you not do that.
A surprising number of candidates crumble right there. The recited answer was the whole inventory, and one layer underneath it there's nothing. A memorized answer isn't a bad sign by itself. But I've stopped treating it as a good one.
Years on the resume
I used to read years of experience as a proxy for seniority. I almost ignore them now, within reason.
There's a floor, obviously. For example, you're not going to be senior with about a year of total programming experience behind you, there hasn't been a plenty time to see enough go wrong. But above that floor, the number stops telling me much. The case that made this click for me was someone who was genuinely senior in another language and moved to Go maybe a year ago. The Go line on their resume says "1 year." Their actual engineering seniority is not one year old. The judgment, the instinct for what will hurt later, the ability to reason about a system, that came with them. Counting their Go months and concluding "junior" would just be wrong.
I came to Go from years of PHP myself, so maybe I'm biased here. But I've seen enough strong engineers cross into Go to stop letting the language tenure on the page stand in for how good they actually are.
Raw speed of answering
This one I didn't drop so much as learn to read properly, because speed isn't one signal. It's at least three, and they point in different directions.
A fast answer can be great. It can also just be someone generating options without thinking. That's not a bad trait on its own, fast idea generation is useful, but if that's all it is, the person needs to learn to validate their own options before committing to one. So a quick answer makes me want to check: did you actually weigh that, or did it just fall out?
A slow answer with visible reasoning is usually a good sign, or at worst a neutral one. When someone takes their time and I can watch the logic move, they're considering it, ruling things out, working toward it, that slowness very often just means they haven't hit this exact problem before. That's experience, not ability. Experience is teachable. I'm not going to penalize someone for thinking in front of me.
The only version of slow that's a clear bad sign is slow plus nonsense, when the person takes a long time and what comes out is just wrong, with no thread of reasoning holding it together. That one's unambiguous. But plain slowness? I stopped treating that as negative a long time ago.
What I weight heavily now
Depth and breadth, not recall
The thing I'm actually trying to measure is how deep and how broad the real understanding goes, not how much got memorized. Those are different things and they come apart fast under pressure.
The way I get at it is simple, and it's the core of how I run the screen. I latch onto one of two things. Either it's a question I asked, and I just keep going deeper on it, the next layer, and the next, and the next, until I reach the edge of what the person actually knows. Or it's a claim the candidate made themselves, something they stated as fact, and I start asking tricky follow-ups on it to see how well they understand the thing they just said. Both roads lead to the same place: the point where recall runs out and you find out whether there's real understanding underneath it or not.
Everybody has an edge. I'm not trying to embarrass anyone by finding it. I'm trying to find out how far away it is, and what's between here and there.
How someone thinks when they don't know
This is the one I care about most, and it's the hardest to fake. When I push someone past the edge of what they know, which I always do eventually, what happens next tells me more than any of the answers they got right.
The good version: "I don't know this, but here's how I'd reason about it," and then they actually do, out loud, in a way that holds together even without the answer. That person I can work with.
The bad version is bluffing, confidently producing something that sounds like an answer but isn't, hoping I won't notice. I always notice, and now I weight it heavily, because someone who bluffs past the edge of their knowledge in an interview will do the same thing in a code review or after an incident, when it costs a lot more.
How you behave at the boundary of your own knowledge is, to me, one of the most honest signals in the whole conversation. Everyone reaches that boundary, and what you do there tells me a lot about how you'll work.
How they handle a question that looks unreal
I'll sometimes ask something that sounds tricky, a situation that looks simple on the surface but feels strange, almost not-real, an edge case that doesn't behave the way the textbook says. What I'm watching for isn't the answer. It's the reaction.
Some people get thrown by it. Some stay calm and start adapting, turning the strange thing over, probing it, working with it instead of freezing. I call that being variative: able to handle a situation that looks ordinary but feels off, without losing the thread. I weight this heavily because it predicts something real about the job. Production throws unreal-feeling problems at you constantly, the bug that can't be happening, the state that shouldn't exist.
The person who stays adaptive in front of a weird interview question is, in my experience, the person who stays adaptive in front of a weird production one.
The candidate who looked perfect on the surface
The clearest version of all of this was a candidate who answered the surface-level questions almost flawlessly. Genuinely clean, the kind of fluency that, early in my interviewing, would have impressed me. It was so smooth I suspected the same or similar questions had come up in his other interviews and he'd simply polished the answers.
So I did what I do now: I went past the surface. I dug into one of his own answers, and I gave him a couple of simple live-coding tasks, nothing exotic. And it fell apart. He mumbled. He didn't understand what was being asked. On a small problem he reinvented the wheel, working hard to rebuild something that didn't need rebuilding. And whenever I pushed for a layer of detail under the fluent answer, he'd say he didn't know "such details."
A few years ago that perfect surface might have carried him through my screen. Now the perfect surface is exactly the thing that makes me dig, and the digging is where I actually learned who he was. The recited answers were the whole inventory. There was nothing one layer down.
How they carry themselves
The last one is harder to put in technical terms, but I trust it. There's the candidate who comes in radiating "I know everything," and there's the candidate who seems a little unsure of themselves and then, the deeper you go, keeps turning out to actually know the thing. More often than not, the second one is the stronger signal. Certainty is easy to perform. Depth that quietly holds up under questioning is not.
The through-line
I moved from screening for what someone has stored to screening for how they think when the stored stuff runs out. Memorized answers, years on the page, raw speed: I demoted all of them, because none of them survived contact with the engineers I actually worked alongside for years. The ones who turned out strong weren't the ones with the cleanest recall. They were the ones with real depth, who stayed adaptive when things got strange, and who told you honestly when they'd hit the edge of what they knew.
That's what I look for in an hour now. You can rehearse answers. You can pad a resume. You can answer fast. What you can't fake, once someone keeps pushing, is depth, and the whole job of a technical screen, the way I run it, is to keep pushing until I find out whether the depth is real.
Recall is cheap. Understanding isn't.
Top comments (0)