When I’m interviewing people, I spend probably 70% of the interview trying to probe how good they are at recognizing and weighing trade-offs. Sure, I ask technical questions like “describe an interesting design pattern” or “what’s the difference between an array and a linked list”, but most of those questions are immediately followed by “…and what’s the trade-off?” Candidates probably think I sound like a broken record.
But there’s a reason I put so much emphasis into probing trade-offs instead of their knowledge of Transact-SQL syntax. There are several, actually.
First, if someone knows a technology really well, then they understand that technology’s trade-offs.
Second, software engineering involves constantly deciding among many trade-offs and that’s a lot of what makes it so hard. If it weren’t so hard, robots could do it.
Third, people who don’t consciously make trade-offs tend to waffle around instead of sticking by their decisions.
So people without a keen sense of trade-off end up blundering their way through software engineering making trade-offs they aren’t even aware of in languages they barely understand. And they constantly change their mind. It’s as if all that instruction they had in CS 46a about trading off memory usage vs. CPU usage evaporated right after the final exam.
Successful engineers and managers tend to understand that no matter what decision they make, there’s always a downside somewhere. The key is to be aware of that downside and consciously accept it. Then, later, when that downside becomes apparent to others and you’re facing criticism for it you can confidently explain why you choose it anyway and what benefits you will reap (or already have reaped) because of your choice.
