Live Q&A with FAANG Engineers and Managers 2025/10/30

this, but it doesn't tell me because YouTube is so slow.

Operating live streams with 15 seconds of delay.

I don't know, man. That I think that will be our next uh next system design.

All right, >> I see us up now. If people can see us, >> they can.

>> There we go. Say something in the chat.

There we go.

>> Okay, hang on one second.

I've got myself in my ear right now.

Cool. All right. Cool. Well, I think everybody is here.

Somebody said comments. Great. So, uh, welcome everyone to our fifth Q&A. Um, it seems like it's been a while since we we've done these and Evan and I were just chatting.

We're like, "Hey, we haven't we haven't chatted with folks um in a while.

" So, here we are. At our last Q&A, companies were laying off engineers.

AGI was just around the corner and interviewing was brutal.

And it turns out that nothing has really changed since we last chatted.

So, um, yeah, the the world is is still burning down.

Just kidding. It's it's not that bad.

People are still interviewing, getting jobs out there. Although, I know some people are having a really tough time and, you know, we we're here with you.

Um, let me introduce us really quick and then, uh, we'll actually jump straight into the the Q&A. I know you guys have already submitted a lot of questions um and and want to get through as many of them uh as we can.

I guess just before I do that, a quick comment.

If you are on the stream, go ahead and add comments if you've got questions.

Uh we are going to try to address those as they come in. We also have a bunch of questions that people have submitted to us uh basically before this stream.

Um so want to be able to interweave the two.

We're gonna favor questions where we can have um you know multiple people can benefit uh from the answers that we give.

So if you've got a question it's really really hypersp specific to your situation, we might skip over that in favor of some other questions. Uh but if you've got something more general, I've got a lot of experience and I'm not sure about this or that or you know I'm a new grad and I'm looking to do this.

Um those are typically the the questions that we're going to answer. Um so just by way of introduction, my name is Stefan.

I am one of the co-founders of Hello Interview and I have about 15 years of experience a little bit more than 15 at this stage uh working at startups uh at big tech uh senior manager at Meta and earlier at Amazon working in ML teams uh primarily um I've done a ton of interviews over my career.

I was a bar raiser at Amazon.

I I focus very closely with recruiting at Meta.

And so I think at this stage I've got more than 2,000 interviews.

um seeing a lot of what candidates struggle with and so really excited to share some of those insights with you uh through this session.

Evan, you want to give a quick intro or do you even need one?

I feel like you're a celebrity at this stage.

Definitely not that.

But yeah, I'm the other half of of Hello Interview.

Uh so Evan was at Meta for for five years. I think actually just from Hello Interview alone, I've passed the 500 mock interview mark.

>> Wow.

>> So that's pretty cool. Um, yeah, excited to chat.

Should be fun.

>> Stephan, do you want to should you introduce Hello Interview for anyone who is not familiar? I doubt that's many people, but probably worth a a quick mention.

>> Yeah, that's a good point.

So, Hello, you might know us as the YouTube channel if you somehow stumbled across this stream.

Hello.com is our platform to help software engineers and managers prepare for interviews. And so, we've got a lot of things there.

Number one, we have a ton of free content that you can use.

um just pulling back the veil on the process. Also, we have a lot of education around system design, around ML system design, behavioral interviews, so on and so forth. We do have a bunch of tools on the site that help you to prepare stories for behavioral interviews or practice system design with AI feedback.

They're definitely worth checking out. And then finally, we have a bunch of coaches that have um opted to work with us who basically conduct mock interviews with you, give you feedback, and kind of close the loop.

The interviewing process can be uh especially challenging because you don't really get feedback on how it went.

And so, uh, one of the goals with with working with our coaches is really to pull back that, uh, that veil and give you an idea of how interviewers are perceiving your performance so you know where to focus, which for a lot of candidates, uh, can be a real challenge.

So, hello.com. Uh, go ahead and and check it out. Um, let's go ahead and dive into the questions. Evan, I I wanted to shoot the first one to you.

We we've had a lot of interest um in these AI enabled coding interviews. Um I think everybody's kind of waiting for the shoe to drop with respect to how coding interviews will evolve and there was a lot of excitement when uh meta started to pilot and I think it still is in a pilot stage an AI assisted coding interview.

What do you know about this?

What should candidates know?

What what does this mean for kind of the future of interviews for software engineers?

>> Yeah, so so this is cool. As you said, Meta is currently piloting what they call an AI enabled coding interview.

Um, and we've been waiting for this for a while.

Like people have been saying leak code is dead for, you know, a year plus now, and it continues to stick around.

But Meta is really the first one making a large move here. I spent this week and a little bit of last week really trying to dig in to understand talking to candidates who have been through it, talking to some of our friends on the inside to try to understand what this thing entails.

Um, and I guess first off, everything that I learned was just published in a blog on hello.com.

So, let me actually share that in the chat so you guys can see that. And then I'll give you the TLDDR here as well.

So I just put that link in there.

Um, but basically the first thing to know is that it's an early pilot and so most candidates, the overwhelming majority of candidates are not getting this interview.

They're still getting just two traditional coding interviews.

So people are freaking out, running around with their hair on fire trying to figure this thing out, but you're probably not going to get it. Um, so don't stress too much.

And in the pilot, it's only E4 and E5 so far. So that's mid-level and senior.

Um but my understanding is that the pilot is now expanding to E6 staff and M1 uh which is manager. So know that that's coming.

Now what actually is it?

Um it's 60 minutes long whereas the traditional coding interview is just 45 minutes and it puts you into an IDE that has your AI chat window on the right hand side just like cursor or GitHub copilot.

And interestingly, it only enables some of the more lightweight models.

And so you don't have the state-of-the-art large heavy models just yet.

Um, and what this means is that your responses come in quicker.

Um, but also that you should trust the AI less.

And so as opposed to getting leak code style questions, you get one cohesive project to build upon. So one example that I heard from a candidate was like a a spreadsheet application.

So things like being able to set cells, get cells, work with formulas to some degree.

This was, you know, what they were tasked with creating over the 60 minute period.

Um, now some tips for this. I think a surefired way to fail this interview would be just fully trying to prompt your way to success. And so what this would look like is that you are in the right hand side of the window.

