쉐도잉 연습: 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
202 문장
SOFTWARE ENGINEER Interview Questions & TOP SCORING ANSWERS!
Business EnglishInterview EnglishUniversity Students
B22
75 문장
The unfair way I got good at Leetcode
Business EnglishInterview EnglishUniversity Students
B21
113 문장
Google Interview Tips That Actually Get You Hired
Business EnglishInterview EnglishUniversity Students
B2257 문장
How I Escaped Help Desk Fast (Step-by-Step)
Business EnglishInterview EnglishUniversity Students
B23
63 문장
How To Land Your First Junior Dev Role
Business EnglishInterview EnglishUniversity Students
B21
119 문장
Cracking the Behavioral Interview for Software Developers
Business EnglishInterview EnglishUniversity Students
B21
196 문장
I cloned 3 apps and now make $35K/month
Business EnglishInterview EnglishUniversity Students
B24
219 문장
How To Speak Like A Billion-Dollar CEO
Business EnglishInterview EnglishUniversity Students
B2218 문장
Ace every UX/UI design interview like THIS
Business EnglishInterview EnglishUniversity Students
B21
64 문장
Walk Me Through Your Resume: How to Answer
Business EnglishInterview EnglishUniversity Students
B23
265 문장
How I Would Start Cybersecurity in 2026 (If Starting From Zero)
Business EnglishInterview EnglishUniversity Students
B24
23 문장
Interviewing Part 1 - What You Need To Ask In Advance
Business EnglishInterview EnglishUniversity Students
이 비디오로 배울 실용적인 영어 회화 기술
이 영상은 코딩 인터뷰 준비에 관한 내용이지만, 영어 회화 연습에 매우 유용한 기술을 담고 있습니다. 특히 자연스러운 질문하기와 명확한 의사소통, 리스닝 후 즉각적인 반응의 세 가지 기술을 기를 수 있습니다. 유튜브 영어 공부를 하면서 이런 실제 대화 체험을 반복하면, IELTS 스피킹에서도 중요한 '의사소통 능력'을 크게 향상시킬 수 있습니다.
듣고 주목해야 할 발음 특징
영어 원어민의 발음에서는 연결 발음과 축약 발음이 많이 나타납니다. 이 비디오에서도 "it's not because"가 "it's not 'cause"로, "you're supposed to"가 "you're s'posed to"로 축약되는 것을 들을 수 있습니다. 또한 "a bunch of"에서 "a"와 "bunch"가 연결되어 "uh bunch of"로 발음되며, "what you were asked"는 "wha' you were asked"로 약화됩니다. 이러한 연결과 축약을 파악하면, 유튜브 영어 공부를 더 효과적으로 할 수 있습니다.
원어민처럼 말하는 방법: 리듬과 강세
원어민처럼 말하려면 리듬과 강세를 중시해야 합니다. 이 비디오의 화자는 "clarify the question"에서 "clarify"를 강조하고, "expected output"에서 "expected"에 강세를 둡니다. 또한 문장의 흐름에서 중요한 정보를 전달할 때는语速를 늦추고, 보조적인 내용은 빠르게 말하는 것을 볼 수 있습니다. shadow speech (쉐도잉) 연습을 할 때는 이 리듬을 따라가며, 강세가 있는 단어를 명확히 발음하는 것이 핵심입니다. shadowspeak 기술을 연습하면, 영어 회화에서 자연스러운 흐름을 만들 수 있으며, IELTS 스피킹에서도 높은 점수를 받을 수 있습니다.
매일 10분씩 이 비디오를 활용해 쉐도잉 연습을 하면, 발음 뿐만 아니라 의사소통 능력도 크게 향상될 것입니다. 영어 회화 연습은 지속적인 노력이 필요하지만, 올바른 방법을 따라가면 빠르게 실력이 늘어납니다.
이 영상의 문법
화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.
| 문형 | 영상 속 표현 |
|---|---|
| 현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때 | haven't grinded · I've received · I've worked |
| 수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점 | were never taught · were asked · be related |
| 관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보 | problem, which means · framework, which is · algorithm, which is |
쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법
쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.