Shadowing Practice: FullStack Interview Questions (Junior & Mid) - Learn English Speaking with Video

So first question of today's interview, what is an SQL injection attack?

An SQL injection attack.

Can I share my screen?

Yeah, sure.

Go ahead.

If that helps.

Okay.

So SQL injection, it's basically when we have a webpage, right?

And we have an input field on that webpage.

Let's imagine it that way.

And basically the attacker, so this is our application.

We have a backend and the attacker is capable of writing SQL code over here.

So they do write some SQL.

Oh my God, I'm super zooming.

So they write some SQL over here

and that SQL gets actually executed because we failed to sanitize that input into our database.

And they could do certain things like they could probably, for example, change the privileges of their own user.

They can read our database.

They can drop the database.

And this was a very common attack, I think back in the early 2000s.

So basically what they would do is I would write here some SQL, like select all from but they need to engineer their queries very well

so for example what they would do is they would add they'll try different things

and you would start this statement with maybe a semicolon

and what that would do is that in the back

if in the back end the way the back end developers

go their queries was like this like let's say they had

a select all from users where user username it's equal to and you would normally do string interpolation

with the input that comes from the front end.

So you'd put directly the input here.

The attacker could actually put this query that they put in into here.

And so you'd end up running SQL on the database.

And the way to avoid this is to just use, first of all, sanitize all the input.

And second of all, use SQL parameters.

Basically, they look something like this.

But what SQL will do when you send this query over and you provide this dollar sign argument separately, it will not run this as SQL.

It was really like the query, the executable part of the query is this one and then provide this as an input and then it won't work.

If they provide some SQL here, it's just going to, they will get no results, but it's not going to execute that on our database.

Cool.

Now we're going to move on with the second question.

Can you explain HTTP caching?

Right.

And also go into advantages and let me know if you ever used it in the past later.

Awesome.

Sure.

So HTTP caching, it's one of my favorites because it's very easy to set up these days.

And basically, well, it's always, it's an HTTP mechanism.

So it happens between a client and a server.

And imagine we have here a CSS file or any other file, an image, a heavy file.

We definitely want the users, we could actually make the webpage load faster

if users could reuse this resource in the future and not have to download it every time they go to their website.

So what happens normally is, let's imagine this is our server.

And they will be our client.

Yes.

And they'll make a first request of an asset.

It can be even a REST resource, an HTML file.

And so what they would receive in the HTTP headers would be a header called cache control.

And there's different values for this header.

but one of the most common is to basically specify this is the header that specifies

how the client should cache this

so basically here they would have something like let me make this bigger perfect

so we'll have something like public and a max age property

so max age and this would be milliseconds

and what this means is the client can reuse that resource as long as the age

of the asset so there's an age which starts at zero

when we just got it as long as the age it's

smaller than max age the client doesn't need to get

that resource uh basically the web browser would store

that on the computer and get the resource from there get the css file from there um

and that's so that's basically the the basics behind it what would happen what what's happening

when the age goes higher than this uh then then whatever the max age was is that the

client will make a request but it's not a request for the resource

but it's rather to check

if it's this is what we call caching validation is the resource still fresh is the resource still fresh

and basically they will do that nowadays with the e-tag

so you probably have an extra tag which was it's the tag

and basically it's a unique hash that was computed for this version of the css file

and so they will send that to the server

and check was this modified

and the server can answer with in two ways they can either say no it wasn't modify keep

that version or yes it was modified make a request get a new version over

and back to your question on

if i ever used it this is basically uh most of

times comes out of the box with any cdn you're using

so if you're deploying your application

and you put a cdn in front of it like a

content delivery network basically they already apply this to all your

static assets they add etags they add the cache control

and the age and we can even go in

and look at the live example

if you want yeah let's pick something like maybe github

or any like popular developer website okay let me see if i can share my screen again Now,

one thing I want you to do to go over is this public parameter.

You know, what does public mean in that request?

Okay, so let's see how this looks like in Stack Overflow, for example.

Yeah, so I'm going to go over why I did that and what does that mean, but I just reloaded a page right now.

And as you see here, it says 200 from the disk cache.

So this was not, this is not coming from the server.

This is coming from my personal computer.

And the reason for that is that you see I'm not sure how big this is, but the age parameter here, the age, it's this minimum milliseconds.

100

And if we look at the cache control, it's a public mass max age 315, 360.

101

So basically what this is saying is, Hey, you, you can keep the asset for a bit longer.

102

Yes.

103

