Framing the Problem is Half the Work
What I really appreciate is not a big and convoluted solution to a complex problem, but a tasteful framing of the problem which makes the solution simple and obvious.
Finding an appropriate framing has to do with finding the correct interfaces and layers of abstraction. Upper layers usually deal with the same concepts as the problem-domain, and lower layers deal with incidental implementation specifics.
Taking as an example, web application authentication and authorization.
At the business logic level -- a higher abstraction layer -- we're only concerned with “are we authorized to perform this action” and the user being authenticated is taken as a given.
In a lower abstraction layer, we're authenticating the credentials from the JWT token of the user, fetching their set of authorized actions.
At an even lower abstraction layer, we're setting up the TCP and TLS connections, ensuring we've received the complete message from the client.
The beauty of this approach is that each problem -- from network packet message passing, to authentication and authorization -- is each solved in its own layer, allowing higher levels to assume the guarantees provided by the lower levels.
This clear separation of concerns allows understanding each level in isolation: someone concerned with the correction of business logic need not to look into and understand JWT token parsing; someone working in TLS libraries has no idea (or cares) about the bytes of data that flow through it -- as long as it's correctly transported to the other end.
In many ways similar to this, what really allows really complex problems to be tackled is very crucially the framing. A big problem, such as writing an operating system or a program compiler, can be very tractably tackled if the appropriate abstraction boundaries are set.
The challenge arises when from the fact that -- especially for novel problems -- it is not at all obvious what is the ideal framing should be when you have not yet struggled with the problem enough and have not spent the time pursuing and learning from a number of non-optimal approaches.