Full Stack Developer Interview Questions

"The one I'd pick is a booking app for a small chain of fitness studios. Members book classes on the web, and staff manage schedules. I used React on the front, a Node API, and Postgres, because bookings, members and classes are tightly related and I needed transactions so two people couldn't take the last spot. It ran in containers on a single cloud provider with a managed database. The part I'm proudest of is the booking step. I first checked capacity in code and then inserted, and under load we got overbookings. I moved the check into one transaction with a row lock on the class, and the problem went away. If I built it again, I'd add proper monitoring from day one, because I found that bug from a customer email, not an alert."

"What I like most is owning a feature from the table to the button. When I understand both sides, I can make better trade-offs, like shaping an API around what the screen actually needs, or noticing that a slow page is really a missing index. Honestly, I'm stronger on the backend. I'm comfortable designing schemas, writing queries and debugging APIs under load. On the frontend I'm solid with components, state and forms, but I'm less experienced with fine-grained accessibility and animation work. I've been closing that gap by taking the UI tickets on purpose and asking our designer to review my screens. I think most full stack developers lean one way, and I'd rather tell you which way I lean than pretend I don't."

"I start from what the user needs to see and do, usually by looking at the design and listing the data each screen needs. From that I sketch the API contract: the endpoints, the request and response shapes, and the errors. That contract is the thing I want agreed early, because it lets frontend and backend work move in parallel and it shows me what the data model needs. Then I build one thin slice through every layer, say creating one item from the form all the way to the table and back, before I add editing, validation and edge cases. Getting a skinny version working end to end early surfaces the surprises, like a field the design assumes but the data doesn't have."

"In my first year, our only infrastructure person left and I had to change how our app was deployed so we could add a background worker. I'd never written a deployment config. I started by reading our existing setup line by line and writing down what each part did, then went through the official docs for just those pieces. I found someone in another team who knew the platform and asked for thirty minutes to review my plan, which saved me from a mistake with health checks. I tried everything on staging first, deployed during a quiet hour, and wrote a short guide so the next person wouldn't start from zero. It went out in about a week, and that guide is still what new people read."

"When they click Save, the click handler runs, checks the fields in the browser, and sends a POST with a JSON body. The browser attaches the session cookie, or the app adds a token header. If this isn't the first request, DNS is cached and the connection is already open, so it goes straight to the load balancer, which picks an app server. On the server, the router matches the path, middleware parses the body and checks who the user is and whether they're allowed to do this. Then I validate the input again, because the browser check can be skipped. The handler writes to the database, usually in a transaction, and returns a 201 with the saved record. Back in the browser, the code updates the local state so the list shows the new item, and shows a confirmation. If anything fails, the status code tells the UI which message to show."

"CORS is a rule the browser enforces, based on headers the server sends back. By default a page can't read a response from a different origin unless that response says it's allowed. Curl isn't a browser, so it just shows the response. For requests with a JSON content type or an Authorization header, the browser first sends an OPTIONS preflight asking which origins, methods and headers are allowed, and if the API doesn't answer that properly, the real request never goes out. The fix is on the API: return Access-Control-Allow-Origin with the frontend's exact origin, answer preflights with the allowed methods and headers, and if we use cookies, allow credentials too, which rules out using a star. Another clean option is serving the API under the same origin through a reverse proxy, so CORS doesn't apply at all. What I wouldn't do is allow every origin just to make the error go away."

"It depends on how different the clients' needs are. GraphQL shines when several clients need different shapes of the same data, like a mobile screen that wants three fields and a web dashboard that wants thirty. The client asks for exactly what it needs in one round trip, and the schema is a typed contract both sides can rely on. But it moves complexity to the server. Plain HTTP caching is harder because most queries go through one endpoint, often as POST. Naive resolvers cause N+1 database queries, so you need batching. And since clients can write any query, you need depth or cost limits. For a small team with a few well-understood screens, I'd usually start with REST, well-designed resources and good docs, and move to GraphQL if we keep building one-off endpoints just to reshape data."

"First I'd see if the change can be additive. Adding a new field or a new endpoint doesn't break old clients, as long as they ignore fields they don't know, so I'd rather return the new shape alongside the old one than change the old one. If it's truly breaking, like a field changing type, I'd release a new version, either as a new path like v2 or through a header, and keep v1 working, ideally with v1 as a thin adapter over the new code so I'm not maintaining two copies of the logic. Then I'd log which app versions call v1, add a minimum-version check in the app so we can prompt people to update, and only switch v1 off when its traffic is close to zero. With mobile you have to assume some users won't update for months."

