Well claiming is a very far galaxy from "demonstrating". What about references? What about networking? What about published books and papers. This stuff is very hard to make up, especially references.

It can be a chicken and the egg problem. None of those matter if the person can code and solve problems, and is a good fit. We don't care if they are 15 or 60 years old.

I think you'd be surprised that it's actually a lot easier than one might think.

Unless they are references from people who those involved with hiring personally know.

This. We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer, who can't explain the difference between a list and a vector (or when to use each), or give even a ballpark estimate for search/insert/remove times for a basic BST. At the same time, there are candidates who are technically good at coding, but terrible problem solvers. We do use whiteboards for the interview, but more as a conversation starter for the algorithmic design, and don't expect compile-able code. In fact, when I interviewed here a year ago, I didn't touch the whiteboard, and we just talked about the design, tradeoffs, wrinkles/edge cases, etc.

It is usually a pretty organic process. If we get into it and question their coding ability, we might ask a few basic questions, like how do you declare an array or vector in C++. Do you use std::algorithm? Then possibly into C++14 territory. It depends on the position. On the other hand, if they breeze through some basic coding questions, it quickly turns into a discussion and feeling the candidate out in terms of fit. But if we get a senior SE come in, and we talk about previous projects and we get "I fixed bugs, reduced memory usage, and saved $X million dollars" that is a big red flag.

> We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer...

Sounds like your expectations are part of the problem.

Why do you expect someone 15 years out of university, working in the now enormously wide software space to have your pet questions memorized? C++ is well known for being too big and needing to be subset(-ed). And, why not realize that such a person could become an expert in those questions in less than an hour of googling and reading?

The bigger problem is that companies are not willing to invest even four hours of training into employees!

I assume you're exaggerating slightly and that you mean "couldn't code as well as the resume suggested". How certain are you that the pressure of the interview (which often means broken concentration, poor sleep the night before, etc) and the unfamiliarity of the setting (even typing in a Google doc without proper spacing, syntax highlighting and auto completion can be incredibly disorienting) aren't a major factor? Isn't it conceivable that some worse coders are better under such circumstances than a great coder who suffers mightily under them?

I don't think he's exaggerating; for the past 4 positions I've had to fill (at six figure comps) 80%+ of candidates with extensive resumes couldn't solve a simple recursion problem. We give the a notebook with an IDE and access to the language docs.

These folks with many "senior" level positions on their resume can't manage a task our last hire did in about 6 minutes.

because swift remove the ++ operator?