As a rule they aren't insulting – but as with anything there are good and bad implementations. I've been on both sides of the fence, as both an applicant and t

As a rule they aren't insulting – but as with anything there are good and bad implementations. I've been on both sides of the fence, as both an applicant and the hiring manager. I personally hate "leetcode" nonsense, "find-the-bug"-style quizzes or algorithmic white board challenges. I'd consider going through with them as an applicant, depending on the organisation, but I don't think they're useful tools and it would be a bit of a red flag that suggested they didn't have a great hiring process. But I realise that people have different views on this and try not to take it personally. We have settled on using a compact take-home coding exercise, which is a pretty representative example of the sort of thing we do day-to-day. There are obvious downsides to this, in that it requires a few hours of commitment, but we've tried to be as flexible and light-touch with it as possible. My experience is that roughly 50% of people totally flunk it – and this is post-first-interview, after we've had a decent chat and decided that they can communicate and have the right level of apparent expertise. And our analysis isn't that harsh – it's basically "did you write code that I could read and which does something in the ballpark of the spec". It's pretty surprising to see so many don't hit that bar. I am very much aware of the requirement to be respectful of everyone's time, so I figure this is probably fairer than having people waste effort continuing with the process when they've no chance. Any approach you take is going to have a set of tradeoffs, and all you can really do is make sure that whatever process you put in place is checking for the things you want.