Welcome to the software engineer's technical interview survival guide. Using a mock interview with the classic FizzBuzz question, we cover various tips and strategies for high-pressure problem solving. 

Thanks to @ThePrimeagen  for collaborating! 

#programming #interview #softwareengineer 

🔗 Resources

FizzBuzz Question https://leetcode.com/problems/fizz-buzz/
Coding interview https://en.wikipedia.org/wiki/Coding_interview
How to get a Tech Job https://youtu.be/Xg9ihH15Uto
How to Learn to Code https://youtu.be/NtfbWkxJTHw

🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- Technical interview tips
- What are software engineer interviews like?
- How difficult is a coding interview?
- Failing a technical interview
- How to prepare for programming interview
2024-02-04T05:22:30.784Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
5927aaf4-c0a1-4ea3-b79d-bed32d79ac53
a91102ac43908f0a89b5bb455094c3ea29e48b407cd5c0162b0040049e27fa97
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
The single worst moment of my life was the moment I was born.
I wish that were true, but as a software engineer, I've experienced far worse things during technical interviews.
If you're lucky enough to survive tutorial hell before the age of 25, and find a way to impress the algorithms that automatically read your resume, you get dropped into a high stakes life or death game with a 6 figure salary on one side and Arby's on the other, you can tell yourself the interview process is broken, and maybe it is, but like most things in life, if you can't control it and just have to play the game.
In today's video, you will experience the psychological roller coaster ride that is the technical interview.
Along the way, you'll learn the secrets to a high pressure problem solving on the spot, and how to impress the interviewer even if you totally suck at writing code.
To make this hyper realistic, I've invited a special guest who's conducted hundreds of interviews in the real world.
Let the story begin.
It's been a long difficult year of learntocode.
I've turned down dates with beautiful women, stop doing flat earth research, and even cancel Netflix, all for the opportunity to stare at a computer screen for the rest of my life.
Thanks to this awesome video I watched on YouTube, I finally landed an interview with Big Scary Tech Corporation.
I've got dozens of leak code questions and a bunch of half finished Udemy courses under my belt.
Nothing can stand in my way now.
I'm about to jump on this call and change my life forever.
Hello, mister Fireship.
My name is the Primogen.
Welcome to hell.
Welcome to hell.
Survive I'm just kidding.
I'll be conducting your interview today.
You know?
Let's just get straight into it.
I'm gonna ask you actually a classic question.
It's called FizzBuzz.
I want you to print out numbers 1 through 100.
Please print out Fizz and Buzz.
Fizz Buzz.
How cliche is that?
I mean, I just built my own compiler and JavaScript last night.
This is too easy.
Survive Wait
a minute.
I have no idea what I'm doing here.
Hash map.
Link list, mom.
Mom, why am I so dumb?
Wait.
Directed graph.
Uh, I I can't do it.
I'm just gonna tell him I I can't do it.
Binary treat.
I'm an imposter.
I'm blacking out.
A few you, which means I don't care anymore, and magically when I stop caring, the anxiety goes away.
Screw the code, let's just talk about the problem.
Okay.
So, it looks like we have 3 conditions here, and when we have conditions, we use a conditional statement like if.
One way I could represent this is with a flowchart on a whiteboard, or if that's not an option, I might start by writing some pseudo code because I don't wanna worry about syntax or boilerplate before I even know what I'm going to implement.
For each iteration of a loop, we have a number.
If it's divisible by 3 and 5, we print fizzbuzz.
Otherwise, if it's divisible by 3, we print fizz.
Or if it's divisible by 5, we print buzz.
And finally, just print the number if none of these are true.
Wow.
So this is actually a very simple problem when we take the time to break it down.
I was totally overthinking it.
I was expecting something with a really complex solution because this is Big Scary Tech Corporation after all.
You know, I can't give you the answers, but I do really want to see you succeed.
So feel free to ask questions as we go along.
That solution looks pretty good.
So how would you take that and turn it into code?
I'm most comfortable in JavaScript, so I'll go ahead and use that for the implementation.
First, we'll need a loop that iterates 100 times.
As I'm writing this code, I'm not thinking about getting things done quickly, but rather I'm taking my time and making sure I fully understand the requirements before wasting my time writing a bunch of code that'll have to correct later.
What's really important is that I think out loud and explain my decisions throughout the process.
Normally, I like to use for each for loops, but, in this case, I'm going to use a traditional for loop and not for each, because I happen to know that for will result in better performance.
Now, even if what I'm saying isn't totally correct, it's important for the interviewer to understand my problem solving process, saying something is almost always better than saying nothing at all.
Unless, of course, you say some dumbass, in which case it may be optimal to just shut the fuck up.
Before you set foot into the Thunderdome, you should practice literally saying everything out loud as you solve a problem.
Personally, I hate talking while I write code, and it just takes a lot of practice to get comfortable with this.
Follow the ABC rule I just made up, which doesn't mean always be coding, but always be chatting.
Another tip is that if you get confused and freeze up, don't just sit there, but try to come up with a question.
The longer you sit there and stare at the headlights, the more likely you are to lose your composure.
We can't have anyone Freak out out there, okay?
We've gotta keep our composure.
We've got too far.
There's too much to lose.
We've gotta keep our closure.
I'm a little confused here, so I might ask a question like, should the program take an input and return an answer for a specific index, or should always iterate over all 100 answers.
Good question.
Uh, a loop is just fine.
Now I feel like I'm going in the right direction, so what I'll do next is create a few conditional statements that line up to what I sketched out on the whiteboard.
Now, the tricky thing about FizzBuzz is determining if one number is a multiple of another number.
I guess I could divide by the target number and if it's an integer it's a match, but if it's a decimal then it's not a match.
That should work.
So when it's 3 we'll log fizz, when it's 5 we'll log buzz, but if it's false on both of these, then we'll just console log the number.
Yeah, I think that looks good.
Let's go ahead and use bun to run it just to show off my a ledge of blazingly fast JavaScript tooling, and yes, it works perfectly.
I'm a goddamn genius.
Interesting.
But can you do without magical type conversion?
Yeah.
You do have the modulo operator correct.
Why don't you give it a try?
Yeah.
That would make more sense here.
What it does is give us the remainder when doing division.
So if that number is 0, then we know that it's a multiple whatever number we're trying to divide by, that gives us a solution that isn't so dependent on the loosely typed nature of JavaScript.
It's usually a good idea to avoid language civic magic, the interviewer might be a c developer with 50 years of experience who's going to think your clever little JavaScript tricks are mid AF.
The modulo operator's available in every language, so it's best to stick with that.
This is looking pretty good.
But can you make FizzBuzz print on a single line?
Oh, yeah.
That's kind of not correct, is it?
Okay.
I think I an idea, but I remember reading this article that's messing with my head right now that said the else keyword is an anti pattern.
Maybe I should stop believing everything I read on the Internet.
Let's give it a try and walk through it, we'll first check for the fizz buzz condition, then use if else a couple times to check for fizz and buzz.
And then finally, we'll use else to log the number itself.
Not only does just put fizz buzz on a single line, but the code is just more simple now.
In fact, I don't think it can get any better.
Oh, that looks correct.
Now what happen if I wanted Add some more conditions.
Let's say 7 is pass.
How are you gonna deal with that?
Uh, man.
I knew it.
Else statements really are garbage.
Always believe everything you read on the Internet.
It's never failed me.
When you have a lot of conditions to check, one thing you generally want to do is try to extract the data out of that statement.
We can easily do that here by defining a variable for the thing we want to print.
Now, we could set up a switch statement to check all the different conditions, but I think using if is just as good if not better.
As you can see here, I have GitHub Copilot enabled, but let's just keep that on a down low because I really need this job.
Now, instead of console logging here, we'll just mutate the variable.
This allows us to eliminate the FizzBuzz check and can also scale better if we decide to add additional words to it.
Impressive.
Very nice.
Impressively very nice.
Blazingly correct.
Now, how would you describe the Performance of your algorithm.
I would describe it as strong to quite strong.
As you can see when I run it, there's almost no lag time because my holistic approach is so blazingly fast.
Well, that's one way to describe it.
I was more talking about Big O time complexity.
Oh, yeah.
I guess I should have studied Big O a little better before doing this interview.
If the FizzBuzz game were to go on forever, I'd say we have linear time complexity or o of n, however, technically, the game is only played for 100 steps, which would simplify down to o one or constant time.
Wow, I can't believe it's been an hour already and I blacked out.
Where the hell am I?
Is this heaven?
Oh, hey, congratulations.
You've got the job.
Blood, sweat, and tears into this, and my mom is going to be so proud
Hold on just one second.
Uh, it looks like we've just implemented a hiring freeze.
Um, I'm gonna have to rescind that offer.
Survive congratulations.
Now you know how to bomb your technical interview just like me.
Make sure to subscribe to the Primagen for more awesome developer content.
Thanks for watching, and I will see you in the next one.

