When you begin the habit of writing code to solve problems that you don't have - that's a real problem. Joel Spolsky famously called these people Architecture Astronauts. They create such ambiguous, high-level abstractions in the code that at a certain point the code becomes unreadable and, for all intents and purposes, unmanageable.
There is a somewhat lesser known space trilogy from CS Lewis and in the first book a human from Earth visits a foreign planet that is mainly inhabited by three different classes of physical creatures: the Sorns, the Hrossa, and the Pfifltriggi. At one point in the story the human asks one of the Sorns (its name is Augray) where he got his impressive oxygen mask from. Augray answers the human somewhat sheepishly:
““The Pfifltriggi like making things,” said Augray. “It is true they like best the making of things that are only good to look at and of no use. But sometimes when they are tired of that they will make things for us, things we have thought, provided they are difficult enough. They have not patience to make easy things however useful they would be.””
I've worked with developers that, I swear, care about how clean/pretty/clever their code looks more than how well it might actually solve the customer's problem. They seem to not have the patience to actually make useful software. In a sense they consider it to be something below them. They are only interested in contributing to the project if the project is challenging enough to give them the opportunity to show off their "astronaut" architecture skills. Like the Pfifltriggi, they seem to like best the making of things that are only good to look at and of no use.
Several years ago I hired a software consulting company to help me finish what I thought should have been a straight-forward task of adding product-level permissions to a database that I was working on. The project soon began running late and I couldn't figure out why immediately. But after discovering 14 new tables had been added to the database and that virtually every existing API call had been modified, I soon found out why! I was dumbfounded, honestly.
I greatly regretted not adding a simple yet powerful requirement to the project: "solve this in the simplest way possible." Instead what I got was a database that could handle any possible level of permission for any type of product configuration that could ever be thought of - even if it hadn't been invented yet! It was more than just overkill, it was a budget kill!
What Can you Do About It
So how can you spot a Pfifltriggi before you hire him/her? Well the bad news is that there is no sure way to detect one ahead of time. The problem is that they regularly sound very confident about how to solve a problem and no matter what objections you raise, they have a tendency to dismiss it with a clever remark or some theoretical way to navigate around your concern. If you are considering hiring a developer full-time to your staff, be sure to not only make them write code at the interview but also intentionally give them a somewhat simple problem to work through and see if they come up with a simple solution.
One technique I used in the past in hiring new developers is to give them a coding problem to work on but either intentionally withhold information that they would need to finish the solution or subtly ask them to make the program do something that would be virtually impossible to accomplish. A straight-forward developer who is interested in the simplest solution possible will stop part way through the test to come ask you questions. A Pfifltriggi will try to solve the impossible task without you by showing you some kind of "impressive" architecture that they have come up with on the fly.
If you're planning on hiring a contractor for a short or mid term project, first hire a business analyst to help you estimate a budget for the project and ask the software contractor to work on a per-project basis rather than an hourly rate. This will naturally help protect your project costs because you won't be directly paying for all those potentially unnecessary hours of over-engineering.