As long as this age goes over, they will rely on the e-tag.

104

So there's this e-tag header that should be somewhere.

105

Now, because there's no e-tag, because I probably did not, give me a second, accept.

106

Okay, it didn't really find the e-tag.

107

I think they might be relying on the last modified.

108

Last modified, it's an alternative and expires.

109

There are alternatives to eTags, but because it's so hard in programming to compare dates and you need to always bring them back to a time zone,

110

it's just a lot easier to use the eTags.

111

And so the modern way is to use eTags.

112

Maybe if we look at another asset, like a CSS asset, they probably use...

113

I could see the eTag there.

114

There you go.

115

It has an eTag.

116

but again um the cache control on this resource is no cache

117

so okay even

118

if we have it's not really being used that's what i was looking for this one that's a better example

119

but again there's no there's no e-tag on this one

120

so it very much depends on how they um perfect it's

121

pretty much i feel like they're using an older um setup because they're using expire and last modify all the time

122

The other thing is, as you see here, if we enable Disable Cache, what we will be doing, and this is something really cool that Google Chrome does for us, is that whenever we get a resource,

123

on the request headers, we are setting a cache control ourselves to no cache as the client.

124

We're saying, hey, there won't be any caching happening.

125

Bypass the cache, right?

126

Yes, you could say that.

127

We're actually using the headers to specify there is no cache.

128

and because we do that, you see cache control, no cache, then it doesn't really matter what the server implements.

129

So just going back to the drawing, this is how HTTP caching works, I'd say at top view.

130

Awesome, Bogdan.

131

Now let's move on with the next question.

132

So imagine you have a huge SQL database.

133

We want to scale that.

134

So what are the different ways we can scale that huge SQL database?

135

Okie dokie so we have one of those um i'm going to go back to my board just

136

because it's a lot easier to show than tell um yeah

137

as a quick question do we know anything about the traffic

138

on this database in terms of reads versus writes for example do we read a lot

139

or do we write a lot what is it let's let's assume we read a lot more than we write

140

but as we scale we will also um face a writing problem down the road.

141

Okay, I mean most web applications you will read a lot more than you write

142

if you take the example of Instagram and so on

143

or any social media people watch and consume stuff much more than they publish on average.

144

Yeah that's a good news feed based application like a social media that's a good example so you can use that yes.

145

Okay so if that's the case and we get a lot of incoming traffic here

146

and we figure out that the queries are getting slower the memory on this component memory

147

and cpu usage uh it's blown up what we can do is to basically apply a replication strategy

148

that will basically rather than having one database we will have one database

149

that handles the reading

150

and then we're going to have a bunch of let me copy this a bunch of read-only replicas so

151

they used to be called master

152

and slave although right now we can just call it the the main database

153

and then uh and basically what happens is we write to the main database

154

and whenever we write that it gets replicated to the child to the to the read-only replicas

155

but whenever we read from the database we go to this cluster of read-only replicas

156

and so we can offload a lot of reading pressure to these replicas

157

and they are quite performant and

158

that will be one of the easiest way to scale the

159

database by by having read-only let me write it down here

160

read-only replicas you can do this in aws i've done this with rds it's very straightforward

161

and it's one of the easiest way now to follow up

162

on what you mentioned as a second case imagine we do need to write a lot so

163

um we are getting to this point where this database right is getting bigger

164

and bigger we have too much pressure on the hardware

165

and we either add more hardware which is usually a bad strategy or what we can try to implement it's sharding

166

so basically what we do is

167

that we try to split um into different databases based on a property

168

that we hash so for example we have a bunch of records here

169

and then we take their let's say the id

170

and then we somehow hash it

171

and you can think of this as a almost a load balancer it's not really a load balancer

172

but based on the id we can actually push the record here or here or here

173

and whenever we need to read based on the id whenever we want to fetch

174

that then they will redirect

175

and read from the right database getting into the distributed systems

176

part right yes this is a bit more complex to implement again um

177

because you don't want to do this with you don't write

178

any application code you don't we don't want to couple the storage with our code

179

so this becomes a bit more complex to implement um you need to know about consistent hashing

180

and the hard thing about this is when you have joins

181

or when you want to query um you want to query records

182

that are distributed over distribution it's always um a huge limitation

183

but if you're on a scale there's There's no way around it.

184

Yeah, you mentioned scaling it via hardware, right?

185

Let's say vertical scaling.

186

This is an example of horizontal scaling.

187

Why not scaling our database vertically?

188

