So if the bar is lower at non-FAANG companies that means if you take longer to complete a task or lead an initiative that takes a little longer won’t that be something that gets exposed quickly and it indicates you’re not ready to operate there?
What’s the right mentality to be able to build your stories authentically for interviewing for FAANG companies where the bar is much higher and frankly seems to be less room for error? Do I go and get a mentor who can basically ask me to go into detail for how I went about projects and analyze interactions and learn how to think about this stuff so I actually can push myself to work faster or operate at a high level at my current job?
I'm going to be 100% honest: In this market, almost everyone trying to break into FAANG who has never worked at Big Tech before (or at an adjacent top startup like Notion/Airtable) will get down-leveled. Not only because of the market pressure, but also for their own good so they don't get PIP-ed (e.g. I was a tech lead at Course Hero but joined Meta as an E4, which is mid-level).
My advice, as always, is to shore up your skills as much as possible. Just because the bar is lower at your company compared to FAANG doesn't mean you can't strive to do good work. And if it's literally impossible to do good work at your current company (this is often the case for non-FAANG companies), then write awesome code outside of work through side projects and open-source. In other words, follow all the advice from our course here: [Course] Level Up Your Code Quality As A Software Engineer
Also, you don't get graded on stuff like how fast you shipped a project during an interview as that will vary a lot based on the company. It's more about the quality of your narrative and the mentality you demonstrate. FAANG knows that non-FAANG engineers are rarely 100% ready for a FAANG job, so they are also hiring for potential, not just current skills. If you can demonstrate all the stuff we talk about in Taro (striving to ship good code, build relationships with others, create scope, think proactively, etc), then that's a good signal for FAANG that while you may not have the necessary skills now, you have the right mentality to acquire them efficiently in the future.
I also recommend doing what you can to get promoted as well as if you're getting downleveled with X-1, then you obviously want X to be as high as possible: [Course] Nail Your Promotion As A Software Engineer
Storytelling is a skill you can improve with practice. I love this idea, which I've taken from Ben Horowitz of a16z fame:
"You can't change what happened, but you can assign meaning to it."
So even if you feel like you screwed up a past project or don't have anything meaningful to talk about, you can discuss how you could have done differently or extended the project. Talk about the various factors and players involved, and make sure you portray yourself in the driver's seat (you're not a victim!)
Another thing is maybe nitpicking how you communicate isn’t that something that people really care about more? How can I get feedback for that where frankly the room for error is less
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:
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
A common situation I faced in my onsite that I quite frankly made it go poorly was that I explained my story (the disagreement question) that I thought showcased good constructive collaboration between 2 designs (i definitely am looking for an e4 position) but I think the interviewer found a hole in the story and questioned why I didn’t go with a more complicated solution?
I think is the name of the game to pick stories where if the interviewer pokes the holes it still holds well as if ur demonstrating good independence and all?
Another situation was I mentioned I talk too fast as my weakness and it felt like the interviewer was trying to dig for red flags. Turns out I think he was able to get the impression I might have the wrong mentality about how to prove independence.
Is this something indicating I should tweak the narrative or should I figure out new stories that if the interviewer asks more probing questions? Any help on how to improve upon these stories will help.
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:
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:
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:
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.
For the first question I actually don’t have any real disagreements that happened at work beyond the typical explain the situation to others who initially had a suggestion that indicated they didn’t have the full context so I really am trying to flesh out a story that indicates a design disagreement that in reality ended with a objective scorecard lol.
For the second question I might actually need tips for how to frame a talking fast weakness it sounded like when I went into the interview the interviewer wasn’t satisfied with my answer about criticism when I went into a project delay related to not ordering the deliverables well and then later asked me about a criticism someone on my team casually mentioned to me so I talked about talking fast. It unfortunately painted a picture of fear and anxie
Any tips on how to structure it a little better? I know I have a lot of potential to figure things out on my own and ask others without guidance from my manager and if I need help I consistently try to give context and ask questions indicating I googled it and did my best.
Just feel some of these stories indicate a mismatch in terms of how much weight I considered criticism and depth at my previous jobs (I got strong ratings and am considered independent and valuable at my current job and all my past jobs (never needed handholding and independently built relationships to get work done w other teams) but in my interviews it’s coming across differently.
I might be going back to the drawing board here but ya was really close in coding and did that well so one thing at a time
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?