The employee knows about all of the parts of a standard application and can speak to them, but cannot put them together without hours of coaching and discussion. Or the inability to make the right decision when presented with information. Or to fail to ask questions when presented with an unknown, instead making the wrong decision.
When presented with a standardized solution that is formalized and utilized across the entire application, will either implement a new, inadequate solution or keep asking around the senior members of the team until someone, given a small enough slice of the problem set, is coerced into validating the inadequate solution, usually devolving into wasteful group meetings on said topic.
When asked to following the standard conventions of the large codebase he or she is now working in, decides to implement new folder hierarchies, naming conventions and to litter the code with unnecessary common functions, copied and pasted code blocks, large commented blocks, all of these against the communicated and often repeated standards of the application.
---
I initially took it as an affront. Most of the standards were being ignored or questioned by this person. And I had regrets about hiring them.
Having had some time to consider the problem, I think that part of the issue is that the person comes from a background where they were in a "get things done" frame of mind. Technology was the means to an end and never a first class citizen. And they were the only programmer. And they had major business responsibilities as well.
Being the sole programmer of an organization leaves you in a very isolated position, unable to learn about new standards and technologies unless you actively seek them out. If you are getting things done, well then all is well with you and your skill set. You clearly have the right answers because things are working.
I believe that someone coming from that type of background is likely to need to reframe the world in the way they have known it, unable to accept new standards. They are lost without being able to anchor themselves in their old conventions. They are likely to accept the first working solution, because the code is not an asset, it's a tool. Copying and pasting are a savings in the short term. Commented out code is an artifact of their results-driven development process.
---
I agree that there are times when you just have to fire someone, but that is not always the only option on the table. Sometimes you can work with what you have by understanding why things are they way they are.
In order to get the best value out of this person, I try to capitalize on their strengths by assigning tasks that I am comfortable letting them own. They have a niche, and they call the shots in that niche. They are empowered and in control of their own domain again.
When I find that they are deviating from our standards, I convey the reasoning for the standards, but I do so in the form of questions that lead the person to arrive to the right conclusions. In this way, they are deriving the right answers and they own that reasoning. The old way is no longer necessary because the new way makes sense to them now.
And it gets better.