[speeder]

Learned the hard way that lie is mandatory for some questions.

For example: many companies insist on asking how you did "x" (for example solves a conflict of idea of solution) in situation "y" (for example between two teams in same department) and you are obliged to answer something, even if you never been in that situation (a certain multinational company for example asked me that question three times across two different attempts to join them, both of times I failed because this question, I never worked in a company with many departments).

After a lot of Glassdoor reading found out people that got the jobs I wanted, all lied outright, not just embellishments, but outright inventing things that sound plausible.

[SpicyLemonZest]

I think you're overcorrecting here. I've been on the other side of the table for questions like that, and the intent is to ensure that you have been in the appropriate situations before. At most multinational companies, resolving conflicts between two engineering teams is an everyday occurrence, and any new hires above entry level are expected to know how to do it.

That some people manage to escape the requirement by lying doesn't mean lying is the intended strategy.

[speeder]

So you mean, that to work in a large multinational company above entry level, it is mandatory to have worked for one in the past?

[scottLobster]

Can you blame a company for prioritizing people who have worked in similar environments before?

In large corporations technical responsibility is often more distributed than in startups just due to size, so your technical skills, while important, are typically less important than they would be in small-business/startup land. What fills in the gap is communication skills and your ability to navigate corporate social networks. If you can't conflict resolve issues between engineering teams, well guess what? That engineering team you can't work with is going to hold you up and cost the company money while your superior, who really has better things to do, has to take time out of their day to address the issue you should have been able to handle.

Not saying it should be a mandatory skill, but you can't blame large corporations for filtering for it. It's a factor.

[SpicyLemonZest]

Most companies smaller than multinationals are still large enough to have conflicts between teams. The most common failure mode I see is people who simply opt out of those conflicts, preferring to keep their heads down and write code rather than talking about what should be done and how. I'm not familiar with how it works in older companies like IBM, but at the FAANGs of the world, participating in those discussions is what distinguishes entry-level engineers from more senior ones.

If your experience is only in companies with a handful engineers, yes, it can unfortunately be pretty hard to get a senior position at larger companies. It's not impossible, but people will have justified worries about whether you can handle the responsibilities.

[bradknowles]

You can get that same kind of experience elsewhere. It doesn't have to come from working in a large multinational company.

Now, working in a large multinational company would help ensure you have that kind of experience, but that's not your only option.

[clarry]

> resolving conflicts between two engineering teams is an everyday occurrence

And how difficult do you think it is to learn this skill?

If it's an everyday occurrence in huge companies, and any new hires above entry level are expected to know how to do it, it sounds like something anyone and everyone will learn. Which sounds like a real easy skill.

If it's a real easy skill, why do you need to have it already when you join? Why can't you learn it on the job, like you learn a bazillion other skills?

This kind of thing comes up a lot with technical stuff... people think that X (something you can look up on wikipedia or SO and teach yourself in an hour or two tops) is really important, therefore they can't hire anyone who hasn't learned X. But whoever they hire must be a person who's super eager to learn new stuff.

[SpicyLemonZest]

I agree it's not tremendously difficult to learn. The problem is that many people don't have the instinct to learn it. If left to their own devices, they'll just write code satisfying whatever requirements they're given, without any impulse to discuss or question what the requirements should be. I've seen many times where another team said "oh you shouldn't do X, you've gotta do Y instead", and a junior teammate of mine just accepted Y as another requirement instead of thinking about whether it was the right way to go.

So you don't want to give people the level of independent responsibility a senior title carries unless they've already learned how to avoid that.

[bradknowles]

What I've done in with interviews where I don't have the exact situational experience they're looking for, is I recall a situation that was similar, mention that it's not exactly what they asked for, and then go ahead and answer the question relative to that experience.

Many times, when they ask a specific question, they're not hard-locked on getting an exact answer that is 100% directly related to that exact situation. They're also looking to see how you might slightly redirect the question to something that is relevant to your experience, and then how you answer that.

Of course, sometimes they are hard-locked onto an exact answer to that precise situation, and if you don't have that experience, then you're done. You're not likely to know in advance if that's the case, but at least you got more interviewing experience, and you learned of another place that you do not want to work.