Full Stack Interview Questions for Junior and Mid Developers

THE QUESTIONS

Real questions, senior answers

1. 01

   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
2. 02

   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
3. 03

   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
4. 04

   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
5. 05

   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
6. 06

   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
7. 07

   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
8. 08

   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
9. 09

   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