Speaker 0: The single worst moment of my life was the moment I was born. I wish that were true, but as a software engineer, I've experienced far worse things during technical interviews. If you're lucky enough to survive tutorial hell before the age of 25, and find a way to impress the algorithms that automatically read your resume, you get dropped into a high stakes life or death game with a 6 figure salary on one side and Arby's on the other, you can tell yourself the interview process is broken, and maybe it is, but like most things in life, if you can't control it and just have to play the game. In today's video, you will experience the psychological roller coaster ride that is the technical interview. Along the way, you'll learn the secrets to a high pressure problem solving on the spot, and how to impress the interviewer even if you totally suck at writing code.

To make this hyper realistic, I've invited a special guest who's conducted hundreds of interviews in the real world. Let the story begin. It's been a long difficult year of learntocode. I've turned down dates with beautiful women, stop doing flat earth research, and even cancel Netflix, all for the opportunity to stare at a computer screen for the rest of my life. Thanks to this awesome video I watched on YouTube, I finally landed an interview with Big Scary Tech Corporation.

I've got dozens of leak code questions and a bunch of half finished Udemy courses under my belt. Nothing can stand in my way now. I'm about to jump on this call and change my life forever.

Speaker 1: Hello, mister Fireship. My name is the Primogen. Welcome to hell.

Speaker 2: Welcome to hell.

Speaker 1: Survive I'm just kidding. I'll be conducting your interview today. You know? Let's just get straight into it. I'm gonna ask you actually a classic question.

It's called FizzBuzz. I want you to print out numbers 1 through 100. Please print out Fizz and Buzz.

Speaker 0: Fizz Buzz. How cliche is that? I mean, I just built my own compiler and JavaScript last night. This is too easy.

Speaker 2: Survive Wait

Speaker 0: a minute. I have no idea what I'm doing here. Hash map. Link list, mom. Mom, why am I so dumb?

Wait. Directed graph. Uh, I I can't do it. I'm just gonna tell him I I can't do it. Binary treat.

I'm an imposter. I'm blacking out. A few you, which means I don't care anymore, and magically when I stop caring, the anxiety goes away. Screw the code, let's just talk about the problem. Okay.

So, it looks like we have 3 conditions here, and when we have conditions, we use a conditional statement like if. One way I could represent this is with a flowchart on a whiteboard, or if that's not an option, I might start by writing some pseudo code because I don't wanna worry about syntax or boilerplate before I even know what I'm going to implement. For each iteration of a loop, we have a number. If it's divisible by 3 and 5, we print fizzbuzz. Otherwise, if it's divisible by 3, we print fizz.

Or if it's divisible by 5, we print buzz. And finally, just print the number if none of these are true. Wow. So this is actually a very simple problem when we take the time to break it down. I was totally overthinking it.

I was expecting something with a really complex solution because this is Big Scary Tech Corporation after all.

Speaker 1: You know, I can't give you the answers, but I do really want to see you succeed. So feel free to ask questions as we go along. That solution looks pretty good. So how would you take that and turn it into code?

Speaker 0: I'm most comfortable in JavaScript, so I'll go ahead and use that for the implementation. First, we'll need a loop that iterates 100 times. As I'm writing this code, I'm not thinking about getting things done quickly, but rather I'm taking my time and making sure I fully understand the requirements before wasting my time writing a bunch of code that'll have to correct later. What's really important is that I think out loud and explain my decisions throughout the process. Normally, I like to use for each for loops, but, in this case, I'm going to use a traditional for loop and not for each, because I happen to know that for will result in better performance.

Now, even if what I'm saying isn't totally correct, it's important for the interviewer to understand my problem solving process, saying something is almost always better than saying nothing at all. Unless, of course, you say some dumbass, in which case it may be optimal to just shut the fuck up. Before you set foot into the Thunderdome, you should practice literally saying everything out loud as you solve a problem. Personally, I hate talking while I write code, and it just takes a lot of practice to get comfortable with this. Follow the ABC rule I just made up, which doesn't mean always be coding, but always be chatting.

Another tip is that if you get confused and freeze up, don't just sit there, but try to come up with a question. The longer you sit there and stare at the headlights, the more likely you are to lose your composure.

Speaker 3: We can't have anyone Freak out out there, okay?

Speaker 2: We've gotta keep our composure. We've got too far.

Speaker 4: There's too much to lose.

Speaker 2: We've gotta keep our closure.

Speaker 0: I'm a little confused here, so I might ask a question like, should the program take an input and return an answer for a specific index, or should always iterate over all 100 answers.

Speaker 1: Good question. Uh, a loop is just fine.

Speaker 0: Now I feel like I'm going in the right direction, so what I'll do next is create a few conditional statements that line up to what I sketched out on the whiteboard. Now, the tricky thing about FizzBuzz is determining if one number is a multiple of another number. I guess I could divide by the target number and if it's an integer it's a match, but if it's a decimal then it's not a match. That should work. So when it's 3 we'll log fizz, when it's 5 we'll log buzz, but if it's false on both of these, then we'll just console log the number.

Yeah, I think that looks good. Let's go ahead and use bun to run it just to show off my a ledge of blazingly fast JavaScript tooling, and yes, it works perfectly. I'm a goddamn genius.

Speaker 1: Interesting. But can you do without magical type conversion? Yeah. You do have the modulo operator correct. Why don't you give it a try?

Speaker 0: Yeah. That would make more sense here. What it does is give us the remainder when doing division. So if that number is 0, then we know that it's a multiple whatever number we're trying to divide by, that gives us a solution that isn't so dependent on the loosely typed nature of JavaScript. It's usually a good idea to avoid language civic magic, the interviewer might be a c developer with 50 years of experience who's going to think your clever little JavaScript tricks are mid AF.

The modulo operator's available in every language, so it's best to stick with that.

Speaker 1: This is looking pretty good. But can you make FizzBuzz print on a single line?

Speaker 0: Oh, yeah. That's kind of not correct, is it? Okay. I think I an idea, but I remember reading this article that's messing with my head right now that said the else keyword is an anti pattern. Maybe I should stop believing everything I read on the Internet.

Let's give it a try and walk through it, we'll first check for the fizz buzz condition, then use if else a couple times to check for fizz and buzz. And then finally, we'll use else to log the number itself. Not only does just put fizz buzz on a single line, but the code is just more simple now. In fact, I don't think it can get any better.

Speaker 1: Oh, that looks correct. Now what happen if I wanted Add some more conditions. Let's say 7 is pass. How are you gonna deal with that?

Speaker 0: Uh, man. I knew it. Else statements really are garbage. Always believe everything you read on the Internet. It's never failed me.

When you have a lot of conditions to check, one thing you generally want to do is try to extract the data out of that statement. We can easily do that here by defining a variable for the thing we want to print. Now, we could set up a switch statement to check all the different conditions, but I think using if is just as good if not better. As you can see here, I have GitHub Copilot enabled, but let's just keep that on a down low because I really need this job. Now, instead of console logging here, we'll just mutate the variable.

This allows us to eliminate the FizzBuzz check and can also scale better if we decide to add additional words to it.

Speaker 1: Impressive. Very nice. Impressively very nice. Blazingly correct. Now, how would you describe the Performance of your algorithm.

Speaker 0: I would describe it as strong to quite strong. As you can see when I run it, there's almost no lag time because my holistic approach is so blazingly fast.

Speaker 1: Well, that's one way to describe it. I was more talking about Big O time complexity.

Speaker 0: Oh, yeah. I guess I should have studied Big O a little better before doing this interview. If the FizzBuzz game were to go on forever, I'd say we have linear time complexity or o of n, however, technically, the game is only played for 100 steps, which would simplify down to o one or constant time. Wow, I can't believe it's been an hour already and I blacked out. Where the hell am I?

Is this heaven?

Speaker 1: Oh, hey, congratulations. You've got the job.

Speaker 0: Blood, sweat, and tears into this, and my mom is going to be so proud

Speaker 1: Hold on just one second. Uh, it looks like we've just implemented a hiring freeze. Um, I'm gonna have to rescind that offer.

