First, accept that the vast majority of people you want to hire are already employed and normally couldn't be bothered with your startup. The leftovers are either really unlucky or not worth hiring.
Second, go after the top 98% and leave the others for the rest of the industry. Don't waste time trying to interview them beyond a quick phone screen on personality, because any time of theirs you ask for is extremely expensive to them and you need to acknowledge it from the start (or they'll not respond). Offer them _more_ than they're earning now. After you find one you like, and you're willing to pay them more than they're currently getting, and they're willing to jump ship for that, close the deal as quickly as possible.
This works because their current employer vouches for them (by employing them), and their current employer is presumably a better judge of technical skill than your team is. So leverage that skill instead of cobbling together some facsimile yourselves.
The downside for this approach is that if they're currently earning $200k and you have a budget of $120k for the position (or even $220k), you're not going to hire anybody. It's a shared delusion in the industry that everybody can lowball the senior talent and they won't wise up.
It's been said before, but it bears repeating. For senior talent, you're not buying the job, you're selling it. It's a buyer's market and you need to play motivated salesman and not choosy PITA customer.
Hopefully you mean the top 2%, or the 98th percentile. /snark
Generally though, I agree with this advice for small companies (i.e. your first ~5 hires). I would recommend making a list of experts on your stack who you would love to work with. Trawl GitHub, StackOverflow, HN, LinkedIn until you identify a list of candidates that are verifiably good at what they do. Then just start recruiting them, a.k.a. selling your company and vision.
For small companies, this aggressive approach seems like it would be both more reliable and efficient than the "pull based" approach of vacuuming up resumes.
I mean I've been on the job market for a long time now. I'd actually prefer some kind of full time commitment over doing boring CRUD apps. But it's just not a good deal. Interview process is either too painful, compensation is too low, or the job is too meaningless.
Why? There is a lot of stuff happening in the top layer of everything (UI, full-stack, os/cloud/vm/container)... and it is impossible to evaluate properly knowledge in that area.
BUT... If I ask for basics (OS, Database, organization, how to isolate processes from each other, how to scale), I can see if the answer is solid technically, if the candidate can articulate an answer, how she/he communicates.
Also, I always ask for a projects candidate is proud of.
I want to hear what (s)he did, and why. Architects have to decide stuff, so I want to hear the whys and the why nots.
Then I ask what the would do differently now in the same project.
Reject the candidate if (s)he would do everything the same way: there is always room for improvement, and shit usually happens.
This is a sign other people did the work, or the candidate has a complicated personality that might backfire after hiring.
The great thing about anyone who's working in their trade more than five years that you can actually ask them "what were the most interesting projects you worked on" and get a meaningful response. I would ask him about the experiences of what you just listed here and go with the flow. Also you may want to read about CAR (context action result) interview method to have a better understanding how should you structure your questions about these topics.
What was the worst problem erformance wise he had to overcome? What was the largest team he ever supervised, why did he get in that position? If you talk about these kind of questions for a good hour or two you already will feel something about this person. You then have to transorm this feeling to a yes or no as a team. As he will be your future mentor and technical leader I would interpret the "yes,but..." And "no, but..." Answers as "no".
With senior engineers, you tell them what you do and ask them their opinion on it. Pay attention to their questions. Ask them what they think would improve the system. Pay attention to how they diagnose your system.