You are only writing uh, you know, English words into the prompt and then just accepting whatever comes through. What Meta is certainly looking for is that you are still driving.

that you are the engineer making the decisions that you are justifying your decisions and that you are using the AI just to enable you to move faster.

So ensure that you're doing that.

Um people always ask how do I practice for this? Of course it's new.

There's not many questions.

There's not like the leak code ecosystem but on leak code you can search for things that are tagged as design. And these are the problems that most closely simulate the sorts of practical coding exercises that you'll get in this interview. And so my recommendation to you would be to search for those that are tagged as design.

Find those, open those up in cursor or wherever else uh you know you tend to to do your work and then work through the problem in a 60-minute period.

Importantly talking through as you're as you're going as you're prompting uh mention what why you're prompting it, what the justification is, what the potential trade-offs are, and then always obviously um kind of reviewing the code that is outputed by the AI.

So I think the last thing here is just that my understanding is that from an evaluation perspective, it's actually evaluated on the same four competencies as is the case of the normal coding interview at Meta. And so this is your ability to problem solve, write uh high quality code, code quality, verification, testing and debugging, and communication.

So it's those same four things.

Don't lean on the AI too much.

It's there to help you. It's a new format.

I'm sure if it's successful, it'll ramp up. Um, but as of now, you're probably not going to get it.

>> I thought it was super interesting that uh they give you only these very light LLMs. But it it kind of makes sense in some respects, like you don't want to have a candidate sit there, write a mega prompt for uh, you know, sonnet and then spend 40 minutes watching it execute.

And so they're obviously dealing with like very real constraints here in that it's kind of like uninteresting if you're just waiting for an LLM to respond.

But it also puts a lot of onus on you, the candidate, to pick up on the mistakes because these smaller models are not that good. They can accelerate your workflow, but if you're used to coding with Sonnet or GBD5, uh, this might be a different environment that's probably worth practicing.

Is that something you you would recommend, Evan?

>> Yeah, definitely. And I think probably something else that stood out to me as interesting is that even with the more lightweight models, these problems aren't overwhelmingly challenging.

Um, and so the lightweight models can still probably get you there, but they're evaluating your ability to get there on your own with the help of the model as opposed to the model getting there with the slight help of you. And that's kind of an important distinction.

Um, so that's something I would make sure that I was practicing as you're designing, too, because it's so easy nowadays to just prompt, lean back, watch it go, and and trust the output.

>> Definitely. Awesome. Okay. Uh, let's go on to another question here. Um, I think James Gold in our Discord.

If you haven't gotten in our Discord, go ahead and go to hello.com. We've got a very vibrant Discord with a lot of super helpful people sharing experience with interviews, sharing tips, working through problems. So definitely a cool place to check out. He asked, "How did you become so knowledgeable in system design resources and practice?" Um, I I'd actually really love to hear your response on this, Evan. I'll give mine really quickly on this. Um, my path is is a little bit non-traditional.

I'm not sure if it's going to be uh too helpful for everyone, but the main thing that has really propelled a lot of my knowledge about system design is curiosity and a lot of it has centered around performance in computer architecture.

So what happens for me is I encounter a problem and it might be a really mundane problem. I, you know, I need my um I I need my my API to respond more quickly.

And what I want to figure out in that moment is what is the absolute best way to do this?

What is the most optimal way? And that usually leads me down a ton of very interesting but mostly irrelevant rabbit holes around cache architecture, around uh various services, around best practices, around how data is organized.

And it turns out that if you accumulate enough of those rabbit trails, then you can start to put them together in in somewhat meaningful ways. So for me at least, unfortunately, the learning process itself is is not very repeatable.

I I would say that the um you may be able to take up um similar practices of following your curiosity and and looking to juice performance.

Uh but it's not going to be something that you can accumulate in a very short amount of time. Now that said, I would highly recommend to adopt some of those as an engineer in general. Like I think a lot of engineers kind of stop at getting the job done and I think that can be somewhat valuable, but especially as software development starts to change that deep technical knowledge and being able to connect kind of desperate ideas is going to be really important uh for engineers moving forward. So for me, the practice is going deep and following my curiosity when I've seen it.

Evan, do you have any resources or things that you've kind of run across?

>> Yeah, I guess the first thing I do have a a resource that I'll share in the chat here in just a moment, but first, and this might be recency bias.

Um, but teaching clearly we do a lot of that here on the channel and I know that that's benefited me tremendously because you have to understand something deeply to be able to teach it to somebody else.

And you wouldn't want to find yourself in a situation either in a mock interview or in one of the YouTube videos that we're creating where, you know, you don't know your stuff.

Now, most of you don't have a YouTube channel or a site dedicated to helping candidates, you know, learn this stuff, but you can teach your friends.

You can teach those around. You can teach those in the Discord channel. And I think you really understand something if you have the ability to cohesively teach somebody else.

Um, now to the resource.

This is a site that I check at least maybe once a week. Um, I just put it in the chat and it aggregates blogs from the top companies. So, the top engineering blogs from the top engineering companies.

Um, so you can see how Facebook solved problem X, how Google solved problem Y, Reddit, etc. So, every once in a while, scroll through that, you can see the titles, the things that peique your interest.

Um, click on them. And then maybe the very last thing, and this one sounds obvious, uh, but build. Um certainly at Hello Interview while we're not you know Facebook or Meta or Google scale um we get to build a lot of things and a lot of these things are the sorts of things that we have in our system design breakdowns.

So like we have a lightweight chat application we have real-time collaboration when you're in the mock interviews. Um and so all of these things if you can get your hands on them actually build them even if they're a small scale it helps things really click.

>> Yeah. Awesome. All right. I want to pick up one from the chat because I think it's an easy one and then we'll go into some of the deeper questions that we've seen beforehand.

So I see a recruiter from Fang reached out the same company has been laying off people. Why are they doing this interviewing candidates at the same time they're laying off people?

Um so just like as a a macro understanding big companies are very rarely acting as like individual units.

In fact, when a big company acts as an aligned individual unit, um they can be incredibly powerful, but it is so hard to pull off. Instead, when you look at big tech companies or even just larger, even late series F companies, they've probably got like six or seven organizations with different priorities, different P&Ls, different kind of success metrics.

