シャドーイング練習: I ask this question to every Backend Engineer I interview - 動画で英語スピーキングを学ぶ

What's going on guys?

My name is Hussain and I thought I'm gonna make a little bit of a lighter weight video for you guys today.

Taking a break from the pre-search of back-end engineering, right?

Those can exhaust your mind when you watch these videos and keep learning and learning and learning.

So I thought I'd talk to you about my interviewing techniques.

And by no means, it's not perfect.

And I don't think there is a perfect interview question that you need to memorize to get any job you want.

Those might be shortcuts where you learn certain thing and you know what the interviewer will ask.

And based on that, you can guess or answer and memorize these things.

But I don't think this is a good strategy in general.

But that being said, my approach is instead of asking,

oh, solve Dicestra algorithm or do a quick sort algorithm,

which can be easily memorized if you think about it, right?

and as a result, if you ask these kind of questions

and the candidate just memorized them and happened to guys read or take these courses, right?

These algorithm courses and come to an interview and nail the interview.

Yeah, how do you know they are good?

They might have been able to solve these algorithms, but it doesn't prove that they have the capability to think on themselves.

They have the abilities to have analytical thinking.

So that's the question I ask.

I'm going to tell you in a minute, but it's a very open-winded question.

And I tailor this question specifically to the back end,

but I tweak it a little bit based on how the interview is going.

And the reason I make it

so open-minded is the candidate will not be able to kind of give one answer and this is the right answer.

Because guess what?

That question doesn't have an answer.

It just has like multiple thousands of answers.

And as a result, you can just gauge your interviewee.

You can gauge your candidate skills.

You can gauge how much they know.

You can gauge how willing are they to be pragmatic on their solutions.

All right.

So three minutes and we didn't ask that question.

The question is as the following.

given an

architectural system there is a database

and there is a back end web application right the database

could be postgres sql server could be mysql anything you want there is a database there is a web server

that is consuming this database right at the backend could be node.js could be django java anything you prefer

and there's in front of that there is a reverse proxy

that does load balancing this thing and i don't specify details

if you notice i just say very high level details right

and then this reverse proxy could be nginx of hl proxy could be caddy i just give them examples right

and then finally there is this application

right this the client application could be a desktop application could be a web browser

and the reason i don't say one thing is just to confuse them even more

because there there are just

if you pick a web versus desktop the branch first of

all the candidate will go to the branch they are most comfortable

which is something i want to know second thing is they

if they go to the web that's not wrong it's just

i would i want to know where they're going after that right it's just fascinating to have a discussion.

So this is the stack, right?

And I told them, I told the candidates, hey, you're responsible for the whole stack.

I don't like the word full stack engineer,

just because I don't think there is someone who can be adept in the whole stack.

Yeah, you can know about the whole thing,

but to be very well a master on certain thing, you have to pick one thing and dive deep into it.

There's nothing wrong with being a full stack engineer.

I'm just saying you will be a generalist at best, right?

That's my idea, right?

But yeah, so you're responsible for the whole stack.

And now I just say, here's what happened.

Here's the problem.

My user has this application all the way here, and they're clicking on a button, right?

And this button, the moment they click on this button,

the application freezes for 60 seconds, exactly 60 seconds.

And then the response comes back and a table is displayed with the results.

So this button is responsible to display the results.

So I say this is the question.

Where where where what do you do to identify the performance problem in the whole stack

and I just let them run with it obviously there is no right

or wrong answer the problem right could be in the front-end

application could be in the reverse proxy there's the reverse proxy could be choking on something

that the web server could be processing this stuff

and it could be that the database could be just a slow database query

that doesn't have indexes or could be we're retrieving too much information

or could be we're doing something any anything in this stack right

and and based on

that it is fascinating for the past 16 years from of

my career the different answers i get on these questions

and based on that i i have a gut feeling to okay let's hire this guy

or gal it's just a gut feeling at the end of the day because

oh all right you you will notice that

if someone is is really interesting databases they will spend

so much time here all their time

so okay i might do this i might do this i

might go do database tuning i might i might actually uh enable uh database tracing