Why distribute in the first place?

189

Very good question.

190

The problem with vertical scaling is that it's going to become exponentially more expensive.

191

The more hardware...

192

So the difference between a machine that has, let's say 16 gigabytes to 32 in terms of price, it's very high.

193

And the other problem is you will most likely not need

194

so much capacity all the time you probably have peak hours

195

and so the problem once you scale vertically is that it's not

196

so easy to go back you need to shut down the server

197

and then relocate to a bigger machine or even

198

if you do it in the cloud it's usually very expensive it has downtime

199

and you still have a unique point of failure that's another problem that can appear.

200

So distribution not only improves scalability, but also improves availability of the resource.

201

Okay, now we're going to go and talk about deployment.

202

Could you explain the different deployment types?

203

And as you explain them, feel free to dive deep into pros and cons, advantages, disadvantages.

204

Yeah, different deployment types you've been exposed as a senior backend engineer.

205

Okay, so I'm going to start with the simplest one.

206

I used to do this, we used to do this at pretty much every startup you work for.

207

That would be the in-place deployment.

208

And this basically means that in one way or the other, we have our server, whatever that is, a Linux server, let's say.

209

And we have a code that's, let's say, so let me make this green.

210

Let me make my code blue.

211

And basically, we just kind of somehow replace the code with a new version.

212

I'm going to put that green.

213

right so we somehow push a new version

214

and then we restart the server i've done a lot of

215

those especially at the beginning of my of my career it's

216

very robust it's very easy to set up you just need to know a bit of server administration

217

but you do have downtime so whenever you are restarting the application there might be downtime

218

and it's extremely hard to roll back sometimes

219

so rollback can be a problem uh you and

220

because you don't have a good rollback mechanism downtime can another problem um

221

and also well it depends how you have it set up

222

but usually it's very very manual but this is like the good old-fashioned deployment um

223

and you need to stay awake until

224

2 p.m when you have no users right down downtime yeah i mean it depends on your traffic

225

but i had to i did a bunch of all nighters doing those

226

so um not funny cool not at all not at all um then Then there's the rolling deployment, which is more or less the same,

227

but the only difference here is that, and this is when it gets complicated, because you, let's say, have a fleet of instances, because we are horizontally scaling our service, let's say.

228

In Amazon, in AWS, they call this auto-scaling groups, but it doesn't really matter.

229

You have a fleet of instances, and so what you do is you gradually deploy the new version of the software, right?

230

So this becomes green all of a sudden, and then this too.

231

And then ideally, there's no issues, and then it can continue um this is again it's kind

232

of complex uh the disadvantage is some people will access version two

233

and some other will action version version one

234

so you can have problems there especially if you have databases involved

235

because you need to also deploy migrations if you have a skill databases

236

so again it's not great but it is the only way you can deploy to a fleet of instances

237

the advantage here it's if there's any problem with these two you still have the other two alive

238

so you can maybe just shut this down really quickly

239

and then instantiate a bunch of those really fast

240

so downtime it's a bit less

241

but it's also again it's complex um you pay a lot of costs

242

because you're distributing everything how do you distribute the traffic in this case

243

um so in this case you have a load balancer component

244

that sits here

245

and the load balancer it's responsible for kind of distributing traffic either with a round robin algorithm

246

or whatever load balancing algorithm you choose

247

but again the load balancer doesn't really know which version is it

248

so some users will go over there some users will go over there that's kind of the problem

249

let's go into prosynchrons

250

so um i what i understand is there is no downtime

251

you just might get different different users might get different versions right

252

but here we avoid the downtime right

253

because we have this rolling strategy um yes

254

and no you can still have users that experience bad experiences because if there's a mistake here, it's going to affect them.

255

So you have less downtime, but you can have problems.

256

And this is what the next, like the blue-green deployment kind of solves.

257

Blue-green.

258

So in here, we basically duplicate the whole thing.

259

So rather than, imagine this is our old version, right?

260

It's receiving traffic right now.

261

yes and what we do is we totally deploy

262

and provision in a total copy of this with a new application so let me just make this green

263

okie dokie and so that

264

because we have two of them we can actually make all our checks

265

and then start redirecting traffic here and

266

if there's any problem you keep alive this distribution and and shut it down as soon as you see there's a problem.

267

So this has basically, literally, it shouldn't have no downtime.

268

Like literally this has no downtime.

269

No downtime.

270

And the rollback, it's very fast because you keep this alive.

271

And if there's any problem, you can shut it down.

