Alternatively: How do you identify programmers addicted to novelty/who have a hard time internalizing business goals?
Let's put it this way. If Christopher Columbus was looking for the new world and he got 80% of the results the reward would be a watery grave.
The other 80% of the work was sailing around the southern end of South America, and building the Panama Canal so you could actually reach Asia by sailing west from Europe.
I'm looking for the opposite of a person who leaves a trail of proof-of-concepts behind them without actually delivering anything real people can use.
0- They should care about getting projects done, in reasonable time and without the need for subsequent reworking. Regardless of what the project actually is.
1- They should have internalized that nothing is ever finished. After the "building" phase comes the "maintenance" phase and they should be aware of this and behave like they know that maintenance for every line they write will be one of their long term task (see #5, #6).
2- Willingness to do the least pleasurable and more mundane parts of the project (possibly trying to reduce the time needed through automation if it makes sense), that are necessary to finish it.
3- They should be able to always keep a clear idea of the current status of the project, what they still need to do and what is still missing. They shouldn't have a tendency to throw away time to look into unnecessary and irrelevant details (i.e. technical rabbit holes).
4- They shouldn't lose interest or lose direction when something doesn't go according to plan. In these cases the plan should be re-evaluated and a new plan defined.
5- They shouldn't be too hasty with what they have to do just to get it over with quickly and jump to the next thing.
6- Understand that there is a difference between a project that needs to be completed and used in production and something you can experiment on and has no hard requirements related to when it will be ready and how reliable it will be.
Many developers are "addicted to novelty" because that is how the industry works. You don't get very far in the game by only knowing VB.NET and C++. To get a high salary you need to change jobs many times. To change jobs many times you need to have knowledge about the latest and greatest (AJAX, jQuery, MongoDB, TypeScript, Android, iOS, Rust, Go, Scrum, TDD, whatever...).
You're justifying the game plan of a certain type of programmer. I'm asking how to find someone who's professional toolbox includes the ability to knuckle down and manage the boring shit until it's done, over a project-level time period.
In this instance I don't want to hire an alphabet soup programmer who will move on to the next company as fast as the next resume update allows. If it's a side effect of kicking ass on a variety of projects, broad experience is a nice-to-have, but I need someone who will hang around long enough to internalize and take responsibility for business goals.
If you have limited time with the person (say, 3 weekly meetings over a period of 3 weeks) then I would watch for the following...
a) did they do what they said they would do (in the previous meeting) -OR- are they asking for clarification on what was discussed in the previous meeting?
b) can you or another dev build and run their code from whatever they last checked in/committed -OR- do you get build errors, compile errors, or runtime errors?
c) do they ask questions and help you clarify what needs to be done?
Regarding the addicted to novelty, not internalizing business goals question, I see that as more of a management issue than an individual trait. They may be too busy learning a new technology to care about the business goals, in that case the engineering manager needs to make sure they are on track (and that the new technology is relevant to the work being done). Once they become proficient then they can easily internalize the business goals, but they will need repeated exposure.
I'll start with dev incentives and why it explains their behavior. Now one thing that is fairly common is internal raises are relatively much smaller when compared to market for jr. devs than sr. ones. This incentivizes most young/jr devs to switch jobs fairly often to get market pay raises(which are very substantial for young devs and usually much larger than internal raises, I quadrupled my salary in my first 3 years of working). To do this they need to build up technical expertise as quickly as possible because this is what the next job is looking for. And there really isn't any incentive to build up domain knowledge that will become useless the first time they switch jobs.
Senior/older devs for instance are usually on the opposite end where the pay raise for switching jobs is relative lower compared to internal raises. They are usually at a point where job security is more important because they fear being a hard to hire greybeard. They're already close to maxing out as a single contributor(and a lot of time if they wanted to move to management/tech leadership they would have already). And for them to pursue their goals of job security and maxing out pay by being valuable to one company as opposed to many companies they'll pursue and acquire lots of domain knowledge.
So I think you have two options. Hire an expensive older/sr. dev and convince them that the company would be a great place to spend the next 5-10 years. Or hire a younger dev and explain how it would be very beneficial for them to make a career there, talk about how much your company values domain knowledge and internalizing business goals. And then explain that you are willing to pay very handsomely for that and match what are the absolutely nuts pay bumps that go to jr. devs when they switch jobs.
*Note I'm generalizing like crazy and I don't think this is true in every case. I've met plenty of older devs who were fascinated by new tech and had little interest in domain knowledge and vice versa. But I think as a general rule it holds, and it holds for myself. When I first started I always got really excited about new tech and building out things the "right" way. Now 10 years in meeting business deadlines/goals and learning deep domain knowledge so the application really shines excites me more than learning Yet Another Framework.
I feel like the personal value system and personality are what drive long term performance. You can explain and cajole all you want, but inevitably a few months later the core personality starts coming back through. Establishing a culture around certain things will go a long way toward making those behaviors expected, but finding a person who has the appropriate temperament and skill level for a the types of activity needed for a role is so incredibly easier than doing everything the hard way.
Maybe I've been spoiled... I have a few engineers in other roles who do naturally get things done and don't need constant hand-holding to get through anything boring, but so far the programmers mostly just want to work on whatever they think is cool and turn into procrastination machines if I push too hard or give them an uncool task. I do have one older guy who I can leave to his own devices and the result will mostly make sense and happen without lots of my time pushing to finish. The other engineering roles with 'finishers' are mostly young guys, though, so I'm still hopeful any age could be this type.