I interview most tech roles the same way regardless, but actual architect roles I usually do a design heavy focus as you'd expect.
Basic idea is have them tell you common design patterns they should know, if cloud make sure the understand distributed problems, split brain and how to overcome or mitigate them. I always ask them to pick their favorite design and have them explain it to me, they can leave out the proprietary functionality, but give me the design and how it worked together. What this will tell you is can they communicate and articulate the design clearly and when you ask questions/probe them about it can they defend it well. This isn't adversarial just discussion based. After I do that, I usually have them design a basic system framework for me, and discuss pros/cons and let them drive it and I play requirements producer. By that I mean I will give them a list of needs, share a list of requirements and tell them the goals, then it is up to them to ask questions and layout the framework and how they would break down the dev cycle.
I'd say the most important part for a solutions architect is to have good communication and be able to break things down cleanly and quickly. So on those types of roles I always focus on their design and structure along with their communication. I don't push on code or specific languages because in the end that is not their daily focus, although I may give a weird constraint on language and see if they push back or challenge it (look at me like I have 3 heads whatever).
Try to make the interview as if you were working with them, and not an adversarial challenge they have to pass to get a job -- this is for anyone you interview IMO.