272

The disadvantage is you're going to pay a lot in your infrastructure costs.

273

This can cost you a lot because you are duplicating this infrastructure and you need to keep it alive for a while.

274

You also need to have a lot of complex tooling to be able to manage these load balancer components, to spin infrastructure really fast, so something like Infrastructure as Code can help you.

275

But again, this is very complex.

276

If you're using tools like Kubernetes and containers, you can set it up fairly quick.

277

Is there any more type of deployments that you would like to mention?

278

There's Canary deployment, and it's pretty much the same as Blue Green, but there's a big difference,

279

which is that you usually only redirect part of the traffic to our new instance.

280

So you go ahead and you say, let me have 2% of the traffic over here or 10%, or let me have the traffic from a specific geography.

281

I worked with that a lot.

282

And the other thing, the reason it's called canary is because you have a canary.

283

remember the

284

uh back in the days the miners had a canary

285

that they would send over to see if if there's any gas leak

286

and the canary

287

if it comes back then then it's all good um the

288

canary it's usually an entrance test that's running all the time

289

and you run it against the new instance and so

290

if the canary it's okay then you start um radiating more traffic again you need a canary that's number one

291

and complex load balancing setup because you want to redirect you want to slice your traffic somehow

292

and number five i do not consider this a type of deployment i know some people do

293

but that would be the feature toggles where you you're really not you deploy the whole version

294

but you have some code logic that can switch a feature on

295

and off um i do not consider this a type of

296

deployment for me it's almost like a feature in the software but some people do and it has several advantages

297

which is that you decouple your deployment from your code deployment, like the deployment of the feature from the code deployment, but at the same time having a lot of feature toggles

298

really increments the amount of testing you need to do to your software.

299

So I'm not gonna add it as an extra deployment.

300

Next question, how does the internet works?

301

And I want you to explain that, you know, since the moment you type something into your browser, until the page is shown,

302

but until the page is rendered to the users to yeah

303

to the final user okay that's actually a very fun exercise

304

um how does internet work well let's say it all starts as you mentioned with

305

a web browser where we type something let's say we type the senior dev

306

um so we type this in our web browser

307

and the first thing the web browser will do it will

308

make a query to look up the dns like the ip

309

address of this of the server that's hosting this website

310

and they will make

311

that to the dns server like the domain name system the servers are basically like tables

312

so you just kind of think of a table hosted somewhere

313

that says you know what the senior dev uh let me see has

314

so this senior dev whatever it has this ip address

315

so whatever okay that's not the real ip address

316

that i'm adding there but you get the idea so

317

and they have a bunch of them

318

and then the browser knows okay that's the ip address

319

and of course this is the internet protocol and

320

so over the ip network we will start sending we can now start sending ip packages um

321

these ip packages are containing tcp packages and tcp packages are put together in an http request so basically

322

when you type this address you end up making a 200

323

get a get request to uh to this path to our domain

324

and i would assume the the browser will send some headers to like what does it accept

325

and most of times it would be something like accept text slash html

326

so it's basically requesting an html file that we have here um

327

so that would be the request and then it will be a response.

328

So the server will connect, will open up a TCP connection with this and probably reply with, ideally, if I think it's successful, a 200 OK.

329

And there will be some headers, but basically the headers will tell you what's the content type of our response,

330

which would be text slash HTML.

331

And then there's an empty line, and then you have your HTML document.

332

HTML, which is obviously, it's just text, right?

333

It's just a bunch of text.

334

And then the browser will take this and see, okay, this is text HTML.

335

So I'm going to get all the body of the request here and applies basically what we call the critical rendering path.

336

So basically it will take our markdown.

337

It will try to build the HTML tree.

338

It will request any links to CSS assets

339

or javascript assets it will interpret those

340

and then it will try to stream to incrementally build the

341

ui as it reads down the html very good overview um

342

we're not gonna go deep into the critical rendering pad um because that belongs more to the front-end engineering

343

interview but that's definitely a topic that um that's pretty interesting talking about

344

painting final the final website to the user well bugdon uh

345

this is it for uh today very well done now uh for the people watching us um you know

346

if there's any specific back-end question you want bar the night

347

to dive deep uh just drop it in the comments

348

and we will add it to our next video that's number

349

one um number two we are putting together a community for javascript software engineers

350

that are looking to get to the senior level with quality

351

resources accountability we have monthly calls where you can directly interact with bargain

352

and i um you know we help you with interview technical

353

interview resources any kind of resources you need to make