And so what very often happens with layoffs is you might have some crosscutting uh you know company priorities.

We need to go and prune headcount or you know we need to figure out how to how to solve some of our cash flow problems. Fine. That's the layoffs that you're seeing.

But simultaneously some of their biggest bets they really need to pay off. And so it may be that the teams that are most important to the company are still hiring. One of the kind of standing understandings, at least in my time at Meta and Amazon, especially for more senior talent, is there's almost always openings for those talent um because the pipeline is so long.

And so what we oftentimes see is if you are like a staff level engineer or an E6 and you know you're looking for jobs, it's it's entirely possible that um you know they they literally close down a position but they will entertain a loop with you in part because uh for that talent the time for them to open a position and actually land it can vary between three months to a year plus.

So, uh, the recruiting dynamics are not always the same as kind of the HR hiring and firing dynamics that you see on the ground.

I know this can be super confusing and it's honestly somewhat disrespectful to the people who have been laid off and told, "Hey, you know, there's redundant positions." Like, it's clearly like only a halftruth at a certain level.

Um, but that's why you see this and it's part of why um as as you're looking for jobs that you may not want to avoid companies even if they've had recent layoffs. Um, I've heard some people say, you know, I'm I'm worried about this company. I'm worried about joining them and then getting laid off right after.

Truth be told, it's a very real concern.

Some people do actually run into that situation.

It's quite awful. Uh, but statistically, the odds of that are quite a bit lower than you might imagine.

And so important to keep your your options open. Um, and I realize this can all sound very inhuman.

I I think it is. All right.

Uh, let's jump into a Do you have something else to add there, Evan?

>> Uh, no. I was going to say it's the next question.

>> Cool. All right. You want to pick it up?

>> Yeah. So, we got a we got a question from MM here in the Discord.

Says, uh, how should you answer an interviewer if they ask if you've actually used tech uh in a system design interview?

Presumably tech that you haven't. And then Jack says something similar. says, "Is it okay to admit if you have you haven't deeply used a technology when asked a deep question in a system design interview?

" Um, these are good questions.

First off, I would say this is very unlikely to happen. I think we have a pretty good sense of what interviewers are asking. I haven't seen this.

Interviewers aren't typically trying to put you on the spot to say, "Have you actually used this before?

" They're trying to evaluate whether or not you have the knowledge um kind of maybe more inadvertently. Um, so don't overly stress this for one. Um, but if they do ask you, I think the answer is to be honest, of course. But a a simple no probably isn't sufficient. So if they say, you know, have you actually used Flink before?

As unlikely of a question as that would be. Just saying no maybe isn't the best, but tying that with where you learned these things from is sufficient.

So no, I haven't, but I've read a bunch of blogs on the blogs on the topic specifically maybe from these companies.

or no I haven't but I've worked with these similar technologies and I understand that the distinction is XYZ or no I haven't but I've read these books etc. Um so kind of to tie that into an example for example if it was maybe CFKA pub you could say no I've never used CFKA pub but I do have some experience with Reddis Pub and I understand that the main distinction is that CFKA is going to provide stronger durability guarantees here and that's what we need for this specific design.

Perfect. It's an amazing answer.

Um, so in an ideal world, maybe you'll stick to technologies that you do have experience with, but I recognize that that's entirely unrealistic and the overwhelming majority of candidates don't have experience with all of these technologies.

Um, and that's totally fine.

So, that would be the approach.

Be honest, but explain maybe where you learned this information. Keep in mind that for interviewers, it's actually not uncommon for a candidate to bring up a technology that the interviewer hasn't heard about.

So, it kind of is a two-way street.

Unless this is their first interview, there's likely been a scenario where they didn't know either.

So, it would be a little bit hypocritical for them to just ding you completely.

Now, you know, you do need to know about the base level technologies like know about, you know, a relational database, you know, a NoSQL database.

You should know about cache technologies, that sort of thing.

But a very specific technology is almost never a red flag. Uh, unless the interviewer is poor in that case. Sorry.

>> Yeah.

>> Some questions about that later on, I'm sure.

>> Yeah. Actually, that was a perfect segue into uh this other one. So, I think it's Kilish from our Discord says, "How to handle uh egotistic, toxic interviewers who throw you off mentally?" Um, this is a a fun question because in some sense it's it's very practical. I I love the the framing of this, which is to say, "Hey, I'm getting thrown off by this person.

Uh, you know, what can I do about it?

" And there's a bunch of things that I'd recommend here. So the first thing is when you're going into an interview, you're going to necessarily do worse than all of the practice that you've done beforehand. But in some sense, all of your practice and preparation is your upper bound.

So, the more that you've been able to kind of see problems and work through solutions, even just sitting in front of a blank Excaladraw uh screen and doing a problem before your interview is going to set you up um for with a better footing uh than you would otherwise.

Um, interviewers have all sorts of weird emotional issues.

I'm going to link the blog as soon as I finish talking.

you did fantastic.

>> Um, but one of the worst ones is feeling kind of insufficient. So, especially for more junior interviewers, what I've noted is sometimes they're out to try to prove whether the knowledge that they have is um, you know, is good.

And the way that they're going to prove that out is by asking you a bunch of questions until they can find cracks and they can feel good about the knowledge that they have.

And the solution for this is, you know, basically just to make them feel like a peer, make them feel uh more relaxed in the environment. So if they challenge you on something, you can say, "Oh, I hadn't thought about that's a good idea.

Here's let let me explore that with you. Let's let's partner on this.

" Another thing that I've seen candidates do is treat the interviews more like a fun exercise that they're going through.

When I was doing a lot of engineering, I love those moments where me and a co-worker could go stand in front of a whiteboard and hash out a problem together.

Those were always really fun.

They were really relaxed.

They honestly felt very safe.

Now, I realized that interviews aren't like that.

You know, you've got a judge who's hanging out over your shoulder. But in a lot of ways, if you can try to reproduce that feeling with your interviewer of sitting alongside a peer and working through a problem together, not only are they going to feel more at ease, which reduces the chance that they have one of these sort of ego battles with you, but you're going to be more at ease, too, which is going to help you to actually perform at your potential.