"I'd add a comments table with an id, the post id, the author id, the body, a created time and a status, so we can hide spam without deleting it. It gets an index on post id and created time, since we always load comments for one post in order. For the API, a GET that lists comments for a post, paginated with a cursor so new comments don't shift the pages, a POST that creates one for the logged-in user, and a DELETE that only works for the author or a moderator. The server checks the length and stores the text exactly as written, and the frontend renders it as plain text so it's escaped on output. In the UI, I'd show a skeleton while loading, a friendly empty state, and an error with a retry button. When someone posts, I can show the comment straight away as 'posting', then confirm it, or mark it failed with a retry, keeping their text so they never lose what they wrote."

"On one project, we split a fairly small app into five services early, because we expected to grow fast and it felt like the professional way to build. In practice, the same four developers owned all five. A simple feature like adding a field to the user profile meant changes and deploys in three services, and debugging meant chasing a request through several logs. Local development needed a pile of containers just to start. Growth came slower than we planned, so we paid the cost without getting the benefit. If I did it again, I'd build one well-organised app with clear modules and split out a service only when a part genuinely needed to scale or deploy on its own. The lesson I carry is to design for the team and traffic you have, while keeping boundaries clean enough to split later."

"If I put the token in localStorage, any JavaScript on the page can read it, so a single XSS hole, even in a third-party script, lets an attacker steal it and use it from anywhere. An HttpOnly cookie can't be read by scripts, which is why I prefer it. The catch is that the browser sends cookies automatically, so another site could trigger a request on the user's behalf. That's CSRF. I handle that with SameSite set to Lax or Strict, and for state-changing requests a CSRF token or a check of the Origin header. Keeping a short-lived access token only in memory, with a refresh token in an HttpOnly cookie, is another common pattern. Either way, HttpOnly doesn't make XSS harmless. Injected script can still make requests as the user while the page is open, so preventing XSS is still the real fix."

"With sessions, the browser holds a random id in an HttpOnly cookie and the real session lives in a store like Redis or the database. Every request does a lookup, but logging someone out or banning them takes effect at once, because I just delete the session. A JWT is signed data the server can verify without any lookup, which is handy across several services and for mobile apps that don't handle cookies as naturally. The catch is revocation. A stolen or outdated token stays valid until it expires, so I keep access tokens short-lived, a few minutes, and pair them with a refresh token that's stored server-side and can be revoked. For this product I'd likely use a cookie session for the web app and short access tokens with refresh for mobile, both backed by the same user and session records."

"When they click the button, my app redirects them to the provider's authorize page with my client id, the exact redirect URL, the scopes I need, a random state value, and a PKCE code challenge. The user signs in there and agrees. The provider redirects back to my callback with a short-lived code and the same state. I check the state matches what I stored, which stops someone forcing their login onto my user. Then my server, not the browser, sends the code, my client secret and the PKCE verifier to the provider's token endpoint. I get back an access token and, with OpenID Connect, an ID token, which I verify: signature, issuer, audience and expiry. I look up my user by the provider's stable user id, create one if needed, and then issue my own session cookie. From then on, my app runs on its own session, not the provider's token."

"Cross-site scripting is when text an attacker controls ends up running as script in another user's browser. The classic case is a comment containing a script tag that's saved and then shown to everyone who opens the page. That script runs with the victim's session, so it can read the page and make requests as them. The main defence is escaping output for the context it lands in. Modern frameworks like React escape text by default, so the risk comes back when someone uses innerHTML or its equivalents. If we really must show user HTML, like rich text, I run it through a well-maintained sanitiser with an allow-list. On the backend I validate input, set a Content Security Policy that blocks inline scripts, and keep session cookies HttpOnly, which limits the damage if something slips through."

"If the search endpoint builds the query by gluing the search text into the SQL string, the text becomes part of the command. Someone can type a quote followed by their own SQL and turn a simple search into a query that dumps every user, or worse. The fix is parameterised queries. I write the SQL with placeholders and pass the values separately, so the database always treats them as data, never as SQL. ORMs do this for you, until someone drops into a raw query. One gap people miss is that you can't use a placeholder for a column name or a sort direction, so if the user picks the sort column, I check it against a fixed list of allowed columns. I'd also give the app's database user only the permissions it needs."

