How can I compare my non-FAANG work experience to what a FAANG company expects so I can figure out what I need to do to qualify?

I would do mocks, like a lot of them. While you're getting mocks, make sure to closely observe what the other person is doing so you can learn to provide good mocks as well.

Options for single-player:

1. Type up your interview responses and run them by ChatGPT
2. Record yourself going through the questions, play it back, and be as critical of yourself as possible

I like this other discussion a lot too: "How can I most effectively talk about my projects?"

This is also important: [Course] Effective Communication For Engineers

My guess is that you're experiencing a truly intense, high-performance behavioral interview for the first time, which will happen with FAANG as they're looking for the best of the best.

As a Meta interviewer, I was always looking for holes:

• Does your DSA solution cover all edge cases?
• Does your system design scale?
• Does your behavioral interview story have any paths that you could have taken instead?

I wasn't doing this to be mean. I was doing this because I was pushing the candidate to do their best work and show their best self. Tactically, I did this because that's what life at FAANG is like:

• After I joined Meta, my first pull requests got completely annihilated with comments. I'm talking 10-15
• As I started growing to senior and giving system design proposals, those were also peppered with questions during tech review meetings

Working at FAANG and being a high-performing engineer in general is incredibly hard because you need to both be confident and able to graciously handle feedback. You need to know when to have conviction and when to back down. This requires very high emotional and social intelligence, which is what these behavioral rounds are looking for.

From your comment, it seems like you're perceiving the interviewer finding a hole with your designer story for example as antagonistic. Their proposed solution seems more complicated to you, but maybe not to them. Or maybe it is more complicated, but the outcome would have been better (this happens all the time). As the candidate, you have 2 paths:

1. Hold your ground, go through the pros/cons of the interviewer's suggested approach to give it merit, and then use all this information to explain why you still chose your original path
2. Realize that the interviewer's suggestion was indeed better and focus on how you've grown from making a sub-optimal decision in the past

The path I've seen many candidates take is that they crumple in some way. Either they get super defensive and push back against the interviewer or they just completely fold and seem weak. This leads to immediate rejection.

Is this something indicating I should tweak the narrative or should I figure out new stories that if the interviewer asks more probing questions?

Don't respond with a new story if you're asked a probing question. You need to embrace the back-and-forth; that's the entire point of a behavior interview. If you just pivot to a new story once the original gets too much heat, you look like someone who runs away from intensity. This is really bad as working at FAANG is constantly intense.

I'll talk about all this in-depth in my upcoming behavioral interview course.

The disagreement question is a tough one as many engineers in the E3/E4 bracket have never had a real disagreement before. In your case, your story isn't a real disagreement as they were objectively incorrect. This is the tricky part about behavioral interviews: It's not just about your performance in the moment during the interview. You need to come in with an arsenal of rich stories from your prior experience.

However, I don't believe this is unfair. FAANG hires engineers who are ambitious and are regularly putting themselves in those tricky situations to solve the hardest problems and learn the most. In other words, FAANG hires engineers who follow the advice in Taro about striving to deliver quality work (particularly with system design), building relationships with others, and creating scope. When you do this, you will organically produce more quality stories to tell.

Zooming out, it's just incredibly tough to give feedback on behavioral interviews unless the feedback giver was literally also in the room. This is because it's not just about your content (i.e. the stories and actual words you said), but also the presentation (i.e. your body language, intonation, etc). I feel like a story about learning to talk more slowly (this is a problem I have to) can be presented in a way that looks great in a behavioral interview, even for FAANG. But again, I wasn't there.

When it comes to presentation, follow the advice from my Effective Communication course: [Course] Effective Communication For Engineers. At a meta level, look at how I talk. That's how I talk in behavioral interviews too!

Another disagreements which I feel also unfortunately doesn’t count are 2 things:

• as a platform team our lead made a rule that we should not ad hoc take on everyone’s debugging of issues on our platform. Obviously every consuming teams gonna push back. But doesn’t this not really count? I’m just speaking on behalf of our lead, not necessarily being my own person?

• one platform component we built the model is we build the base framework but the consuming team of the framework has to own all underlying infrastructure due to the maintenance overhead being stuff like cert renewal and clicking buttons to redeploy. One team was not being cooperative but it got resolved by engineering manager going to senior engineer/tech lead and getting that sorted.

To follow up first story basically I ran into disagreements over why I as the only us based engineer have to get involved and help debug by the manager. Some times if it is really a urgent issue I consult with them on my own give the fix and explain the situation once everyone else wakes up

Both of your stories don't feel that satisfying.

The first one is something your tech lead did as you mention.

The second one involves another team breaking an agreed upon contract.

When it comes to disagreements, I'm usually expecting something along the lines of product, design, or technical direction. Something where the answer actually isn't very clear.

The stories you've presented just seem like other teams not being cool.

Hmm so i work on the backend. Won’t I have to focus more on technical direction?

Product/design issues seem more ui focused? My main stack is exposing rest and graphql and consuming/producing from queues.

Wait are you saying basically trying to find ways to improve the product or arch as a whole is kind of this higher level goal that us as e3/e4 need to work towards so putting ourselves in those uncomfortable positions to not just memorize where to make changes but have that opinion of where it has to go is key? I know e5 is where that’s expected but is the idea if we can come up with our own opinions and speak up when we have a better idea is kind of what we should strive for?

That way naturally we have better disagreement stories but it’s all toward that broader goal we need to push for?