354

that jump towards a senior and beyond um

355

if you want to check it out uh just check the link in comments you can apply

356

and we will um you know we we have a bunch of people waiting to get in

357

so we will review your application just give us time

358

and get you in if there's a fit and finally

359

if you would like to work personally with barton

360

and i in a you know one-on-one group mentoring um coaching

361

program right this is what software mastery is designed for we are helping developers fill up the tinkle gaps

362

and become that confident competent senior engineer um

363

but we cannot work with any kind of developer

364

so uh this is a premium service if you think you know

365

that would be something you'd be interested in just click on

366

the link in the comments also you'll find a link to

367

apply for a small chat with me where we will see hey can we help you is this a fit

368

and see if we can talk fighter uh whether you want to join us

369

or not with that being said thank you so much very great answers

370

and we will see you folks in the next one

📺 Zelfde Kanaal

✨ Aanbevolen Video

245 zinnen

QA Automation Interview Questions and Answers

Business EnglishInterview EnglishUniversity Students

158 zinnen

OWASP Top 10 Explained

Business EnglishUniversity StudentsWorking Adults

11 zinnen

full audio online video cutter com

Business EnglishInterview EnglishUniversity Students

26 zinnen

🔥 Java Multithreading Rapid Fire | Can You Answer These Interview Questions? #shorts

Business EnglishInterview EnglishUniversity Students

674 zinnen

FULL Data Science Mock Interview | SQL, Statistics, Business

Business EnglishInterview EnglishUniversity Students

63 zinnen

How To Land Your First Junior Dev Role

Business EnglishInterview EnglishUniversity Students

193 zinnen

SOC Analyst: Top Interview Questions & Answers (2025)

Business EnglishInterview EnglishUniversity Students

114 zinnen

Design a File Upload Service Like a Senior Engineer

Business EnglishUniversity StudentsWorking Adults

200 zinnen

10 JavaScript Interview Questions You HAVE TO KNOW

Business EnglishInterview EnglishUniversity Students

230 zinnen

Job Interview in English | Talking About Your Weaknesses

Business EnglishInterview EnglishUniversity Students

95 zinnen

API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer

Business EnglishInterview EnglishUniversity Students

156 zinnen

SELECT COUNT (*) can impact your Backend Application Performance, here is why

Business EnglishUniversity StudentsWorking Adults

Woordenschat en spreektips bij deze les

Deze spreekles op niveau C1 is gebaseerd op de video “FullStack Interview Questions”. Deze video bevat 370 zinnen en 4456 woorden om na te spreken. Het gesproken deel duurt 24:36. De spreker praat snel, ongeveer 181 woorden per minuut, dus reken op verbonden en ingeslikte klanken. 84% van de woorden hoort bij de 3.000 meest gebruikte Engelse woorden; de rest kun je beter vooraf bekijken.

Belangrijke woorden in deze video

De 15 moeilijkste woorden uit de video, met uitspraak en betekenis:

Woord	Uitspraak	Betekenis
cache zelfstandig naamwoord	/kæʃ/	cache
downtime zelfstandig naamwoord	/ˈdaʊnˌtaɪm/	downtime
query zelfstandig naamwoord	/ˈkwɪɹ.i/	vraag, verzoek
header zelfstandig naamwoord	/ˈhɛdɚ/	kop
canary zelfstandig naamwoord	/kəˈnɛəɹi/	kanarie, kanarievogel
deploy werkwoord	/dɪˈplɔɪ/	uitrollen
modify werkwoord	/ˈmɑ.dɪˌfaɪ/	modificeren, veranderen
distribute werkwoord	/dɪˈstɹɪbjuːt/	verdelen
redirect werkwoord		bijsturen, verwijzen
hash zelfstandig naamwoord	/ˈhæʃ/	hachee
attacker zelfstandig naamwoord	/əˈtækɚ/	aanvaller
disadvantage zelfstandig naamwoord	/ˌdɪsədˈvæntɪd͡ʒ/	nadeel
render werkwoord	/ˈɹɛn.dɚ/	veroorzaken
injection zelfstandig naamwoord	/ɪnˈd͡ʒɛk.ʃən/	inspuiting
millisecond zelfstandig naamwoord	/ˈmɪlɪˌsɛkənd/	milliseconde

Phrasal verbs die je zult horen

