The best software engineer interview performances feel like a collaborative experience between the interview candidate and the interviewer. If an interview is going well, you will be supporting them as the interviewer and maybe giving hints. However, both sides need to be careful about how this happens.
Here are the core points from the video:
- Giving hints is tricky. There are some situations where it's good and some where it's bad.
- In general, you should lean towards giving less hints as an interviewer to maximize the signal you get.
- Don't give hints when the candidate is desperately fishing, and they have no idea how to solve the problem.
- Fishing example: "Can we use a binary tree for this?" (they didn't explain their thought process at all prior to asking)
- Fishing questions like the one above are tricky as you can't answer them normally:
- If you say "Yes": You reveal the core pattern behind the problem, solving way too much of the problem for the candidate. At this point, they have failed the question.
- If you say "No": The candidate is one step closer to the core solution via process of elimination. This sets them up to keep fishing until you say "Yes".
- When the candidate is fishing, say something like, "How do you feel about it? If it makes sense, we can try building it out." Flip the question back to them and push them to think through it more.
- Give hints to bridge small gaps. If the candidate is 90%+ of the way there, just give them the hint so everyone can move on.
- A common scenario here is that the candidate has almost all of the solution working minus some trivial 1-liner. You are losing signal by having them struggle on this trivial piece and not working on other, larger problems. In this case, just give them the 1-liner.