"I'd point out that hiding the buttons is fine for the interface, but it isn't a security check. Anyone can open the browser tools or use curl and call the admin endpoints directly, so if the API doesn't check the role, a normal user can do admin things. The server has to verify the token's signature and check the role on every protected route, ideally in shared middleware so no endpoint forgets. I'd also mention that a role inside a JWT stays valid until the token expires, so if we remove someone's admin rights we either keep tokens short-lived or check the role in the database for sensitive actions. I'd keep the tone practical, maybe show the curl call hitting the endpoint as a regular user, and suggest a test that makes sure non-admins get a 403."

"I start from the data and how it's used. If the app has lots of things that relate to each other, like users, orders, products and payments, and I need joins, foreign keys and transactions across several rows, I go relational. That covers most business apps, and Postgres also has a JSON column type for the parts that genuinely vary. A document database fits when each record is mostly self-contained and read as one unit, like a product catalogue where each item has different attributes, or event data where the shape changes often. The trap is picking a document store to skip schema design and then rebuilding joins in application code. So my default for a new app is relational, and I'd need a clear access pattern to move away from it."

"I'd have users, products and orders, and then an order items table in between, because one order has many products and one product appears in many orders. Each order belongs to a user through a foreign key and has a status and a created time. Each order item points at the order and the product and holds the quantity. The key point is that it also stores the unit price at the moment of purchase. If I only linked to the product and read the current price, then changing a price tomorrow would silently change every past order's total, which is wrong for receipts, refunds and accounting. I'd add a check that quantity is positive, and index orders by user id because 'my orders' is the most common read."

"I wouldn't stream big files through my API servers, and I'd never put them in the database. The browser asks my API for permission to upload, the API checks the user and the declared size and type, and returns a short-lived signed URL for object storage. The browser uploads straight to storage, and for multi-gigabyte videos it uses multipart upload, so a dropped connection only retries one part. When it finishes, the browser tells my API, which records the storage key, the owner and the status in the database. Then a background job checks the real file type rather than trusting the extension, scans it, makes thumbnails or transcodes the video, and marks it ready. Files are served through a CDN, and private ones get signed download links that expire."

"A straight rename breaks things, because during a deploy the old code is still running and still asks for the old column name. So I'd do it in steps across several releases. First, add the new column as nullable, which is a quick change. Next, release code that writes to both columns but still reads the old one. Then backfill the existing rows in small batches, so I don't lock the table or flood the database. Once the data matches, release code that reads from the new column. After that's been stable, stop writing the old column, and in a final release drop it. It's more work than one migration, but every step can be rolled back on its own, and at no point is running code looking for a column that isn't there."

"I'd look at it layer by layer. Static files like scripts and images get fingerprinted names and long cache lifetimes, so the browser and CDN serve them without touching my servers. The product data itself changes rarely, so the CDN or a reverse proxy can cache the page or the API response for a short time, and even a minute takes most of the load off. Behind that, I'd put an in-memory cache like Redis in front of the expensive queries, reading from the cache first and falling back to the database. For staleness, I decide per field. The description can be a few minutes old, but price and stock can't, so I either delete the cache key when the product is updated, or fetch stock separately and uncached. And anything per user, like the cart, must be marked private so a shared cache never serves one user's data to another."

"First I'd reproduce it with the browser's network tab and performance panel open. That tells me straight away if the eight seconds is one slow request, a chain of requests waiting on each other, a huge download, or the page busy rendering after the data arrives. If it's an API call, I check the server timing. With tracing or even simple timing logs, I can see how much is in our code and how much is database. Often it's a few classic things. A list endpoint that runs one query per row, the N+1 problem. A query missing an index, which I'd check with the database's explain plan. Or the dashboard calling five endpoints one after another when they could run in parallel. I fix the biggest measured cost first, re-measure, and set an alert so we know if it creeps back."

"On every pull request, the pipeline runs linting, type checks and unit tests for both frontend and backend, builds the frontend, and runs integration tests against a real database in a container, because mocks hide query bugs. A preview environment for UI changes is a nice extra, so design and product can click through before merging. On merge to main, it builds one artifact, usually a container image, tags it with the commit, and deploys it to staging, where migrations run and a few smoke tests hit the key pages and endpoints. Production gets that exact same image, not a rebuild. I prefer a gradual rollout with health checks, so a bad release only reaches some traffic, and I want rollback to be one command. Secrets live in the platform's secret store, never in the repo."

