[yesiamyourdad]

About 20 years ago, I used to do interviews that were "write a program to add two numbers together" (I think specifically I asked for a web application). It's trivial, right? There's actually a lot going on. They have to parse input, and sometimes you get strange things like "well if I make it use doubles then I'll cover all scenarios". You have opportunities to talk about error handling (bad characters in the input, int overflow, etc). You can talk about refactoring (now make it handle -,* & /). You can ask them about writing tests. Ask about how they'd handle arbitrarily large numbers. There's a bunch of ways you could take the conversation and really just talk about average developer activites.

What I liked about that process is that it relied less on their ability to suss out a solution to some problem they'll never have to solve on the job and focused more on average activities. Sometimes I'd get a candidate who would go "wait, is this a trap?" and start asking a lot of questions - good! Now I got to see them refine requirements.

Having them review a PR is a good exercise too, you can see how they are at feedback.