So, few things here. A practice. B, make sure that um you know you are keeping this as much as a peer oriented exercise as possible.

Then the last thing that I will say is don't get into turf wars or or battles with your interviewer.

I realize interviewers are sometimes wrong.

They'll challenge you about things that they don't know about.

They'll get facts incorrect. I think the worst case scenario is to dig in your heels and try to fight them on that.

You do want to be able to push back.

It's not okay to just take everything that they say for granted, especially for junior candidates because interviewers will oftentimes quiz you on things that you know are actually correct.

Um that doesn't mean you need to surrender each time they challenge you. Uh but if you get into a big battle on whether microservices are appropriate or whether durability and reddus is the most important thing for you to solve for a particular problem, then in some sense you've lost because the interviewer is human.

the assessments are partially subjective.

Uh so you want to avoid those pinch points when you can.

Um I feel bad for everybody who has garbage interviewers.

Uh it's kind of like how the the industry is structured.

So apologies in advance for those who encounter them.

But I think with some of the tips in the blog and the three things that I mentioned here, you're going to set yourself up for a much better time in the vast majority of scenarios.

>> Yeah. The the one thing that I would add there which I think is some of impactful advice that surprises candidates the most is that your recruiter is on your side here.

You can talk to them.

So if you leave an interview and you felt like the interviewer was a particularly bad interview for excuse me [clears throat] bad interviewer for some reason, you can bring it up to them. Like do so politely obviously.

Um but explain to them where you think things went wrong from the interviewer's perspective and let them know that things were a little bit off.

and the chances are that they'll work with you, maybe even reschedule another interview.

They recognize that there's limitations within the interviewer pool.

Uh recruiters are often just as frustrated by those limitations as you as candidates are. So, feel free to involve them in a polite and respectful way, of course.

>> Sweet. All right. I got another question for you, Evan. This one is coming from uh one of our YouTube posts that we put out from Sean on piano. We actually have a lot of piano players. I noticed one of our subscribers actually has this fantastic channel where he plays um in front of crowds. So um you might want to look through some of those.

But anyway, Sean asks, "How necessary are back of the envelope calculations in system design and will not doing them hurt my score?

" >> Yeah.

So if you've uh if you've watched the channel, you know my opinion on this certainly.

I think it's a question that's asked in every single Q&A.

It comes up all the time. Um, the TLDDR is the back of the envelope estimations are important, but they should be used in order to justify a decision. And so, the results of those calculations should impact what you do next. So, all this to say, blindly doing back of the envelope estimations at the very beginning of the interview is oftentimes not that important.

But if for example you're getting towards the end of the interview, you're getting into deep dives and now you're talking about a non-functional requirement about scaling, then it's completely reasonable to head over your database and do some math in order to justify whether or not you need to shard. And so this could either be your throughput calculations, your total storage in order to make the decision that yes, I need to shard.

This is my justification with the math and then subsequently here's what I'm going to shard by. But doing those calculations in context is far more interesting for the interviewer than blanket estimations up front.

Um, now zooming out, I think the question was directly like what did he say?

Will it hurt my score if I don't do back of the envelope calculations?

>> I wouldn't be so prescriptive.

Like the reality is, and this is true whenever a candidate asks a question kind of specific like this in that your interviewer doesn't have this really narrow prescriptive set of checklist items that they're trying to get off.

They're trying to determine whether or not you are competent at designing systems. And so if by not doing back of the envelope estimations, you went in a totally wrong direction, then that would impact your score negatively. Um, but if you designed the right system or a good system and you were able to justify it in other ways, then that would probably be fine.

Um, I think the last thing that I'll say here is just ask your interviewer.

Um, if you want to know whether or not they specifically really care about you doing this and you felt like it wasn't necessary in your design, then just ask them, "Hey, I felt like it wasn't necessary.

I didn't do it for this reason.

Would you rather? I end up doing it.

I'd be happy to do so.

" And then follow their lead.

>> Yeah, good call. I I have never seen an interviewer who said, "Hey, this guy can't do mental arithmetic under pressure in a time uh setting without a calculator.

Uh, he can't be hired.

" um that that that almost that might almost never h I've never seen it happen.

On the other hand, what people might be able to say and this would be the case where you might get uh you know a lower score would be oh well they made this decision later on that I don't think scales like if we assume that Postgress has 10,000 TPS then they're going to name a thousand instances like that doesn't make any sense. So, it's more often that interviewers in their notes are writing that these decisions aren't well justified and those numbers would have helped the justification um than any of the mechanics of doing a back of the envelope estimate.

I think this is a disservice from our predecessors in in people kind of like putting together system design material that they included this as a step that everybody must do this back of the envelope calculation.

And the reality is that it just doesn't matter in many cases.

Like, okay, you've got cache instances and it might be one or it might be seven. Um, but that doesn't really make a difference in the rest of the design.

Uh, so yeah, good good comments here, Evan.

Okay. Um, I'm going to go on to another one that I just saw in the chat.

Can you make more comments for engineering managers in their interview processes?

And then I think I saw this on a post from Shankar.

Uh, guidance on people management interviews for leadership.

What signals matter? Um, typically EM interviews are going to cover kind of like a set of different things.

Um, first of all, they want to know about how you grow and performance manage engineers.

So, this invariably involves a question around have you gotten people promoted?

Have you gotten people unstuck?

There are some really creative questions that really try to understand how you can diagnose problems and then what you do about them. The flip side of that is performance management.

oftentimes they want to see that you've actually terminated an engineer.

I know this sounds harsh, but it's part of the job of an engineering manager.

In many cases, if you don't have that experience, they want to know a situation where you really had to kind of go to the the map to make sure that someone was able to to get back in a good standing.

Uh the next thing that they're are often covering is recruiting.

They want to know that you can bring new talent onto the team when necessary.

Uh, this is always a little bit funny, especially lately, because a lot of EM are like, I don't I haven't done recruiting in like two or three years, or maybe I've never done it.

I just got, you know, turned into an EM role, but we've never had any opening.

Um, but oftentimes the companies that are hiring are also the ones that want you to do recruiting, so they want to see experience here. Uh, the next thing that they want you to touch on is collaboration or alignment. Um, this is oftentimes crossunctional, but it can also be between teams. What I mean by crossf functional is like the data science team or the design team or the finance team.

