Most technical interviews for structural engineers test the wrong thing. They ask questions with clean answers — define this, state that, what's the formula for the other — and reward the candidate who memorised the most. But recall isn't engineering. Plenty of people who can recite the code can't reason their way through a problem the code doesn't directly answer, and the interview that only tests memory will hire them anyway.
The questions that actually reveal an engineer share a feature: they don't have a single clean answer. You're not listening for the result. You're listening for how the person thinks on the way to it.
Why fact questions fail
"What's the load factor for imposed actions?" tells you whether someone read the standard. It tells you nothing about whether they can apply it, when it doesn't fit, or what to do when the situation falls between clauses. Worse, it's exactly the kind of thing a junior can look up in seconds and a tool can answer instantly — so you're testing the one capability that's least scarce.
Fact recall also fails in the other direction: it can make a strong engineer look weak. A genuinely good engineer might not have the exact coefficient memorised because they've always looked it up — that's correct professional behaviour, not a gap. Penalising them for it while rewarding the candidate who crammed definitions is selecting for precisely the wrong trait. The interview should reward reasoning, because reasoning is the thing that's hard to acquire and impossible to look up.
Open the problem up, don't close it down
The most revealing questions are deliberately under-specified, because real engineering problems arrive under-specified. You want to watch the candidate impose structure on ambiguity.
"How would you approach the lateral design of a thirty-storey residential tower?" has no right answer, which is the point. A weak candidate freezes, or reaches for a formula. A strong one starts asking their own questions — what's the site, what's the wind region, is it seismic, what's the floor plate, where can the cores go, is there a podium or transfer. That instinct to interrogate the problem before solving it is the single clearest signal of an engineer who thinks, and you can't fake it. The questions a candidate asks back tell you more than any answer they give.
Ask them to estimate something
A quietly brutal and brilliant question: ask for a rough number with no calculator and no references. "Roughly how deep would you expect a transfer beam spanning twelve metres carrying a couple of columns to be?" or "ballpark the reinforcement rate for a typical suspended slab."
You don't care about precision. You care whether they have an internal sense of scale — the feel for magnitudes that separates an engineer from a calculator operator. A strong engineer reasons out loud toward a sensible ballpark and tells you how confident they are. A weak one either guesses wildly or refuses to commit without running numbers, which reveals they've never built the intuition that should come from years of seeing real structures. The estimate itself barely matters. The presence or absence of a calibrated gut is everything.
Ask "what would you check?" and "how would you know it's wrong?"
Two of the most informative questions you can ask are about verification, not solution.
"You've run the model and it gives you this result — what would you check to believe it?" reveals whether someone treats output as a claim to verify or a fact to accept. A strong engineer immediately lists sanity checks: does the period suit the height, do the reactions sum, is the mode shape sensible, does it match a hand estimate. A weak one has nothing, because they've never learned to distrust a model.
"How would you know if this design were wrong?" is even sharper. It forces the candidate to reason about failure — load paths, what governs, what's sensitive, what the consequences of an error would be. Engineers who think about how things fail are the ones you want. Engineers who only think about how to get an answer are the ones who miss the failure nobody designed for.
Push past the first answer
Whatever they answer, push on it. "Why?" "What if the span doubled?" "What would change if it were seismic?" "What are you assuming there, and when does that assumption break?"
This is where memorisers and engineers separate cleanly. The memoriser gave you the fact and has nothing behind it — push once and they're out of road. The engineer has reasoning underneath the answer, so they can follow it wherever you take it, adjust when you change the conditions, and tell you honestly where their certainty ends. You're not trying to catch them out. You're testing whether there's a structure of understanding beneath the answer, or just the answer.
What this means in practice
If you're interviewing structural engineers, stop testing what they've memorised and start testing how they reason. Open the problem up and watch them structure it. Ask them to estimate and listen for a calibrated gut. Ask what they'd check and how they'd know they were wrong. Then push past every first answer to see whether reasoning or recall was holding it up.
And if you're the one being interviewed: the good news is that none of this can be crammed the night before, which means it can't be faked — but it also means that if you've genuinely built judgement, it shows, even on a problem you've never seen. The engineers worth hiring aren't the ones with the most facts ready. They're the ones who, handed an ambiguous problem with no clean answer, start thinking — out loud, from first principles, asking the right questions on the way. That's the whole thing the interview is trying to find.