I like to get people to talk about a project that they are proud of that that they felt particularly engaged with. If it's a hobby or a side project that's great, but if it something they did at work that's great too. If they're not proud or passionate about anything that's a bad sign. This kind of question is good for rapport building and will often put the candidate at ease so it's good to ask this question early in the interviewing process.
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.
Provide some sample code, perhaps with bugs, perhaps without, and ask the candidate to add features, etc.
The point of a useful interview is to learn what it would be like to work with someone. The point of a coding problem is that it gives the candidate a chance to show you how they work. How do they break down a problem and start devising a solution? How do they communicate about their thinking? How do they resolve uncertainty?