Uh they want to know how you manage those relationships because they oftentimes show up as like stress points for engineering uh teams. And then the last thing that they want to see is can you execute and deliver.

So this is going to probably be something like a deep dive into a project that you've done recently. It might be questions around how you manage sprints if they're into agile or you know what sort of ceremonies you have and processes.

They want to understand how you stay engaged and you know in touch with the details while not getting into micromanagement and and fixing things along those lines. Um, so those are typically the competences that we see see show up and each company's going to be a little bit different in how they structure the interviews themselves and then how they uh stress each part of this.

So it may not be that you've got four different sessions covering each of these competencies.

They might be all bundled into one. They might be the same interview but done by two different interviewers or they might be broken out.

Um, do we have plans to make more content around this? Yes. Uh, I would say it is not imminent. Um, I'd like to to be able to add more here.

Uh, we definitely see it as a need.

We work with a lot of EM on our platform.

Um, sometimes just like strict behavioral interviews.

Um, but also with some of the leadership pieces. So, we hope to get to that, but unfortunately, if you're asking this question, you've got an interview coming up soon. Um, I can't commit that that we'll have anything then.

>> Nice.

>> Okay. I'll uh I'll I'll grab a a comment here, too.

This is a a quick one, but I thought it was interesting and relevant.

And so the the comment was in behaviorals, does the technical challenge of the story matter or is it more the signals that you're looking for?

I've only had very simple technical work and I feel like it's not enough to say.

So this is interesting because your technical expertise is not explicitly one of the competencies that your interviewer is evaluating you on.

However, it is incredibly important in determining your leveling. So um this to say if you're giving a conflict resolution story and your conflict is around you know fixing some bug or around a very simple task then your interviewer is going to be biased towards thinking and understanding that you're much lower level and they're going to say as much in their in their evaluation of your uh in in your interview.

And so is there a checkbox for whether or not you're technically competent enough in a behavioral interview?

No. That's what the technical interviews are for. However, it does play into this holistic determination as to whether or not uh you are acting at the at the level that you are interviewing for or performing at the level that you're interviewing for.

>> Yeah. Awesome. All right, Evan, I'm going to fire another one at you while you're on a role. Um, this was a a question.

How do you stay motivated and prepared during a bleak job market when no interviews are lined up?

Um, tough situation.

>> Yeah. Um, so you you you said this in the intro, but I mean we'll acknowledge that the market really sucks right now.

Um, so for all of you, everybody here, I'm sure, is looking for jobs currently.

That's why you are here. Um, keep your head up, stay focused, keep working on it.

We're here with you. We know how brutal it is and and kudos to you guys for fighting so hard through this.

The first thing that I would say is don't just be blatantly preparing for interviews.

If you don't have an interview lined up, go try to get an interview lined up, of course. And so be applying um be applying to a wide range of companies.

One thing that we see often is that people are pretty narrowly hellbent on landing on one of the top fangs.

And so those are the only companies that they're applying to and they're not hearing back and as a result they're unemployed or in limbo for a really long period of time. And so the suggestion would be to branch out a little bit.

There are plenty of companies that are fantastic companies that are not some of the top five six bank companies.

particularly some of these even like series B C really fun interesting startups nowadays uh would be interesting to apply to. So go that route.

Build relationships with people.

So people ask us a lot about referrals.

I think we're generally of the opinion that these blind referrals are not very effective nowadays.

I know that's kind of a contrarian take. Um but instead build relationships with people.

And so whether this is a friend of a friend, people that you have met in discords, LinkedIn's otherwise like get to know them, try to provide value, study with them, do whatever it is that builds a relationship such that you can leverage that relationship um to potentially find further opportunities.

Now once you do find the opportunity or maybe in parallel I can say there's a handful of techniques that folks in our discord regularly chat about um which they have found most effective and those few things are a and maybe this sounds obvious but consistency and so setting a schedule for yourself making sure that you're doing end problems every single day but then maybe most importantly it's staying focused on a given topic for a period of time so I think the instinct might be that if you need to prepare for behavioral system design and coding that like you do a little bit of each uh each day or maybe you split days amongst each of those different interview types.

What candidates are finding most effective is that they allocate a week, two weeks on specifically system design or on specifically ramping up on DSA or behavioral and then remaining kind of consistent doing some space repetition on that given topic is make sure that it's it's fresh and that it's actually really sticking.

Um the other things that people regularly talk about is the importance of community. This can be tough.

Like it can be emotionally taxing to be alone in your office in your room studying for interviews 247 for months on end.

And so find other people who are doing the same. Whether it's online in Discords or in person have a community of people who are also preparing.

This is going to help with what I mentioned earlier where you can teach them things which will solidify things in your own mind.

They can teach you things.

That community is going to keep you both motivated.

So that's going to be really important.

Um, and then the last thing that is always talked about in Discord, which I will I will echo, is quote unquote touch grass. Make sure you go outside, make sure you have some fun, make sure you hang out with your family, hang out with your friends.

Don't be kind of stuck in interview zone for so long because you're going to drive yourself crazy.

So, be consistent, have some community, touch grass.

We know it's tough, but uh, kudos for you guys for sticking through it.

>> Stellar advice. Yeah, and I I want to just reiterate the very first point that you made that for a lot of people um they kind of use interview prep as a form of procrastination.

Getting interviews is really really hard and as a result sometimes we can build in our minds this idea that oh well that's hard but I need to be ready for when those interviews do come. And in the worst scenario, people will go months without really putting a strong effort into lining up those interviews and it's almost across the board going to be a bad situation.

So, you know, don't take this to apply to absolutely everything.

Um, you know, there are some situations where you might expect that, you know, you need to be ready. Sure, go for it.

Um, but if you find yourself consistently not having interviews and spending a lot of time in the prep process, please consider whether your time is better spent. Even lining up interviews at companies that you wouldn't accept to get that practice and to make sure that you're kind of like fishing in the right ponds uh is really important.

We don't want you guys to stay stuck uh in a situation where you know you go a long time without an actual interview.

That that can be really tough.

>> Okay, >> we got we got I got a good one for you.

Any plans to get a new hat?

That's from Harry's Golf.

