I hadn't thought of tech jobs being a target for fraud but it makes sense. Candidates will always test the market for how much they can inflate their experience.
This is exclusive of any level of seniority, which I like to be flexible on where I can.
While I wouldn’t say this is fraud per se, the candidates were obviously using a shotgun approach to apply to any job in the industry.
I'm a native Swift developer, with over 30 years' experience programming Apple devices, but I have also written a lot of PHP (backend) stuff, and Web sites.
A few years ago, I spent a few months, learning Android, and decided I didn't like it, but I do have Java and Android Studio in the mix.
I often get recruiters, trying to match me with Web design or C# (nowhere in my stack) jobs.
I'll still get pinged by recruiters for a senior network engineering job in Idaho or some such.
I never gave one single test, and I could usually weed out the spammers from a quick glance at their résumé. I often hired folks that didn't "hit all the sweet spots" on their CV, because I found them to be eager, energetic and curious.
Had a couple of bad decisions, but very few.
Much less extreme, but I've also seen many people who looked very similar in their resumes but were worlds apart in how the coding interview went. Some of them could quickly flush out specifications, asking good questions, talk about why they want to solve the problem the way they did, and fluently write code, while many others struggled in different areas or sometimes all of the areas. This is also really important for figuring out which of them we want to hire, and how badly we want to hire them.
How the interview is run matters a lot, and also what sorts of problems you choose. I think it's really important to choose problems that aren't essentially spending 45 minutes on one narrow knowledge test (especially of the "have you already seen this before" variety), but instead test as many aspects of the person's skills as possible. I want to see how they handle incomplete requirements, simple design, thinking about how to create an output format that is maximally useful to a consumer on another team, naming things, thinking about the runtime of different approaches, thinking about big-O space usage, thinking about back of the envelope space usage in bytes, coding, thinking about edge cases, etc. If I had more time I would want to check code reading, testing, and debugging as well, since these are so important to being an effective programmer, but they're unfortunately much slower to evaluate.
[1] I've interviewed people like that as well, and within the confines of the interview I've been asked to run the best I can do is note that I don't think we're able to evaluate them well this way.
I'm spoiled. In my open-source work, I've done some fairly significant (but still below-the-radar) stuff, and got used to basic, simple, respect; without people trying to wrestle me into some kind of subservient role. That's not to say that we didn't have disagreements. Quite the opposite, in fact. I've done Service for some of the most disagreeable people that you can imagine, and left them happy and enthused.
So I actually looked at a few startups. I have a fairly unique conflux of skills and experience that could make an enormous difference in small teams. What I found, is that they imagine themselves to be "mini-FAANGs," and treat their prospects pretty badly. I know that startups tend to have rather chaotic, personality-laced workplaces (see "working with difficult people," above), but if they can't keep that crap out of their triage interview, then the place, itself, must be a nightmare.
I'm working for free, for a friend. I stepped in, because I watched him being set up by contract houses that were obviously going to do very bad work, for lots of money (they barely hid it; I guess because he's non-technical, and doesn't know better). Since he's doing an NPO, and looking at grants for funding, he can't afford that kind of object lesson.
Instead, he's getting a platform that would make a lot of "big houses" green with envy. For free. This is something that I have a lot of prior art in. It's already pretty awesome, and I've only been working on it for a month.
There's a lot to be said (and gained) by simply treating people with basic respect, and motivating them. The workplace is not the military. If we treat our employees and co-workers badly, they won't stick around. If we treat them well, they could do some pretty amazing stuff.