"Checkout is money, so my first move is to stop the damage, not to debug live. If the change is behind a feature flag, I switch it off. If not, I roll back, and I check the error rate actually drops. I'd post in the team channel straight away saying checkout is failing, that I'm rolling back, and when I'll update, so support knows what to tell customers. Then I investigate. The 'some users' part is a big clue with a cross-stack release. Often it's users still running the old frontend from cache calling the new API, or the new frontend hitting an API server that hasn't updated yet. So I'd look at the errors grouped by client version and server instance. Afterwards, I'd make the API accept both old and new request shapes during deploys."

"At my last company, a release I'd worked on caused password reset emails to stop going out for about two hours. I'd changed how we loaded config, and in production a variable for the email service came through empty, so the send failed quietly and only logged a warning. Support noticed first. I was the one who traced it, and we fixed the config and re-sent the missed emails to everyone who had asked in that window. I wrote the review with no blame, and said plainly that my change caused it. We made three changes afterwards: the app now refuses to start if a required setting is missing, failed email sends raise an alert instead of a warning, and we added a check after deploy that sends a real test email. Nothing like it has happened since."

"I'd first talk to the designer and the product manager to understand what the number is for. Sometimes it only matters for a few rows, or it's fine if it's an hour old. Then I'd come with options and their costs. We could show it only on the detail page, where computing it for one item is cheap. We could precompute it in a background job and store it, which makes the list fast but the figure slightly stale. We could load it lazily after the list appears. Or we could ship the list on Friday without it and add it the following week properly. What I wouldn't do is quietly compute it per row inside the list request and let the page crawl. Once we pick, I'd write down the decision and any follow-up ticket so it doesn't get lost."

"It sounds like a one-hour job, so I'd ask a few quick questions first. Who should be able to use it? Which fields do they actually need, because exporting phone numbers and addresses has privacy rules attached? And how many users are we talking about? Then I'd build it with the permission check on the server, not just a hidden button. I'd export only the agreed fields, and log who ran it and when. If it's a few thousand rows, I can stream the file straight from the query. If it's hundreds of thousands, I'd run it as a background job that emails a short-lived download link, so the request doesn't time out and the database isn't hammered. I'd also neutralise values that start with characters like an equals sign, so the file can't run formulas when someone opens it in a spreadsheet."

"At my last job, product wanted live search that updated on every keystroke across all customer records, including notes. Our database couldn't do that quickly, and doing it properly meant adding a search engine, which was weeks of work plus something new to run. Instead of just saying no, I showed a quick prototype on a copy of real data where each keystroke took about two seconds, which made the problem obvious. I offered two options: live search on names and emails only, which I could ship that sprint, or the full thing in a later quarter. The product manager chose the first one, and it covered most of what support used it for. Later we did add proper search when notes search became a real need. What I learned is that showing the cost beats describing it."

"I like being involved early, because I can flag things the mockups usually don't show. What happens when the list is empty, when a name is very long, when the request fails, or when the user doesn't have permission? Those questions often shape the design and the API. While the fuzzy parts get settled, I start on what's unlikely to change, like the data model and the basic endpoints, and I keep my assumptions written in the ticket so anyone can correct them. Then I show work early, even rough, in a quick demo or a preview link. It's much cheaper to hear 'that's not what I meant' on day two than after the feature's done. And if something is technically hard, I say so before it's designed in, not after."

"I notice it when people wait for me to review things only I understand, or when my holiday makes a release risky. That's a team problem, even if it feels flattering. I write short docs for the parts that confuse people most, like how a request is authenticated end to end, or how to run the app locally with real-looking data. When someone asks me the same question twice, that's a sign it should be written down. I pair on tricky tickets instead of taking them myself, and in code reviews I explain the why, not just 'change this'. Most of all, I hand areas over on purpose. I'll let a frontend-focused teammate own an API change with me as the reviewer, so next time they don't need me at all."

"At my last company, users reported that dates in their order history were sometimes a day off. It looked like a frontend formatting bug, and the first fix attempt changed the date display, which didn't help. I followed one bad order through the stack. The API response already had the wrong date, so it wasn't the browser. The database had the right date, so it wasn't the data either. The problem was in between. The column stored a date without a time zone, the server converted it to midnight in the server's time zone, and then the frontend converted it again to the user's. For users far from the server, midnight crossed a day boundary. We changed the API to return plain calendar dates as date strings, not timestamps, and added a test with a user in a far-off time zone."