>> A new hat? No, I think I'm This one probably has to go through the wash.

I'm losing my hair. I don't want to even show it to you guys. So, yeah. I got a got a new hat here.

>> We're getting shots taken.

Somebody earlier said that I looked super tired.

[laughter] >> I I think I've gotten complaints about my haircut and about my hat. So, I think I now need a sombrero. I think that's the only way out of this. I'll have to figure something [laughter] out.

Anyway, um let's see. I I saw a couple one.

I saw this one in the chat. It looks like um who put this Mir uh said, "Do you have any plans to have guided practice for behavioral interviews and then thoughts on AI behavioral interviews?

" I'm going to tackle these both together.

Um so guided practice for behavioral interviews.

Yes. Um we're hoping to have something there actually pretty >> Sorry, sorry to interrupt quickly.

Should you mention what guided practice is for those who >> Oh, yeah. Let me just explain this quickly.

Guided practice is a a um a thing that we currently a tool that we have on the site where you can actually work through system design problems directly with feedback that Evan and I have actually trained into the AI.

It's very hard. We beat it into the AI mercilessly.

Uh so that it can answer questions right and not focus on stupid stuff that nobody cares about. Uh and so functionally what you have is you work through a problem with a peer who's going to tell you what you got, what you got right, what you got wrong, and make some suggestions for you.

Uh we've gotten tremendously good feedback across the board from people who've used this and it's a fantastic complement to just studying like in some sense that practice is so important to making sure that you actually perform in the interview as opposed to just drawing blanks and and memorizing. Now as it pertains to behavioral interviews, it's not quite the same thing.

Like behavioral interviews in some part are refining and mining the stories from your own experience that you need, how you deliver them to interviewers and then how you understand the questions that are being asked.

Interviewers will frequently ask you questions and there's specific things that they're looking to get.

They aren't always looking for you to answer their questions completely literally.

Uh sometimes they're looking for you to answer questions in a way that uh helps to set the level.

Sometimes they're looking for questions to be answered in a way that shows that you can deal with ambiguity or things along those lines. And so what we've got in the pipeline, and I'm hoping to share it with you guys soon, is a tool that breaks down how interviewers are thinking, guides the conversation in a realistic way, so you can kind of see how interviewers will ask follow-up questions, and then gives you feedback on how you can refine your stories to hit on the signals that interviewers care about.

So that is coming.

Um I would say for behavioralss that is the one place where having a mock interview with a real human can be so valuable because in a lot of cases um you know working with a machine doesn't completely represent how people are actually evaluating things. Uh but we're going to get as close as we can um with a tool that we'll release shortly.

Now as it pertains to AI behavioral interviews like companies using AI for behavioral interviews uh I have a quick hot take on this. Um, I don't expect that to to actually be all that common.

Uh, especially for, you know, midlevel to senior positions. And here's why.

Um, generally speaking, recruiting is something that Evan and I call an alpha game.

It It's basically companies need an edge.

Um, if they are fishing in the same ponds with the same techniques that everybody else is, um, they are necessarily getting worse results.

They're finding less quality candidates than companies that are clever about finding the people who are passively searching or evaluating candidates who are the diamond in the rough that have really great skills but maybe not great resumes.

And so companies are constantly trying to refine their process both to be faithful to what they care about like what success looks like on a job and then also to give themselves a oneup on all the other companies out there.

Now AI behavioral is like a democratizing but like flattening process.

It means that everybody has kind of the same thing and maybe the AI is really good but it needs to be different.

And so what I've seen from the AI behavioral um companies so far is first of all it's quite unsettling to to take these AI behaviorals like it it just feels weird.

Um, so as a candidate, I am already turned off by the process.

But secondly, they are so generic and bland.

They're not really getting at the things that make good candidates great. And so most companies will be heavily resistant to this.

Especially because if the most interesting candidates, the John Carmax of the world, are immediately going to be screened out because they recoil and they don't want to talk to an AI for their behavioral, then that means the process can't really succeed. it in what it needs.

So, I don't expect this to actually take off with behavioralss.

Uh, not at least in in short order.

They may solve some of these problems over the long run.

Um, but it won't be quick.

Okay. Um, let's keep going. I like this question.

This is more of a a career question.

I think I I pushed this one to you, Evan, u just because I think you're the the right person to answer about promotions given your very rapid uh rise through the the ranks. But the question was an advice for a 13-year-old senior engineer stuck at the senior level for six years.

How to move to staff or manager manager?

How do I pick the right projects for promotion? It's a good career oriented question.

>> Yeah, I can definitely take a stab at the the senior to staff being stuck there.

Uh maybe I'll pass it back to you to discuss the manager transition.

Um, but I I guess from what I saw from so many colleagues who were quote unquote stuck at senior was that there were some attributes which were consistent and that was that they were exceptional performers at the senior level.

Um, but interestingly that's not the same thing as performing at staff. And this is really the first time in the career ladder where these things uh kind of diverge where you can be exceptional at your given level but not exhibit the characteristics of the level above you.

And so the very first thing that you want to do is figure out within your organization, within your company, within your team. What is staff?

What are the attributes of staff? Uh and the way that you would do this of course would be talking to your manager.

That's an important first place to start.

But maybe more importantly observing and talking to the staff engineers around you within your team if there are any organization etc. to get a firm grasp of what those expectations are. And I know that for me personally this was pretty difficult.

It was like how do I flip that switch to be thinking so differently than I am today? And I was sort of begging for someone else to be explicit and tell me what the characteristics of a staff engineer were.

But what's unique about staff is that for someone else to tell you what is staff almost goes against being staff in the first place. Um you sort of need to define kind of your own characteristics at that next level.

Um so once you've done that, you understand what you're really looking for, then you should be identifying what the organization cares about. And so at senior, but especially at mid-level and at junior, you're really being told what to do by everybody else above you.

And at staff, the expectation is that you're identifying most of these opportunities, but importantly identifying them in a cross organizational nature. And so this requires you zooming out, understanding what the teams next to you, around you are doing.

Understand what your manager, what's keeping them up at night, what their manager, potentially your director, what's keeping them up at night.

So that you have this thousandfoot view of the priorities within your organization because those are the projects or that is where you'll want to create projects for yourself in order to tackle those specific problems. And then maybe relatedly with that new perspective, think outside of the box.

