I'm part of a small IT team that supports about 1,000 users across North and South America. We use CrowdStrike as our primary antivirus solution, and we were affected by the recent incident.

On Friday, despite the chaos, our team organized efficiently and managed to restore all affected servers and workstations, even with some team members, including our "director," on holiday.

During this incident, no manager or director, including our IT director, approached us to inquire about the situation. Instead, they sidetracked us with unrelated, trivial questions.

Most users were unaware of the broader issue, thinking only their own device was affected, despite every single news outlet talking about it and our prompt communication about the situation. We received no inquiries or acknowledgments.

Today, with the situation fully under control, not a single person has asked about the outcome or the current status.

This was one of the most severe IT incidents we have ever experienced, yet it seems everyone here is pretending nothing happened. We weren’t seeking praise or appreciation, as that is rare. However, it was a serious, business-disrupting situation, and it’s just odd that no one expressed any concern.

It seems that if the higher-ups don't feel the need to praise or appreciate IT and day-to-day operations, they also don’t feel the need to acknowledge IT's efforts in serious situations like this.

Ultimately, it doesn't matter to me if I receive insincere thanks from anyone. I love what I do and know what needs to be done. But I do want to say that I appreciate the efforts my team has made to ensure the higher-ups and board members achieve their profit margins and bonuses for the month.

If you find yourself in a similar situation, always remember that you are invaluable to your organization, even if no one ever acknowledges you, thanks you for your efforts, or fully understands the work required to keep IT systems up and running 24/7.

Also know that there are always jobs for good IT people, so don't feel stuck in a thankless job. Keep up the good fight!

I'm currently stuck between a rock and a hard place and could use some assistance from you more experienced engineers. I'll do my best to make this as vague as possible.

A coworker of mine was put on a cross-team effort to resolve a production issue that was affecting customers - in short, a bunch of systems are sending information down a pipeline and our team is the last step in said pipeline, but sometimes the information just...doesn't get to us. It just disappears.

The OG coworker had to go on vacation (a pre-planned PTO) so they handed off the resolution to me and explained everything they'd done up to that point for triage and basically left me with: "we've exhausted all our options on our team's side and cannot figure out the root cause, based on what I've found and what I've explained to you, the problem has to be from one of the other teams. We can't debug something when the information we need to debug isn't getting to us." After their explanation of the issue and walking through it with test examples step by step, I agreed.

So, while they were gone I spent the last week basically going back over their research with a fine-tooth comb and came to the exact same conclusion. I then created an incident report detailing our findings and what we've discovered and raised it up the chain to say: "hey we can't figure this out, here's what we've tried. Please take a look into it and let me know if you find anything actionable."

Today I'm getting barraged almost every other hour for updates and to look into it and while I agree that this is a production issue that needs to be resolved, we literally cannot triage and further; how can we triage something when we don't have information to look at?

I've talked to my manager about it, and he's basically said the same thing, we can't triage with lacking information.

This is actually exhausting me as I have other priority tasks to deal with and a bunch of PMs are hounding me for updates that I don't have and cannot provide them with, but I don't know a diplomatic way to say: "hey, this isn't our fault, you gotta talk to the other two teams and figure it out."

I'm just a lowly mid-level dev and while I appreciate this as a value learning experience of dealing with prod issues in a large scale company, the nonstop barrage of updates is seriously interfering with my work that I've sidelined to resolve this issue.

As a continuation from my about Interview Tips & Tricks, I'm making a dedicated post for The Behavioral.

I said it during that post, but I'll say it again, BEHAVIORAL INTERVIEWS are way more important than you think. They largely help figure out what level you are hired in at. Some companies like Google or Meta will hire generally, and tell you the level afterwards. Some companies will ask you to apply to a specific level ahead of time, but will reject you if your behavioral responses don't meet the criteria they are looking for at that level.

So, sit back and relax as I walk you through everything I know about the behavioral interview.

NOTE: I am not a recruiter. I do not give interviews at FAANG. This is just from the perspective of someone who recently passed a FAANG interview.

General Tips & Tricks

• Doctors hate this one simple trick - do not lie. A lot of the following advice may result in you thinking to yourself, well, I don't have any experience for the job I want, I gotta make some good stories up to prove I'm at the level I want to be at. NO. Baadddddd idea. There is a huge difference between reframing your very-real experience to be perceived at a specific level, and just making up an experience to begin with. Let's say you have a company that really wants employees with Jetpack Compose experience. You may think to yourself, "Well, it's not like they are asking me to write Jetpack Compose, I'mma just tell them I did a side project - yeah, that'll fool them." So you say, "I worked on a side project that uses Jetpack Compose." But they immediately follow it up with, "What was the project about?" Uh-oh. Maybe you are quick on your feet, you say "It's a way for users to keep up with soccer scores around the world." Phew, you think. You did it, you got away with it. "What was the hardest part about transitioning from XML to Jetpack Compose?" Well, shit. They know. They always know. Don't do it. It's tempting, don't do it.

