쉐도잉 연습: Backend Interview Questions (Junior & Mid) - YouTube로 영어 말하기 배우기

쉐도잉 컨트롤

0% 완료 (0/195 문장)

here with Bogdan today and we will talk about senior back-end interview questions.

⏸ 일시 정지

재생 속도:

반복 횟수:

대기 모드:

자막 동기:0ms

모든 문장

195 문장

here with Bogdan today and we will talk about senior back-end interview questions.

We're gonna jump right in.

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.

We will start with the first question, Bogdan,

what makes an API restful and what is an example of a non-restful api okay so what makes an api

restful um probably the most important thing is the way you define your api endpoints and in the actual style you always want

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

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.

So you always want to stick to resources and then use HTTP verbs to actually define the actions.

So when you make a post to payment, it's when you actually create a payment.

Okay.

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?

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.

And that's one of the most important things, standardization.

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.

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.

Cool, then Poggin, nice.

Number two, this is also a question that has to do with APIs, but a bit more specific.

So can you explain what content negotiation is and can you give me an example of content negotiation sure so

content negotiation it's an http mechanism um and basically it allows the client to specify which shape of a resource they want so

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

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

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

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.

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,

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.

So that would be content negotiation, you basically get the same resource but you can specify what format of that same resource.

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

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

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

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

resource they will add this header of i accept just adjust or a broadly compressed version of this asset and

it helps you with scalability by decreasing the throughput increasing performance in general cool now on to something different

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

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

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.

That's why SQL database usually have a schema and the schema is really opinionated on how the data should look like.

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.

Yeah.

So let's imagine this scenario.

You are a backend engineer.

Your product manager is thinking together with a business team to launch a new service and you need a database.

And this service, it's about, let's say, storing a certain category of products.

Okay, just imagine this.

What would you use for this purpose?

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?

What would be your choice and why?

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.

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.

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.

If you already have an SQL database, I would go for SQL as a general rule.

When would you use a NoSQL database then?

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.

Let's say somebody clicked on a button or evoked something.

They're not so related.

Of course, you would query them at some point, but they're kind of independent events.

And there is no need for a schema because sometimes maybe you send extra information in those events.

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.

Nice, Barton.

Now, there's one thing that came up in the last few years and that is GraphQL, right?

Data layer technology.

So my question for you is, have you used GraphQL before?

And can you tell me the differences between GraphQL and REST?

And when would you use GraphQL?

What's the use case for GraphQL versus REST in your opinion?

Sure.

Yeah, I've been using GraphQL in the last five years.

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.

And so all of a sudden the front end can decide how much data to query.

Whereas in REST, you have a very well-defined schema of the API around resources.

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.

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.

The other thing is, imagine they would need the product and also different variations of the product.

They will need to make an Excel request.

And that's what we call underfetching.

The fact that one endpoint wouldn't give you enough data.

So you either get too much or too little.

Whereas in GraphQL, the backend offers this data layer that you can write a query against.

And that query, it really gives you pretty much everything you need in your view.

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.

Sorry, now I really liked what you said with the advantages and the flexibility that GraphQL gives you to avoid underfetching or overfetching.

But what would be, I'm sure like any technology, this thing has its disadvantages as well.

So can you tell me, name a few of the disadvantages that GraphQL implies?

So I guess the first one that comes to mind is caching.

It's just much harder to cache the results of a GraphQL query than it is to cache a simple REST endpoint.

That's also the complexity.

Why?

Why is it easier to cache a REST answer than a GraphQL one?

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.

Whereas in GraphQL, you have this nested query.

And so you need to think, okay, I need to cache at field level.

and all of a sudden it just becomes a lot harder.

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.

And complexity, it's one of the problems with GraphQL.

It's a lot more complex to define your schema and write resolvers to resolve the data behind that schema in the backend.

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.

And then when it comes to authentication, pretty much the same because people can run queries against our data, against

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

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

YouTube

App Store 및 Google Play에서 4.9/5

Shadowing English
모바일에서

Shadowing English 앱으로 언제 어디서나 영어를 배우세요. 오늘 의사 소통 능력을 향상 시키십시오!

학습 진행 상황 추적

AI 채점 및 오류 수정

풍부한 비디오 라이브러리

스캔하여 다운로드

Download on theApp Store

GET IT ONGoogle Play

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

☕ 커피 한 잔 사주기

ShadowingEnglish는 여러분의 지원 덕분에 100% 무료로 운영됩니다. 서버 및 AI 유지 비용이 많이 듭니다. 여러분의 커피 한 잔이 큰 힘이 됩니다! ��

PayPal로 기부하기

ShadowingEnglish.com – 영어 쉐도잉 연습

쉐도잉(Shadowing)으로 원어민처럼 영어를 말하세요. YouTube 영상을 한 문장씩 듣고 따라 말하며, 진짜 발음과 유창성을 키우세요. IELTS 학습자들이 선택한 방법.

쉐도잉 연습: Backend Interview Questions (Junior & Mid) - YouTube로 영어 말하기 배우기

Shadowing English
모바일에서

이번 수업에 대하여

주요 어휘 및 구문

연습 팁

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉 연습: Backend Interview Questions (Junior & Mid) - YouTube로 영어 말하기 배우기

Shadowing English 모바일에서

이번 수업에 대하여

주요 어휘 및 구문

연습 팁

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

Shadowing English
모바일에서