There is an aspect of hackerrank-style questions that tests raw preparation, but in my experience interviewing people with customized/twist versions of these problems, nobody is just coding up a solution they memorized either. They’re composing ideas they already know, but this is exactly the skill we want to test them for anyway. I will grant that being a good test taker, calm under pressure and relaxed enough to talk through the solution, working methodically until the end, these skills do make a huge difference in interview performance. In my opinion it is the candidate’s responsibility to prepare for the interview environment as well.

My opinion is that you're missing a lot of good talent with this sort of approach. There are people that are just as good/fast at solving problems in a quiet space with the ability to play around with trial and error in an actual dev environment. They can answer your questions well too, given some time to mull it over quietly.

Being able to do it on a whiteboard with people around you, and answering questions right when they are asked is a skill, I admit. It's a poor analog for what the work usually ends up being, though.

There was a time when candidates would get stuck on a problem and I would tell them "if you want, keep working on this problem and email me tonight with your work." Most people didn't follow up, but some people did, and we usually hired them. They usually had very high grit and follow through, but were unfortunately (as a rule) slower and generally worse at their jobs than other hires. We had to let one of these people go despite his excellent communication and organization skills. Today I can rely on a stronger recruiting pipeline so I don't need to make exceptions like this, but I'm not really sure if I would go back given the chance.

No matter how much grit you have, if it takes you 10 hours to do what everyone else is doing in 1 hour, you will struggle _a lot_ at your job.

Perhaps the working environment just isn't what I'm used to. Assuming the interview is closed book, no internet, you're measuring recall against whatever random questions you ask. It's hard for me to picture that really mapping against the real work at hand.

Theres generally no memorization required for leetcode style interviews, its about having a strong background in algorithms and data structures

I say memorization because they don't allow you to look anything up. I can, for example, look at a problem and remember vaguely that there's an algorithm and/or data structure that's ideal for solving it and some of the high level concepts/keywords I would need to find it. I also know the right google foo to find it again, see if it's still current best practice, find a decent implementation of it, where good documentation is, and so on.

I can't always bang it out on a whiteboard from memory though. If I could, I don't think that would somehow make me a better developer. It might make be a better T/A in an academic environment, but that's not typically what these kind of interviews are hiring for.

Which basically limits to newly graduates or those lucky to work in domains where dealing with leetcode style programming is daily stuff.

Yeah thats fair , definitely agree that its more useful when interviewing new grads