> “Often, I will give them a scenario where the processes are failing the team to find what they would do to tackle inefficiencies and if they would be willing

> “Often, I will give them a scenario where the processes are failing the team to find what they would do to tackle inefficiencies and if they would be willing to speak up.“ While the intention here is good you are unlikely to get an accurate answer from the candidate using this method because the candidate “should” tell you what you want to hear rather than what they would do in reality. You basically want to find out how the developer delivers criticism. Do they bruise egos or are they tactful or do they simply stay silent. A better approach is allowing a candidate to demonstrate how they offer criticism. Give them a codebase to read and make sense of and ask them to explain it to you. Ask them to to point out parts that could be better designed. You can gather a lot of information this way. 1. Can the candidate read a foreign codebase and make sense of it. 2. Can the candidate pick up business logic from the code. 3. Does the candidate offer criticism that is likely to make another developer defensive or are they more guarded with their communication and offer higher level design alternatives.