シャドーイング練習: Backend Interview Questions (Junior & Mid) - YouTubeで英語スピーキングを学ぶ
C1
シャドーイング コントロール
0% 完了 (0/195 文)
here with Bogdan today and we will talk about senior back-end interview questions.
⏸ 一時停止中
再生速度:
リピート回数:
待機モード:
字幕同期:0ms
すべての文
195 文
1
here with Bogdan today and we will talk about senior back-end interview questions.
2
We're gonna jump right in.
3
These are senior level questions that can appear also on mid-level and junior level interview but you will see how Bogdan will try to answer them as a senior engineer would do.
4
We will start with the first question, Bogdan,
5
what makes an API restful and what is an example of a non-restful api okay so what makes an api
6
restful um probably the most important thing is the way you define your api endpoints and in the actual style you always want
7
to do it around resources that means pretty much every url should be the plural verb of that resource so if you have an api
8
let's say around payments it should be payments and if you go ahead and start adding things like get payments or delete payments in your url that's when you are moving away from restful and going into more of a random endpoint definition.
9
So you always want to stick to resources and then use HTTP verbs to actually define the actions.
10
So when you make a post to payment, it's when you actually create a payment.
11
Okay.
12
And following up on that, what are some advantages, if you can think of top of your head, of making an API restful versus just a non-restful API?
13
So probably the main advantage is just because it's a standard, it's super easy to consume and super predictable for people that use that API to see how they should request it.
14
And that's one of the most important things, standardization.
15
So pretty much everybody can consume that, they know what the shape will be of the request and the response, and it gives you all the advantages of standardization.
16
If you don't follow the standards, you'll have to just explain a lot and document a lot of your API because it just looks like something they've never seen before.
17
Cool, then Poggin, nice.
18
Number two, this is also a question that has to do with APIs, but a bit more specific.
19
So can you explain what content negotiation is and can you give me an example of content negotiation sure so
20
content negotiation it's an http mechanism um and basically it allows the client to specify which shape of a resource they want so
21
um just to give an example whenever you want to get a css file for example you could get a plain css file as a client
22
or you could specify with an accept header that you are willing to accept also a jzip version of that file and so then the server
23
can decide if they have a compressed version of that to send the compressed one and to let you know in the headers that that version is
24
actually compressed and they do that with the accepting coding probably with a content encoding header and so you know okay i need to decompress this and this allows you to have for example um http compression in compression in http so content negotiation does that.
25
Now back in the days, I know people also used it for translations of their web pages because back in the days you just had an index HTML page that was in German,
26
let's say one in English and one in French and there were just different files and depending on the language of the browser, they would send you the language in the header and you'd send them a different HTML file, that's back 20 years ago probably.
27
So that would be content negotiation, you basically get the same resource but you can specify what format of that same resource.
28
And you mentioned one of the advantages of content negotiation it's compression can you tell me more about that what do you mean by compression and
29
knowing the type of compression i need how does this translate to an advantage for the back-end engineer well basically the fact you can use
30
compression means you can have a lot more performance because it's usually cheaper to send go to compress something which would reduce if you're using josep it probably reduce the size by 70 send that over the network and decompress it
31
it's much faster than sending the original asset so it's pretty much the standard and most browsers whenever they make a request to a css
32
resource they will add this header of i accept just adjust or a broadly compressed version of this asset and
33
it helps you with scalability by decreasing the throughput increasing performance in general cool now on to something different
34
we will talk about databases and this is a pretty standard question what is the difference between sql and no sql databases probably the most important one is that in sql databases you store tabular data
35
that looks a bit like excel let's say whereas in no sql you can store documents you can store graphs but there's not so many relationships between the data you can think of no sql as a
36
As a drawer where you can just throw everything, SQL would be like well-classified and well-defined set of the drawers where only certain things fit.
37
That's why SQL database usually have a schema and the schema is really opinionated on how the data should look like.
38
And you really need to confirm to that schema when you put data in, whereas in NoSQL, you just throw mostly whatever you want there.
39
Yeah.
40
So let's imagine this scenario.
41
You are a backend engineer.
42
Your product manager is thinking together with a business team to launch a new service and you need a database.
43
And this service, it's about, let's say, storing a certain category of products.
44
Okay, just imagine this.
45
What would you use for this purpose?
46
Would you advise them to, if they ask you to draft a preliminary architecture for this, would you use an SQL database or a no SQL database?
47
What would be your choice and why?
48
I mean, if it's a business logic with relationships, like you mentioned, products and categories, I would expect people to be able to query those and I would expect those relationships to be meaningful and to grow.
49
Then I would go for a relational SQL style database, MySQL, PostgreSQL, because I would assume they would want to query that in a meaningful way.
50
It can be done with MongoDB nowadays too by using an ORM, but it's just going to be much easier down the road if you keep evolving those relationships.
51
If you already have an SQL database, I would go for SQL as a general rule.
52
When would you use a NoSQL database then?
53
I'd probably go for an NoSQL database where you're building like an analytics service, where you just send logs and this log, you're logging events.
54
Let's say somebody clicked on a button or evoked something.
55
They're not so related.
56
Of course, you would query them at some point, but they're kind of independent events.
57
And there is no need for a schema because sometimes maybe you send extra information in those events.
58
So if you look at any log storage, it's usually an an OSQL document database, for example, that would be a use case where I use NoSQL.
59
Nice, Barton.
60
Now, there's one thing that came up in the last few years and that is GraphQL, right?
61
Data layer technology.
62
So my question for you is, have you used GraphQL before?
63
And can you tell me the differences between GraphQL and REST?
64
And when would you use GraphQL?
65
What's the use case for GraphQL versus REST in your opinion?
66
Sure.
67
Yeah, I've been using GraphQL in the last five years.
68
And I guess the main difference with REST is that in GraphQL, what you offer to our consumers, it's a data layer that they can query as they want.
69
And so all of a sudden the front end can decide how much data to query.
70
Whereas in REST, you have a very well-defined schema of the API around resources.
71
And it happens many times that front end developers either had to overfetch or underfetch, that means they needed to create a certain view and they wanted, let's say a list of products.
72
They just want to display the title and the price of the product, but they get the full product because that's how the product endpoint is defined.
73
The other thing is, imagine they would need the product and also different variations of the product.
74
They will need to make an Excel request.
75
And that's what we call underfetching.
76
The fact that one endpoint wouldn't give you enough data.
77
So you either get too much or too little.
78
Whereas in GraphQL, the backend offers this data layer that you can write a query against.
79
And that query, it really gives you pretty much everything you need in your view.
80
And so there's many advantages here, but the most important one is that you reduce the need of round trips to the server and you get everything in one request.
81
Sorry, now I really liked what you said with the advantages and the flexibility that GraphQL gives you to avoid underfetching or overfetching.
82
But what would be, I'm sure like any technology, this thing has its disadvantages as well.
83
So can you tell me, name a few of the disadvantages that GraphQL implies?
84
So I guess the first one that comes to mind is caching.
85
It's just much harder to cache the results of a GraphQL query than it is to cache a simple REST endpoint.
86
That's also the complexity.
87
Why?
88
Why is it easier to cache a REST answer than a GraphQL one?
89
Because at the REST level, you have this specific resource and it's extremely easy to know if the resource is still fresh or to invalidate the cache.
90
Whereas in GraphQL, you have this nested query.
91
And so you need to think, okay, I need to cache at field level.
92
and all of a sudden it just becomes a lot harder.
93
Of course, there's tooling around it and you can maybe work around it, but even debugging where caching happened, because we have a query again and you could cache at any level in that query, it's just a lot more complex than you would in a simple REST API.
94
And complexity, it's one of the problems with GraphQL.
95
It's a lot more complex to define your schema and write resolvers to resolve the data behind that schema in the backend.
96
So that's another thing that might be a bit of a disadvantage error handling, we have good solutions right now, but it used to be the problem in the beginning.
97
And then when it comes to authentication, pretty much the same because people can run queries against our data, against
98
layer they might have different privileges at different levels so maybe someone starts requesting they make a full query but imagine part of that query they're not
99
authorized to see you need to do kind of a field level authorization or authentication which is just it can be done but it's more complex
100
than protecting a rest standpoint so you're basically exchanging flexibility in your query with complexity of the backend yes and of course testing it's also a bit harder you have so many more use cases in GraphQL.
101
Yes, you have more use cases.
102
You need a lot of specialized tooling to deal with this graph structure than you used to have with a standpoint where you just send JSON and get JSON back.
103
Now, there is one thing in GraphQL that's pretty specific to GraphQL, and that is the N plus one problem.
104
Have you heard about this problem in GraphQL?
105
How would you go about it?
106
Why does it happen and how would you solve it?
107
Yeah, sure.
108
So yes, we had this problem before, especially in the very beginning.
109
We started the implementation of the GraphQL layer, And basically, imagine in our case, we had a product and imagine then the product would fetch, let's say, descriptions in different languages.
110
And you need the information about the language.
111
For every product, you end up making another resolver query to your database, fetching all the languages.
112
And so if you have three products and each one of them has, I don't know, 20 different languages, you end up making three by 20 queries to the database to fulfill one request.
113
So you're basically making a denial of service attack on your database.
114
You could literally bring your database down if you don't solve that.
115
And the solution to that is to basically batch queries.
116
So rather than sending those 60 queries, you accumulate, you batch all the IDs of all the languages you need and all the products, and you send them in a single query, and then you distribute the results back to your resolver functions, which put together the GraphQL answer.
117
And you can do that with a couple of libraries.
118
We used data loaders in the past, and it did a pretty good job.
119
pretty good job awesome now a pretty standard question for a back-end engineer uh could you name three solid principles and i would
120
also love you know if you used one of those principles in your back-end code um give me some examples of you know when they come in handy and why you used i think we have s for um the separation a single responsibility the single responsibility principle
121
Then the L was list code substitution.
122
O stands from open close, S-O-L-I for interface segregation, and the D for dependency injection.
123
I did use a lot dependency injection in the past to make code more testable.
124
So rather than depending directly by using an import onto something, you can provide it as an argument at runtime.
125
So you can either build a class and provide that dependency in the constructor the class or as a function argument in javascript and what that would allow you
126
to do is that um at test time for example you could provide a mock implementation of that dependency uh and in a lot easier way than if
127
you import it directly so i use that a lot i think nest.js implements that by default and a lot of the backend frameworks
128
like dot net and javaspring both they they use that by default dependency inversion from you know can you can you tell me another example with another of those principles?
129
I guess one good example would be the MVC pattern where we split the architecture in layers based on the single responsibility principle.
130
So you have the model and then you have the view layer and you have the controller that does the business logic.
131
And that's basically a result of getting, you know, your spaghetti back in code and applying the single responsibility principle.
132
That would be another example.
133
Amazing.
134
Cool.
135
Now onto a bigger and more high level topic, which is microservices.
136
So can you tell me what microservices are and what are some advantages and disadvantages?
137
I would say, hey, let's name three of each, three advantages and three disadvantages of microservices.
138
Okay.
139
So to put it simply, microservices is basically when you split a monolith, like you have our own backend service that grew quite a lot.
140
And there's so many different responsibilities.
141
And we decide, hey, let's just separate these two things.
142
So they live independently, each with their own database.
143
And they're completely separated and they can call each other over the network through their rest or graphical APIs.
144
So basically, you take your service-oriented architecture, but you distribute it across the network in single small services.
145
And that allows you to scale them independently, to deploy them independently, to have different teams developing them independently.
146
So it allows you to kind of grow your team.
147
And it's been, it's became very, very popular.
148
The one they are back is that as they say, the number one law of distributed system is non-distributed systems.
149
The fact that we distribute our systems means we will have to care a lot about security when we call other services.
150
All of a sudden we have latency because we're doing this over HTTP.
151
So everything takes longer.
152
It's also much harder to access data over the network.
153
And again, you have all this complexity of deploying, building pipelines, maintaining all those independent services.
154
So it's what they call the microservices tax, where you end up maintaining all the services and paying a huge price.
155
price.
156
So you need to be careful that when you split, it actually pays off.
157
Understood.
158
So as a disadvantage, complexity and expensive to maintain.
159
Yes.
160
You could say security.
161
It's another one.
162
You need to have HTTPS certificates that you rotate or load services.
163
They need to authenticate with each other and they need to find each other.
164
So all of a sudden you have to solve all these problems.
165
Whereas in the past, you were just making a call to a different module in your code base to get some data from that extra, from that other service.
166
But then looking at those advantages and disadvantages that you mentioned, you know, when would you, as a backend engineer, let's say you are the lead backend engineer, our backend service is growing and growing.
167
When would you recommend a transition towards microservices?
168
Very good question.
169
I would say it depends on how you want to also distribute your team, because we follow the Conway law, which means the system will look as the team building the system.
170
So if the headcount grows and we see there's like two different feature teams we want to build, and they're all concerned in different parts of the product, then it makes sense to talk to the team and split the services accordingly.
171
So they can actually, the best would be if they can actually deliver and deploy the services independently.
172
So you are working in parallel and you don't need to have something that I saw in some of the teams in my past, a stand up with 15 people, a lot of shared knowledge.
173
It's just impossible to work when you're past 12 people.
174
so you need to split because you want to scale your team mostly.
175
The other situation would be if you imagine you're always seeing in our system that there's a certain part of it that gets a lot of traffic but there are
176
other parts that don't but because that part gets a lot of traffic we need to scale it all together so all of a sudden we're throwing a lot
177
of resources whereas we could just split those things and scale only the service that needs more traffic so you save up in your infrastructure and the third scenario would be if you don't want to have a single point of failure
178
So because we are operating in a monolith, if someone breaks anything, if your database goes down for any reason, you're just down.
179
Whereas in microservices, the whole system is a bit more reliable.
180
It's a bit more resilient because you can recover from failure because failure is somehow isolated to one service.
181
In your experience working with monoliths and microservices, were companies doing the switch to microservices too early or were they rushing?
182
and what would you recommend let's say again let's go back to the product manager um and the executive team is getting around they are they
183
are thinking is it worth it to have a migration scenario here what have you seen in the past and what you would you recommend to
184
um to a team looking to migrate i would say the most common question uh the most common mistake it's uh we were splitting too
185
early and um we end up creating so many services and no one would end up maintaining them because there's just too many and so there's this
186
saying that if your team cannot build a modular monolith they definitely cannot build microservices so you really want to look at your monolith and make sure that
187
you can separate services inside the monolith and really understand what the problem is before we go in and start throwing at the solution i think there
188
was a lot of hype around microservice architecture everybody was doing it but then there was a bit of a backslash and people are right now using
189
monoliths and really considering but be very conservative in your decision because it's an expensive decision to make and it's quite hard usually once
190
you made it to all back also we have a lot more tooling about how to manage your monorepo right which which uh
191
helps people avoid right migrating too fast um cool button thank you so much this was it for today we will come back with um another series on software senior back-end engineering
192
interview questions as for you what i wanted number one is there any question that you want us to cover in our next
193
video drop it in the comments and bug and i will pick it and cover it in a next back-end engineering series and number
194
two if you're looking for a place to accelerate your engineering career then check out also the link in comments our free community there you will have exclusive access to barter and i and you can ask us questions directly and you can also
195
share your insights with a community of like-minded developers that are also interested into growing as for baghdad and i we will see you in the next one
App StoreとGoogle Playで4.9/5
Shadowing English
モバイル版
Shadowing Englishアプリでいつでもどこでも英語を学びましょう。 今すぐコミュニケーションスキルを向上させましょう！
学習の進捗を追跡する
AIによる採点とエラー修正
豊富な動画ライブラリ
このレッスンについて
このレッスンでは、バックエンドのインタビューに関連する質問に取り組むことで、APIの設計や特性について学びます。特に、RESTful APIと非RESTful APIの違いや、コンテンツネゴシエーション、SQLとNoSQLデータベースの違いについて詳しく説明します。これにより、実践的な英語のスピーキングと理解力を向上させることができます。
重要な語彙とフレーズ
- API（アプリケーションプログラミングインターフェース）
- RESTful（リソース指向の設計スタイル）
- コンテンツネゴシエーション（リソース形式の指定）
- SQL（構造化クエリ言語）
- NoSQL（非構造化データベース）
- HTTPメソッド（GET、POSTなどの操作）
- 圧縮（データサイズの削減）
練習のコツ
このビデオの内容を効果的に学ぶためには、shadowspeakを用いた練習が非常に有効です。まず、スピードとトーンに注目しながら、ビデオを何度も再生してみてください。発言の後に続けて自分の声を出すことで、文章の流れやイントネーションを掴むことができます。特に、英語スピーキング練習においては、リズムに合わせて話すことが重要です。また、ビデオの内容を自分の言葉で再構成することに挑戦することで、理解を深め、shadow speechのスキルを高めることができます。YouTubeで英語学習ができるこの機会を利用し、他の動画とも併用して、さらなる練習を重ねることをお勧めします。
シャドーイングとは？英語上達に効果的な理由
シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。