With the limited time we have in interviews, it's important to know the most important bits of information that will help you decide whether the candidate is a good fit. I roughly divide this into two questions.
# Will you be a good team player?
The questions I like to ask for an initial screening, are those that ask people to describe problems. I want to understand the following:
* Does the candidate feel they have internal agency to solve problems, or do they see problems as something on others to change. * Does the candidate consider other people when making decisions? * Is the candidate able to take action independently?
Asking candidates to share stories of failure or friction at work is a helpful way to see how they describe it. Following up asking them to explain why it happened, how it was identified, how the solution was implemented, etc.
Additionally, and specially for senior candidates, I like to ask about a positive impact more junior members have had on their career, and understanding.
# Will you be able to do the job? (Technical)
I don't believe code challenges work. Either because they're toy examples that don't reflect how the person actually works, or because they demand an amount of time that is unreasonable for unpaid work.
Instead I prefer to invite the candidate to share some code they've written. Whether it's for personal projects or with permission, a properly redacted bit they've done for work. I believe this lets us ask far more interesting questions.
* What tradeoffs were you considering when designing this? * What don't you like about it, and would like to change? Why? Why is it still like that? * What part are you proud of? Why? * How does this solve the customer problem? * How does this perform in operation? * Are there any known bugs and issues?
Questions like this let us dive more into real examples of how the candidate designs and approaches problems, deals with constraints, prioritizes, considers the customer journey, and works with others.