and see how the squares look like i i'm gonna see they've spent a lot of time and

if they're they're really passionate about front-end engineering you will see most of their time spent on the front end

and this is okay i'm gonna look at div top uh div tops div tools

and i do all

that stuff i'm gonna check all these networking i'm gonna check the javascript stack i'm gonna check the event loop

and see if i'm doing something wrong and and

and sometimes they say stuff i don't even know like uh i'm gonna check react components

which i don't i don't know anything about right so so yeah it's just it's so

and as they took through the stack i see their eyes light up in certain areas

and this is where i know this guy

100

or gal is really passionate about this area right

101

because they're spending a lot of time just discussing this stuff right

102

and if they gloss over this thing doesn't mean they are bad it's just they're not interested

103

and that's absolutely fine right

104

so some people spend a lot of time in the reverse proxy

105

and my god i met one gal she was

106

so good she broke down she spent almost like 25 minutes talking about the reverse proxy

107

and how she can optimize it i was baffled she was

108

so good yeah she ended up accepting another offer though

109

but uh yeah

110

so that's that's fascinating all this stuff is fascinating to me

111

that's what's the question i ask guys in an interview again

112

it doesn't give you it doesn't give you any it gives you some indication

113

but i don't think there is a question

114

that you can ask that's the gal i want

115

or that's the guy i want i don't think they exist there's there is no way way to find

116

if this person fits your job you can ask them technical

117

question all all you want it's like oh what is

118

and sometimes i do that's like

119

if they they uh sometimes i like to make the candidate uncomfortable a little bit like

120

if they spend a lot of time in their front end i know they don't know much about backing

121

so i ask them very very stupid questions

122

that i know they're not gonna answer

123

but i just want them to feel a little bit at

124

ease right it's just it's just an asshole move from me

125

and it's like okay what what what is uh talk to

126

me about repeatable read isolation level for example in databases and

127

when we're going to use it obviously this is a little bit of a very technical question

128

and specifically to the relational databases right but i like to ask this question

129

but they if they didn't answer that does not mean they don't get the job

130

or they are bad not at all right and most engineers that interview for a long time understand this thing

131

there's there's no way it's always a gamble

132

if we hire someone it's always about how you feel gut feeling

133

and gary v actually says that sometimes says okay i

134

if i look at someone he's even at the extreme end it's like he look at someone

135

and say okay you're hired because he quickly fires someone

136

if it doesn't if they they don't perform he doesn't have a problem with

137

that right so this is his approach so he hire hire hire her and he doesn't have a problem with firing.

138

So he doesn't have a problem with hiring.

139

He doesn't have a problem.

140

It's like he chose a trial based on his gut feeling, right?

141

And yeah, so that's the idea of the interview.

142

I hope it gives you some sort of idea.

143

If you're interviewing for a job, just be yourself.

144

And if you're truly to yourself, you're enjoying engineering, there is a job out there for you that just fits you and just be kind,

145

be nice, be down to earth.

146

And if you know something, if you don't know something, just say, I don't know.

147

That's absolutely fine.

148

It doesn't mean anything, right?

149

If the interviewee, if the interviewer asking you difficult questions just for the sake of they showing their skills,

150

then I don't think that's a good interviewer either.

151

So it's a balance.

152

I don't know.

153

So I don't think there is a way to pass an interview, right?

154

A sure thing way to pass an interview.

155

Yeah, you can memorize all the algorithms you want, but I never ask any algorithm question in my job or even my previous job for that matter.

156

But yeah, guys, that's a quick video today.

157

I hope you have a wonderful Wednesday.

158

Today's Wednesday.

159

And I'm going to see you in the next one.

160

I had to head back to work it's around 6 in the morning

161

just thought I'm gonna make a video for you guys I'll see you in the next one

162

you guys stay awesome, goodbye

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイング練習: I ask this question to every Backend Engineer I interview - 動画で英語スピーキングを学ぶ

この動画で話す練習をする理由は？

文法と文脈の中の表現

一般的な発音の罠

シャドーイングとは？英語上達に効果的な理由