Backend Interview Questions for Junior and Mid Developers

I'm here with Bogdan today, and we will talk about senior back end interview questions. We're going to jump right in. These are senior level questions that can appear also on mid level engineer 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 it 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 endpoint. And in the rest architecture 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 uh 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 the payment. Okay, and uh 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? Uh, 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.

Um and that's that's one of the the most important things, standardization, so pretty much everybody can consume that, they know how what the shape will be of the request and the response, and gives you the all the advantages of standardization. If you don't follow the standards, you have to just explain a lot and document a lot your API because it just looks like something they've never seen before. Cool.

Then, nice. Number two. This is also a question that has to do with APIs, uh, but a bit more specific. So, can you explain what content negotiation is? 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 as a client, or you could specify with an accept header that you are willing to accept also a GZIP 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's actually compressed, and they do that with the accepting encoding probably. With a content encoding header. Um, and so you know, okay, I need to decompress this. And this allows you to have, for example, um, HTTP compression in uh compression in HTTP. So, content negotiation does that. Now, back in the days, um, I know people also used it for translations of the web pages because back in the days we just had an index HTML page that was in German, let's say, and 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 uh 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 um you mentioned one of the advantages of content negotiation, it's compression. Can you tell me more about that? What what do you mean by compression and knowing the type of compression I need? How does this translate to an advantage for the backend 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 Gzip, 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 a standard, and most browsers, whenever they make a request to a CSS resource, they will add these header of I accept gzipped or a broadly compressed version of this asset, and it helps you with scalability by decreasing the throughput, increasing performance in general.

uh Now, onto something different. We will talk about databases. And um 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 tabulate data, um and that looks a bit like Excel, let's say. Whereas in no SQL, uh 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 any throw everything. Um SQL would be like well classified and well-defined set of drawers where only certain things fit. That's why SQL 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 no SQL you just throw mostly whatever you want there.

Yeah, so let's let's imagine this scenario, you are a back end engineer, um your product manager is thinking together with the business team to launch a new service and uh you need a database and this service, it's about um let's say storing um a certain category of products. Okay, just imagine this. What would you use for this purpose? Would you advise them to um if they ask you to draft a preliminary architecture for this, would you use a an SQL database or a no SQL database?

What would be your choice and why? Man, 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. Uh because I would assume they would want to query that, you know, 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 adding and evolving those relationships, if you already have an SQL database. I would go for SQL as a general rule. a no SQL database, then. I'd probably go for an SQL 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. You don't really they're not so related, of course you will query them at some point, but they're kind of independent events. And uh 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 SQL document database, for example. Uh that would be a use case where I use no SQL. Nice, but now there is one thing that came up in the last few years and that is GraphQL, right? Data 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? Sure, yeah, I've been using GraphQL in the last 5 years. And um I guess the main difference with 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 need to create a certain view and they want it, 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 um defined. The other thing is imagine they would need the products and also different variations of the products, they would need to make an extra 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 it's too little. Whereas in GraphQL, the back end offers this data layer that you can write a query against and that query it's 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.

Um, I really liked what you said with the advantages and and the flexibility that graph gives you to avoid underfetching and overfetching. Well, what would be I'm sure like anything technology these thing has its disadvantages as well. So, can you um tell me name a few of the disadvantages that graph QL implies. So I guess the first one that comes to mind is caching. Um it's just much harder to cache the results of a graph QL query than it is to cache a simple rest endpoint. Uh that's also the complexity. Why? Why is it easier to cache a rest answer than than a graph QL one? Because at the rest level, you just have to you have this specific resource and it's extremely easy to uh to know if the resource is still fresh or to invalidate the cache. Whereas in graph QL, 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's just becomes a lot harder because it's tooling around it and you can maybe work around it, but even debugging where caching happen. Because we have a query again and every you could cache at any level in that query. It's just a lot more complex than than you would in a simple rest API. And complexity, it's one of the problems with graph QL. It's a lot more complex to define your schema and write the resolvers to resolve the data behind that schema in the back end. Uh, so that's another thing that um might be uh a bit of a uh 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 uh against our data 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 and notification, which is just it can be done, but it's more complex than uh protecting a rest endpoint. So you're basically exchanging uh flexibility in your query with complexity of the back end. Yes. And of course, testing, it's also a bit harder. You have so many more use cases in graph QL, yes. You have more use cases, you need you need a lot of specialized tooling to deal with this graph structure uh than you used to have with the rest.

