Shadowing Practice: Backend Interview Questions (Junior & Mid) - Learn English Speaking with Video
Creando lección...
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
📺 Mismo canal
✨ Recomendar Video
C11
154 oraciones
Manual Testing: QA Interview Preparation Questions and Answers
Business EnglishInterview EnglishUniversity Students
C11
95 oraciones
API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer
Business EnglishInterview EnglishUniversity Students
C11
392 oraciones
Uber Data Engineering Mock Interview - Ride-Sharing Data Warehouse Schema
Business EnglishInterview EnglishUniversity Students
C12
405 oraciones
Netflix product manager mock interview and tips (with ex-Netflix Lead PM)
Business EnglishInterview EnglishUniversity Students
C12
129 oraciones
How to Become a Great Software Developer — Best Advice from Top-Notch Engineers
Business EnglishInterview EnglishUniversity Students
C11
49 oraciones
Next JS Interview Questions and Answers 2026 | Top 20 Most Asked Questions
Business EnglishInterview EnglishUniversity Students
C13
26 oraciones
🔥 Java Multithreading Rapid Fire | Can You Answer These Interview Questions? #shorts
Business EnglishInterview EnglishUniversity Students
C1228 oraciones
PhD Interview Questions | What do PhD supervisors look for in applicants?
Interview EnglishUniversity StudentsWorking Adults
C11
674 oraciones
FULL Data Science Mock Interview | SQL, Statistics, Business
Business EnglishInterview EnglishUniversity Students
B21
193 oraciones
SOC Analyst: Top Interview Questions & Answers (2025)
Business EnglishInterview EnglishUniversity Students
B21
96 oraciones
Content Moderation Most Important Interview Question and Answers | @CorporateWala | Ankit Yadav
Business EnglishInterview EnglishUniversity Students
Vocabulario y notas de pronunciación para esta lección
Esta lección de conversación de nivel C1 se basa en el vídeo “Backend Interview Questions”. Las palabras que más se repiten: Graphql, database, query, product. Este vídeo tiene 195 frases y 3655 palabras para practicar shadowing. La parte hablada dura 18:54. El hablante habla rápido, unas 193 palabras por minuto, así que espera sonidos enlazados y reducidos. El 83 % de las palabras está entre las 3.000 más comunes del inglés; conviene repasar el resto antes de empezar.
Vocabulario clave de este vídeo
Las 15 palabras más avanzadas del vídeo, con su pronunciación y significado:
| Palabra | Pronunciación | Significado |
|---|---|---|
| query sustantivo | /ˈkwɪɹ.i/ | consulta, pregunta |
| cache sustantivo | /kæʃ/ | memoria caché, caché |
| monolith sustantivo | /ˈmɑn.əˌlɪθ/ | monolito |
| disadvantage sustantivo | /ˌdɪsədˈvæntɪd͡ʒ/ | desventaja |
| negotiation sustantivo | /nɪˌɡəʊ.ʃiˈeɪ.ʃən/ | negociación, tratativa |
| distribute verbo | /dɪˈstɹɪbjuːt/ | distribuir |
| compress verbo | /ˈkɑmpɹɛs/ | comprimir |
| endpoint sustantivo | punto extremo, extremo | |
| dependency sustantivo | /dɪˈpɛndənsi/ | dependencia |
| header sustantivo | /ˈhɛdɚ/ | encabezado, encabezamiento |
| complexity sustantivo | /kəmˈplɛk.sɪ.ti/ | complejidad |
| independently adverbio | /ˌɪndɪˈpɛndəntli/ | independientemente |
| deploy verbo | /dɪˈplɔɪ/ | desplegar |
| specify verbo | /ˈspɛs.əˌfaɪ/ | especificar, circunstanciar |
| authentication sustantivo | /ɔːˌθɛntɪˈkeɪʃn̩/ | autenticación |
Phrasal verbs que vas a escuchar
| Palabra | Pronunciación | Significado |
|---|---|---|
| end up verbo | terminar, ir a parar | |
| check out verbo | investigar, chequear | |
| go ahead verbo | /ˌɡoʊ əˈhɛd/ | venga, adelante |
| pay off verbo | valer la pena, salir a cuenta | |
| put together verbo | construir, elaborar | |
| work around verbo | baipasear, circunvalar |
Frases que vale la pena repetir
Frases cortas y completas del vídeo que puedes reutilizar en la conversación diaria:
- We're gonna jump right in.
- What would you use for this purpose?
- What would be your choice and why?
- How would you go about it?
- When would you recommend a transition towards microservices?
Gramática en este vídeo
Las estructuras que más usa el hablante, con las palabras exactas del vídeo:
| Estructura | En el vídeo |
|---|---|
| Oraciones condicionales if + oración, will/would + verbo — una condición y su resultado | If you don't follow the standards, you'll have |
| “Used to” used to + verbo — un hábito o estado pasado que ya no es cierto | used to be · used to have |
| Voz pasiva be + participio pasado — importa lo que ocurre, no quién lo hace | is really opinionated · can be done · is defined |
| Oraciones de relativo who / which + oración — información extra sobre una persona o cosa | authentication which is · topic, which is · law, which means |
Pronunciación a tener en cuenta
El hablante usa 31 contracciones y formas reducidas, como you're, don't, they're. Dilas en su forma corta, tal como las oyes.
- Los sonidos de “th”: monolith /ˈmɑn.əˌlɪθ/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, authenticate /ɔˈθɛn.tɪ.keɪt/, authorize /ˈɔθəɹaɪz/, throughput /ˈθɹuː.pʊt/
- Los sonidos de “sh” y “zh”: cache /kæʃ/, negotiation /nɪˌɡəʊ.ʃiˈeɪ.ʃən/, compression /kəmˈpɹɛʃ.ən/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, standardization /ˌstæn.də.daɪˈzeɪ.ʃən/
- Palabras largas — cuida el acento: disadvantage /ˌdɪsədˈvæntɪd͡ʒ/, negotiation /nɪˌɡəʊ.ʃiˈeɪ.ʃən/, dependency /dɪˈpɛndənsi/, complexity /kəmˈplɛk.sɪ.ti/, independently /ˌɪndɪˈpɛndəntli/
Sonidos difíciles para hispanohablantes:
- s + consonante al inicio — sin añadir una “e” delante: schema /ˈskiːmə/, specify /ˈspɛs.əˌfaɪ/, standardization /ˌstæn.də.daɪˈzeɪ.ʃən/, standpoint /ˈstændpɔɪnt/, scalability /ˌskeɪ.ləˈbɪl.ɪ.ti/
- /v/ — no es /b/: los dientes tocan el labio inferior: disadvantage /ˌdɪsədˈvæntɪd͡ʒ/, verb /vɝb/, invalidate /ɪnˈvæl.əˌdeɪt/, inversion /ɪnˈvɚ.ʒən/, evolve /ɪˈvɑlv/
- /z/ — sonora, no /s/: standardization /ˌstæn.də.daɪˈzeɪ.ʃən/, browser /ˈbɹaʊ.zəɹ/, authorize /ˈɔθəɹaɪz/, resilient /ɹɪˈzɪl.jənt/, specialize /ˈspɛʃəˌlaɪz/
Cómo practicar con este vídeo
- Escucha el vídeo entero una vez sin hablar y anota las palabras que no conoces.
- Empieza a velocidad 0,75×, haz shadowing frase por frase y vuelve a la velocidad normal cuando te resulte fácil.
- Grábate y compara con el original, prestando atención a palabras como query, cache, monolith.
¿Qué es la Técnica de Shadowing?
Shadowing es una técnica de aprendizaje de idiomas respaldada por la ciencia, desarrollada originalmente para la formación de intérpretes profesionales y popularizada por el políglota Dr. Alexander Arguelles. El método es simple pero poderoso: escuchas audio en inglés nativo y lo repites en voz alta de inmediato, como una sombra que sigue al hablante con solo 1-2 segundos de retraso. A diferencia de la escucha pasiva o los ejercicios de gramática, el shadowing obliga a tu cerebro y músculos de la boca a procesar y reproducir simultáneamente patrones de habla reales. Las investigaciones muestran que mejora significativamente la precisión de la pronunciación, la entonación, el ritmo, el habla conectada, la comprensión auditiva y la fluidez al hablar, convirtiéndola en una de las metodologías más efectivas para la preparación del IELTS Speaking y la comunicación en inglés en el mundo real.