I've interviewed a lot of people over my career. I'm not sure "entitlement" is why the people who lie do so.
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.
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.