> Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited.
> Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.
> And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.
I've seen your interviewing approach in action and it works brilliantly. This is pretty much a step-by-step of the way my last hiring manager interviewed and he never failed to build very strong dev teams.
> Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.
> And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.
I've seen your interviewing approach in action and it works brilliantly. This is pretty much a step-by-step of the way my last hiring manager interviewed and he never failed to build very strong dev teams.