Software architecture questions are an interesting topic because unlike software implementation, you cannot simply give someone a task and ask them to demonstra

Software architecture questions are an interesting topic because unlike software implementation, you cannot simply give someone a task and ask them to demonstrate it. Architecture is not just a matter of selecting components, it's about understanding conflicting roadmaps for multiple teams and available human talent and technical resources. My favored approach for it has been to ask people questions that mirror problems I've been forced to solve in the past at the current venue you're hiring for. I think this approach has a number of advantages: 1. You know how YOU solved the problem, so you've got at least some qualifications to discuss it with authority. 2. You can answer any and all questions the prospective architect wants to ask. These questions and their quantity are often even more telling than any hastily described solution ever could. Do they ask about infrastructure? Do they ask about expertise? Do they mention specific tooling you yourself decided on? 3. This gives them a chance to wow you in a controlled environment. If their idea for a solution is better than yours, you know you have a very high value candidate. 4. This also is a supreme test of technical communication skills. They need to rapidly get YOU to tell them things by asking questions, formulate an idea, and then communicate it to you in a way you can understand. Of course this assumes the interviewer has done some architecture, but I think that's probably required to do this job right. Personally, I think all this talk of "war stories" and whatnot is not a very good idea. If you're concerned about someone's personality and grace under pressure, you should treat that separately from their technical skills. That way you can weigh those attributes separately and fairly when it comes time to decide if you will hire the candidate.