Woord	Uitspraak	Betekenis
set up werkwoord	/ˌsɛt ˈʌp/	bereiden, voorbereiden
end up werkwoord		belanden, terechtkomen
come back werkwoord		terugkomen
figure out werkwoord		uitvogelen, er achter komen
fill up werkwoord		opvullen, vollopen
go back werkwoord		teruggaan
look up werkwoord	/ˌlʊk ˈʌp/	opkijken
shut down werkwoord		afsluiten, uitzetten

Zinnen om te herhalen

Korte, volledige zinnen uit de video die je in alledaagse gesprekken kunt gebruiken:

Can I share my screen?
Let's imagine it that way.
You know, what does public mean in that request?
Why not scaling our database vertically?
Could you explain the different deployment types?

Grammatica in deze video

De structuren die de spreker het meest gebruikt, met de exacte woorden uit de video:

Structuur	In de video
“Used to” used to + werkwoord — een vroegere gewoonte of toestand die niet meer klopt	used to be · used to do
Lijdende vorm be + voltooid deelwoord — het gaat om wat er gebeurt, niet om wie het doet	was computed · was modified · be called
Betrekkelijke bijzinnen who / which + zin — extra informatie over een persoon of ding	tag which was · hardware which is · deployment, which is
Present perfect have/has + voltooid deelwoord — iets uit het verleden dat nu nog telt	i've done · you've been exposed

Uitspraak om op te letten

De spreker gebruikt 51 samentrekkingen en verkorte vormen, zoals I'm, you're, we're. Spreek ze kort uit, zoals je ze hoort.

De klanken “sh” en “zh”: cache /kæʃ/, hash /ˈhæʃ/, injection /ɪnˈd͡ʒɛk.ʃən/, exponentially /ɛkspə(ʊ)ˈnɛnʃəli/, instantiate /ɪnˈstænʃieɪt/
Lange woorden — let op de klemtoon: parameter /pəˈɹæm.ə.tɚ/, disadvantage /ˌdɪsədˈvæntɪd͡ʒ/, millisecond /ˈmɪlɪˌsɛkənd/, vertically /ˈvɝ.tɪ.kəli/, ideally /aɪˈdi.ə.li/

Klanken die Nederlandstaligen lastig vinden:

Stemhebbende eindmedeklinker — /b/, /d/, /g/, /z/, /v/ niet verscherpen: disadvantage /ˌdɪsədˈvæntɪd͡ʒ/, millisecond /ˈmɪlɪˌsɛkənd/, sanitize /ˈsænətaɪz/, offload /ˌɑfˈloʊd/, reload /ɹiːˈləʊd/
/æ/ — opener dan de Nederlandse “e”: cache /kæʃ/, balancer /ˈbæ.lən.sɚ/, hash /ˈhæʃ/, parameter /pəˈɹæm.ə.tɚ/, attacker /əˈtækɚ/
/g/ — een harde plofklank, geen Nederlandse “g”: toggle /ˈtɒɡ.əl/, algorithm /ˈælɡəɹɪðm̩/, gigabyte /ˈɡɪɡəbaɪt/, bargain /ˈbɑːɹɡən/, geography /d͡ʒiˈɑɡɹəfi/

Zo oefen je met deze video

Luister de hele video één keer zonder te spreken en noteer de woorden die je niet kent.
Begin op 0,75× snelheid, spreek zin voor zin na en ga terug naar normale snelheid zodra het makkelijk gaat.
Neem jezelf op en vergelijk met het origineel; let daarbij op woorden als cache, downtime, query.

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: FullStack Interview Questions (Junior & Mid) - Learn English Speaking with Video

how AI broke the SWE Career Ladder

Backend Interview Questions (Junior & Mid)

Senior Frontend Developer Interview Questions

QA Automation Interview Questions and Answers

OWASP Top 10 Explained

full audio online video cutter com

🔥 Java Multithreading Rapid Fire | Can You Answer These Interview Questions? #shorts

FULL Data Science Mock Interview | SQL, Statistics, Business

How To Land Your First Junior Dev Role

SOC Analyst: Top Interview Questions & Answers (2025)

Design a File Upload Service Like a Senior Engineer

10 JavaScript Interview Questions You HAVE TO KNOW

Job Interview in English | Talking About Your Weaknesses

API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer

SELECT COUNT (*) can impact your Backend Application Performance, here is why

Woordenschat en spreektips bij deze les

Belangrijke woorden in deze video

Phrasal verbs die je zult horen

Zinnen om te herhalen

Grammatica in deze video

Uitspraak om op te letten

Zo oefen je met deze video

Wat is de Shadowing-techniek?