> they speak about how these exist to reduce false negatives

This doesn't sound right. Are you sure that they were referring to false negatives? Or is there something specific about the example problem? As far as I understand the interviewing process, the false negatives is the group the employer cares the least about. To be clear:

    True positive = good candidate, got hired

    False positive = bad candidate, got hired

    True negative = bad candidate, got rejected

   False negative = good candidate, got rejected

As the hiring company, you don't care how many false negatives you have (i.e. how many good candidates you reject) as long as you get a high number of true positives and a low number of false positives. The metric for this is called precision.

    Precision = TP/(TP+FP)

In my experience companies tend to optimise their hiring process for precision and algorithm interviews are a part of this.

Sorry thank's for correcting

When I interview candidates, for me the coding interview is an opportunity to see how the candidate reasons about a problem, how they communicate their thoughts and if they are able to ask for help or get pieces of advice and action on them.

Whether they can solve the problem or not it's almost secondary. Of course, there are expectations based on the level for that role, but I prefer to hire someone that fits the team culture rather than some random rockstar developer.

If the candidate can do the exercise correctly and efficiently that's, of course a plus, but again, not a blocker.

Finally, I do think that for more senior roles it is good to also try to have a whiteboard session where you can discuss more high level / architectural problems. This will help to get a full picture on the level of expertise of the candidate and it's another opportunity to have a conversation and see how the candidate explains their idea or react to rapidly evolving scenarios.

I hope this opinion helps, but keep in mind it is only my opinion :)

I would not call adding two binary numbers algorithmic.

Having candidates write code is always a good filter. You'd be surprised by the amount of people who can't write a nested loop with a decade of experience under their belt.

Playing devil's advocate, and being on both sides of the interview, I've noticed that a lot of people new to the leetcode interview game see nested loops as deathly evil and desperately try to find some "trick" or "gimmick" algorithm that would let them avoid it.

I was guilty of it too. I wasted a lot of interview time trying to spot the nonexistent gimmick when the optimal (or at least good enough) solution was in fact, utilizing a nested loop.

If you have a decade of real world experience under your belt, your first instinct would probably be to just write code that uses nested loops and perhaps refactor and optimize as necessary for performance.

But now in the leetcode interview game, you're often forced into a situation to prematurely optimize everything to get the "optimal solution" without running out of time.

That would still tell me something about the candidate. That they don't double check their assumptions is not a great sign.

For the record I always encourage candidates to start with the simplest solution and tell them we can then chat about improvements after we get the basics right.

Phenomenon like what I described is part of the problem with whiteboard leetcode interviews though.

Sounds like you're a good interviewer, and what you describe is how it should be. Even recruiting literature says that the purpose of the interview is for the interviewer and interviewee to "pair" or "partner" to solve the problem.

What usually happens more often than not though, is the interviewer is not very cooperative, and sometimes even hostile. S/he is not partner, but judge jury and executioner. So the interviewee, especially if they are new at this whole leetcode interview game, feels pressured to find the optimal solution ASAP otherwise face rejection.

And even if you tell them what you say above, they'll still feel pressured because if they "waste time" coming up with a simple, obvious, but seemingly suboptimal solution, then they feel that's less time they'll have to spend coming up with and coding the optimal solution.

I've heard this a few times before and I still don't get it. How do these people survive and manage to keep a job?