[terryjsmith]

As with any interview, I like to make it as personal as possible. Tell me about something you have architected and why you've architected that way. I will ask probing questions about why you chose this stack, this database tech, this integration layer, questions about security concerns, areas for improvement, what you learned and would've done differently, etc., etc. This also allows you to see the interviewee's excitement and really turns the table to put them in a comfortable position where they are the most knowledgeable person, which makes for a much smoother interview. If that goes well, I may turn to some specific tasks or problems we have faced or are facing and discuss at large how those might be addressed, again really focused more on brainstorming than any "right" answer.

If you don't have any projects or work to talk about, the interview is basically over as I don't see much value in talking about cookie cutter problems.

[corysama]

This is great stuff. A fun bit to add is "That thing you made, if you had more time, how would you make it better? How would you make that version better?" And, so on until it start to get a little ridiculous.

[maxxxxx]

I do the same. With people who actually know something an interesting conversation will develop.

A lot of "architects" will only repeat generalities and have nothing left to go deeper. I also don't like too many buzzwords like "integration patterns" or "serverless architecture".

[pacaro]

Also, what were the pragmatic trade offs: CapEx vs OpEx; development time vs quality; etc.