Video guide
24:47 · 23 April 2024
Full Stack Interview Questions for Junior and Mid Developers
Chapters 5 sections
Interview questions in this video:
- 01
1. What is an SQL injection attack?
An attacker types SQL into an input field on your page, and your backend executes it because the input was never sanitized. The classic cause is building queries with string interpolation — WHERE username equals whatever the form sent, verbatim. From there they can read your database, escalate their own user's privileges, or drop tables — a very common attack in the early 2000s.
SQL injectionsecurityinput sanitization - 02
2. How do you prevent SQL injection?
Sanitize all input, and use SQL parameters. With a parameterized query, the executable part is fixed and the input travels separately as a dollar-sign argument. If the attacker sends SQL, it is treated as plain data — they get no results, and nothing executes on your database.
parameterized queriessecuritySQL - 03
3. Can you explain HTTP caching?
It is an HTTP mechanism between client and server so heavy assets are not re-downloaded on every visit. The server sends a Cache-Control header — for example public with a max-age — and the browser stores the file on disk. As long as the asset's age stays under max-age, the browser serves it from the local cache without touching the server.
Cache-Controlmax-ageHTTP - 04
4. What happens when a cached asset's age passes max-age?
The client does not re-download — it asks whether the resource is still fresh: cache invalidation. It sends the ETag, a unique hash of the version it holds, and the server answers either keep it or fetch the new one. Last-Modified and Expires are the older alternatives, but comparing dates across time zones is painful, so ETags are the modern way.
ETagcache invalidationLast-Modified - 05
5. Have you used HTTP caching in practice?
Yes — it comes out of the box with any CDN. Put a content delivery network in front of your app and it adds Cache-Control and ETags to all your static assets. You can verify it in DevTools: a 200 from disk cache response never hit the server, and the request-side Cache-Control: no-cache header is how disable cache bypasses it all.
CDNDevToolsstatic assets - 06
6. How do you scale a huge SQL database that is read-heavy?
First ask about traffic: most web applications read far more than they write. For read pressure, apply replication: one main database takes the writes, and a cluster of read-only replicas serves the reads — every write replicates down to the replicas. It offloads most of the pressure, and it is one of the easiest ways to scale; AWS RDS makes it very straightforward.
replicationread replicasAWS RDS - 07
7. What do you do when the database is write-heavy?
When writes blow up the hardware, you implement sharding: split the data across databases based on a hashed property, like the record ID. The hash decides which shard a record lives on, for writes and reads alike — think of it as almost a load balancer for storage. It needs consistent hashing, must not couple storage to application code, and joins across shards are a real limitation — but at that scale there is no way around it.
shardingconsistent hashingdistributed systems - 08
8. Why not just scale the database vertically?
Vertical scaling gets exponentially more expensive — going from 16GB to 32GB of hardware costs far more than double. You rarely need peak capacity all the time, going back down means shutting the server off and relocating, and you keep a single point of failure. Distribution buys you availability, not just scalability.
vertical scalingavailabilityinfrastructure - 09
9. What is an in-place deployment?
You replace the code on the server with the new version and restart — the default at pretty much every startup. It is robust and easy; you only need some Linux administration. But you get downtime, rollback is hard, and it is very manual: the deployment where you stay awake until 2 a.m. waiting for zero users.
in-place deploymentdowntimerollback - 10
10. What is a rolling deployment?
You have a fleet of instances — an auto scaling group in AWS — and you deploy the new version gradually, instance by instance. Less downtime, and if version two breaks you still have healthy instances on version one to fall back to. The catch: users hit different versions at the same time, which gets ugly when SQL migrations are involved.
rolling deploymentauto scalingmigrations - 11
11. How is traffic distributed during a rolling deployment?
A load balancer sits in front of the fleet and distributes requests — round-robin or whatever algorithm you choose. It does not know which instance runs which version, so during the rollout some users land on the old code and some on the new. That version mix is the price of rolling deployments.
load balancerround-robintraffic - 12
12. What is a blue-green deployment?
You provision a complete copy of the infrastructure running the new version, run all your checks against it, then redirect traffic to it. Literally no downtime, and rollback is instant — the old environment stays alive, so you point traffic back the moment something breaks. The cost: duplicated infrastructure and complex tooling — infrastructure as code, Kubernetes, containers — to spin environments up fast.
blue-green deploymentinfrastructure as codeKubernetes - 13
13. What is a canary deployment?
Like blue-green, but you route only a slice of traffic to the new version — 2%, 10%, or one specific geography. The name comes from the miners' canary: a canary test runs continuously against the new instance, and you ramp traffic up only while it stays healthy. You need that test plus a load balancer setup that can slice traffic.
canary deploymenttraffic splittingtesting - 14
14. Are feature toggles a deployment type?
Some people count them, but no — a feature toggle is code logic that switches a feature on and off, a feature of the software rather than a deployment. The upside is real: it decouples releasing a feature from deploying the code. The downside: every toggle multiplies the amount of testing your software needs.
feature togglesrelease managementtesting - 15
15. How does the internet work, from typing a URL to the rendered page?
The browser first asks a DNS server for the site's IP address — think of DNS as a lookup table from domain to IP. Over the IP network it sends TCP packets that carry an HTTP GET request, with headers like Accept: text/html. The server opens the TCP connection and replies 200 OK with Content-Type: text/html and the document, and the browser runs the critical rendering path: build the tree, fetch the linked CSS and JavaScript, and incrementally paint the page.
DNSTCPHTTPrendering
Transcript
So, first question of today's interview, what is an SQL injection attack? An SQL injection attack? Um, can I share my screen? Is that okay? Yeah, sure. Go ahead if that helps. Okay, so SQL injection, it's basically when we have a web page, right? And we have an input field on that web page, let's imagine it that way. And basically, the attacker, so this is our application, we have a back end. And the attacker is capable of writing SQL code over here, so they do write some SQL.
Oh, my God, I'm super zoom in. So, they get some SQL over here. And that SQL gets actually executed because we fail to sanitize that input into our database. And they could do certain things like they could probably, for example, change the privileges of their own user, they can read our database, they can drop the database. And this was a very common attack, I think back in the early 2000s. Um, so basically, what they would do is I would write here some SQL like select all from.
But they need to engineer their queries very well. So, for example, what they would do is they would add they would try different things and you'll start this statement with maybe a semicolon. And what that would do is that in the back if in the back end, um the way the back end developers go their queries was like this, like let's say they had a select all from uh users. where user username it's equal to.
And you would normally do string interpolation with the input that comes from the front end. So you'd put directly the input here. The attacker could actually put this query that they put in into here. And so you'd end up running SQL on the database. And the way to avoid this is to just use um first of all, sanitize all your input and second of all, use SQL parameters, basically, they look something like this.
But what SQL would do when you send this query over and you provide this dollar sign argument separately, it will not run this as SQL. ight of the query is this one and then provide this as an input and then it won't work. If they provide some SQL here, it's just going to they will get no results, but it's not going to execute that on our database. Cool. Now, um we're going to move on with the second question.
Can you explain HTTP caching right? Um, and also go into advantages and and let me know if you ever used it in the past, later. Uh, awesome. Sure. So, HTTP caching, it's one of my favorites, uh, because it's very easy to set up these days. And basically, well, it's always it's an HTTP mechanism, so it happens between a client and a server. And imagine we have here a CSS file or any other file, an image, a heavy file.
Um, we definitely want the users, we we could actually make the webpage load faster if users could reuse this resource in the future and not have to download it every time they go to the website. So, what happens normally, it's let's imagine this is our uh this is our server. And there will be our client. Yes. And they will make a first request of an asset, it can be even a rest resource, an HTML file.
And so, what they would receive in the HTTP headers would be a header called cache control. Uh, and there's different values for this header. Uh, but one of the most common is to basically specify, this is the header that specifies how the client should cache this. Um, so basically here they would have something like, let me make this bigger, perfect. So, we'll have something like public and the max age property.
So, max age, and this will be milliseconds. And what this means is the client can reuse that resource as long as the age of the asset, so there's an age, which starts at zero when we just got it. As long as the age, it's smaller than max age, the client doesn't need to get that resource. Uh computer and yet they get resource from there, get the CSS file from there. Um and that's so that's basically the the basics behind it. What would happen what what's happening when the age goes higher than this, uh then then whatever the max age was, is that the client will make a request, but it's not a request for the resource, but is rather to check if is this is what we call caching validation, is the resource still fresh? Is the resource still fresh? And basically they will do that nowadays with the E tag. So you probably have an extra tag which was which is the E tag. And basically this is a unique hash that was computed for this version of the CSS file. And so they will send that to the server and check was this modified and the server can answer with in two ways. Uh they can either say no, it wasn't modified, keep that version, or yes, it was modified, make a request, get the new version over. And um back to your question on if I ever used it, this is basically uh most of times comes out of the box with any CDN you're using. So if you're deploying your application and you put a CDN in front of it like um a content delivery network, basically, uh they already apply this to all your static assets, um they add e tags, they add the cache control and the age. And we can even uh go in and look at the live example if you want. Yeah, let's pick something like maybe GitHub or any like popular developer website. Okay, let me see if I can share my screen again. Now, one thing I wanted you to to uh go over is this public parameter, um you know, what does public mean in that request? Okay, so let's see how this looks like in stack overflow, for example. Yeah, so I'm going to go over why I did that and what does that mean, but I just reloaded the page right now and as you see here, it says 200 from the disk cache. So this was not this is not coming from the server. This is coming from my personal computer. And the reason for that is that you see this, I'm not sure how big this is, but the age parameter.
here. The age, it's Yeah. this many milliseconds and if we look at the cache control, it's a public max max age 315360. So basically, what this is saying is, hey, you uh you can keep the asset for a bit longer. Yeah. Um As long as this age goes over, they will rely on the eTag. So there's this eTag uh header that should be somewhere. Um now, because there's no eTag because I probably did not give me a second. Uh accept. Okay, it didn't really find the eTag. I think they might be relying on the last modified. Last modified, it's an alternative and expires. They're alternative C tags, but because it's so hard in programming to compare dates and you need to always transform uh bring them back to um to a time zone, it's just a lot easier to use the eTag. And so the modern way is to use eTags. Maybe if we look at another asset, like a CSS asset, they probably use I could see the eTag there. There you go. It has an eTag. But again, um the cache control on this resource is no cache. So Okay. even if we have a it's not really being used. That's why I was looking for this one. That's a better example. But again, there's no there's no eTag on this one. So it very much depends on how they um perfect. It pretty much I feel like they're using an older um set up because they're using expire and last modify all the time. Mhm. Yeah. Um the other thing is as we see here, if we enable disable cache, what we will be doing and this is something really cool that Google Chrome does for us, is that whenever we get a resource, on the request headers, we are setting a cache control ourselves to no cache as the client. We're saying, hey, there won't be any caching happening. Bypass bypass the cache, right? Bypass bypass the cache, right? Um yes, you could you could say that. We're actually using the the headers to specify there is no cache. And because we do that, as you you see cache control no cache, then
It doesn't really matter what the uh what the uh server implements. So, just going back to the drawing, this is how Mhm. http caching works. I'd say a top view. As some park, now let's move on with the next question. Um, so imagine you have a huge SQL database. Uh, we want to scale that. So what are the different ways we can scale that huge SQL database? Okey dokey, so we have one of those. Um, I'm going to go back to my board, just because it's a lot easier to show than tell.
Um, as a quick question, do we know anything about the traffic on this database? In terms of reads versus writes, for example. Do we read a lot or do we write a lot? What is the use case? Let's, let's assume we read a lot more than we write. But, as we scale, we will also um face a writing problem down the road. Okay. Um, I mean, most most web applications you will read a lot more than you write. If you take the example of Instagram and so on, or any social media, people watch and consume stuff much more than they publish on average.
Yeah, that's a good that's a good a news feed-based application, um, like a social media. That's a good example, so you can use that. Yes. Okay, so if that's the case and we get a lot of incoming traffic here and we figure out that the queries are getting slower, the memory the memory on this component, the memory and CPU usage, uh, it's blown up. What we can do is to basically apply a replication strategy that will basically, rather than having one database, we will have one database that handles the reading.
And then we're going to have a bunch of Let me copy this. A bunch of read-only replicas. So, they used to be called Master and Slave. Although right now we could just call it the the main database and then, uh, and basically what happens is we right to the main database. And whenever we write that, it gets replicated to the child to the to the read-only replicas. But whenever we read from the database, we go to this cluster of read-only replicas.
And so we can offload a lot of reading pressure to these replicas and they are quite performant. And that would be one of the easiest way to scale the database by by having read only, let me write it down here. Read only replicas. Um you can do this in AWS. I've done this with um IDS, it's very straightforward and it's one of the easiest way. Now, to follow up on what you mentioned as a second case, imagine we do need to write a lot, so um we are getting to this point where this database, right, is getting bigger and bigger, we have too much pressure on the hardware and we either add more hardware, which is usually a bad strategy. Or what we can try to implement is shading. So basically, what we do is that we try to split um into different databases based on a property that we hash. So for example, we have a bunch of records here and then we take their let's say their ID and then we somehow hash it. And you can think of this as a almost a load balancer, although it's not really a load balancer, but based on the ID, we can actually push the record here or here or here. And whenever we need to read, based on the ID, whenever we want to fetch that, then they will redirect and read from the right database. Getting into the distributed systems part, right? Yes, this is a bit more complex to implement and and um because you don't want to do this with you don't want to write any application code. We don't want to couple the storage with our code. So this becomes a bit more complex to implement. Um, you need to know about consistent hashing. And the hide thing about this is when you have joins, or when you want to query um you want to query records that are distributed over. Distribution it's always um a huge limitation, but if you want to scale there's no way around it. Yeah, you mentioned um scaling it via hardware, right? Let's say vertical scaling, like this is an example of horizontal scaling. Um why not scaling
you know, vertically. Why why not? Why distribute in the first place? Um, very good question. The problem with vertical scaling is that it's going to become exponentially more expensive the more hardware. So the difference between a machine that has, let's say 16 GB to 32 in terms of price, it's very high. And the other problem is you will most likely not need so much capacity all the time. You probably have peak hours and so the problem once you scale vertically is that it's not so easy to go back. You need to shut down the server and then relocate to to a bigger machine.
Um or even if you do it in cloud, it's usually very expensive, it has downtime. Um and you still have a unique point of failure. Uh that's another problem that can appear. So not only distribution, not only improves scalability, but also improves availability. of the resource. Okay, now we're going to go and talk about deployment. Um could you explain the different deployment types and as you explain them, um you know, feel free to dive deep into pros and cons, advantages, disadvantages. Um yeah, different deployment types you've been exposed as a senior backend engineer.
Okay, so I'm going to start with the simplest one. I used to do this we used to do this at the the pretty much every startup you work for. That would be the in place uh in place deployment. And this basically means that in why one way or the other, we have our server, whatever that is, a Linux server, let's say, and we have our code that's let's say. Um, so, let me make this green. Let me make my code blue.
And basically, we just kind of somehow replace the code with a new version. I'm going to put that green, right? So we somehow push that new version and then we restart the server. I've done a lot of those, especially at the beginning of my of my career. Um, it's very robust. It's very easy to set up. You just need to know a bit of server administration. But you do have downtime. So it whenever you are restarting the application, there might be downtime.
time and it's extremely hard to roll back sometimes. So roll back can be a problem. Uh you and because you don't have a good roll back mechanism and downtime can be another problem. Um and also, well it depends how you have it set up, but usually it's very very manual. But this is like the old good old fashion deployment. Um and you need to stay awake until 2:00 PM when you're have no users, right? down downtime.
Yeah, I mean, it depends on your traffic, but I had to I did a bunch of all nighters doing those. So, um Not funny, not at all, not at all. Um then there's the rolling deployment, uh which is more or less the same. But only difference here is that and this is when it gets complicated. Because you let's say have a fleet of instances, because we are horizontally scaling our service, let's say that's our that's our um in in Amazon in AWSD call this auto scaling groups, but doesn't really matter.
You have a fleet of instances. And so what you do is you gradually deploy the new version of the software, right? So this becomes green all of a sudden and this too. And then ideally there's no issues and then you can continue. Um this is again, it's kind of complex. Uh the disadvantage is some people will access version two and some other will action version version one. So you can have problems there especially if you have uh databases involved because you need to also deploy migrations if you have SQL databases.
Um so again, it's not great, but it is the only way you can deploy to a fleet of instances. Um the advantage here it's if there's any problem with this too, you still have the other two alive. So, you can maybe just shut this down really quickly and then instantiate a bunch of those really fast. So, downtime it's a bit less, but it's also again, it's complex, um you pay a lot of cost because you're you're distributing everything.
How do you distribute the traffic in this case? Um so in this case you have a load balancer component that sits here. And the load balancer it's responsible for kind of distributing the traffic either with a round robin algorithm or Whatever load balancing algorithm you choose. Mhm. About again, the load balancer doesn't really know which version is it. So some users will go over there, some users will go over there.
That's kind of the problem. Let's go into pros and cons, so um I what I understand is there is no downtime, you just might get different different users might get different versions, right? But here we avoid the downtime, right? Because we have this rolling strategy. Um, yes and no, you you can still have users that experience bad bad experiences because if there's a mistake here, they just it's it's going to affect them.
So you have less downtime, but you do have you can have problems. And this is what the next like the blue green deployment kind of solves. Blue green, right? So in here we basically duplicate the whole thing. So rather than imagine this is our old version, right? It's receiving traffic right now. Yes. And what we do is we totally deploy and provision in a total copy of this with a new application.
So let me just make this green. Okey-dokey. And so that because we have two of them, we can actually make all our checks and then start redirecting traffic here. And uh if there's any problem, you keep alive this distribution and shut it down as soon as you see there's a problem. So this has base literally it shouldn't have no downtime, like literally it has no downtime. No downtime. And the roll back is very fast because you keep this alive and if there's any problem you can shut it down.
The disadvantage is you're going to pay a lot to your infrastructure cost. This can cost you a lot. Um because you are duplicating this infrastructure and you need to keep it alive for a while. You also need to have a lot of complex tooling to be able to manage this load balancer components, to spin infrastructure really fast, or something like infrastructure as code can help you. But again, this is very complex.
If you're using tools like Kubernetes and containers, you can set it up rather fairly quick. Is there any any any more uh type of deployments that you like to mention? Uh there's Canary deployment and it's pretty much the same as blue green. But there's a big difference which is that you usually uh only redirect part of the traffic to our new instance. So you go ahead and you say, um let me have 2% of the traffic over here.
or 10% or let me have the traffic from a specific geography. I worked with that a lot. Um and the other thing the reason it's called Canary is because you have a Canary. Uh you remember the uh back in the days the the the miners had a canary that they would send over to see if if there's any gas leak and the canary, if it comes back, then then it's all good. Um the Canary it's usually an enter-in test that's running all the time and you run it against the new instance.
And so if the Canary it's okay, then you start um redirecting more traffic. Again, you need a Canary that's number one and complex load balancing setup because you want to redirect uh you want to slice your traffic somehow. Um and number five, I do not consider this a type of deployment. I know some people do, but that would be the feature. Toggles where you you're really not you deploy the whole version, but you have some code logic that can switch a feature on and off.
Um I do not consider this a type of deployment for me it's almost like a feature in the software. But some people do and it has several advantages, which is that you decouple your deployment from your code um deployment like the deployment of the feature from the code deployment. But at the same time, having a lot of feature toggles really increments the the the amount of testing you need to do to your software.
So I'm not going to I'm not going to add it as extra deployment. Yeah, next question, how does the internet works? Uh and I want you to explain that, you know, since the moment you type something into your browser until the page it's shown, but until the page is rendered to the users, to yeah, to the final user. Okay. That's actually a very fun exercise. Um how does the internet work? Well, let's say it all starts as you mentioned with a web browser where we type something.
Let's say we type the senior dev. Um so we type this in our web browser and the first thing the web browser will do, it will make a query to look up the DNS, like the IP address of this of the server that's hosting this website, um and they will make that to the DNS server, like the domain name system. The servers are basically like tables, so you just kind of think of of a table hosted somewhere that says, you know what, the senior dev, uh let me see, has, so this senior dev, whatever, it has this IP address.
So, whatever, okay, that's not a real IP address that I'm adding there, but you get the idea. So, and they have a bunch of them. And then the browser knows, okay, that's the IP address. And of course this is the internet protocol and so over the IP network, we will start sending, we can now start sending IP packages. Um, those IP packages are containing TCP packages and TCP packages are put together in an HTTP request.
Um, so basically when you type this address, you end up making a two hun a get right a get request to uh to this path, to our domain. And I would assume the the browser will send some headers to like what does it accept and most of the times it would be something like accept text/HTML. So it's basically requesting an HTML file that we have here. Um, so that will be the request. And then there will be a response, so the server will connect, will open up a TCP connection with this and probably reply with ideally, if everything it's successful, a 200 okay.
Mhm, and there will be some headers. But basically the headers will tell you what's the content type of our uh response, which would be text/html. And then there's an empty line and then you have your HTML document. HTML, which is obviously it's just text, right? And uh it's just a bunch of text. And then the browser will take this and see, okay, this is text HTML, so I'm going to get all the body of the of the request here.
And applies basically what we call the critical rendering path. So, basically it will take our markdown, it will try to build the HTML 3, it will request any links to um CSS assets or JavaScript assets. It will interpret those and then it will try to stream, to incrementally build the UI as it reads down the HTML. Very good overview. Um we're not going to go deep into the critical rendering path, um because that belongs more to the to the front end engineering.
Um interview, but that's definitely a topic that um that is pretty interesting, talking about uh painting final the final website to the user. Well, Bogden, uh this is it for uh today. Very well done. Now, uh for the people watching us, um, you know, if there's any specific backend question, you want Bogden and I to dive deep, uh just drop it in the comments and we will add it to our next video. That's number one.
Um, number two, we are putting together a community for JavaScript software engineers that are looking to get to the senior level with quality resources, accountability. We have monthly calls where you can directly interact with Bogden and I. Um, you know, we help you with interview, technical interview resources, any kind of resources you need to make that jump to as a senior and beyond. Um, if you want to check it out, uh just check the link in comments.
group mentoring um coaching program. Like this is what software mastery is designed for. We are helping developers fill up, date angle gaps and become that confident, competent senior engineer. Um, but we cannot work with any kind of developer. So uh this is a premium service. If you think, you know, that would be something you would be interested in, just click on the link in the comments also you'll find a link to apply for a small chat with me where we will see, hey, can we help you? Is this a fit and see if we can talk further. Uh whether you want to join us or not.
With that being said, thank you so much, Bugdon, very great answers, and we will see you folks in the next one.