ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: Backend Interview Questions (Junior & Mid)
เลือกโหมดฝึก
แต่ละโหมดจะเปิดห้องฝึกแบบเต็มจอ
195 ประโยค
หากประโยคสั้นหรือยาวเกินไป กดที่ Edit เพื่อปรับแก้
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
ดาวน์โหลดแอป
ทุกอย่างที่ต้องใช้เพื่อพูดได้คล่อง
AI ให้คะแนนการออกเสียงให้คะแนนทุกประโยค
ฝึก IPAเชี่ยวชาญทุกเสียง
คำศัพท์สร้างคลังคำของคุณ
เกมคำศัพท์เล่นไปเรียนไป
ช่องเดียวกัน
C12
how AI broke the SWE Career Ladder
Business EnglishInterview EnglishUniversity Students
C15
FullStack Interview Questions (Junior & Mid)
Business EnglishInterview EnglishUniversity Students
C1React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM)
Daily ConversationUniversity StudentsWorking Adults
C1Senior Frontend Developer Interview Questions
Business EnglishInterview EnglishWorking Adults
FOR YOU
วิดีโอแนะนำ
C11
162 ประโยค
I ask this question to every Backend Engineer I interview
Business EnglishInterview EnglishUniversity Students
C11
392 ประโยค
Uber Data Engineering Mock Interview - Ride-Sharing Data Warehouse Schema
Interview EnglishUniversity StudentsWorking Adults
C11
49 ประโยค
Next JS Interview Questions and Answers 2026 | Top 20 Most Asked Questions
Interview EnglishUniversity StudentsWorking Adults
C12
239 ประโยค
Excellent 2 Years AWS DevOps Engineer Mock Interview with Questions and Answers | Cloud | Docker
Business EnglishInterview EnglishUniversity Students
C12
95 ประโยค
API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer
Business EnglishInterview EnglishUniversity Students
C1217 ประโยค
10 Data Analyst Interview Questions and Answers - Senior Data Analyst Explains
Interview EnglishUniversity StudentsWorking Adults
C12
233 ประโยค
.NET Mock Interview - Scenario Based - 7+ Years Experienced Candidate
Interview EnglishUniversity StudentsWorking Adults
C12
129 ประโยค
How to Become a Great Software Developer — Best Advice from Top-Notch Engineers
Business EnglishInterview EnglishUniversity Students
C12
65 ประโยค
What Is REST API? Examples And How To Use It: Crash Course System Design #3
Daily ConversationUniversity StudentsWorking Adults
C12
188 ประโยค
IT System Administrator Interview Questions and Answers | How to Pass an IT System Admin Interview
Business EnglishInterview EnglishUniversity Students
ทำไมถึงควรฝึกพูดกับวิดีโอนี้?
การฝึกฝนการพูดภาษาอังกฤษผ่านการดูวิดีโอที่เกี่ยวข้องกับการสัมภาษณ์สามารถช่วยเสริมทักษะการสื่อสารได้อย่างมีประสิทธิภาพ ในวิดีโอนี้ คุณจะได้เห็นตัวอย่างของคำถามสัมภาษณ์ที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ ทำให้คุณมีโอกาสเรียนรู้คำศัพท์ใหม่ ๆ และประโยคที่ใช้ในสถานการณ์จริง ไม่ว่าจะเป็นการพูดคุยเกี่ยวกับการออกแบบ API หรือความแตกต่างระหว่างฐานข้อมูล SQL และ NoSQL การได้ยินเสียงพูดที่ชัดเจนช่วยให้คุณปรับปรุงการออกเสียงและสร้างความมั่นใจในการพูด ชาโดว์อิ้งภาษาอังกฤษ เป็นวิธีที่ดีในการเรียนรู้และนำไปใช้ในชีวิตจริง
โครงสร้างไวยากรณ์และการใช้ภาษาในบริบท
- API Restful: ประโยคเช่น "สิ่งที่ทำให้ API เป็น Restful คือวิธีการกำหนด endpoints" เน้นการใช้ไวยากรณ์ที่ถูกต้องและเป็นทางการเมื่ออธิบายความหมายของคำศัพท์ทางเทคนิค
- Content Negotiation: "Content negotiation เป็นกลไก HTTP ที่ช่วยให้ไคลเอนต์สามารถระบุรูปแบบของข้อมูลที่ต้องการ" ทำให้ผู้เรียนสามารถเข้าใจการใช้คำและความหมายในบริบทเทคนิคได้ดีขึ้น
- ความแตกต่างระหว่าง SQL และ NoSQL: "ใน SQL คุณจัดเก็บข้อมูลเป็นตาราง ขณะที่ NoSQL สามารถจัดเก็บเอกสารหรือกราฟ" โดยเน้นโครงสร้างที่อธิบายความแตกต่างอย่างชัดเจน
กับดักการออกเสียงที่พบบ่อย
หลายคนมักจะมีปัญหาเกี่ยวกับการออกเสียงคำเฉพาะเมื่อพูดถึงเทคโนโลยี เช่นคำว่า "API" ที่บางคนอาจออกเสียงผิด นอกจากนี้ยังมีคำว่า "negotiate" ซึ่งอาจมีเสียงสะกดที่ไม่ธรรมดา การฟังนักพูดในวิดีโอนี้ช่วยให้คุณฟังและเรียนรู้การออกเสียงที่ถูกต้อง ประกอบกับการทำ shadow speak เพื่อฝึกฝนการออกเสียงของคุณในเวลาต่อมาจะช่วยให้คุณพูดได้อย่างมั่นใจมากขึ้น
ไวยากรณ์ในวิดีโอนี้
โครงสร้างที่ผู้พูดใช้บ่อยที่สุด พร้อมคำพูดจริงจากวิดีโอ:
| โครงสร้าง | ในวิดีโอ |
|---|---|
| ประโยคเงื่อนไข if + อนุประโยค, will/would + กริยา — เงื่อนไขและผลลัพธ์ | If you don't follow the standards, you'll have |
| “used to” used to + กริยา — นิสัยหรือสภาพในอดีตที่ตอนนี้ไม่เป็นแล้ว | used to be · used to have |
| Present perfect have/has + กริยาช่อง 3 — เหตุการณ์ในอดีตที่ยังเกี่ยวข้องกับปัจจุบัน | they've never seen · Have you heard · it's been |
| Passive voice be + กริยาช่อง 3 — เน้นสิ่งที่เกิดขึ้น ไม่ใช่ผู้กระทำ | is really opinionated · can be done · is defined |
เทคนิค Shadowing คืออะไร?
Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