I don't think there is a silver bullet here. I've been working on our engineering hiring process for the last couple years for a company with ~200 engineers - reading everything I can on the subject during this while.
Most articles complain about the status quo but don't offer any practical advice. When they do, it is some approach that may not be an option on most cases - e.g. 40 minute interview followed by a 90 day probation period.
Live coding interview can be pretty tough for candidates, but we try to make a lit bit less difficult by:
- Giving them time and resources to prepare.
- Letting them use their preferred language and IDE/editor.
But since you have no control over format or time, maybe try to:
- Use reasonable problems - to assess skills people will actually need on the job. In our case it usually boils down to using comodity structures like a dictionary or map to do simple tasks efficiently.
- Use problems that start simple but can be extended. This is good because when candidates finish the first part, they get a boost in confidence. It is also nice because if they freeze, you can help them finish the current "level" and still have material to assess other skills.
- Set them up for success during interview:
- Reserve the first 5~10 minutes for introductions, ice-breakers or questions about the interview.
- Reserve the last 5~10 minutes for the candidate to ask any question about the company or the hiring process.
- Make clear that is OK to ask any question.
- Help them on small blockers.
- Be friendly.
Making these little tweaks helped us to diminish the pain of this kind of interview.
Most articles complain about the status quo but don't offer any practical advice. When they do, it is some approach that may not be an option on most cases - e.g. 40 minute interview followed by a 90 day probation period.
Live coding interview can be pretty tough for candidates, but we try to make a lit bit less difficult by:
- Giving them time and resources to prepare.
- Letting them use their preferred language and IDE/editor.
But since you have no control over format or time, maybe try to:
- Use reasonable problems - to assess skills people will actually need on the job. In our case it usually boils down to using comodity structures like a dictionary or map to do simple tasks efficiently.
- Use problems that start simple but can be extended. This is good because when candidates finish the first part, they get a boost in confidence. It is also nice because if they freeze, you can help them finish the current "level" and still have material to assess other skills.
- Set them up for success during interview:
Making these little tweaks helped us to diminish the pain of this kind of interview.Some links/references:
[1]: https://lawler.io/scrivings/erics-guide-to-hiring-software-d...
[2]: https://medium.com/@alexallain/what-ive-learned-interviewing...
[3]: https://www.holloway.com/g/technical-recruiting-hiring/about