Once or twice I've been asked in tech interviews, "tell us about a very complex system that you built."

This question reliably stumps me, because I don't feel like I've built complex stuff, even though I've shipped large, profitable, efficient and reliable systems. I've stuck to simple but effective designs and methods.

And that's the whole trick, really.

@sanityinc sounds like a great answer
@sanityinc I was asked a similar question the other day: "tell us about something you've built that you were really proud of". I feel it was an opportunity to "show off" a complex system, however I spoke my truth and talked about my favourite project; a slack integration that monitored the office coffee pot.
@sanityinc Due to the Oxford Dictionary: complex = consisting of many different and connected parts. In my opinion any large system will be complex in one or another way. So I don’t get your issue with the question.
@devtxdotnet When I say "large system" I really mean a large scope of functionality, implemented with a careful combination of simpler (but not too small) subsystems. The end result is fewer "different and connected parts" and therefore less complexity. But I get your point: there's indeed some essential complexity in the scope of a "large system". However, any incidental complexity is highly variable and usually optional.
@sanityinc Thanks for your reply. I totally agree with you. My only point is if you change “tell us about a very complex system that you built.” to “tell us about a very large system that you built.” then your answer “I've stuck to simple but effective designs and methods.” shows your mindset how to build large (or complex) systems. ;-) And that’s in my opinion a good question to ask any software developer (or architect or engineer or whatever term you prefer). Or?
@sanityinc I agree.
I prefer to ask candidates to talk about a project their are proud of, or that they would like to highlight in their resume. This allows them to also put in front things that required more soft skills, rather than focusing on technical aspects.