跟讀練習: How to NOT Fail a Technical Interview - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

160 句

如果句子過短或過長，請點選 Edit 進行調整。

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 six-figure salary on one side and RVs on the other.

You can tell yourself the interview process is broken, and maybe it is, but like most things in life, you can't control it and just have to play the game.

In today's video, you will experience the psychological rollercoaster ride that is the technical interview.

Along the way, you'll learn the secrets to 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 hashtag learn to code.

I've turned down dates with beautiful women, stopped doing flat-earth research, and even canceled 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, Mr. Fireship.

My name is the Prime Gen. Welcome to hell.

Welcome to hell.

I'm just kidding.

I'll be conducting your interview today.

You know, let's just get straight into it.

I'm going to ask you actually a classic question.

It's called FizzBuzz.

I want you to print out numbers 1 through 100.

But if it's divisible by 3, I want you to print out fizz.

If a number is divisible by 5, please print out fuzz.

But if it's divisible by both 3 and 5, please print out fizz and buzz.

Fizzbuzz, how cliche is that?

I mean, I just built my own compiler in JavaScript last night.

This is too easy.

Wait a minute.

I have no idea what I'm doing here.

Hashmap, link list.

Mom, mom, why am I so dumb?

Wait, directed graph.

I can't do it.

I'm just gonna tell him I can't do it.

Binary treat.

I'm an imposter.

I'm blacking out.

A few moments later.

Mr. Fireship, before we write any code, let's just talk about the problem.

How would you kind of approach a problem like this?

You know what?

I think I've already failed this interview, 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 three 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 pseudocode because I don't want to worry about syntax or boilerplate before I even know what I'm going to implement.

For each iteration of the 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 I'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 4 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 st, in which case it may be optimal to just shut the fk 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 come too far!

There's too much to lose!

much to lose!

Keep our composure!

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 it always iterate over all 100 answers?

Good question.

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 will log fizz, when it's 5 will 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 knowledge of blazingly fast JavaScript tooling.

And yes, it works perfectly.

I'm a goddamn genius.

Interesting.

What can you do without magical type conversion?

Do you know what modulo is.

Oh man, he's not impressed at all.

I'm such a loser.

Modulo?

100

I've never even heard that word in my life.

101

Oh wait, are you talking about the remainder operator in JavaScript?

102

Yeah, you do have the modulo operator correct.

103

Why don't you give it a try?

104

Yeah, that would make more sense here.

105

What it does is give us the remainder when doing division, so if that number is zero, then we know that it's a multiple of whatever number we're trying to divide by.

106

That gives us a solution that isn't so dependent on the loosely typed nature of JavaScript.

107

It's usually a good idea to avoid language-specific magic.

108

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.

109

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

110

This is looking pretty good, but can you make FizzBuzz print on a single line?

111

Oh yeah, that's kind of not correct, is it?

112

Okay, I think I have 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.

113

Maybe I should stop believing everything I read on the internet.

114

Let's give it a try and talk through it.

115

We'll We'll first check for the fizzBuzz condition, then use if-else a couple times to check for fizz and buzz.

116

And then finally we'll use else to log the number itself.

117

Not only does this put fizzBuzz on a single line, but the code is just more simple now.

118

In fact, I don't think it can get any better.

119

Oh, that looks correct.

120

Now, what happened if I wanted to add some more conditions?

121

Let's say 7 is BAS.

122

How are you going to deal with that?

123

Ah man, I knew it.

124

L statements really are garbage.

125

Always believe everything you read on the internet.

126

It's never failed me.

127

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.

128

We can easily do that here by defining a variable for the thing we want to print.

129

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.

130

As you can see here, I have GitHub Copilot enabled, but let's Just keep that on the down low because I really need this job.

131

Now, instead of console logging here, we'll just mutate the variable.

132

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

133

Impressive.

134

Very nice.

135

Impressively very nice.

136

Blazingly correct.

137

Now, how would you describe the performance of your algorithm?

138

I would describe it as strong to quite strong.

139

As you can see when I run it, there's almost no lag time because my holistic approach is so blazingly fast.

140

Well, that's one way to describe it.

141

I was more talking about Big O time complexity.

142

Oh yeah, I guess I should have studied Big O a little better before doing this interview.

143

If the FizzBuzz game were to go on forever, I'd say we have linear time complexity, or O of N.

144

However, technically, the game is only played for 100 steps, which would simplify down to O1, or constant time.

145

Wow, I can't believe it's been an hour already.

146

I blacked out.

147

Where the hell am I?

148

Is this heaven?

149

