Yes. I've interviewed "senior software engineers with 10+ years of C++ experience" that could not tell me the difference between a char and a char pointer.
When I see "expert" on a CV I have learned to become cynical.
I asked him about his expertise and he spoke in platitudes about it - at a sort of BBC News kind of level. I'm certainly not an expert but I know sufficient to be able to ask useful questions about it.
He couldn't tell me anything at all about biometrics. I continued to probe.
Turns out that by "biometrics expert" he quite unashamedly meant he had, at the request of a manager, bought a USB fingerprint reader from PC World and installed it so that his manager didn't have to use a password any more.
One has to play this game on marketing documents to be considered. For some reason "pretty good, definitely still learning" doesn't click with many HR people. You can't really blame candidates for trying to get hired by presenting themselves in an authoritative context.
I don't consider anyone an actual expert in something unless they have hard, indisputable credentials, like a long history of commits to the core project (for expertise in specific software/languages/frameworks), etc.
But something about "expert" really grates on me. I think it's that it is a self-anointed title in nearly all cases. There are legitimately experts in lots of different areas - if you happened to invent IDS, for example, you go right ahead and call yourself an expert. If you happen to have run a bunch of Snort rules across a prod environment for a year or two, you might be "experienced", go on, stretch it to "highly experienced" for all I care, but if you stretch it to "expert" then paint me cynical.
Some of these stories about super experienced ("10+ years") developers not being able to answer the most basic of basic syntax or "algorithm" questions seem far-fetched to me.
I'm not sure how this is possible either, but the world works in mysterious ways.
Really I don't think those sort of on-the-spot tests/trivia questions are representative by themselves. They may be a useful part of a larger investigation.
Two things to stop code sample plagiarism: choose a unique code challenge and, if you're really worried about it, give the client a laptop and tell them to bang something simple out right there and come back in 30-60 minutes to check.
Honestly, though, I've rarely depended on either code samples or code trivia to determine if someone is a good hire. If you sit and talk about dev with a person, you can tell if they're on their game or not 90% of the time. The sample/on-the-spot tests can help weed out that extra 10%.