Shadowing Practice: How To Pass Coding Interviews Like the Top 1% - Learn English Speaking with Video

Most experienced software engineers still can't pass even basic coding interviews.

And it's not because they haven't grinded 300 lead code questions.

It's simply because they were never taught the process that I'm going to walk you through in this video.

Now, just to give you a little bit of credibility here, my name is Tim.

I've received offers from both Shopify and Microsoft after passing their coding interview rounds.

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,

and have literally helped hundreds of people land jobs by passing coding interviews.

Now, to give you a concrete example here, we recently just had a software engineer join DevLodge.

He was very experienced, but he was having trouble getting and passing technical interviews.

After our assistance, he just passed a four-round technical interview, received a 180K per year job offer, and is now interviewing with Meta,

where we expect that he'll receive an offer because he's already in the final route.

Look, he was already an experienced software engineer.

We didn't need to teach him how to code.

We simply taught him this process.

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.

Anyways, let's get into it here.

And I want to start talking about the three pillars of a coding interview

that you need to understand before I can get into the framework.

So the three major pillars of a coding interview are first, the planning and the design.

second, the coding, and then lastly, the communication, which obviously happens the entire time.

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,

which just makes them unable to pass.

I can't give you a pass in a coding interview if you miserably fail any one of those three areas.

So you need to understand how to pass them and how to do well in them.

And sure, you can prepare for communicating.

You can prepare to do the planning really well by doing leak code questions.

But if you don't know the framework that you're supposed to follow through, you're going to end up failing the interviews.

I've seen this countless times, people that have done 700 leak code questions, but they still can't get a pass.

That's not because they don't understand how to solve the problem.

It's because they don't know how to play the game of interviewing.

Trust me, it's very frustrating.

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.

You need to learn how to play the game.

And that's why I'm going to break down this framework for you now.

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.

Anyways, let's get into the framework.

Now this you can view as a checklist or an order of operations.

So something that you should always do anytime you're given a problem.

And I recommend practicing with this in mind.

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.

Now the first thing that you need to do in this framework is to always clarify the question.

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,

reverse that array, giving you a very, very basic question.

Now this is almost never enough for you to actually be able to solve the problem.

What they're expecting you to do in this situation is to really break down what you were asked

and then ask a bunch of clarifying questions about it.

Now these questions are almost always going to be related to the input that you're given and then the expected output.

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?

Are the integers bounded?

Can they be really large?

Can they be really small?

Are they only positive?

Are they only negative?

Can I have a zero value?

And then you want to ask things related to, is there always going to be an answer to this?

Should I be expecting a null input?

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?

So just think about the question and start coming up with all these different questions

that you can ask to show that you're thinking about it deeply and that you're clarifying it.

Now, this helps you in a lot of ways.

Obviously, it shows that you're thinking about the question and trying to understand it.

But a lot of times you can actually save yourself a few lines of code

or simplify your solution by clarifying these types of inputs.

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?

And they say, yes, that's a whole edge case you now don't need to implement in your solution.

So you start by clarifying the problem, which means make sure that you understand it.

So ask any questions as well to make sure you do understand what's going on

and then clarify the input and the output so that you know what to expect when you go into the next phase.

So the next step in this framework is problem visualization.

And this is not always possible, but I highly recommend when you can and you're given the opportunity to draw out the problem.

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?

Where you have nodes, where you have connections.

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.

Right now, again, we're in this kind of planning and design phase where you want to demonstrate how you think critically.

That's what this is about.

So if you can visualize the problem, that's always just helpful to me, to be honest, to solve the problem,

but also allows the interviewer to see what you're doing and to kind of unlock that visualization into your thought process.

Now that leads me to the next part in our framework, which is test cases.

Okay.

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.

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.

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,

it may actually take you a few minutes to understand why this input equals this output.

And you should walk through

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.

Now beyond that, I highly recommend that you create your own test cases.

So at this point, start to think about various edge cases that could occur.

What if this is empty?

What if I have a negative value?

What if I have duplicate values, right?

There's all kinds of edge cases that could occur.

And you can do that by creating oftentimes more complex test cases

that you can use for yourself when you start trying to solve the problem.

So I always did this.

I always had success in this step.

Come up with another test case and just walk through it and see if from your test case, can come up with the answer.

This solidifies that you actually understand what the problem is, and then you can move on to the next phase.

Okay.

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.

📺 Zelfde Kanaal

✨ Aanbevolen Video

22 zinnen

I'm an ex-Google interviewer. You're doing LeetCode wrong.

University StudentsBusiness English+2

202 zinnen

SOFTWARE ENGINEER Interview Questions & TOP SCORING ANSWERS!

University StudentsBusiness English+2

63 zinnen

How To Land Your First Junior Dev Role

University StudentsBusiness English+2

218 zinnen

Ace every UX/UI design interview like THIS

University StudentsBusiness English+2

257 zinnen

How I Escaped Help Desk Fast (Step-by-Step)

University StudentsBusiness English+2

77 zinnen

Tell Me About Yourself (The BEST Way to Answer this Interview Question)

en-USUniversity Students+3

196 zinnen

I cloned 3 apps and now make $35K/month

University StudentsBusiness English+2

113 zinnen

Google Interview Tips That Actually Get You Hired

University StudentsBusiness English+2

265 zinnen

How I Would Start Cybersecurity in 2026 (If Starting From Zero)

University StudentsBusiness English+2

218 zinnen

My Entire Job Search Process: Software Engineer Resume & Interviews

University StudentsBusiness English+2

278 zinnen

How to Answer the 8 HARDEST Interview Questions | Job Interview Tips

University StudentsBusiness English+2

210 zinnen

Wat is de Shadowing-techniek?

Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop — als een schaduw die de spreker volgt met slechts 1–2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert — waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.

Shadowing-techniek: lees de volledige stap-voor-stap-gids →

Shadowing Practice: How To Pass Coding Interviews Like the Top 1% - Learn English Speaking with Video

Claude Code: The Advanced Guide (99% of Devs Skip These Features)

Learn C++ With Me #19 - Sets

How to learn Machine Learning like a GENIUS and not waste time

I'm an ex-Google interviewer. You're doing LeetCode wrong.

SOFTWARE ENGINEER Interview Questions & TOP SCORING ANSWERS!

How To Land Your First Junior Dev Role

Ace every UX/UI design interview like THIS

How I Escaped Help Desk Fast (Step-by-Step)

Tell Me About Yourself (The BEST Way to Answer this Interview Question)

I cloned 3 apps and now make $35K/month

Google Interview Tips That Actually Get You Hired

How I Would Start Cybersecurity in 2026 (If Starting From Zero)

My Entire Job Search Process: Software Engineer Resume & Interviews

How to Answer the 8 HARDEST Interview Questions | Job Interview Tips

Top 10 Linux Job Interview Questions

The Scenario: Nailing Technical Interviews (and English Fluency)

Useful Chunks & Collocations to Master

Your Shadowing Challenge: Speak Like a Pro

Wat is de Shadowing-techniek?