Good.

Whiteboard coding is probably one of the least useful methods I have ever seen to evaluate candidates. It tells me nothing about the persons actual qualification and can be gamed.

My warm-up questions are usually something like "reverse a singly-linked-list" or "check if a string is a palindrome", and you would be surprised at how many people have just no clue on how to do it, even with a lot of help (and I work in a FAANG so we should be getting decent candidates).

I could probably work these problems out, but I might not seem too confident about it.

> It’s just basic usage of objects in the case of a JavaScript implementation.

Just because you would make a linked list via objects doesn't mean that anyone would actually do it.

Probably many times a day actually, whenever you use an ArrayList or the equivalent in the language of your choice.

So you'd be great for a job whose task is doing coding interviews then!

I don’t know how to do it. I would need dictionary.com to find out what a palindrome means and stackoverflow for the rest, but I’ve used and evaluated five different JavaScript frameworks in building full scale web apps. Would you hire me?

Needing stackoverflow to check for palindrome-ness would probably be a bigger problem though. Of course during your day-to-day you'll be allowed to google all sorts of things, but checking if something is a palindrome is so basic that all google could possibly provide you is the exact answer to the question.

And if you need stackoverflow to reverse a linked list, no, I would not hire you.

Many people have used many technologies. I started programming when I was 12, and I had no idea of what I was doing beyond copy-pasting code from tutorials and putting them together, but if "how many technologies did this dude work with" is your criteria, you would have hired 12 years old me.

On the other hand, usage of linked lists in the wild can be rather limited outside c/c++. Only languages I’ve used them a lot and then only when I was teaching algorithms and data structures.

I think I used a linked list for a MRU list in a menu someplace ages ago in c# winforms app.

You use linked lists in pretty much all languages, they're just hidden behind the flavor that you prefer, List in C#, LinkedList or ArrayList in Java, etc.

I've written sites, apps, ORMs, enterprise tools, code generators, FAAS platforms from scratch, exporters for DOCX and EPUB, etc etc for decades. I've been junior, mid, senior, lead of two teams. I've transitioned companies to cloud, created data warehouses, built BI universes. All sorts of stuff over the years.

Sounds like your hiring techniques would pass on me, as those whiteboard exercises would have me saying no thanks and ending the interview. Utterly pointless.

(and FYI that's from experience on both sides of the table as I've also been the recruiter interviewing from junior devs to team leads)

Then I saved 45 minutes of my life, great. The point is, if you want to join the company I work for (and many people want to), you have to jump through the hoops of this company.

You should re-read the start of my comment, because I don't think those whiteboard questions are a great way to hire people. I just don't think there's a way that's more respectful of the candidate while being time efficient and providing good data points.

The truth is that the achievements that you claim can have been done by others. I'm in a top 1% company, and yet I see many people that are just utterly shit at being software engineers. There are parasites like this everywhere and they can just coast and claim the achievements of others for themselves (especially when applying to another company that has no way to verify their claims), so whiteboarding exercises and others crap is 100% necessary, no matter your level.

But fair enough, if it works for you it works for you.

They're not guaranteeing that an applicant is necessarily right for the job, but they do separate the chaff from the wheat proverbially speaking.

This is where we differ. What they separate isn’t chaff from wheat, but those who can do a specific type of interview from those who can’t. The latter aren’t chaff and the former aren’t wheat.

The only time these kinds of questions/tasks are suitable is if they genuinely represent the work being hired for.

Our opinions on this differ, and that’s fine, so whatever works for you.

But then you work with these idiots that can reverse a linked list in other companies and they can't organize code to save their lives. They use patterns and shit they used in facebook everywhere, even when they shouldn't because they always so smart and right.

(yes, after cleaning up code for shitty ex facebookers and ex netflixers, my opinion of the 'wheat' boils down to they may be wheat, but they infested with parasites and bugs and rotten at the core, but hey, what do I know, just been doing sw development for 25+ years, published author and worked on stuff that most here use daily, I'm just chaf because I don't want to work for FANGs)

It CAN show that.

Problem is; even a terrible candidate can prepare, knowing the kinds of things that will likely be tested, by memorizing the solutions to these very specific problems.

Sure, it comes with experience and lessons learnt. But, I don't think a junior dev would straight talk to finance guys for money. They would have support from his own tribe in some form (PM/Manager/Director). Nonetheless, you are making a good point. In sprint demos, I make sure my team members do not bring up any tech jargon.

> In sprint demos, I make sure my team members do not bring up any tech jargon

thats exactly what i mean. the audience does not care about the tech, they care that their problems are solved and money is made.

Do the suits at Boeing get upset that the engineer they hired keeps talking about things like thrust, lift and control surfaces instead of what EBITDA will be this quarter? Actually maybe... That might be the reason airplanes are throwing themselves at the ground and why all your personal information is now public knowledge.

Interpersonal skills and confidence are deciding factors after you've filtered out the candidates with low technical skill, as determined by leetcode, whiteboard, online coding exercises, etc.

Once again, I've seen enough candidates talk the talk, and then get caught typing in answers verbatim from Google or SO, to know that eliminating coding exercises in the interview process is folly -- it's opening the door for bad hires who can't code and who waste everyone's time.

On a super short timescale with no testing feedback loop, 99% of "algorithms" questions are "Have you encountered this thing before" shit tests in practice, rather than meaningful tests of problem-solving skills, and do not effectively test whether someone will be effective. This is to me a classic Goodhart's Law + policy problem: One can easily assess the answer to an algorithm problem, so it's popular as an assessment and becomes pervasive. Goodhart's Law predicts the next part

But ultimately it seems very divorced from reality of what I do, which is TestOps (building out CI pipelines, reporting, test infra, etc...).

I don't see a need for outrage here.

I've seen this used as justification for implementation of shiny third-party things that were both a fundamentally unfit solution and permitted those pushing it to avoid understanding the root cause of their current problems.

A lot of people are just really scared of what they don’t know, and don’t even give themselves a chance to self-teach or expand their skills