>"does this person really know their stuff or are they just good at taking tests"

Which is interesting, given that the places that should be able to tell if a person really knows their stuff tend to lean hard on "leetcode" type interviews. Which is basically "is this candidate good at memorization and taking tests?"

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

> to figure out if a candidate is any good

In a lot of organizations, the people responsible for identifying if a candidate is "good" and the people who are responsible for calibrating their offer, and where they enter a ladder in terms of seniority, are entirely different groups. Certifications are justifiable insofar as they're aimed entirely at the latter.

And those are precisely the organizations I avoid like the plague. I’ve gotten to offer stage before and sensed this type of disconnect and promptly declined to continue in the process. It’s a huge red flag if the finances of a technical organization are controlled by people who don’t understand technology and consequently that unable to ascertain and appropriately appraise value.

Many of those organisations are strong contributors to the FOSS that everyone around here enjoys playing with.

Curious to know what % of all companies you probed to get to your "usually".

Many dozens through the years and across the spectrum of industries, company sizes, and ages.

Dozens of %?