* Give us a presentation about a meaningful amount of work you did at a company (no NDA violations of course) and spend at least an hour talking about what you did, how you did it, what went well and what did not, and then be prepared for questions.
* Actual software development issues that the team sees every day (not hard mode, just normal) submitted as a PR - review it thoroughly.
* Given a running code environment, fix a bug (you have a debugger, full ide, and an hour to look at it) - not so much about the end result as seeing how you work and your process.
Long ago, I worked for a contractor company, so my colleagues and I had a lot of interviews to get sub-hired. As we had many of those interviews, we got pretty good at them, and we shared our experiences, knew popular tricky questions (like "swap using [place here any constraint]") and had names for different types of interviews. "Kick in the balls" was one of them, tricky questions which showed nothing, except that somebody solved that particular narrow problem or was already familiar with that question.
Having that experience, I know that the only reasonable interview is an open conversation. What was your last project? What was the architecture? What was problematic? How did you solve that? How did you come up with the solution? And so on. The candidate is relaxed, drinks coffee, and talks. After 1 hour, you know who you're dealing with.
If there's time, a pair coding session is informative. There are many small hints, like using shortcuts, that give away pros.
I have tried the first two things in that list. I haven't tried the third. I would need to think about how to do that in a way that is general enough that it can be re-used across candidates with different skill sets. I like the idea, though. Thanks for sharing it.
* Give us a presentation about a meaningful amount of work you did at a company (no NDA violations of course) and spend at least an hour talking about what you did, how you did it, what went well and what did not, and then be prepared for questions.
* Actual software development issues that the team sees every day (not hard mode, just normal) submitted as a PR - review it thoroughly.
* Given a running code environment, fix a bug (you have a debugger, full ide, and an hour to look at it) - not so much about the end result as seeing how you work and your process.