[ethbr0]

I've also had good luck asking about a project they were on that went off the rails and what they'd do differently next time around.

You can tell pretty quickly how involved they were and if they were thinking through solutions vs just doing as told.

[squeaky-clean]

I also ask the same question. Because of my current industry, usually with the caveat that they have to be able to get into some technical details without breaking NDA.

Some of my favorite other questions are:

1 - You're diving into one of our repos for the first time and you need to add X feature. Let's assume everything is perfect, what would you want to see in the repo and what are your first steps in learning the code?

2 - Tell me about your favorite bug? It doesn't have to be one you caused. And it doesn't have to be a super technical obscure bug. Just your favorite bug.

3 - What are some of your personal philosophies when it comes to programming. In other words: What are some of your opinionated takes. I understand, when working here you'll follow company policy. But what if you were the person who wrote the company policies.

All are great jumping off points for further discussion and open up a lot of followup questions. I find they're pretty hard to fake after the conversation goes on for more than a minute or so.

[yieldcrv]

> You can tell pretty quickly how involved they were and if they were thinking through solutions vs just doing as told.

Yes, but which has more utility for you.

Do you tell people what you are indexing for? Its not a fair assessment if you don't tell which has more utility for you, or don't tell the recruiter how to help people prepare and just gaslight people with "there's no right/wrong answer, I just want to see how you think" if you actually want someone that does what they were told or someone that synthesized solutions. Many people have experience in both environments and have an answer for both environments.