And so I'm sure there are lots of things that have already been tried.

Figure out what those things that have been tried are and ask yourself, why have these other things not been tried? What are we missing?

What has everybody else been avoiding and why have they been avoiding it or what have people not been seeing?

And this might be kind of super clear and obvious, but for some reason, whether kind of ingrained in the leadership's perspectives or otherwise, everybody's been going down a certain path, but take that step back and see if there's a different direction that you can be going. Um, and then maybe the the last thing that was the most eye openening to me is that in order to make that senior to staff jump, you need to get over doing everything yourself.

And so up until this point in your career, writing the majority of the code has been a good thing. It's made you stand out.

Um, but when you're trying to get to staff, that's no longer the case.

It's all about leverage. And so, you need to figure out how you can build a coalition of people, I don't want to use the word under you, but maybe around you at at lower levels in order to help achieve the goals that you're defining.

And this in many cases means that you're no longer writing a lot of the code, but you're setting direction and you're helping people.

you're helping other people grow.

You're helping them identify how they can get to their own next level in order to support this larger journey or this project that you're after.

Um, so all of those things in combination succinctly, you need to switch your mind and start thinking differently than thinking like an exceptional senior engineer.

>> Yeah, good stuff. I I'm going to add on to that a little bit that often times your trajectory, your promotion path is going to be heavily tilted by how people perceive you.

And if you've been in the same role as a senior for six years, people around you are probably thinking, "This person is really solid.

They've been here at this level.

They're gonna keep doing that." They aren't seeing you as that person in the next level.

So for some people, I actually would recommend that you switch teams or maybe even companies to give yourself a chance to really set that that uh trajectory.

Um, some of it is going to be just perception and that is really hard to change.

I'm going to drop another link in the chat. This is about ramping up in a new position. But I talk a little bit about what characteristics of like engineers in a new role are indicators of high performance. In some sense, what you want to be able to do is solidify the perception that you are one of these people um as early as you can because as their perception starts to solidify, it's difficult to change. So, I think for people who have been in the same role for a long time without a promotion, um first of all, you're going to have to do something different.

I think Evan touched on that really well, but sometimes that doing something different needs to be paired with a new environment, a new project, something else.

Um, just because kind of beating your head against the same wall or even amongst the same people oftentimes isn't going to get the result that we're looking for.

Um, I want to touch on one more career promotion thing before we move on.

We got a question from Nicholas or Nicholas on LinkedIn who asked what less obvious skills are needed to rise from manager to director and beyond. I haven't been a VP so you you just hear me pontificating a little bit here but I can speak a little bit about what it takes to rise in the ranks of management. Um the first thing that I'll mention is managers in general are very sensitive to loyalty.

This makes it sound kind of like a a huge political red ocean. It's not um but you need to convey that you can be trusted and that you have the interests of your group and your leaders in mind.

Um some um early managers seem to act as if there is no political environment that they inhabit and that's usually wrong and it just tells me that that individual is probably naive and is going to struggle when they get put in actual challenges that involve people.

Um, so conveying some of that loyalty, some of that understanding is is important.

Another thing that I frequently see, especially from more junior managers or managers who get stuck, is they see this system that they occupy as kind of inflexible.

Um, all human systems are very malleable.

You're able to change rules. The rules that are put in place were put in place for certain reasons.

uh if you're not able to see how things can shift and what things are squishy and what things are actually pretty firm uh it's going to be really difficult for you to operate at a higher level when many more people were dependent on you. Uh and then the final thing that I would mention here is being cognizant and being able to sense kind of nonobvious tensions and pressures in the organization uh is really critical.

I would oftentimes have conversations, especially around performance reviews and things where a manager would basically kind of communicate to me that they didn't completely understand all of the different factors that had given rise to how we're going to deliver ratings this half or what our priorities are.

Sometimes that's an education gap that meant that I wasn't doing my job or maybe my director wasn't doing my job.

But in other cases, it's just a question of are are you perceptive enough to be able to see these things. So some of the the more important things for you to rise are really occupying a human organization and and kind of acknowledging what that means.

Um seeing its limits and and and and where things can change, but then also being perceptive to pressures that are invisible.

Uh once you're able to see all those things clearly, you're going to notice that a you have a lot more leverage.

you can actually make changes that other managers might think are impossible.

And once you're able to pull that off, the promotions just start to roll in.

Um, so those are difficult skills to tune. I'd recommend finding a mentor.

Uh, you're going to find it easier to find a mentor if your leadership chain senses that that you have uh potential um than if uh you're a run-of-the-mill manager who who maybe, you know, won't be able to develop these skills over the long run.

So communicating that and signaling that is actually maybe one of the first steps on this uh on this path.

>> Nice. Yeah, really informative. Um we we have a handful of questions here about behavioral interviews.

Um maybe I'll take a quick stab at answering it and then I know you've had so many interviews with Austin on the YouTube channel.

I'll post that in just a moment.

Um so I'll turn it over to you afterwards.

But the question here is apart from having answers in STAR format, what are the main things I should be looking at while building my answers for behavioral questions?

I think my stories are just not good enough.

Any tips? Um, the most practical advice that I could give you is to reverse engineer the competencies.

And so when I say competencies here, these are the things that your interviewer is evaluating you on. And so at every single company, they have a set of characteristics that they're trying to extract from you in the behavioral interview.

And so in the case of Meta, and it's very similar across all of the major companies, you have conflict resolution, driving results, handling ambiguity, growth mindset, and communicates effectively.

And so each question that they give you, they're expecting to be able to or they're expecting you to demonstrate one of those competencies, at least one if not multiple of those competencies.

And so one thing that you can do is that when you get asked a question is to reverse engineer hm which competency do they probably care most about by this question.

So for example, what's the largest obstacle you've overcome at work or in your career? This is probably driving results.

And so let me think about how I can deliver a story which makes it fully clear to my interviewer that I am effective at driving results.

And let me not get lost along the way of my story, but understand that that's the takeaway they want. And so that should be the kind of thematic through line throughout my story. And so if you do this when you're building up your stories, you'll ask that question.

Which competency is this aligned to?