• Reshape your responses to be for the job you WANT, not the job you HAVE. First off, be realistic. Remember not lying? Your experience of figuring out how to write your first unit test isn't going to get you a Staff-level job. Self-awareness will get you far in life. Writing Unit Tests CAN get you a mid-level job if you frame it the right way. "Early in my career I made an update to production and it blocked users from being able to update their password for 24 hours. While I'm lucky it wasn't a more important feature, it made me realize that tomorrow it could be payments. I wanted to find ways to manage production rollout, so I took it upon myself to learn different methods of testing: unit, integration, etc. to prevent issues as much as possible." See, you still were learning testing, but now you phrased it in a way that is more self-sufficient, so now I'm seeing you in a mid-level light. You proved you can identify mistakes you've made, and think about how you can prevent those issues in the future. Et voilà!

• Focus on what YOU did. Engineering is a team sport, it's easy to say "We did this." "My team did that." The company you are interviewing for wants to know what YOU did. What impact did YOU have. This is something that is truly harder for women than it is men. My best advice is to practice, practice, practice. Don't take credit for other people's work, but don't feel bad taking full credit for the work you did, either.

• Be a good story teller. The higher up you go, the more important this is. Interviewers give interviews a LOT. Make it worth their wild. Make them want to care, make them want to list. Set the stage, mention the conflict, share the resolution, give 'em the ol' happy ending.

STAR Method

I, personally, used to help me with this.

Situation

Give me 1-2 sentences of context.

I, personally, found giving a single sentence for what the context is, like:

• I was on a team doing X

• We were currently following Y process

• We just hired Z people within a week

• Team was focused on A

Followed by why that matters for the story you are about to tell:

• Which was leading to us missing deadlines

• Causing code review process to take an average of X days

• Without any experience, but we needed them on client work ASAP

• Which led to us forgetting about B

Is usually a good starting place.

Task

What are you trying to change about that situation?

• I wanted to identify a way to keep track of timelines better

• As the lead, I needed to reduce the time spent on code review

• I was proactive in putting together training material and clear expectations for new hires.

• Recognizing we forgot about our second priority B, I wanted to escalate the issue, and guide teams towards a long-term focused architecture that would allow us to more easily focus on A and B.

Action

What exact steps did you take to implement said change?

• I took the lead in defining a roadmap after researching and client engagement. I then came up with a better tracking system to keep track of progress towards our new shared goals.

• I raised concerns to the team about our long running average of code review time. After analyzing our process Y, I identified the following ABC shortfalls. I proposed a solution of Z instead.

• I made a quick website with training materials relevant to the job. I associated it with a calendar roadmap so they can make sure they were staying on track with expectations.

• I escalated the issue to our VPs, resulting in a staff-level engineer being assigned to the project. Together, we advocated for and implemented a Clean Architecture approach. I created an example feature module for other teams to reference. Etc.

Result

What impact did those actions have?

• App ratings improved from X to Y. Increase client engagement led to an contract extension. Revenue increased by Z% due to the new features implemented as a direct result of the roadmap I created.

• Code review turnaround time went from X days to Y days. Team morale also went up as a result with team satisfaction scores going from A to B.

• X out Y people were assigned to client work within Z days. Client-contracts were met as a result of fast-tracking their training.

• This new architecture allowed us scale the project easier, allowing the team to focus on A and B more easily. It also increased communication across different teams as a result.

Level Differential

Entry-Level (E3 at Google/Meta)

• Are you someone we want to work with?

• Are you someone who is willing to learn?

• Are you good with feedback?

Mid-Level (E4 at Google/Meta)

• Are you self-sufficient?

• Can you own small features by yourself?

• Are you thinking about ways you can grow your craft?

Senior-Level (E5 at Google/Meta)

• How are you helping the team?

• Can you own big features / projects by yourself?

• How do you handle the bad stuff?

• How do you impact the good stuff?

• What are you doing to grow your leadership skills?

Staff-Level (E6 at Google/Meta)

• How are you helping the organization?

• What are you doing to share knowledge across teams?

• What do your office hours look like?

• What are you focused on teaching others about your platform right now?

• What are you doing to help the business?