You're growing your software team, and you have ambitious plans for your roadmap. You'd better go out and hire your 10X ROCKSTAR NINJA, right?
Just kidding. You know better than to put those terms in your job post (seriously, developers with any experience will roll their eyes and move on). Still, if you focus on technical aptitude to the exclusion of other attributes, you are asking for trouble.
High performing teams have a strong sense of team identity. They want to succeed together, as a team. They will celebrate individual wins, and they will learn together from their failures. The team is a resilient, self-correcting system.
If that's the team you want, you must intentionally create it. If you simply hire developers for raw technical skill, you're more likely to end up with internal politics, hoarded information, and inconsistent deliveries. And when one of those developers leaves, unknown amounts of institutional knowledge will go with them.
Your team will outlast the tenure of any one developer, so you need to make sure it has a self-reinforcing culture of collaboration and self-improvement. This way, the loss of a single developer may be a short-term hit to productivity, but it will not be a catastrophic loss of institutional knowledge or fundamental capabilities.
Of course you should hire the most competent developer you can, and of course there will be differences in abilities between different developers.
But instead of hiring a rockstar, hire a music professor (still speaking figuratively here). The professor has the same technical proficiency as the rockstar, but shares this proficiency with their teammates and builds the collective skill level of the group. One long-term benefit of building this kind of culture is that you are better able to hire junior developers, retain them, and groom them to become senior developers.
So how do you select for music professors instead of rockstars?
Obviously, start with your job postings. You're not going to get what you're looking for if you don't ask for it. Make clear that you're looking for developers who are eager to learn from their teammates, as well as share what they know.
In interviews, ask candidates about when they've led a project and how they did it. If project leadership doesn't seem relevant to your team, you can instead ask more generally about a time when they were the senior person on a team. Get a sense of whether they tend towards collaboration, dictatorship, or isolation. Likewise, ask them about when they were a junior member of a team. How did they take initiative to learn technically from the more senior members? What did they learn about leadership by watching the more senior members?
Any of these questions are good for junior and senior hires alike. You don't want to hire a senior who thinks they know everything. Likewise, you don't want to hire a junior who just views themself as the novice, there to absorb but never take initiative.
So how do you build a team? Hire team members, not individuals.