A major part of what makes somebody "the best" is tacit knowledge. This is the sort of skill and "know-how" you can build up from experience and one-on-one instruction, but cannot easily be captured in text.

For programmers, this manifests as some mix of intuition and taste. I've worked with people who have had some especial insight that most doesn't; they don't necessarily "produce" the most, but they make the right key decisions and create the kind of core abstractions and systems that provide a better foundation for everything down the line. Or, alternatively, perhaps they're just preternaturally great at finding and fixing bugs. (My experience has been that really good folks tend to lean heavily towards one side or the other, even if they're solid at both.)

I've written before about how this should change how we structure our teams and manage creative, high-leverage work[1]. The same concept should also change how we find and evaluate candidates, but, honestly, I'm not sure how. Evaluating tacit knowledge and expertise is hard, even for experts!

One thing I've found that works is figuring out a way to show-rather-than-tell that you're willing to do things differently. Doing things differently won't be appealing to everyone, but it will be very appealing to specific kinds of experts! When you can't compete on comp and brand, this is one of the better options. One way to do this is to use a specialized, niche language like Haskell. Alex saw this in action at Freckle and I saw it in action hiring folks for Target's supply chain optimization team. But it doesn't have to be a language specifically; it just has to be something that at least some experts care about, and that you can demonstrate. (Just saying you're doing something different or technically interesting won't work because everybody is saying that!)

[1]: https://jelv.is/blog/Letting-Experts-Be-Experts/