Your first hires need to be people who make the company faster, not slower. A single bad hire can sink the ship. Someone who is great in a large corporation can ruin an early start-up.
Personally, I'm hoping for low-ego high achievers. But that's up to you. This is where you get to define what the company culture will be.
A verifiable track record beyond the CV, that is extremely hard to fake with valuable experience that you did not know you needed.
As I said before:
1. Open source contributions to high-profile / major repositories (with code-review in the open with core maintainers). No hello world / demo projects.
2. Production-grade shipped projects / side-projects with paying customers or high-profile companies using it and is bringing in recurring revenue.
3. Given several presentations at conferences discussing anything from your project as a library author, maintainer or at a company showcasing your engineering expertise.
All are extremely difficult to fake and easy to verify and requires a level of effort on the applicant to qualify which filters 90% of noise out there. Years of experience is not a requirement but a bonus.
The rest of the other methods like leetcode, hackerrank, take home projects or quiz trivia, wastes time on both the interviewer and the candidate and both can be cheated easily using AI.
It is that simple.
Why you did this?, why this way? , why you joined this company?
This gives good understanding of both Personality and Hard skills.
They don't need fancy credentials or to be super smart or have a great internet presence; what you should look for is a track-record of shipping, and evidence of independent work; and when you interview them, find out if they have good judgement, if they have a sense of when to trade off perfect for good enough, if they're able to diagnose and fix things when they're broken.
As you grow, you can add more traditional engineers to build a more conventional, well-rounded team. But most companies don't get to 20 employees if their first 5-10 aren't able to work quickly & make good decisions without getting side-tracked on all the myriad little distractions of designing the perfect framework for the framework, office politics, dev environment isn't quite right, etc, etc.
My experience has been that solving a very technical problem and solving a social one are very different skill sets and very few people have both skills and are capable of using both of those skills at the same time.
In the beginning, you need the person who knows how to solve the problem. They are harder to find.
If you are pressured to grow quickly, you might be tempted to lower the bar. You can, as long as you understand that the person who knows how to solve the problem is still critically important, because they will be telling people which algo to use.
I think every company that uses tech needs at least one of these people to start with.
Give me 10 of those and you can kiss anyone goodbye.