Point where we just send Jason and get Jason back. Now, there is one thing in GraphQL that's pretty uh specific to GraphQL and that is the N+1 problem. Um Have you heard about this problem in GraphQL? How would you go about it? Why does it happen and how would you solve it? Uh yeah, sure. So, yes, we we had this problem before, uh especially in the in the very beginning, we uh we started implementation of the graphical layer. And basically, um imagine in our case we had a product and imagine then the product would fetch uh let's say descriptions in different languages and you need information about the language. For every product, you end up making another resolver query to your database fetching all the languages. And so if you have three products and each one of them has, I don't know, 20 different languages, you end up making 3 by 20 queries to the database to fulfill one request. So, you're basically um making a a denial of service attack on your database. You could literally uh bring your database down if you don't solve that. And the solution to that is to basically batch queries. 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 graphical answer. And you can do that with a couple of libraries. Uh we use data loader in the past and it did a pretty good job. Awesome. now uh pretty standard question for a back end engineer. Uh could you name three solid principles? And I would 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 use I think we have S for um the separation a single responsibility, the single responsibility uh principle. Uh then the L was Liskov substitution. O stands for open closed. Uh S o l I for um interface aggregation and the D for dependency injection. Um I did use a lot dependency injection in the past to make code more testable.

So rather than depending directly by using an import onto something, you can provide it as a as a argument at runtime. So you can either build the class and provide that dependency in the constructor of the class or as a function argument in JavaScript. And what that would allow you 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 you import it directly.

So I use that a lot. I think Nest JS implements that by default and a lot of the back end frameworks like .NET and uh Java Spring boot, they they use that by default dependency version. hm from you know, can you can you tell me another example with another of those principles? Yes, one good example would be the MVC pattern where we split the architecture in layers uh based on the single responsibility principle.

So you have the model and then you have the view layer and you have the controller that does the business logic and that's basically a result of getting you know, your spaghetti backend code and applying the single responsibility principle. That would be another uh example. Amazing. Um cool. Now on to a bigger and uh more high level topic which is uh microservices. So, uh can you tell me what microservices are and, you know, what are some advantages and disadvantages? I would say, hey, let's name uh three of each, three advantages and three disadvantages of microservices.

Okay. Um 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 and there's so many different responsibilities and we decide, hey, let's just separate these two things. So they live independently, each with their own database and they are all, you know, they're completely separated and they can call each other over the network through their rest or graphical APIs.

Um so basically you you take your service oriented architecture, but you distribute it across the network in small. back is that as they say, the number one law of distributed system is don't distribute your systems. Uh the fact that we distribute our systems means um we will have to care a lot about security when we call other services. All of the sudden we have latency because we're doing it over HTTP.

So everything takes longer. It's also much harder to access data over the network. Um and again you have all this complexity of deploying, building pipelines, maintaining all those independent services. So it's what they call the microservices tax where you end up maintaining all these services and paying a huge price. So you really need to be careful uh that when you split it actually pays off. Understood. So as a disadvantage, um complexity and expensive to maintain.

Yes, you could say security, it's another one, you need to have Https certificates that you rotate all those services they need to authenticate with each other and they need to find each other. So all of a sudden you have to solve these problems, whereas in the past you're just making a a call to a different module in your code base to get some data from that extra uh from that other service. But then looking at those um advantages and disadvantages that you mentioned, you know, when would you as a back end engineer, let's say you are the lead back end engineer, um you know, our back end services is growing and growing,

when would you recommend a transition towards microservices? Very good question. I would say it depends on how you want to also distribute your team because we follow the Conwy law, which means the system will look as the team building the system. So if they had count grows and we see there's this like two different feature teams, we want to build all concerned in different parts of the products. Then it makes sense to talk to the team and split the services accordingly.

So they can actually uh the best would be if they can actually deliver and deploy the services independently so you are working in parallel. And you they need to have something that I saw in some of the things in my past, a stand up with 15 people. you want to scale your team mostly. Um the other situation would be if you imagine you're always um seen, you know, a system that there's certain part of it that gets a lot of traffic, but there are other parts that don't, but because that part gets a lot of traffic, we need to scale it all together.

Suddenly, all of a sudden we're throwing a lot 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. So because we are operating in a monolith, if someone breaks anything, if your database goes down for any reason, you're just down.

Whereas in microservices, it's a bit more the whole system, it's a bit more reliable, it's a bit more resilient because you can recover from failure because failure is somehow isolated to one service. In your in your experience working with uh monoliths and microservices, where companies doing the switch to microservices too early or were they rushing? And what would you recommend? Let's say again, let's go back to the product manager, um and executive team is getting around, they are they 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 um to a team looking to to migrate? I would say the most common question uh the most common mistake, it's uh we we are splitting too early and um we end up creating so many services and no one we end up maintaining them because it's just too many. Um and so there's this 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 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 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 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 you made it to all back.

Also, we have a lot more tooling about how to manage them. mono repo right which which uh helps people avoid like mag getting to fast. Um, cool, Bogdan, thank you so much. This was it for today, we will come back with um another series on software senior backend engineering interview questions. As for you, what I wanted, number one, is there any question that you want us to cover in our next video?

Drop it in the comments and Bogde and I will pick it and cover it in next backend engineering series. Um, and number 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 Bogden I and you can ask us questions directly, and you can also share your uh insights with a community of like-minded developers that are also interested into growing.

As for, we will see you in the next one.