A lot of attention is paid to the value of "rockstar" or "10x" programmers in building successful organizations. It's not hard to understand why; the inherently scalable nature of software means that marginal differences in programming work result in large differences in output.
Whether targeting outliers is a sustainable hiring strategy (it certainly can't be if everyone is doing it) is a widely debated topic. Less often talked about is what actually makes somebody one of these great programmers.
Without a mental model, it's difficult to either work towards being a great programmer or identify such individuals when hiring. What follows is an (opinionated) attempt to distill some of the qualities that make a great programmer. In particular, this list emphasizes delivering value within an organization (as distinct from the pure craft of programming). The list is loosely sorted in ascending order of difficulty / rarity.
This means the ability to write working code which yields a solution to a presented problem. Sort an array of values, determine the right data to show a given user, etc. Obviously this is not a binary condition (everyone has different limits) but most development tasks shouldn't stretch the limits of your ability in this regard.
One big reason that software engineering interview processes are broken is that this is simultaneously the minimum requirement for being able to hold a programming job and the complete extent of what is tested for.
This is different from being able to write application logic. Code is for other people and should be written as such. This means succinct and expressive names, modular classes and functions, and readable logic. It's not enough that a piece of code "works". Good code is straightforward for others to use.
There are of course many acceptable solutions to a given design or architecture problem. You can reasonably choose to trade simplicity for performance if the application warrants it. You cannot reasonably choose an approach that is both complex and slow (where a simple or performant solution exists).
Coming up with a "correct solution" means having the depth of understanding to make appropriate tradeoffs and avoid inflicting a deadweight loss on the software.
This is fairly self-explanatory; software engineering is knowledge intensive work. You can Google syntax but you can't Google fundamental problem solving ability.
Again, this is pretty self-explanatory. In the course of working as a software engineer, you will encounter situations where you need knowledge you don't have. Being able to acquire that knowledge is important to being effective.
Yet again, this is straight forward. Teaching is an economical way to deliver value to an organization. It makes others more effective in their work, creates a more attractive work environment, and fosters a culture of knowledge growth.
I'll define this as being able to take high-level business requirements and deliver a good software solution to the problem. This is less a technical skill than a "human factor".
Completing a project often involves a mix of programming and other non-technical concerns that are difficult to bake into a standard process. This means identifying what stake holders want (which is often distinct from what they ask for), forming the correct approach, aligning involved parties, and executing to deliver a strong finished product.
Being able to assume responsibility for these varied factors is a major separator of people who are good at writing code and people who are able to have major impact in an organization.