Anyone with enough experience should be able to answer this question. Anyone who has worked across a number of different organisations and types of organisations; who has worked in a number of different but related roles; someone who has managed people; who has fired people; who has produced great product and who has seen and made many mistakes along the way!

Someone like me.

Paul Graham says that the people you need to employ are "Smart and get sh@t done" which is a massive simplification but gets at the root of the issue. A great developer is clever enough to make short work of hard problems and then get's stuff done so that they can add value to your company. There are plenty of smart people who are not pragmatic and there are plenty of pragmatic people who are not very clever.

Clever people might see great solutions but might take too long to realise them, they might also be perfectionists. There are too many problems to be clever without pragmatism. 

On the other hand, pragmatists who are not clever might be too quick to "hack and whack". Who might think that any solution is a good solution, who are not good at seeing a big picture, or who cannot spot inconsistencies or unmaintainable code.

So here are some scenarios where I have spotted the good from the bad:

1) People who can very quickly debug a problem. The worst kind of problems are those that we know are affecting a production system and possibly affecting thousands of people. Despite that, there are those who can isolate and identify the problem in minutes and get a patch or even a proper fix out to production - and those who can't. Those who can't do this are often good at getting stressed and confused but who simply do not have acceptable debugging skills to use tooling to get logs/callstacks/repeatable local scenarios etc.

2) People who don't need you to write everything out in detail. There are people who I have worked with that I can disucss, say, an API with. With a few simple sentences, they understand enough to go away and produce exactly what I want. They understand enough to know that the stuff we didn't discuss is still important - assumptions like secure, performant, easy to read and maintain etc. Other people take much more time and input and even then do not have enough skill and produce code which is OK at best and incomplete or broken at worst.

3) People who can balance the work arising with staying on task. Some people get easily distracted wile implementing feature X. What they see might be definitely needed or it might be a nice-to-have but good developers know when something is a quick 5 minutes of extra quality, when it might be done but later, and when it is something that requires a quick, "I noticed X was missing, shall I do it" to the Team Leader.

4) People who are very self-aware of their skill level. It is hard to know how good you are at your job when there are so many variables. Programming is like medicine and law in that there is no single measure of ability and much is based on the context but what we do want are people that know that in the world of e.g. .Net, I am a 5 out of 10 or an 8 etc. Usually, the very young are better at this because they know that they don't much and they ask questions which hopefully get fewer and more advanced over time. There are, however, those who think they are an 8 when they are really a 4. What they produce is slow, sub-optimal and hard to maintain. They might have misunderstood the requirements but haven't asked for help because "they're an 8!". These are hard to work with because it's hard correcting something who already thinks they know it all!

5) People who understand architecture. Although we shouldn't pre-optimise code, we should understand that certain things are likely to be extended and certain things are not. If we have no need for multi-branding, we don't need an architecture that supports it. On the other hand, if we are building a plugin system, it should be written to be extensible due to its nature. Some devs don't understand enough and only ever see the code at a micro level.

6) People who both give and receive knowledge. It is nice when people offer knowledge to the group for the "greater good". I don't like asking people to give training but if you are a good developer, it should be part of your mindset. You learn something like OWASP Top 10 because it is really important so why wouldn't you want everyone else to know about it? Not everyone likes giving training but if you are clever, you should be able to work out a good presentation pretty easily.

7) People who live for the "continuous improvement". Good people I have worked with are the sort who say, "look how cool CI/CD is" or "dotnet core is so much faster than netfx, let's look to migrate" etc. I like it because it should be, "why not?" whereas others are so insecure, they prefer living with what they have and know. Obvisously we don't follow every latest trend but in most cases you have to run to stand still in the software world and it is frightening to me that some companies are still using apps that were written 20 years ago and are definitely not patched or up-to-date.

8) People who instinctively get the trade-offs in our profession. A good person would know that introducing Java to a .Net company (as a replacement) is unlikely to ever happen, not because Java is not as good but because there are so many dependencies on the tech stack from expertise, cost of hosting etc that the only reason you might ever do it would be if Java released something that was twice the speed of dotnet core out of the box - maybe it would be worth it. Lots of developers have very obvious preferences for certain things, which might be partially justified or might even be based on something you think you know but don't. These opinions come out in all sorts of ways (everyone else uses NUnit but I use XUnit; Everyone uses and understand Visual Studio but I have use Rider because it's slightly nicer; You have to use Unit Tests even if they don't make sense)

Did you notice what wasn't there? I didn't specify that a great developer knows how to solve a programming problem. Why? Because that is assumed. It is programming 101, even a junior shouldn't take too long to get their head round what is happening and why. If you can't Google something like "How to create dictionary from Linq in .net" you shouldn't be a programmer, honestly! The funny thing is that many developers think that it is precisely this that singles them out from the ordinary devs!

Now for the bad news.

These people are hard to find. They are probably not as rare as you might think but picking them out of the crowd is hard. Part of the problem is that some work for companies where their true selves have been beaten out of them and given the chance, they would thrive in a high quality environment.