[genezeta]

Do an interview with 2 or 3 people from the team with the open position. Include in the interview a discussion about some recent piece of work the team has done. Ideally choose something not too big nor too small. Do not choose an absurdly obscure bug you fixed or an overly weird or complex feature.

Once in the room, don't go too hard on it. Present the task and whatever limitations and then ask for approaches, concerns, potential solutions, cost... Do ask for details but not necessarily written code (unless they want to write something to explain some idea and it is simple, scribbled code). Let them explain their idea, the approach, the tools, the solutions, the difficulties they see. Discuss potential problems with those solutions, if any. Think how they match -or not- what you actually did. If it doesn't match, compare and evaluate why. Discuss your solution with them.

BUT: Do not take shortcuts. Don't use a generic task or exercise but something you've actually done in the last 2 months. Don't just ask a bunch of fixed questions but do strike an open conversation and discussion as if it was closer to a planning meeting or a brainstorming with a colleague instead of an interview. Don't just present your solution and discuss that but leave room for their own ideas. And don't just scoff and brush off any ideas you already discarded or know that don't work, though you can, obviously, point out any problems with those solutions. Finally don't simply evaluate how close they get to how you actually did it but focus more on the thinking process, how the way they approach the process matches your own.

Try to do this "gently". The candidate may be nervous. Make an effort to explain that there isn't a single right answer and do make it feel like a conversation not just a bunch of questions. Use the fact that there is more than one person from the team to your advantage in making it conversational and casual.