It's all about how you twist it. If you say "I built 2 new services that could have just been a feature in an existing service" then you'll probably get a bad review.

However, if you give a reason for building the 2 new services (eg. more extensibility, enables a new flow, easier to use for other teams) then all of a sudden the complexity is justified and you'll appear to have solved a hard problem. No one is going to look super deeply and ask if those reasons are valid and if you even need the extra extensibility or if other teams will use the service.

Do they consider fixing easy bugs are hard problem? Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?

I've seen real bugs that bounce around for months, each time to someone who looks decides it isn't in their code and points to someone else: eventually we tell one engineer to solve it an a few weeks latter she traces it down through many different layers to figure it out. I've seen other cases where a great engineer spent weeks fixing bugs only slightly more complex a misspelling. In the end what counts it the quality of the product not the effort put into it.

I think there just aren’t enough reasonably solvable hard problems. All the low hanging fruit is taken, and the result is artificially complex solutions as a way for engineers to demonstrate craftsmanship.