I have been given an opportunity to interview someone for a Solutions Architect style role within an organisation, and as such given a chance to change the method / style of the interview if required. Which is great, as I know of some additional questions and such I could ask that will hopefully give the candidates an opportunity to really shine.<p>However, the main bulk of an interview would either be a technical test or a solution on a whiteboard - and I have seen that these are slowly becoming a bit of a pain rather than something enjoyable when someone is in interview.<p>If you were looking for someone with a background in cloud architecture, what sort of methods have worked for you in the past? Does the style of a scenario with a whiteboard and time to design and defend still produce the right type of person?<p>Not expecting the answers, but if I get some suggestions on ideas, that would be awesome!<p>Thanks in advance!
I interview most tech roles the same way regardless, but actual architect roles I usually do a design heavy focus as you'd expect.<p>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.<p>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).<p>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.