Oh hey, congratulations, you've got the job.

150

Here's your offer sheet with a $400,000 salary and the job is fully remote with unlimited vacation time.

151

Your first task you'll be working on is changing all of the blue buttons to a slightly different color blue.

152

Wow, I can't believe it.

153

I've spent the last two years pouring my blood, sweat, and tears into this, and my mom is going to be so proud.

154

Hold on just one second.

155

Uh, it looks like we've just implemented a hiring freeze.

156

Um, I'm gonna have to rescind that offer.

157

Bruh!

158

Congratulations, now you know how to bomb your technical interview just like me.

159

Make sure to subscribe to the Primogen for more awesome developer content.

160

Thanks for watching, and I will see you in the next one.

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

同頻道

FOR YOU

背景與上下文

在這段影片中，講述者分享了他作為軟體工程師在技術面試中的真實經歷。這是一場高壓的心理過山車，通過生動的敘述，聽眾可以感受到面試過程中的緊張與焦慮。面對各類面試題，如何在瞬息萬變的環境中依舊保持冷靜，成為每個應聘者需要掌握的重要技巧。

日常交流中的五個重要短語

“歡迎來到地獄”：引入幽默感，幫助緩解面試緊張氣氛。
“在開始寫程式碼之前，讓我們先討論這個問題”：強調了解問題的重要性。
“我真的不知道自己在做什麼”：展現脆弱，使面試氛圍更為輕鬆。
“我們有三個條件”：結構化思維，讓面試官清晰理解你的邏輯。
“我就是個冒名頂替者”：這句自嘲可以讓面試者稍微放鬆下來。

逐步模仿指導

對於想通過模仿學習技術面試交流的英語學習者，通過以下步驟進行雅思口語練習，將有助於提升你的溝通能力：

觀看影片：首先，認真觀看影片並注意講述者的語調和節奏，可以在看YouTube學英語。
模仿發音：選擇一段講述，分段播放並模仿發音。試著提升你的流利度，減少停頓。
理解內容：在理解每個短語的含義後，試著將其應用於不同場合。
使用工具：利用 shadowing site 進行練習並錄製自己的聲音，逐漸改進表達。
反覆練習：不要害怕反覆練習同一段落，直至你完全掌握髮音和語調。

通過這種方式，結合 shadow speak，不僅能夠提高你的英語口語能力，還能增強在高壓環境下的應對能力。讓我們一起踏上這條充滿挑戰與樂趣的英語學習之路吧！

影片中的語法

說話人最常用的結構，並附上影片中的原話：

結構	影片中的用法
現在完成時 have/has + 過去分詞 — 過去發生但與現在仍有關聯的事	I've experienced · I've invited · It's been
被動語態 be + 過去分詞 — 強調發生了什麼，而不是誰做的	was born · is broken · is only played

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: How to NOT Fail a Technical Interview - 通過影片學習英語口語

選擇練習模式

下載應用

同頻道

The last real programmers are dying out...

PostgreSQL in 100 Seconds

React Native in 100 Seconds

Did Google just dethrone OpenAI and Anthropic?

A $6.3 billion open-weight model just got embarrassed by the French...

Every app on Earth is now open source... whether it likes it or not

OpenAI’s lead engineer was secretly a spy...

Mind-bending new programming language for GPUs just dropped...

Intel chips can’t possibly be this bad… 100% crash rate?

Godot in 100 Seconds

Grok 4 pushes humanity closer to AGI… but there’s a problem

Array Map in 100 Seconds

Docker in 100 Seconds

OpenAI’s new browser feels familiar…

Angular in 100 Seconds

10 weird OSS projects you need right now...

Firefox and Tor hit with 9.8 critical level exploit

5 open source tools that replaced my $320/mo AI stack...

The most interesting "hack" in history...

C++ in 100 Seconds

推薦影片

The unfair way I got good at Leetcode

QUALITY ENGINEER Interview Questions & Answers! (How to PASS a Quality Engineer Job Interview!)

FULL Data Science Mock Interview | SQL, Statistics, Business

What is Your Biggest Weakness? (Ace this Interview Question!)

10 JavaScript Interview Questions You HAVE TO KNOW

[2026] TOEFL iBT Speaking Take an Interview | Step-by-Step Strategies #0008

Steve Jobs on Failure

CAP Theorem in System Design Interviews

Recruiter Secrets: Why You Get Rejected in the Middle of the Night

How to Become a Great Software Developer — Best Advice from Top-Notch Engineers

背景與上下文

日常交流中的五個重要短語

逐步模仿指導

影片中的語法

什麼是跟讀法？