What is my interviewer likely looking for here?

And then how can I make it such that my story is so clearly in the direction of giving them, you know, ultimately what they're looking for. Stephan, you have something to add there?

>> No, good points. I think following the signals is is is really useful.

I think when people answer the questions directly, oftentimes they're surprised uh because it feels like you you they asked a question, you answered it, right?

Um but if you haven't solved for that underlying signal, um oftentimes maybe you've missed the the mark.

Uh, another thing that I think is is kind of like a say a secret or that a lot of candidates don't realize is that the presentation gives off a lot of uh vibes along the way. So it's entirely possible for me to tell you the exact same objective story, but one which emphasizes those things that are most important at the level or most important for delivery and the other which just tells me facts along the way that might make it feel like I was just along for the ride.

Um being able to touch on those things that show evidence of basically your accomplishments.

Um but also your thought process as you're working through this uh is part of the kind of unlock of a behavioral interview.

Um, I think as it pertains to your preparation, um, I'm actually a little bit impartial to Carl as opposed to Star, uh, especially for lower level engineers.

And then for staff and manager, I think it's really important that you think about what's my insight like I get asked a question, what is the thing that I bring to the table that is nonobvious before I launch into, you know, what I did. So if I am a manager answering a question, I might say,"I noticed that this engineer was routinely jumping into tasks prematurely, but they didn't realize that they were getting in too early.

And so here's the thing that I did.

" And that tells me that you're able to kind of like unpack the scenario um in a way that if you just told me what you did, uh you you you didn't really succeed.

Uh we've got a bunch more tips on behavioral on the website.

Highly recommend it. We also have if you look at our uh community reported questions.

We actually have some breakdowns of what interviewers are looking for so you can kind of get the signals that Evan's talking about and then some videos of Austin or myself breaking down those questions.

So highly recommend that if you haven't seen it.

>> One one thing I'll I'll throw on the end here is and this is slightly contradictory.

We talk so much about preparing, having your stories ready, all of these things, >> but sometimes the most impactful thing, certainly in the behavioral interviews that I conduct, is when it's just a fluid conversation between myself and the candidate.

Like it puts me as the interviewer at ease. It makes it easier for me to gather the signals.

It makes me leave that interview feeling more comfortable and quite frankly liking the candidate more.

And so be really prepared, but maybe be prepared to the point where you understand your stories and you're going in and you can just talk about them fluidly and comfortably with a colleague. It's really clear when somebody is just repeating what they've memorized and it it puts the interviewer on edge and it makes it even harder to extract the signal. Great point.

Awesome. All right, I'm going to hit one more.

It looks like game moves too had asked how do we prepare for startups that have no previous interview questions series A+ um in some sense I think having interview questions out there sometimes actually misleads candidates they think ah I just need to memorize these questions memorize my responses go look at answer keys online parrot those out and I find that those candidates oftentimes get rejected and they're so frustrated because they don't know why I got all the answers right uh in most cases is actually doing an answer first uh kind of like unpack of an interview process is not the way that we would recommend and so you're not actually at kind of a lower point than these other questions for most startups.

They are occupied by more experienced engineers who have had some sort of connection to big tech at some point in their lives.

Maybe all the decisions they make are contrary to big tech.

Maybe they, you know, they follow Google's uh playbook. um uh kind of like uh letter for letter.

But regardless, what you'll find is that the interview processes oftentimes cargo colt from one another.

So, you know, if I am a new startup and I don't have any opinions about the interview process, I'm probably going to go and look up a bunch of resources that are going to tell me to do my process much like how Google has done.

I might just cowboy it.

In which case, you know, you as a candidate are kind of screwed because they're going to do a really poor job.

They that's not the right place to start.

But if you have nothing else to go on, I would recommend preparing for a fang style interview.

And what you will find is that in a lot of cases it will be a slight departure for some reason that the startup has. You might have, you know, less hardware that you can throw at the problem. You're going to use monoliths rather than microservices.

You're going to favor in-memory stores because you don't need eight nines of uh of durability or availability.

But the process itself will probably mirror more closely some of these big tech companies than you might anticipate with an early stage startup.

Um, so I would say start there, uh, and then adjust as you you learn more or as the recruiter or, uh, sorcerer you're working with, uh, gives you more information.

>> And, and maybe as evidence of that, Stephan and I receive, you know, at least a dozen really nice emails every single week about candidates who have landed roles.

And quite often those candidates are landing roles at early stage startups like this.

and they're thanking Hello Interview and they're they're thanking the content and the tools that we've put together which are following that more or less traditional fang interview process and so these are candidates that follow that process in their preparation many of them are then landing startup roles um so evidence of what Stephan just said.

>> Perfect. All right, I think we are almost out of time. Evan, did you wanna you have any final comments that you wanted to make or do you want to take one last question before we wrap things up?

Uh, no. I would just echo what I said uh probably halfway through the session, which is that it's tough what everybody's going through right now.

We know how difficult the market is.

Um, we're here to help. We want to help.

Reach out to us. We're pretty responsive on all of whether it's LinkedIn, email, etc. Um, we're going to continue to push out products, content, etc. that try to make life easier for you all.

Uh, and we'd love to hear when when things go well.

We really enjoy celebrating with Canada who found what we're putting together valuable.

So rooting for everybody.

>> Well, thank you all for for joining us.

If you've got additional questions or you want to continue the discussion, what I'd recommend is if you go to hell.com, there's a link on the bottom left.

I've just sent it in the chat. You can go click through and go to our discord uh where there's a lot of conversation going on both about career, about interviews, about other things.

So, um, I'll try to stick around for at least a little while and try to shoot from the hip on some of the questions that that people have over there.

We'll also publish this video, uh, so that way if you missed anything, I noted a lot of people in the comments were, uh, asking questions about Meta's, uh, AI enabled coding round.

Uh, Evan touched on that at the very beginning of the video.

Um, so you you'll find our answer, uh, there.

And then, uh, looking forward to doing another one of these uh, hopefully in the future and maybe we'll have a better market.

Maybe we'll have a a bull market and then people will be going crazy about how much inbound they've had or something like that.

Should be interesting to see.

>> All right, thank you all for for coming and we're going to drop off here.

[snorts] Bye everyone.