If you lie about your work experience, it turns out you can't program Rust, then you can get fired for that.
But if you lie about never having been part of a union before, and it turns out you have been part of a union before, then you can't get fired for that.
If you get fired for being part of a union, then you’re being fired for your political position.
It’s not your fault for lying on the resume, it’s the hiring teams fault for not catching it
Anyone who ever complains about how ridiculous hiring interviews in software development have gotten should be referred to this comment. This is exactly why these absurd practices exist. Because people think they're entitled to lie, and it's your fault if you don't catch them.
Most of what I see people lie about isn't the companies they've worked at, it's the kind of work they do. For instance, when I was looking for a senior engineer I'd get people who said they did all this product architecture work, leading teams in the weeds of building products internal and external. A lot of those people turned out to be actually working on projects by themselves or they didn't actually do any technical work. The latter is pretty easy to identify because if you start asking them nitty gritty standards questions about what they built they'll be completely lost. One woman that stood out like this was part of a ton of professional organizations, and was even being granted some really big title in one of them so I was pretty bullish that I'd found my senior. The last major project she led a team on was an internal REST service, so I figured it'd appropriate for us to workshop a REST API design. Pretty easy stuff to iteratively improve through a conversation especially if you've done it a thousand times. She didn't understand the grammar of REST much less how APIs are grouped. By that point I was starting to realize her role was likely more administrative than technical as a lot of roles at her level at non-tech businesses become. Discovering engineers who say they've led teams who haven't is also pretty easy. Frankly, not many engineers have actually led teams - it's an actual rarity. Of all the things engineers are asked to do day to day, leading other engineers is generally not party to them. I'd generally ask something about how they implement "trust but verify" aka delegating work. Engineers who have worked primarily solo will not know how to break down work so that others can consume it and align to the actual idea. It's something that takes a lot of practice and the answer generally involves a pretext of what certain people's strengths and weaknesses were.
I have no doubt both of these folks genuinely wanted to do what they were applying for. I don't think they'd ever really been given the chance, or worked at the wrong kind of companies for what they wanted to do.
To call it the "fault of the team" is easy, but in reality we have a very disjointed industry with no standard practice for building software, much less as a group.
People are paid to find matching talent. Talent isn’t paid to be truthful on resumes.
That’s the crux of the issue.
Software has wild practices because there’s no agreed upon certification and there’s this myth of 10x developers and managers only want those mythical 10x-ers