I have only really done technical interviews. My process is to give the resume a once over to understand what technologies and project they have used that I ha

I have only really done technical interviews. My process is to give the resume a once over to understand what technologies and project they have used that I have a deep understanding of. I then prepare a few questions around those areas and order them in increasing difficulty. First I'll ask someone to describe the project, then I'll hit em with a question that proves that they actually did what they claim, then I'll ask them a question meant to push their limits and see how they react. Finally I get to my most important part, which is taking whatever project they described to me and then asking what they would do if their boss came in today and tweaked the requirements. I'll use a requirement change that would force a serious re-architecturing. Exe you built a crud app, what if you needed to support 10,000 concurrent users? You made a data extraction tool, what if it had to extract 1000 Gb of data instead? You built CI for your project, what if that project had 30 developers? These types of questions tend to show how a developer thinks. The hard part is making sure they are comfortable enough to brainstorm with you, as many technical folks would tend to close up under a lot of pressure. Basing it off of a project that they already know well tends to help give them a starting off point. In addition to this, I like to give them a real problem that the interviewing team has experienced recently that is within their claimed knowledge base. For example if someone claims to be an aws microservice guy, I'll ask them about a time when our AWS ECS jobs needed to decrypt files that were bigger than the maximum allowed disk size. There are many different ways to get around that limit, but they all have tradeoffs.