I'm not trying to nitpick, but UML is purpose-first, not solution-first. The language always allowed for varying levels of abstraction (i.e. linguistics, not layers), and it was always possible to describe the domain instead of classes+methods, but one is always creating diagrams not code. For example, a collaboration diagram can specify domain concepts and use plain language for activities and artifacts; it is not necessary to consider functions and arguments and exceptions. Oh my.

Your anecdotes are more common with object-oriented languages and poor object-oriented design approaches. Any fool can claim to have discovered a OOD pattern, but a good programmer will not claim to have discovered anything. Instead, she will use the software to express the user's activity and desired outcomes.

That being said, some software languages take more skill and experience to implement a solution than others. Sometimes it is necessary for developers to consider the choice of HashMap over List<?> or worse MyCollection which implements List<?> over an array. These considerations may have created to more types of diagrams (UML, OOD, etc.) that describe software in more an more detail, but what is necessary to express a solution is really subjective and rarely universally understood. You can't sit an inexperienced developer in front of a C++ program and expect them to understand that they are looking at code for a text editor anymore than you could sit them down in front of a collection of DDD diagrams and expect them to build a perfect representation in Java.

We (the royal "We") are looking for a proper balance in design and implementation. That is a work-in-progress: it is the point of this career and won't be captured by single checkbox on one's resume, e.g. "knows UML or not".