Speaker 0: Survive congratulations. Now you know how to bomb your technical interview just like me. Make sure to subscribe to the Primagen for more awesome developer content. Thanks for watching, and I will see you in the next one.
The single worst moment of my life was the moment I was born. I wish that were true, but as a software engineer, I've experienced far worse things during technical interviews. If you're lucky enough to survive tutorial hell before the age of 25, and find a way to impress the algorithms that automatically read your resume, you get dropped into a high stakes life or death game with a 6 figure salary on one side and Arby's on the other, you can tell yourself the interview process is broken, and maybe it is, but like most things in life, if you can't control it and just have to play the game.
In today's video, you will experience the psychological roller coaster ride that is the technical interview. Along the way, you'll learn the secrets to a high pressure problem solving on the spot, and how to impress the interviewer even if you totally suck at writing code. To make this hyper realistic, I've invited a special guest who's conducted hundreds of interviews in the real world. Let the story begin. It's been a long difficult year of learntocode. I've turned down dates with beautiful women, stop doing flat earth research, and even cancel Netflix, all for the opportunity to stare at a computer screen for the rest of my life. Thanks to this awesome video I watched on YouTube, I finally landed an interview with Big Scary Tech Corporation.
psychology
journalism
media
deep learning
machine learning
netflix
podcasts
artificial intelligence
documentary
I've got dozens of leak code questions and a bunch of half finished Udemy courses under my belt. Nothing can stand in my way now. I'm about to jump on this call and change my life forever. Hello, mister Fireship. My name is the Primogen. Welcome to hell. Welcome to hell. Survive I'm just kidding. I'll be conducting your interview today. You know? Let's just get straight into it. I'm gonna ask you actually a classic question. It's called FizzBuzz. I want you to print out numbers 1 through 100. Please print out Fizz and Buzz. Fizz Buzz. How cliche is that?
I mean, I just built my own compiler and JavaScript last night. This is too easy. Survive Wait a minute. I have no idea what I'm doing here. Hash map. Link list, mom. Mom, why am I so dumb? Wait. Directed graph. Uh, I I can't do it. I'm just gonna tell him I I can't do it.
programming
Binary treat. I'm an imposter. I'm blacking out. A few you, which means I don't care anymore, and magically when I stop caring, the anxiety goes away.
Screw the code, let's just talk about the problem. Okay. So, it looks like we have 3 conditions here, and when we have conditions, we use a conditional statement like if. One way I could represent this is with a flowchart on a whiteboard, or if that's not an option, I might start by writing some pseudo code because I don't wanna worry about syntax or boilerplate before I even know what I'm going to implement. For each iteration of a loop, we have a number.
programming
documentation
logic
If it's divisible by 3 and 5, we print fizzbuzz. Otherwise, if it's divisible by 3, we print fizz. Or if it's divisible by 5, we print buzz. And finally, just print the number if none of these are true. Wow. So this is actually a very simple problem when we take the time to break it down. I was totally overthinking it. I was expecting something with a really complex solution because this is Big Scary Tech Corporation after all. You know, I can't give you the answers, but I do really want to see you succeed.
So feel free to ask questions as we go along. That solution looks pretty good. So how would you take that and turn it into code? I'm most comfortable in JavaScript, so I'll go ahead and use that for the implementation. First, we'll need a loop that iterates 100 times. As I'm writing this code, I'm not thinking about getting things done quickly, but rather I'm taking my time and making sure I fully understand the requirements before wasting my time writing a bunch of code that'll have to correct later.
programming
What's really important is that I think out loud and explain my decisions throughout the process. Normally, I like to use for each for loops, but, in this case, I'm going to use a traditional for loop and not for each, because I happen to know that for will result in better performance.
Now, even if what I'm saying isn't totally correct, it's important for the interviewer to understand my problem solving process, saying something is almost always better than saying nothing at all. Unless, of course, you say some dumbass, in which case it may be optimal to just shut the fuck up.
logical reasoning
logic
Before you set foot into the Thunderdome, you should practice literally saying everything out loud as you solve a problem. Personally, I hate talking while I write code, and it just takes a lot of practice to get comfortable with this. Follow the ABC rule I just made up, which doesn't mean always be coding, but always be chatting. Another tip is that if you get confused and freeze up, don't just sit there, but try to come up with a question. The longer you sit there and stare at the headlights, the more likely you are to lose your composure. We can't have anyone Freak out out there, okay? We've gotta keep our composure. We've got too far. There's too much to lose. We've gotta keep our closure.
I'm a little confused here, so I might ask a question like, should the program take an input and return an answer for a specific index, or should always iterate over all 100 answers. Good question. Uh, a loop is just fine. Now I feel like I'm going in the right direction, so what I'll do next is create a few conditional statements that line up to what I sketched out on the whiteboard.
programming
Now, the tricky thing about FizzBuzz is determining if one number is a multiple of another number. I guess I could divide by the target number and if it's an integer it's a match, but if it's a decimal then it's not a match. That should work. So when it's 3 we'll log fizz, when it's 5 we'll log buzz, but if it's false on both of these, then we'll just console log the number. Yeah, I think that looks good. Let's go ahead and use bun to run it just to show off my a ledge of blazingly fast JavaScript tooling, and yes, it works perfectly.
I'm a goddamn genius. Interesting. But can you do without magical type conversion? Yeah. You do have the modulo operator correct. Why don't you give it a try? Yeah. That would make more sense here. What it does is give us the remainder when doing division. So if that number is 0, then we know that it's a multiple whatever number we're trying to divide by, that gives us a solution that isn't so dependent on the loosely typed nature of JavaScript. It's usually a good idea to avoid language civic magic, the interviewer might be a c developer with 50 years of experience who's going to think your clever little JavaScript tricks are mid AF. The modulo operator's available in every language, so it's best to stick with that. This is looking pretty good.
artificial intelligence
mathematics
But can you make FizzBuzz print on a single line? Oh, yeah. That's kind of not correct, is it? Okay. I think I an idea, but I remember reading this article that's messing with my head right now that said the else keyword is an anti pattern. Maybe I should stop believing everything I read on the Internet. Let's give it a try and walk through it, we'll first check for the fizz buzz condition, then use if else a couple times to check for fizz and buzz. And then finally, we'll use else to log the number itself. Not only does just put fizz buzz on a single line, but the code is just more simple now. In fact, I don't think it can get any better. Oh, that looks correct. Now what happen if I wanted Add some more conditions. Let's say 7 is pass. How are you gonna deal with that? Uh, man. I knew it. Else statements really are garbage. Always believe everything you read on the Internet.
It's never failed me. When you have a lot of conditions to check, one thing you generally want to do is try to extract the data out of that statement. We can easily do that here by defining a variable for the thing we want to print. Now, we could set up a switch statement to check all the different conditions, but I think using if is just as good if not better. As you can see here, I have GitHub Copilot enabled, but let's just keep that on a down low because I really need this job.
programming
data analysis
Now, instead of console logging here, we'll just mutate the variable. This allows us to eliminate the FizzBuzz check and can also scale better if we decide to add additional words to it. Impressive. Very nice. Impressively very nice. Blazingly correct. Now, how would you describe the Performance of your algorithm. I would describe it as strong to quite strong. As you can see when I run it, there's almost no lag time because my holistic approach is so blazingly fast. Well, that's one way to describe it. I was more talking about Big O time complexity. Oh, yeah. I guess I should have studied Big O a little better before doing this interview. If the FizzBuzz game were to go on forever, I'd say we have linear time complexity or o of n, however, technically, the game is only played for 100 steps, which would simplify down to o one or constant time. Wow, I can't believe it's been an hour already and I blacked out.
video gaming
games
programming
modeling
psychology
probability
Where the hell am I? Is this heaven? Oh, hey, congratulations. You've got the job. Blood, sweat, and tears into this, and my mom is going to be so proud Hold on just one second. Uh, it looks like we've just implemented a hiring freeze.
Um, I'm gonna have to rescind that offer. Survive congratulations. Now you know how to bomb your technical interview just like me. Make sure to subscribe to the Primagen for more awesome developer content. Thanks for watching, and I will see you in the next one.
customer support
The single worst moment of my life was the moment I was born. I wish that were true, but as a software engineer, I've experienced far worse things during technical interviews. If you're lucky enough to survive tutorial hell before the age of 25, and find a way to impress the algorithms that automatically read your resume, you get dropped into a high stakes life or death game with a 6 figure salary on one side and Arby's on the other, you can tell yourself the interview process is broken, and maybe it is, but like most things in life, if you can't control it and just have to play the game. In today's video, you will experience the psychological roller coaster ride that is the technical interview. Along the way, you'll learn the secrets to a high pressure problem solving on the spot, and how to impress the interviewer even if you totally suck at writing code. To make this hyper realistic, I've invited a special guest who's conducted hundreds of interviews in the real world. Let the story begin. It's been a long difficult year of learntocode. I've turned down dates with beautiful women, stop doing flat earth research, and even cancel Netflix, all for the opportunity to stare at a computer screen for the rest of my life. Thanks to this awesome video I watched on YouTube, I finally landed an interview with Big Scary Tech Corporation. I've got dozens of leak code questions and a bunch of half finished Udemy courses under my belt. Nothing can stand in my way now. I'm about to jump on this call and change my life forever. Hello, mister Fireship. My name is the Primogen. Welcome to hell. Welcome to hell. Survive I'm just kidding. I'll be conducting your interview today. You know? Let's just get straight into it. I'm gonna ask you actually a classic question. It's called FizzBuzz. I want you to print out numbers 1 through 100. Please print out Fizz and Buzz. Fizz Buzz. How cliche is that? I mean, I just built my own compiler and JavaScript last night. This is too easy. Survive Wait a minute. I have no idea what I'm doing here. Hash map. Link list, mom. Mom, why am I so dumb? Wait. Directed graph. Uh, I I can't do it. I'm just gonna tell him I I can't do it. Binary treat. I'm an imposter. I'm blacking out. A few you, which means I don't care anymore, and magically when I stop caring, the anxiety goes away. Screw the code, let's just talk about the problem. Okay. So, it looks like we have 3 conditions here, and when we have conditions, we use a conditional statement like if. One way I could represent this is with a flowchart on a whiteboard, or if that's not an option, I might start by writing some pseudo code because I don't wanna worry about syntax or boilerplate before I even know what I'm going to implement. For each iteration of a loop, we have a number. If it's divisible by 3 and 5, we print fizzbuzz. Otherwise, if it's divisible by 3, we print fizz. Or if it's divisible by 5, we print buzz. And finally, just print the number if none of these are true. Wow. So this is actually a very simple problem when we take the time to break it down. I was totally overthinking it. I was expecting something with a really complex solution because this is Big Scary Tech Corporation after all. You know, I can't give you the answers, but I do really want to see you succeed. So feel free to ask questions as we go along. That solution looks pretty good. So how would you take that and turn it into code? I'm most comfortable in JavaScript, so I'll go ahead and use that for the implementation. First, we'll need a loop that iterates 100 times. As I'm writing this code, I'm not thinking about getting things done quickly, but rather I'm taking my time and making sure I fully understand the requirements before wasting my time writing a bunch of code that'll have to correct later. What's really important is that I think out loud and explain my decisions throughout the process. Normally, I like to use for each for loops, but, in this case, I'm going to use a traditional for loop and not for each, because I happen to know that for will result in better performance. Now, even if what I'm saying isn't totally correct, it's important for the interviewer to understand my problem solving process, saying something is almost always better than saying nothing at all. Unless, of course, you say some dumbass, in which case it may be optimal to just shut the fuck up. Before you set foot into the Thunderdome, you should practice literally saying everything out loud as you solve a problem. Personally, I hate talking while I write code, and it just takes a lot of practice to get comfortable with this. Follow the ABC rule I just made up, which doesn't mean always be coding, but always be chatting. Another tip is that if you get confused and freeze up, don't just sit there, but try to come up with a question. The longer you sit there and stare at the headlights, the more likely you are to lose your composure. We can't have anyone Freak out out there, okay? We've gotta keep our composure. We've got too far. There's too much to lose. We've gotta keep our closure. I'm a little confused here, so I might ask a question like, should the program take an input and return an answer for a specific index, or should always iterate over all 100 answers. Good question. Uh, a loop is just fine. Now I feel like I'm going in the right direction, so what I'll do next is create a few conditional statements that line up to what I sketched out on the whiteboard. Now, the tricky thing about FizzBuzz is determining if one number is a multiple of another number. I guess I could divide by the target number and if it's an integer it's a match, but if it's a decimal then it's not a match. That should work. So when it's 3 we'll log fizz, when it's 5 we'll log buzz, but if it's false on both of these, then we'll just console log the number. Yeah, I think that looks good. Let's go ahead and use bun to run it just to show off my a ledge of blazingly fast JavaScript tooling, and yes, it works perfectly. I'm a goddamn genius. Interesting. But can you do without magical type conversion? Yeah. You do have the modulo operator correct. Why don't you give it a try? Yeah. That would make more sense here. What it does is give us the remainder when doing division. So if that number is 0, then we know that it's a multiple whatever number we're trying to divide by, that gives us a solution that isn't so dependent on the loosely typed nature of JavaScript. It's usually a good idea to avoid language civic magic, the interviewer might be a c developer with 50 years of experience who's going to think your clever little JavaScript tricks are mid AF. The modulo operator's available in every language, so it's best to stick with that. This is looking pretty good. But can you make FizzBuzz print on a single line? Oh, yeah. That's kind of not correct, is it? Okay. I think I an idea, but I remember reading this article that's messing with my head right now that said the else keyword is an anti pattern. Maybe I should stop believing everything I read on the Internet. Let's give it a try and walk through it, we'll first check for the fizz buzz condition, then use if else a couple times to check for fizz and buzz. And then finally, we'll use else to log the number itself. Not only does just put fizz buzz on a single line, but the code is just more simple now. In fact, I don't think it can get any better. Oh, that looks correct. Now what happen if I wanted Add some more conditions. Let's say 7 is pass. How are you gonna deal with that? Uh, man. I knew it. Else statements really are garbage. Always believe everything you read on the Internet. It's never failed me. When you have a lot of conditions to check, one thing you generally want to do is try to extract the data out of that statement. We can easily do that here by defining a variable for the thing we want to print. Now, we could set up a switch statement to check all the different conditions, but I think using if is just as good if not better. As you can see here, I have GitHub Copilot enabled, but let's just keep that on a down low because I really need this job. Now, instead of console logging here, we'll just mutate the variable. This allows us to eliminate the FizzBuzz check and can also scale better if we decide to add additional words to it. Impressive. Very nice. Impressively very nice. Blazingly correct. Now, how would you describe the Performance of your algorithm. I would describe it as strong to quite strong. As you can see when I run it, there's almost no lag time because my holistic approach is so blazingly fast. Well, that's one way to describe it. I was more talking about Big O time complexity. Oh, yeah. I guess I should have studied Big O a little better before doing this interview. If the FizzBuzz game were to go on forever, I'd say we have linear time complexity or o of n, however, technically, the game is only played for 100 steps, which would simplify down to o one or constant time. Wow, I can't believe it's been an hour already and I blacked out. Where the hell am I? Is this heaven? Oh, hey, congratulations. You've got the job. Blood, sweat, and tears into this, and my mom is going to be so proud Hold on just one second. Uh, it looks like we've just implemented a hiring freeze. Um, I'm gonna have to rescind that offer. Survive congratulations. Now you know how to bomb your technical interview just like me. Make sure to subscribe to the Primagen for more awesome developer content. Thanks for watching, and I will see you in the next one.
The
the
single
single
worst
worst
moment
moment
of
of
my
my
life
life
was
was
the
the
moment
moment
I
i
was
was
born.
born
I
i
wish
wish
that
that
were
were
true,
true
but
but
as
as
a
a
software
software
engineer,
engineer
I've
i've
experienced
experienced
far
far
worse
worse
things
things
during
during
technical
technical
interviews.
interviews
If
if
you're
you're
lucky
lucky
enough
enough
to
to
survive
survive
tutorial
tutorial
hell
hell
before
before
the
the
age
age
of
of
25,
25
and
and
find
find
a
a
way
way
to
to
impress
impress
the
the
algorithms
algorithms
that
that
automatically
automatically
read
read
your
your
resume,
resume
you
you
get
get
dropped
dropped
into
into
a
a
high
high
stakes
stakes
life
life
or
or
death
death
game
game
with
with
a
a
6
6
figure
figure
salary
salary
on
on
one
one
side
side
and
and
Arby's
arby's
on
on
the
the
other,
other
you
you
can
can
tell
tell
yourself
yourself
the
the
interview
interview
process
process
is
is
broken,
broken
and
and
maybe
maybe
it
it
is,
is
but
but
like
like
most
most
things
things
in
in
life,
life
if
if
you
you
can't
can't
control
control
it
it
and
and
just
just
have
have
to
to
play
play
the
the
game.
game
In
in
today's
today's
video,
video
you
you
will
will
experience
experience
the
the
psychological
psychological
roller
roller
coaster
coaster
ride
ride
that
that
is
is
the
the
technical
technical
interview.
interview
Along
along
the
the
way,
way
you'll
you'll
learn
learn
the
the
secrets
secrets
to
to
a
a
high
high
pressure
pressure
problem
problem
solving
solving
on
on
the
the
spot,
spot
and
and
how
how
to
to
impress
impress
the
the
interviewer
interviewer
even
even
if
if
you
you
totally
totally
suck
suck
at
at
writing
writing
code.
code
To
to
make
make
this
this
hyper
hyper
realistic,
realistic
I've
i've
invited
invited
a
a
special
special
guest
guest
who's
who's
conducted
conducted
hundreds
hundreds
of
of
interviews
interviews
in
in
the
the
real
real
world.
world
Let
let
the
the
story
story
begin.
begin
It's
it's
been
been
a
a
long
long
difficult
difficult
year
year
of
of
learntocode.
learntocode
I've
i've
turned
turned
down
down
dates
dates
with
with
beautiful
beautiful
women,
women
stop
stop
doing
doing
flat
flat
earth
earth
research,
research
and
and
even
even
cancel
cancel
Netflix,
netflix
all
all
for
for
the
the
opportunity
opportunity
to
to
stare
stare
at
at
a
a
computer
computer
screen
screen
for
for
the
the
rest
rest
of
of
my
my
life.
life
Thanks
thanks
to
to
this
this
awesome
awesome
video
video
I
i
watched
watched
on
on
YouTube,
youtube
I
i
finally
finally
landed
landed
an
an
interview
interview
with
with
Big
big
Scary
scary
Tech
tech
Corporation.
corporation
I've
i've
got
got
dozens
dozens
of
of
leak
leak
code
code
questions
questions
and
and
a
a
bunch
bunch
of
of
half
half
finished
finished
Udemy
udemy
courses
courses
under
under
my
my
belt.
belt
Nothing
nothing
can
can
stand
stand
in
in
my
my
way
way
now.
now
I'm
i'm
about
about
to
to
jump
jump
on
on
this
this
call
call
and
and
change
change
my
my
life
life
forever.
forever
Hello,
hello
mister
mister
Fireship.
fireship
My
my
name
name
is
is
the
the
Primogen.
primogen
Welcome
welcome
to
to
hell.
hell
Welcome
welcome
to
to
hell.
hell
Survive
survive
I'm
i'm
just
just
kidding.
kidding
I'll
i'll
be
be
conducting
conducting
your
your
interview
interview
today.
today
You
you
know?
know
Let's
let's
just
just
get
get
straight
straight
into
into
it.
it
I'm
i'm
gonna
gonna
ask
ask
you
you
actually
actually
a
a
classic
classic
question.
question
It's
it's
called
called
FizzBuzz.
fizzbuzz
I
i
want
want
you
you
to
to
print
print
out
out
numbers
numbers
1
1
through
through
100.
100
Please
please
print
print
out
out
Fizz
fizz
and
and
Buzz.
buzz
Fizz
fizz
Buzz.
buzz
How
how
cliche
cliche
is
is
that?
that
I
i
mean,
mean
I
i
just
just
built
built
my
my
own
own
compiler
compiler
and
and
JavaScript
javascript
last
last
night.
night
This
this
is
is
too
too
easy.
easy
Survive
survive
Wait
wait
a
a
minute.
minute
I
i
have
have
no
no
idea
idea
what
what
I'm
i'm
doing
doing
here.
here
Hash
hash
map.
map
Link
link
list,
list
mom.
mom
Mom,
mom
why
why
am
am
I
i
so
so
dumb?
dumb
Wait.
wait
Directed
directed
graph.
graph
Uh,
uh
I
i
I
i
can't
can't
do
do
it.
it
I'm
i'm
just
just
gonna
gonna
tell
tell
him
him
I
i
I
i
can't
can't
do
do
it.
it
Binary
binary
treat.
treat
I'm
i'm
an
an
imposter.
imposter
I'm
i'm
blacking
blacking
out.
out
A
a
few
few
you,
you
which
which
means
means
I
i
don't
don't
care
care
anymore,
anymore
and
and
magically
magically
when
when
I
i
stop
stop
caring,
caring
the
the
anxiety
anxiety
goes
goes
away.
away
Screw
screw
the
the
code,
code
let's
let's
just
just
talk
talk
about
about
the
the
problem.
problem
Okay.
okay
So,
so
it
it
looks
looks
like
like
we
we
have
have
3
3
conditions
conditions
here,
here
and
and
when
when
we
we
have
have
conditions,
conditions
we
we
use
use
a
a
conditional
conditional
statement
statement
like
like
if.
if
One
one
way
way
I
i
could
could
represent
represent
this
this
is
is
with
with
a
a
flowchart
flowchart
on
on
a
a
whiteboard,
whiteboard
or
or
if
if
that's
that's
not
not
an
an
option,
option
I
i
might
might
start
start
by
by
writing
writing
some
some
pseudo
pseudo
code
code
because
because
I
i
don't
don't
wanna
wanna
worry
worry
about
about
syntax
syntax
or
or
boilerplate
boilerplate
before
before
I
i
even
even
know
know
what
what
I'm
i'm
going
going
to
to
implement.
implement
For
for
each
each
iteration
iteration
of
of
a
a
loop,
loop
we
we
have
have
a
a
number.
number
If
if
it's
it's
divisible
divisible
by
by
3
3
and
and
5,
5
we
we
print
print
fizzbuzz.
fizzbuzz
Otherwise,
otherwise
if
if
it's
it's
divisible
divisible
by
by
3,
3
we
we
print
print
fizz.
fizz
Or
or
if
if
it's
it's
divisible
divisible
by
by
5,
5
we
we
print
print
buzz.
buzz
And
and
finally,
finally
just
just
print
print
the
the
number
number
if
if
none
none
of
of
these
these
are
are
true.
true
Wow.
wow
So
so
this
this
is
is
actually
actually
a
a
very
very
simple
simple
problem
problem
when
when
we
we
take
take
the
the
time
time
to
to
break
break
it
it
down.
down
I
i
was
was
totally
totally
overthinking
overthinking
it.
it
I
i
was
was
expecting
expecting
something
something
with
with
a
a
really
really
complex
complex
solution
solution
because
because
this
this
is
is
Big
big
Scary
scary
Tech
tech
Corporation
corporation
after
after
all.
all
You
you
know,
know
I
i
can't
can't
give
give
you
you
the
the
answers,
answers
but
but
I
i
do
do
really
really
want
want
to
to
see
see
you
you
succeed.
succeed
So
so
feel
feel
free
free
to
to
ask
ask
questions
questions
as
as
we
we
go
go
along.
along
That
that
solution
solution
looks
looks
pretty
pretty
good.
good
So
so
how
how
would
would
you
you
take
take
that
that
and
and
turn
turn
it
it
into
into
code?
code
I'm
i'm
most
most
comfortable
comfortable
in
in
JavaScript,
javascript
so
so
I'll
i'll
go
go
ahead
ahead
and
and
use
use
that
that
for
for
the
the
implementation.
implementation
First,
first
we'll
we'll
need
need
a
a
loop
loop
that
that
iterates
iterates
100
100
times.
times
As
as
I'm
i'm
writing
writing
this
this
code,
code
I'm
i'm
not
not
thinking
thinking
about
about
getting
getting
things
things
done
done
quickly,
quickly
but
but
rather
rather
I'm
i'm
taking
taking
my
my
time
time
and
and
making
making
sure
sure
I
i
fully
fully
understand
understand
the
the
requirements
requirements
before
before
wasting
wasting
my
my
time
time
writing
writing
a
a
bunch
bunch
of
of
code
code
that'll
that'll
have
have
to
to
correct
correct
later.
later
What's
what's
really
really
important
important
is
is
that
that
I
i
think
think
out
out
loud
loud
and
and
explain
explain
my
my
decisions
decisions
throughout
throughout
the
the
process.
process
Normally,
normally
I
i
like
like
to
to
use
use
for
for
each
each
for
for
loops,
loops
but,
but
in
in
this
this
case,
case
I'm
i'm
going
going
to
to
use
use
a
a
traditional
traditional
for
for
loop
loop
and
and
not
not
for
for
each,
each
because
because
I
i
happen
happen
to
to
know
know
that
that
for
for
will
will
result
result
in
in
better
better
performance.
performance
Now,
now
even
even
if
if
what
what
I'm
i'm
saying
saying
isn't
isn't
totally
totally
correct,
correct
it's
it's
important
important
for
for
the
the
interviewer
interviewer
to
to
understand
understand
my
my
problem
problem
solving
solving
process,
process
saying
saying
something
something
is
is
almost
almost
always
always
better
better
than
than
saying
saying
nothing
nothing
at
at
all.
all
Unless,
unless
of
of
course,
course
you
you
say
say
some
some
dumbass,
dumbass
in
in
which
which
case
case
it
it
may
may
be
be
optimal
optimal
to
to
just
just
shut
shut
the
the
fuck
fuck
up.
up
Before
before
you
you
set
set
foot
foot
into
into
the
the
Thunderdome,
thunderdome
you
you
should
should
practice
practice
literally
literally
saying
saying
everything
everything
out
out
loud
loud
as
as
you
you
solve
solve
a
a
problem.
problem
Personally,
personally
I
i
hate
hate
talking
talking
while
while
I
i
write
write
code,
code
and
and
it
it
just
just
takes
takes
a
a
lot
lot
of
of
practice
practice
to
to
get
get
comfortable
comfortable
with
with
this.
this
Follow
follow
the
the
ABC
abc
rule
rule
I
i
just
just
made
made
up,
up
which
which
doesn't
doesn't
mean
mean
always
always
be
be
coding,
coding
but
but
always
always
be
be
chatting.
chatting
Another
another
tip
tip
is
is
that
that
if
if
you
you
get
get
confused
confused
and
and
freeze
freeze
up,
up
don't
don't
just
just
sit
sit
there,
there
but
but
try
try
to
to
come
come
up
up
with
with
a
a
question.
question
The
the
longer
longer
you
you
sit
sit
there
there
and
and
stare
stare
at
at
the
the
headlights,
headlights
the
the
more
more
likely
likely
you
you
are
are
to
to
lose
lose
your
your
composure.
composure
We
we
can't
can't
have
have
anyone
anyone
Freak
freak
out
out
out
out
there,
there
okay?
okay
We've
we've
gotta
gotta
keep
keep
our
our
composure.
composure
We've
we've
got
got
too
too
far.
far
There's
there's
too
too
much
much
to
to
lose.
lose
We've
we've
gotta
gotta
keep
keep
our
our
closure.
closure
I'm
i'm
a
a
little
little
confused
confused
here,
here
so
so
I
i
might
might
ask
ask
a
a
question
question
like,
like
should
should
the
the
program
program
take
take
an
an
input
input
and
and
return
return
an
an
answer
answer
for
for
a
a
specific
specific
index,
index
or
or
should
should
always
always
iterate
iterate
over
over
all
all
100
100
answers.
answers
Good
good
question.
question
Uh,
uh
a
a
loop
loop
is
is
just
just
fine.
fine
Now
now
I
i
feel
feel
like
like
I'm
i'm
going
going
in
in
the
the
right
right
direction,
direction
so
so
what
what
I'll
i'll
do
do
next
next
is
is
create
create
a
a
few
few
conditional
conditional
statements
statements
that
that
line
line
up
up
to
to
what
what
I
i
sketched
sketched
out
out
on
on
the
the
whiteboard.
whiteboard
Now,
now
the
the
tricky
tricky
thing
thing
about
about
FizzBuzz
fizzbuzz
is
is
determining
determining
if
if
one
one
number
number
is
is
a
a
multiple
multiple
of
of
another
another
number.
number
I
i
guess
guess
I
i
could
could
divide
divide
by
by
the
the
target
target
number
number
and
and
if
if
it's
it's
an
an
integer
integer
it's
it's
a
a
match,
match
but
but
if
if
it's
it's
a
a
decimal
decimal
then
then
it's
it's
not
not
a
a
match.
match
That
that
should
should
work.
work
So
so
when
when
it's
it's
3
3
we'll
we'll
log
log
fizz,
fizz
when
when
it's
it's
5
5
we'll
we'll
log
log
buzz,
buzz
but
but
if
if
it's
it's
false
false
on
on
both
both
of
of
these,
these
then
then
we'll
we'll
just
just
console
console
log
log
the
the
number.
number
Yeah,
yeah
I
i
think
think
that
that
looks
looks
good.
good
Let's
let's
go
go
ahead
ahead
and
and
use
use
bun
bun
to
to
run
run
it
it
just
just
to
to
show
show
off
off
my
my
a
a
ledge
ledge
of
of
blazingly
blazingly
fast
fast
JavaScript
javascript
tooling,
tooling
and
and
yes,
yes
it
it
works
works
perfectly.
perfectly
I'm
i'm
a
a
goddamn
goddamn
genius.
genius
Interesting.
interesting
But
but
can
can
you
you
do
do
without
without
magical
magical
type
type
conversion?
conversion
Yeah.
yeah
You
you
do
do
have
have
the
the
modulo
modulo
operator
operator
correct.
correct
Why
why
don't
don't
you
you
give
give
it
it
a
a
try?
try
Yeah.
yeah
That
that
would
would
make
make
more
more
sense
sense
here.
here
What
what
it
it
does
does
is
is
give
give
us
us
the
the
remainder
remainder
when
when
doing
doing
division.
division
So
so
if
if
that
that
number
number
is
is
0,
0
then
then
we
we
know
know
that
that
it's
it's
a
a
multiple
multiple
whatever
whatever
number
number
we're
we're
trying
trying
to
to
divide
divide
by,
by
that
that
gives
gives
us
us
a
a
solution
solution
that
that
isn't
isn't
so
so
dependent
dependent
on
on
the
the
loosely
loosely
typed
typed
nature
nature
of
of
JavaScript.
javascript
It's
it's
usually
usually
a
a
good
good
idea
idea
to
to
avoid
avoid
language
language
civic
civic
magic,
magic
the
the
interviewer
interviewer
might
might
be
be
a
a
c
c
developer
developer
with
with
50
50
years
years
of
of
experience
experience
who's
who's
going
going
to
to
think
think
your
your
clever
clever
little
little
JavaScript
javascript
tricks
tricks
are
are
mid
mid
AF.
af
The
the
modulo
modulo
operator's
operator's
available
available
in
in
every
every
language,
language
so
so
it's
it's
best
best
to
to
stick
stick
with
with
that.
that
This
this
is
is
looking
looking
pretty
pretty
good.
good
But
but
can
can
you
you
make
make
FizzBuzz
fizzbuzz
print
print
on
on
a
a
single
single
line?
line
Oh,
oh
yeah.
yeah
That's
that's
kind
kind
of
of
not
not
correct,
correct
is
is
it?
it
Okay.
okay
I
i
think
think
I
i
an
an
idea,
idea
but
but
I
i
remember
remember
reading
reading
this
this
article
article
that's
that's
messing
messing
with
with
my
my
head
head
right
right
now
now
that
that
said
said
the
the
else
else
keyword
keyword
is
is
an
an
anti
anti
pattern.
pattern
Maybe
maybe
I
i
should
should
stop
stop
believing
believing
everything
everything
I
i
read
read
on
on
the
the
Internet.
internet
Let's
let's
give
give
it
it
a
a
try
try
and
and
walk
walk
through
through
it,
it
we'll
we'll
first
first
check
check
for
for
the
the
fizz
fizz
buzz
buzz
condition,
condition
then
then
use
use
if
if
else
else
a
a
couple
couple
times
times
to
to
check
check
for
for
fizz
fizz
and
and
buzz.
buzz
And
and
then
then
finally,
finally
we'll
we'll
use
use
else
else
to
to
log
log
the
the
number
number
itself.
itself
Not
not
only
only
does
does
just
just
put
put
fizz
fizz
buzz
buzz
on
on
a
a
single
single
line,
line
but
but
the
the
code
code
is
is
just
just
more
more
simple
simple
now.
now
In
in
fact,
fact
I
i
don't
don't
think
think
it
it
can
can
get
get
any
any
better.
better
Oh,
oh
that
that
looks
looks
correct.
correct
Now
now
what
what
happen
happen
if
if
I
i
wanted
wanted
Add
add
some
some
more
more
conditions.
conditions
Let's
let's
say
say
7
7
is
is
pass.
pass
How
how
are
are
you
you
gonna
gonna
deal
deal
with
with
that?
that
Uh,
uh
man.
man
I
i
knew
knew
it.
it
Else
else
statements
statements
really
really
are
are
garbage.
garbage
Always
always
believe
believe
everything
everything
you
you
read
read
on
on
the
the
Internet.
internet
It's
it's
never
never
failed
failed
me.
me
When
when
you
you
have
have
a
a
lot
lot
of
of
conditions
conditions
to
to
check,
check
one
one
thing
thing
you
you
generally
generally
want
want
to
to
do
do
is
is
try
try
to
to
extract
extract
the
the
data
data
out
out
of
of
that
that
statement.
statement
We
we
can
can
easily
easily
do
do
that
that
here
here
by
by
defining
defining
a
a
variable
variable
for
for
the
the
thing
thing
we
we
want
want
to
to
print.
print
Now,
now
we
we
could
could
set
set
up
up
a
a
switch
switch
statement
statement
to
to
check
check
all
all
the
the
different
different
conditions,
conditions
but
but
I
i
think
think
using
using
if
if
is
is
just
just
as
as
good
good
if
if
not
not
better.
better
As
as
you
you
can
can
see
see
here,
here
I
i
have
have
GitHub
github
Copilot
copilot
enabled,
enabled
but
but
let's
let's
just
just
keep
keep
that
that
on
on
a
a
down
down
low
low
because
because
I
i
really
really
need
need
this
this
job.
job
Now,
now
instead
instead
of
of
console
console
logging
logging
here,
here
we'll
we'll
just
just
mutate
mutate
the
the
variable.
variable
This
this
allows
allows
us
us
to
to
eliminate
eliminate
the
the
FizzBuzz
fizzbuzz
check
check
and
and
can
can
also
also
scale
scale
better
better
if
if
we
we
decide
decide
to
to
add
add
additional
additional
words
words
to
to
it.
it
Impressive.
impressive
Very
very
nice.
nice
Impressively
impressively
very
very
nice.
nice
Blazingly
blazingly
correct.
correct
Now,
now
how
how
would
would
you
you
describe
describe
the
the
Performance
performance
of
of
your
your
algorithm.
algorithm
I
i
would
would
describe
describe
it
it
as
as
strong
strong
to
to
quite
quite
strong.
strong
As
as
you
you
can
can
see
see
when
when
I
i
run
run
it,
it
there's
there's
almost
almost
no
no
lag
lag
time
time
because
because
my
my
holistic
holistic
approach
approach
is
is
so
so
blazingly
blazingly
fast.
fast
Well,
well
that's
that's
one
one
way
way
to
to
describe
describe
it.
it
I
i
was
was
more
more
talking
talking
about
about
Big
big
O
o
time
time
complexity.
complexity
Oh,
oh
yeah.
yeah
I
i
guess
guess
I
i
should
should
have
have
studied
studied
Big
big
O
o
a
a
little
little
better
better
before
before
doing
doing
this
this
interview.
interview
If
if
the
the
FizzBuzz
fizzbuzz
game
game
were
were
to
to
go
go
on
on
forever,
forever
I'd
i'd
say
say
we
we
have
have
linear
linear
time
time
complexity
complexity
or
or
o
o
of
of
n,
n
however,
however
technically,
technically
the
the
game
game
is
is
only
only
played
played
for
for
100
100
steps,
steps
which
which
would
would
simplify
simplify
down
down
to
to
o
o
one
one
or
or
constant
constant
time.
time
Wow,
wow
I
i
can't
can't
believe
believe
it's
it's
been
been
an
an
hour
hour
already
already
and
and
I
i
blacked
blacked
out.
out
Where
where
the
the
hell
hell
am
am
I?
i
Is
is
this
this
heaven?
heaven
Oh,
oh
hey,
hey
congratulations.
congratulations
You've
you've
got
got
the
the
job.
job
Blood,
blood
sweat,
sweat
and
and
tears
tears
into
into
this,
this
and
and
my
my
mom
mom
is
is
going
going
to
to
be
be
so
so
proud
proud
Hold
hold
on
on
just
just
one
one
second.
second
Uh,
uh
it
it
looks
looks
like
like
we've
we've
just
just
implemented
implemented
a
a
hiring
hiring
freeze.
freeze
Um,
um
I'm
i'm
gonna
gonna
have
have
to
to
rescind
rescind
that
that
offer.
offer
Survive
survive
congratulations.
congratulations
Now
now
you
you
know
know
how
how
to
to
bomb
bomb
your
your
technical
technical
interview
interview
just
just
like
like
me.
me
Make
make
sure
sure
to
to
subscribe
subscribe
to
to
the
the
Primagen
primagen
for
for
more
more
awesome
awesome
developer
developer
content.
content
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
Speaker 0 discusses his experience with FizzBuzz during a technical interview and how he uses a problem-saving code to solve it. They emphasize the importance of letting the interviewer understand the problem before breaking down code. Speaker 1 suggests practicing and avoiding confusion, and Speaker 2 suggests using a conditional statement to test the problem. They also discuss the use of the "other" command to create a loop and test the problem. Speaker 2 suggests using the command line and Speaker 1 asks about the algorithm's performance, to which Speaker 0 describes it as strong to quite strong. They also mention a hiring freeze and Speaker 0 arranges to rescind the offer.
How to NOT Fail a Technical Interview
The single worst moment of my life was the moment I was born. I wish that were true, but as a software engineer, I've experienced far worse things during technical interviews. If you're lucky enough to survive tutorial hell before the age of 25, and find a way to impress the algorithms that automatically read your resume, you get dropped into a high stakes life or death game with a 6 figure salary on one side and Arby's on the other, you can tell yourself the interview process is broken, and maybe it is, but like most things in life, if you can't control it and just have to play the game. In today's video, you will experience the psychological roller coaster ride that is the technical interview. Along the way, you'll learn the secrets to a high pressure problem solving on the spot, and how to impress the interviewer even if you totally suck at writing code. To make this hyper realistic, I've invited a special guest who's conducted hundreds of interviews in the real world. Let the story begin. It's been a long difficult year of learntocode. I've turned down dates with beautiful women, stop doing flat earth research, and even cancel Netflix, all for the opportunity to stare at a computer screen for the rest of my life. Thanks to this awesome video I watched on YouTube, I finally landed an interview with Big Scary Tech Corporation. I've got dozens of leak code questions and a bunch of half finished Udemy courses under my belt. Nothing can stand in my way now. I'm about to jump on this call and change my life forever. Hello, mister Fireship. My name is the Primogen. Welcome to hell. Welcome to hell. Survive I'm just kidding. I'll be conducting your interview today. You know? Let's just get straight into it. I'm gonna ask you actually a classic question. It's called FizzBuzz. I want you to print out numbers 1 through 100. Please print out Fizz and Buzz. Fizz Buzz. How cliche is that? I mean, I just built my own compiler and JavaScript last night. This is too easy. Survive Wait a minute. I have no idea what I'm doing here. Hash map. Link list, mom. Mom, why am I so dumb? Wait. Directed graph. Uh, I I can't do it. I'm just gonna tell him I I can't do it. Binary treat. I'm an imposter. I'm blacking out. A few you, which means I don't care anymore, and magically when I stop caring, the anxiety goes away. Screw the code, let's just talk about the problem. Okay. So, it looks like we have 3 conditions here, and when we have conditions, we use a conditional statement like if. One way I could represent this is with a flowchart on a whiteboard, or if that's not an option, I might start by writing some pseudo code because I don't wanna worry about syntax or boilerplate before I even know what I'm going to implement. For each iteration of a loop, we have a number. If it's divisible by 3 and 5, we print fizzbuzz. Otherwise, if it's divisible by 3, we print fizz. Or if it's divisible by 5, we print buzz. And finally, just print the number if none of these are true. Wow. So this is actually a very simple problem when we take the time to break it down. I was totally overthinking it. I was expecting something with a really complex solution because this is Big Scary Tech Corporation after all. You know, I can't give you the answers, but I do really want to see you succeed. So feel free to ask questions as we go along. That solution looks pretty good. So how would you take that and turn it into code? I'm most comfortable in JavaScript, so I'll go ahead and use that for the implementation. First, we'll need a loop that iterates 100 times. As I'm writing this code, I'm not thinking about getting things done quickly, but rather I'm taking my time and making sure I fully understand the requirements before wasting my time writing a bunch of code that'll have to correct later. What's really important is that I think out loud and explain my decisions throughout the process. Normally, I like to use for each for loops, but, in this case, I'm going to use a traditional for loop and not for each, because I happen to know that for will result in better performance. Now, even if what I'm saying isn't totally correct, it's important for the interviewer to understand my problem solving process, saying something is almost always better than saying nothing at all. Unless, of course, you say some dumbass, in which case it may be optimal to just shut the fuck up. Before you set foot into the Thunderdome, you should practice literally saying everything out loud as you solve a problem. Personally, I hate talking while I write code, and it just takes a lot of practice to get comfortable with this. Follow the ABC rule I just made up, which doesn't mean always be coding, but always be chatting. Another tip is that if you get confused and freeze up, don't just sit there, but try to come up with a question. The longer you sit there and stare at the headlights, the more likely you are to lose your composure. We can't have anyone Freak out out there, okay? We've gotta keep our composure. We've got too far. There's too much to lose. We've gotta keep our closure. I'm a little confused here, so I might ask a question like, should the program take an input and return an answer for a specific index, or should always iterate over all 100 answers. Good question. Uh, a loop is just fine. Now I feel like I'm going in the right direction, so what I'll do next is create a few conditional statements that line up to what I sketched out on the whiteboard. Now, the tricky thing about FizzBuzz is determining if one number is a multiple of another number. I guess I could divide by the target number and if it's an integer it's a match, but if it's a decimal then it's not a match. That should work. So when it's 3 we'll log fizz, when it's 5 we'll log buzz, but if it's false on both of these, then we'll just console log the number. Yeah, I think that looks good. Let's go ahead and use bun to run it just to show off my a ledge of blazingly fast JavaScript tooling, and yes, it works perfectly. I'm a goddamn genius. Interesting. But can you do without magical type conversion? Yeah. You do have the modulo operator correct. Why don't you give it a try? Yeah. That would make more sense here. What it does is give us the remainder when doing division. So if that number is 0, then we know that it's a multiple whatever number we're trying to divide by, that gives us a solution that isn't so dependent on the loosely typed nature of JavaScript. It's usually a good idea to avoid language civic magic, the interviewer might be a c developer with 50 years of experience who's going to think your clever little JavaScript tricks are mid AF. The modulo operator's available in every language, so it's best to stick with that. This is looking pretty good. But can you make FizzBuzz print on a single line? Oh, yeah. That's kind of not correct, is it? Okay. I think I an idea, but I remember reading this article that's messing with my head right now that said the else keyword is an anti pattern. Maybe I should stop believing everything I read on the Internet. Let's give it a try and walk through it, we'll first check for the fizz buzz condition, then use if else a couple times to check for fizz and buzz. And then finally, we'll use else to log the number itself. Not only does just put fizz buzz on a single line, but the code is just more simple now. In fact, I don't think it can get any better. Oh, that looks correct. Now what happen if I wanted Add some more conditions. Let's say 7 is pass. How are you gonna deal with that? Uh, man. I knew it. Else statements really are garbage. Always believe everything you read on the Internet. It's never failed me. When you have a lot of conditions to check, one thing you generally want to do is try to extract the data out of that statement. We can easily do that here by defining a variable for the thing we want to print. Now, we could set up a switch statement to check all the different conditions, but I think using if is just as good if not better. As you can see here, I have GitHub Copilot enabled, but let's just keep that on a down low because I really need this job. Now, instead of console logging here, we'll just mutate the variable. This allows us to eliminate the FizzBuzz check and can also scale better if we decide to add additional words to it. Impressive. Very nice. Impressively very nice. Blazingly correct. Now, how would you describe the Performance of your algorithm. I would describe it as strong to quite strong. As you can see when I run it, there's almost no lag time because my holistic approach is so blazingly fast. Well, that's one way to describe it. I was more talking about Big O time complexity. Oh, yeah. I guess I should have studied Big O a little better before doing this interview. If the FizzBuzz game were to go on forever, I'd say we have linear time complexity or o of n, however, technically, the game is only played for 100 steps, which would simplify down to o one or constant time. Wow, I can't believe it's been an hour already and I blacked out. Where the hell am I? Is this heaven? Oh, hey, congratulations. You've got the job. Blood, sweat, and tears into this, and my mom is going to be so proud Hold on just one second. Uh, it looks like we've just implemented a hiring freeze. Um, I'm gonna have to rescind that offer. Survive congratulations. Now you know how to bomb your technical interview just like me. Make sure to subscribe to the Primagen for more awesome developer content. Thanks for watching, and I will see you in the next one.
Speaker 0 discusses his experience with FizzBuzz during a technical interview and how he uses a problem-saving code to solve it. They emphasize the importance of letting the interviewer understand the problem before breaking down code. Speaker 1 suggests practicing and avoiding confusion, and Speaker 2 suggests using a conditional statement to test the problem. They also discuss the use of the "other" command to create a loop and test the problem. Speaker 2 suggests using the command line and Speaker 1 asks about the algorithm's performance, to which Speaker 0 describes it as strong to quite strong. They also mention a hiring freeze and Speaker 0 arranges to rescind the offer.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : How to NOT Fail a Technical Interview 
        and a small summary : Speaker 0 discusses his experience with FizzBuzz during a technical interview and how he uses a problem-saving code to solve it. They emphasize the importance of letting the interviewer understand the problem before breaking down code. Speaker 1 suggests practicing and avoiding confusion, and Speaker 2 suggests using a conditional statement to test the problem. They also discuss the use of the "other" command to create a loop and test the problem. Speaker 2 suggests using the command line and Speaker 1 asks about the algorithm's performance, to which Speaker 0 describes it as strong to quite strong. They also mention a hiring freeze and Speaker 0 arranges to rescind the offer.
        [/INST]
        
        Generate the video : The single worst moment of my life was the moment I was born. I wish that were true, but as a software engineer, I've experienced far worse things during technical interviews. If you're lucky enough to survive tutorial hell before the age of 25, and find a way to impress the algorithms that automatically read your resume, you get dropped into a high stakes life or death game with a 6 figure salary on one side and Arby's on the other, you can tell yourself the interview process is broken, and maybe it is, but like most things in life, if you can't control it and just have to play the game. In today's video, you will experience the psychological roller coaster ride that is the technical interview. Along the way, you'll learn the secrets to a high pressure problem solving on the spot, and how to impress the interviewer even if you totally suck at writing code. To make this hyper realistic, I've invited a special guest who's conducted hundreds of interviews in the real world. Let the story begin. It's been a long difficult year of learntocode. I've turned down dates with beautiful women, stop doing flat earth research, and even cancel Netflix, all for the opportunity to stare at a computer screen for the rest of my life. Thanks to this awesome video I watched on YouTube, I finally landed an interview with Big Scary Tech Corporation. I've got dozens of leak code questions and a bunch of half finished Udemy courses under my belt. Nothing can stand in my way now. I'm about to jump on this call and change my life forever. Hello, mister Fireship. My name is the Primogen. Welcome to hell. Welcome to hell. Survive I'm just kidding. I'll be conducting your interview today. You know? Let's just get straight into it. I'm gonna ask you actually a classic question. It's called FizzBuzz. I want you to print out numbers 1 through 100. Please print out Fizz and Buzz. Fizz Buzz. How cliche is that? I mean, I just built my own compiler and JavaScript last night. This is too easy. Survive Wait a minute. I have no idea what I'm doing here. Hash map. Link list, mom. Mom, why am I so dumb? Wait. Directed graph. Uh, I I can't do it. I'm just gonna tell him I I can't do it. Binary treat. I'm an imposter. I'm blacking out. A few you, which means I don't care anymore, and magically when I stop caring, the anxiety goes away. Screw the code, let's just talk about the problem. Okay. So, it looks like we have 3 conditions here, and when we have conditions, we use a conditional statement like if. One way I could represent this is with a flowchart on a whiteboard, or if that's not an option, I might start by writing some pseudo code because I don't wanna worry about syntax or boilerplate before I even know what I'm going to implement. For each iteration of a loop, we have a number. If it's divisible by 3 and 5, we print fizzbuzz. Otherwise, if it's divisible by 3, we print fizz. Or if it's divisible by 5, we print buzz. And finally, just print the number if none of these are true. Wow. So this is actually a very simple problem when we take the time to break it down. I was totally overthinking it. I was expecting something with a really complex solution because this is Big Scary Tech Corporation after all. You know, I can't give you the answers, but I do really want to see you succeed. So feel free to ask questions as we go along. That solution looks pretty good. So how would you take that and turn it into code? I'm most comfortable in JavaScript, so I'll go ahead and use that for the implementation. First, we'll need a loop that iterates 100 times. As I'm writing this code, I'm not thinking about getting things done quickly, but rather I'm taking my time and making sure I fully understand the requirements before wasting my time writing a bunch of code that'll have to correct later. What's really important is that I think out loud and explain my decisions throughout the process. Normally, I like to use for each for loops, but, in this case, I'm going to use a traditional for loop and not for each, because I happen to know that for will result in better performance. Now, even if what I'm saying isn't totally correct, it's important for the interviewer to understand my problem solving process, saying something is almost always better than saying nothing at all. Unless, of course, you say some dumbass, in which case it may be optimal to just shut the fuck up. Before you set foot into the Thunderdome, you should practice literally saying everything out loud as you solve a problem. Personally, I hate talking while I write code, and it just takes a lot of practice to get comfortable with this. Follow the ABC rule I just made up, which doesn't mean always be coding, but always be chatting. Another tip is that if you get confused and freeze up, don't just sit there, but try to come up with a question. The longer you sit there and stare at the headlights, the more likely you are to lose your composure. We can't have anyone Freak out out there, okay? We've gotta keep our composure. We've got too far. There's too much to lose. We've gotta keep our closure. I'm a little confused here, so I might ask a question like, should the program take an input and return an answer for a specific index, or should always iterate over all 100 answers. Good question. Uh, a loop is just fine. Now I feel like I'm going in the right direction, so what I'll do next is create a few conditional statements that line up to what I sketched out on the whiteboard. Now, the tricky thing about FizzBuzz is determining if one number is a multiple of another number. I guess I could divide by the target number and if it's an integer it's a match, but if it's a decimal then it's not a match. That should work. So when it's 3 we'll log fizz, when it's 5 we'll log buzz, but if it's false on both of these, then we'll just console log the number. Yeah, I think that looks good. Let's go ahead and use bun to run it just to show off my a ledge of blazingly fast JavaScript tooling, and yes, it works perfectly. I'm a goddamn genius. Interesting. But can you do without magical type conversion? Yeah. You do have the modulo operator correct. Why don't you give it a try? Yeah. That would make more sense here. What it does is give us the remainder when doing division. So if that number is 0, then we know that it's a multiple whatever number we're trying to divide by, that gives us a solution that isn't so dependent on the loosely typed nature of JavaScript. It's usually a good idea to avoid language civic magic, the interviewer might be a c developer with 50 years of experience who's going to think your clever little JavaScript tricks are mid AF. The modulo operator's available in every language, so it's best to stick with that. This is looking pretty good. But can you make FizzBuzz print on a single line? Oh, yeah. That's kind of not correct, is it? Okay. I think I an idea, but I remember reading this article that's messing with my head right now that said the else keyword is an anti pattern. Maybe I should stop believing everything I read on the Internet. Let's give it a try and walk through it, we'll first check for the fizz buzz condition, then use if else a couple times to check for fizz and buzz. And then finally, we'll use else to log the number itself. Not only does just put fizz buzz on a single line, but the code is just more simple now. In fact, I don't think it can get any better. Oh, that looks correct. Now what happen if I wanted Add some more conditions. Let's say 7 is pass. How are you gonna deal with that? Uh, man. I knew it. Else statements really are garbage. Always believe everything you read on the Internet. It's never failed me. When you have a lot of conditions to check, one thing you generally want to do is try to extract the data out of that statement. We can easily do that here by defining a variable for the thing we want to print. Now, we could set up a switch statement to check all the different conditions, but I think using if is just as good if not better. As you can see here, I have GitHub Copilot enabled, but let's just keep that on a down low because I really need this job. Now, instead of console logging here, we'll just mutate the variable. This allows us to eliminate the FizzBuzz check and can also scale better if we decide to add additional words to it. Impressive. Very nice. Impressively very nice. Blazingly correct. Now, how would you describe the Performance of your algorithm. I would describe it as strong to quite strong. As you can see when I run it, there's almost no lag time because my holistic approach is so blazingly fast. Well, that's one way to describe it. I was more talking about Big O time complexity. Oh, yeah. I guess I should have studied Big O a little better before doing this interview. If the FizzBuzz game were to go on forever, I'd say we have linear time complexity or o of n, however, technically, the game is only played for 100 steps, which would simplify down to o one or constant time. Wow, I can't believe it's been an hour already and I blacked out. Where the hell am I? Is this heaven? Oh, hey, congratulations. You've got the job. Blood, sweat, and tears into this, and my mom is going to be so proud Hold on just one second. Uh, it looks like we've just implemented a hiring freeze. Um, I'm gonna have to rescind that offer. Survive congratulations. Now you know how to bomb your technical interview just like me. Make sure to subscribe to the Primagen for more awesome developer content. Thanks for watching, and I will see you in the next one.
        