跟读练习: How To Pass Coding Interviews Like the Top 1% - 通过视频学习英语口语
正在创建课程...
1
Most experienced software engineers still can't pass even basic coding interviews.
2
And it's not because they haven't grinded 300 lead code questions.
3
It's simply because they were never taught the process that I'm going to walk you through in this video.
4
Now, just to give you a little bit of credibility here, my name is Tim.
5
I've received offers from both Shopify and Microsoft after passing their coding interview rounds.
6
And I've worked at a company called Algo Expert, where I've personally created 60 coding interview questions, gone through the solutions, done in-depth video walkthroughs,
7
and have literally helped hundreds of people land jobs by passing coding interviews.
8
Now, to give you a concrete example here, we recently just had a software engineer join DevLodge.
9
He was very experienced, but he was having trouble getting and passing technical interviews.
10
After our assistance, he just passed a four-round technical interview, received a 180K per year job offer, and is now interviewing with Meta,
11
where we expect that he'll receive an offer because he's already in the final route.
12
Look, he was already an experienced software engineer.
13
We didn't need to teach him how to code.
14
We simply taught him this process.
15
And if you want this exact same process and hands-on assistance where we pretty much do it for you, then join DevLaunch or at least apply and see if we can help you from the link below.
16
Anyways, let's get into it here.
17
And I want to start talking about the three pillars of a coding interview
18
that you need to understand before I can get into the framework.
19
So the three major pillars of a coding interview are first, the planning and the design.
20
second, the coding, and then lastly, the communication, which obviously happens the entire time.
21
Now, most developers and I give mock interviews to do at least okay in two out of three of these areas, but it's the other area that they typically fail completely,
22
which just makes them unable to pass.
23
I can't give you a pass in a coding interview if you miserably fail any one of those three areas.
24
So you need to understand how to pass them and how to do well in them.
25
And sure, you can prepare for communicating.
26
You can prepare to do the planning really well by doing leak code questions.
27
But if you don't know the framework that you're supposed to follow through, you're going to end up failing the interviews.
28
I've seen this countless times, people that have done 700 leak code questions, but they still can't get a pass.
29
That's not because they don't understand how to solve the problem.
30
It's because they don't know how to play the game of interviewing.
31
Trust me, it's very frustrating.
32
I hate the fact that we have to go through this to get big tech jobs as a software engineer, but it's just the way that it is.
33
You need to learn how to play the game.
34
And that's why I'm going to break down this framework for you now.
35
And again, if you really just want someone to hold your hand through this process, then consider clicking that link and applying for DevLaunch, where we offer that type of one on one support.
36
Anyways, let's get into the framework.
37
Now this you can view as a checklist or an order of operations.
38
So something that you should always do anytime you're given a problem.
39
And I recommend practicing with this in mind.
40
So even if you don't have someone in front of you, like do this at least mentally so that you get in the habit of doing it and it just becomes automatic.
41
Now the first thing that you need to do in this framework is to always clarify the question.
42
Now most coding interviews will start with someone reading out some question to you, usually it's two or three sentences and they might say something like, given an array of integers,
43
reverse that array, giving you a very, very basic question.
44
Now this is almost never enough for you to actually be able to solve the problem.
45
What they're expecting you to do in this situation is to really break down what you were asked
46
and then ask a bunch of clarifying questions about it.
47
Now these questions are almost always going to be related to the input that you're given and then the expected output.
48
So in that example where you're given an array of integers, you'd want to be asking questions like, could the array be empty?
49
Are the integers bounded?
50
Can they be really large?
51
Can they be really small?
52
Are they only positive?
53
Are they only negative?
54
Can I have a zero value?
55
And then you want to ask things related to, is there always going to be an answer to this?
56
Should I be expecting a null input?
57
Should I be returning, for example, the head of a links list or the tail of a links list if you're given a question like that, right?
58
So just think about the question and start coming up with all these different questions
59
that you can ask to show that you're thinking about it deeply and that you're clarifying it.
60
Now, this helps you in a lot of ways.
61
Obviously, it shows that you're thinking about the question and trying to understand it.
62
But a lot of times you can actually save yourself a few lines of code
63
or simplify your solution by clarifying these types of inputs.
64
For example, if you're given a really complex problem and that problem may not have a solution to it, but you ask the interviewer, is there always going to be a solution based on the inputs?
65
And they say, yes, that's a whole edge case you now don't need to implement in your solution.
66
So you start by clarifying the problem, which means make sure that you understand it.
67
So ask any questions as well to make sure you do understand what's going on
68
and then clarify the input and the output so that you know what to expect when you go into the next phase.
69
So the next step in this framework is problem visualization.
70
And this is not always possible, but I highly recommend when you can and you're given the opportunity to draw out the problem.
71
Now, this is very useful, especially if you have a graph-based problem or a matrix problem or something where you can actually visualize it, right?
72
Where you have nodes, where you have connections.
73
This helps you, first of all, to actually see what's going on, but it also demonstrates to the interviewer that you're trying to understand the problem more before you dive into a solution.
74
Right now, again, we're in this kind of planning and design phase where you want to demonstrate how you think critically.
75
That's what this is about.
76
So if you can visualize the problem, that's always just helpful to me, to be honest, to solve the problem,
77
but also allows the interviewer to see what you're doing and to kind of unlock that visualization into your thought process.
78
Now that leads me to the next part in our framework, which is test cases.
79
Okay.
80
So before you just dive into coming up with the solution and designing your algorithm, you should really run through the example test cases that you're given.
81
And if you're not given any test cases, then at least ask for them, ask for at least one, hopefully they'll give them to you and make sure you understand how the answer to the problem is derived.
82
Now, in a simple problem, it's usually very clear to see, okay, this sample input equals this sample output, but for some more complex problems,
83
it may actually take you a few minutes to understand why this input equals this output.
84
And you should walk through
85
that verbally with the interviewer where you're writing out the test case and you're kind of just walking through it and saying, okay, I understand why this test case equals this answer.
86
Now beyond that, I highly recommend that you create your own test cases.
87
So at this point, start to think about various edge cases that could occur.
88
What if this is empty?
89
What if I have a negative value?
90
What if I have duplicate values, right?
91
There's all kinds of edge cases that could occur.
92
And you can do that by creating oftentimes more complex test cases
93
that you can use for yourself when you start trying to solve the problem.
94
So I always did this.
95
I always had success in this step.
96
Come up with another test case and just walk through it and see if from your test case, can come up with the answer.
97
This solidifies that you actually understand what the problem is, and then you can move on to the next phase.
98
Okay.
99
So the next phase here is algorithm design.
100
Now, this is the most important phase where this is going to make or break the entire interview for you.
101
Either you're going to do this part correctly, or you're pretty much just going to fail the entire interview.
102
So you need to come up with a very detailed plan, essentially the entire algorithm.
103
So the solution to the problem before you move on to do any type of coding.
104
Now, this is the part where all of that preparation is going to come in, right?
105
So oftentimes, if you've done a lot of prep, you're already going to have a very good idea of how to solve this problem because you've seen these patterns before.
106
Now you'll still need to do some critical thinking.
107
And what I want to remind you of here is that you need to treat this like a game.
108
Okay.
109
Even if you already know the answer to the problem, you need to pretend like you don't, and you need to show the interviewer that you're smart, essentially, that you can break down the problem,
110
that you can think critically, and that you can derive the algorithm by walking through your critical thinking and your problem solving steps.
111
This is exactly what I did at Microsoft in my second round.
112
I was given a question that I'd seen verbatim before, like an exact same Liko question.
113
I already knew the exact solution.
114
I knew the optimal case.
115
I knew the brute force case.
116
What I did is I pretended that I didn't know the answer, right?
117
And I said, okay, how would I think about this?
118
And I walked through and because I knew what the answer was, I was able to have a perfect thought process as I kind of derived the solution.
119
So that's what you're aiming to do.
120
Now, a few other tips in this kind of area here, always start with a brute force approach.
121
So oftentimes these problems are not that difficult to solve.
122
They're just difficult to solve in a optimal time complexity, right?
123
You may not know this really advanced technique.
124
So to save yourself, always try to come up with the brute force
125
or the naive approach where using a double for loop, triple for loop, something along those lines, so that at least if you can't come up with the optimal approach, you have something and you can and get to the coding phase.
126
So you should design a brute force algorithm, which is typically very simple, and then you're gonna say, hey, okay, this is not optimal because of this reason,
127
this reason, this reason, let me try something else.
128
So you start really quickly with a naive approach.
129
Then you explain to the interviewer, hey, I know this isn't good because of X, Y, Z.
130
Let's proceed to do something more optimal.
131
You try to come up with the optimal solution, and then you move on to the next phase.
132
Now, if you cannot come up with the optimal solution, that's still okay.
133
You can go ahead and implement the brute force approach, which I'm going to talk about in the next step.
134
But again, you need to walk through your thought process clearly.
135
you need to come up with an algorithm.
136
And at the end of this step, you should have written out step-by-step in plain English, this is what I'm going to do to solve this problem.
137
If you don't have that at the end of this step, then you failed.
138
You need to have a step-by-step plan so that in the next phase, when we start coding, you can simply translate that to code.
139
So now we're moving on to coding.
140
Now, in my opinion, this should be the easiest part, okay?
141
That's because you probably code all the time.
142
And here you've already done the hard work.
143
You've come up with the algorithm, you've thought about it deeply, and honestly, you can take about half the time to actually come up with the algorithm before you get into the coding phase,
144
if you're actually good at coding, right?
145
Now at this phase, all you're doing is you're translating English or your algorithm into code.
146
Again, in my opinion, that should be pretty trivial.
147
That should be easy.
148
Some algorithms can be more difficult to code out, but generally speaking, I find this is the easiest.
149
Now that said, I'm still going to give you a few tips here.
150
So first of all, when you're coding, you want to make sure you avoid having really long periods of silence.
151
I know for a lot of you, you need to be coding in silence, right?
152
Like you can't code while you're talking.
153
For me, for example, I can, because I do that every single day on YouTube and I have a lot of practice doing that.
154
But for many people, they need to kind of have a clear, bright brain and they can't be talking while they're doing this.
155
So if that's you, make sure you say what you're about to code before you start coding and you do that frequently.
156
So for example, you'd say, okay, I'm going to start solving the problem.
157
I'm going to make the function definition and then I'm going to sanitize the input.
158
Boom.
159
Okay.
160
You go do that.
161
Takes 30 seconds a minute, right?
162
Okay.
163
Now I'm about to check to make sure this thing is valid.
164
Boom.
165
You do that.
166
Okay.
167
Stop.
168
And just keep updating the interviewer on what you're doing.
169
You want to make sure that you're kind of streaming your consciousness onto the interviewer
170
and they understand what it is you're doing at every single step.
171
Don't worry if you make a small mistake.
172
Don't worry if you misspeak.
173
It's a lot better to be really verbal and saying a lot than it is to just sit there in silence.
174
If you just sit there in silence, they have no idea what you're doing.
175
And I can tell you as an interviewer, it's really painful because a lot of times we want to help you.
176
We want to give you tips and advice, but we can't because we have no idea what you're doing.
177
So make sure that you're speaking out loud a lot.
178
And again, you can speak, then code in silence, then speak, then code in silence.
179
That's fine.
180
Okay.
181
A few small tips here, rapid fire, make sure you use good variable names, be descriptive.
182
You can be verbose in what you're saying, especially if you have enough time, make sure that you're splitting things into functions.
183
So if you have a really long kind of algorithm, split it into separate parts and name those functions,
184
something accurate, make sure that you're writing code in an easy to read and easy to follow along with kind of style.
185
So reduce your indentation levels again, follow all of kind of those best practices.
186
And then overall, just keep it simple.
187
Don't try to use any super complex syntax or something the interviewer might not understand.
188
You definitely don't want to kind of make them feel dumb
189
if you're using something that don't know what's going on
190
and they should just be able to follow your code like very easily.
191
They should be able to read it like English.
192
Okay.
193
That's the coding portion.
194
Now let's move on to the next step.
195
So once you finish coding, you may or may not have a finished solution that's going to work.
196
Most times your code is probably not going to compile, especially if you're writing it on a whiteboard or
197
if you're doing it in Google docs or something ridiculous like they make you do, right?
198
That's totally fine of times interviewers are not expecting you to completely solve the problem in the 45 minutes
199
or hour that you have.
200
So don't stress about that.
201
But at this point, what you do need to do is you need to analyze your code
202
and go through the space and time complexity.
203
So you need to explain, okay, this is the approach I went with.
204
This is why I went with it.
205
This is the complexity.
206
So this is the time complexity in big O notation.
207
This is the space complexity.
208
And then you should tell the interviewer if you have a suboptimal solution.
209
So say, Hey, I know I didn't implement the most optimal solution because I did X, Y, Z.
210
I'm pretty sure there's an approach where I could solve this in linear time.
211
I just didn't have enough time to come up with that.
212
It's totally fine.
213
You're not like giving up or giving them a reason to fail you.
214
In fact, you're just giving them more reason to potentially bring you onto the next round.
215
So if you did make a mistake or you don't have the most optimal solution, it's okay.
216
Just explain that and tell them why you think it's not optimal and how you think you could improve it.
217
Right.
218
And then you can kind of walk through a quick verbal algorithm.
219
And a lot of times that's good to go.
220
All right.
221
Now in rare cases, you've got to this point, you've done the analysis and you still have some time left.
222
If that's the case, you may be asked to optimize this problem further.
223
I would actually suggest if you have extra time, bring that idea up to the interviewer, right?
224
Say, Hey, actually, I would like to optimize this further.
225
Can I change some of this?
226
Can I tweak this around?
227
This is kind of a bonus section because most people don't get to this point, but once you finish implementing, especially if you did a naive approach, you may be asked to do the optimization.
228
So when you do the optimization, again, you're going to go back to that analysis.
229
You're going to say, okay, this is where it was suboptimal.
230
And then you can start doing optimization where you make it faster, right?
231
Or you just make it better time complexity, better space complexity, et cetera.
232
There's There's not really much more for me to add to this section other than for you to be aware
233
that this is something that you will probably have to do
234
or that you might be able to do if you have enough time.
235
So just know that's kind of in the framework.
236
Okay.
237
So that's pretty much it.
238
That's the entire framework, right?
239
There's a lot of points there.
240
I know there's a lot of information.
241
Last thing though, I just want to go over a few things that you have to do in your interview.
242
Otherwise you're going to fail a hundred percent.
243
So just follow these three pointers when you go through this framework.
244
Now, first you need to stream your consciousness to the interviewer.
245
I said this before in the coding section, but this goes for the entire interview, right?
246
Most of what you're being judged on is what you say, your problem solving skills, and what they hear come out of your mouth.
247
You can make mistakes, that's fine, but you need to be very, very verbal, right?
248
If you don't say something, they don't know that you're thinking it.
249
It's really frustrating as an interview when a candidate's just kind of sitting there thinking
250
and they don't say anything because you can't help them
251
and you have no idea what it is that that they're actually doing.
252
More than half of this interview is just purely communication.
253
And even if you fail everything, but you communicate really well, you still have a chance to move forward.
254
So just make sure you're really communicating and overly communicating more than you think you should be.
255
Next, you need to code fluently, okay?
256
It needs to look like you're actually a software engineer
257
when you hop into the code editor when you're writing code by hand.
258
Now I'm saying this because I recently did a few mock interviews with some students that joined DevLodge.
259
I'm not gonna expose their name and now they're doing a lot better since we've worked with them, but they were senior level software engineers, and I brought them into a mock kind of coding environment,
260
just like VS Code, and told them, hey, whip up this Java code.
261
And it looks like they'd never written a line of code in their life because they rely on AI tools, they rely on autocomplete, and they couldn't even remember the syntax for like a for loop or a while loop.
262
It doesn't matter how good you are
263
or how well you do in the rest of the interview if it looks like you haven't written code before.
264
So just make sure that you can code fluently.
265
So do practice without using autocomplete, without using the IDEs, put that away when you're doing this DSA prep so that,
266
you know, you actually have this basic syntax memorized and you can code it up fluently from heart.
267
I know it's annoying, but it's just something you need to do.
268
And then lastly, think of your interviewer like a teammate.
269
Communicate with them, ask them questions, laugh, be friendly, right?
270
This interviewer is probably someone, especially in later rounds, who's actually going to be working with you on a team.
271
So they're also trying to gauge, do I want to work with this person?
272
Would my team, you know, be a good fit with them?
273
So try to kind of show that personality and don't think of it like an interview.
274
Think of it like you're working with this person to solve this problem.
275
And a lot of times, the more friendly you are, the more hints you're going to get, the more they're going to be rooting for you.
276
And I can tell you in all of my interviews, by the time I got to the end of it, I did genuinely feel like I was on a team with this person and we just solved it together.
277
Sure, I did most of the work.
278
They already knew the answer, but they were kind of there along the way, like a teammate, not someone who is rooting for me to fail.
279
In most cases, the interviewer wants you to succeed, but they can only want that if you're actually communicating, being verbal, being friendly, et cetera.
280
So just kind of a last piece of advice there.
281
Think of it like a teammate.
282
Don't think of it like they're challenging you or, you know, trying to make you fail because that's almost never the case.
283
All right.
284
That was a lot.
285
That is my framework.
286
Those are the steps.
287
I want it to be as detailed as possible and just give you as much value as I possibly can.
288
Now, if this video is helpful
289
and you want us to hold your hand through this process and make sure that you're prepared for technical interviews,
290
Join Dev Launch where we're already doing that every single day and seeing a ton of success.
291
Anyways, I hope you guys enjoyed.
292
If you did, leave a like, subscribe, and I will see you in the next one.
📺 同频道
✨ 推荐视频
B21
22 句
I'm an ex-Google interviewer. You're doing LeetCode wrong.
Business EnglishInterview EnglishUniversity Students
B21
202 句
SOFTWARE ENGINEER Interview Questions & TOP SCORING ANSWERS!
Business EnglishInterview EnglishUniversity Students
B23
63 句
How To Land Your First Junior Dev Role
Business EnglishInterview EnglishUniversity Students
B2218 句
Ace every UX/UI design interview like THIS
Business EnglishInterview EnglishUniversity Students
B2257 句
How I Escaped Help Desk Fast (Step-by-Step)
Business EnglishInterview EnglishUniversity Students
B24
77 句
Tell Me About Yourself (The BEST Way to Answer this Interview Question)
American AccentBusiness EnglishInterview EnglishUniversity Students
B21
196 句
I cloned 3 apps and now make $35K/month
Business EnglishInterview EnglishUniversity Students
B21
113 句
Google Interview Tips That Actually Get You Hired
Business EnglishInterview EnglishUniversity Students
B23
265 句
How I Would Start Cybersecurity in 2026 (If Starting From Zero)
Business EnglishInterview EnglishUniversity Students
B24
218 句
My Entire Job Search Process: Software Engineer Resume & Interviews
Business EnglishInterview EnglishUniversity Students
B21
278 句
How to Answer the 8 HARDEST Interview Questions | Job Interview Tips
Business EnglishInterview EnglishUniversity Students
B22
210 句
Top 10 Linux Job Interview Questions
Business EnglishInterview EnglishUniversity Students
本节课你将练习什么？
本节课围绕一段关于编程面试技巧的视频展开，你将通过影子跟读练习提升英语口语能力，同时学习与职场面试、技术沟通相关的实用表达。视频内容涵盖面试框架、沟通技巧等，语速适中且逻辑清晰，非常适合用来训练听力理解与口语流畅度。
核心词汇与短语
- coding interview：编程面试
- clarifying questions：澄清问题
- framework：框架（此处指面试流程框架）
- lead code questions：力扣题目（编程面试常见练习题）
- order of operations：操作顺序
影子跟读练习技巧
视频中说话者语气自信且条理分明，语速约为每分钟150-180词，适合使用“影子跟读”法练习。建议先完整听一遍，抓住整体逻辑；再逐句跟读，重点模仿重音（如“three pillars”“clarify the question”等关键词）和停顿。若觉得困难，可使用shadowing site或shadowspeak工具放慢语速。练习时注意观察说话者如何通过升调表达疑问（如视频中举例的澄清问题部分），这对提升英语口语练习的真实感很有帮助。坚持用shadowspeaks方法每天练习5-10分钟，你会发现自己的反应速度和表达流畅度明显提升。记住，影子跟读的关键是“同步”而非“复述”，尽量跟上说话者的节奏，感受语言的韵律。
什么是跟读法？
跟读法 (Shadowing) 是一种有科学依据的语言学习技巧，最初开发用于专业口译员的培训，并由多语言者Alexander Arguelles博士普及。这个方法简单而强大：您在听英语母语原声的同时立即大声重复——就像是一个延迟1-2秒紧跟说话者的影子。与被动听力或语法练习不同，跟读法强迫您的大脑和口腔肌肉同时处理并模仿真实的讲话模式。研究表明它能显着提高发音准确性，语调，节奏，连读，听力理解和口语流利度——使其成为雅思口语备考和真实英语交流最有效的方法之一。