I ask every candidate the same question: what’s a technical challenge you’re proud of solving?
Most answers start with the solution.
“I optimised the database query and improved response time significantly.” “I refactored the architecture and made it more scalable.” “I built a feature the team said was really clean.”
This week, one candidate started with the constraint.
“Each scan cost $0.05 and took 45 seconds. As the app scaled, that stopped being sustainable.”
He was talking about a halal food checker app he’d built solo. Over 25,000 installs. More than $600 in monthly recurring revenue. And one central problem: every barcode scan was hitting an API call fresh. Fast and expensive. Slow on repeat lookups.
His solution was a caching layer. Once a product was scanned, every future scan of that barcode was instant and free. Costs dropped significantly as the user base grew.
The solution itself wasn’t exotic. What stayed with me was how he arrived at it. He knew the cost per call. He knew when the unit economics stopped working. He’d done the math before writing a line of code.
There’s a type of engineer who builds things until they break, then figures out why. And there’s a type who thinks in constraints first — cost, scale, edge cases — and builds something that won’t break in the first place.
You can often tell which one you’re talking to by where their answer begins.
When they start with what they built, they’re showing you the output. When they start with the problem — its shape, its cost, its limits — they’re showing you how they think.
I find the second kind less common. And when I hear it, I slow down.
If you do technical interviews: in your experience, does leading with the problem versus the solution actually predict the quality of the work?
Leave a Reply