Full Stack Developer Interview Questions and Answers

I start from trust. Anything security-relevant, like price calculations or permission checks, must live on the server or in the database, because the client is fully under the user's control. Validation is duplicated on purpose: cheap format checks in the browser for fast feedback, and authoritative validation on the server. Business rules go in one place, usually the server, so two clients cannot drift apart. I push logic into the database when it is a data integrity concern, such as a uniqueness rule or a foreign key, because that is the only layer every writer passes through. The tiebreaker for everything else is the next change: I put the logic wherever the next likely modification is cheapest and safest.

On submit the browser runs client-side validation for quick feedback, then serializes the form and sends a request, usually with a session cookie or a bearer token. The request hits the load balancer, then the application server, where middleware authenticates the user and parses the body. The handler validates again, because client checks are not trustworthy, then opens a database transaction. It writes the record, updates any related rows and commits, which is the point of no return. The server returns the created resource with a status code, and the client updates its cache and shows a confirmation. If any step fails, the transaction rolls back and the interface shows an error tied to the field that failed. I try to make the failure path as explicit as the success path.

When I am the only developer I am also the future maintainer, so I optimize for the version of me who returns in six months. I keep a sharp boundary between client and server code, usually a shared types package so the API contract is checked at compile time. I write short decision records for anything surprising, like why a table is denormalized or why a job runs at a fixed hour. I put linting, type checks and tests in CI so I cannot skip them when I am in a hurry, which is exactly when I would. I resist adding a library for every problem, because each dependency is a future upgrade. Finally I keep a README that brings up a new environment in one command, because a broken setup is the most expensive kind of rot.

I design the data shape and the API contract first, because everything else depends on them and changing them later is the most expensive kind of rework. I ship the server change behind a flag or as an additive endpoint, and I verify it with tests and a manual call before any UI exists. Then I build the interface against the real contract rather than a mock, since a mock hides serialization problems. I keep the old code path intact until the new one is proven, so rollout is a flag flip rather than a risky deploy. For anything user-visible I release to a small percentage first and watch error rates and the specific metric the feature is meant to move. The entire sequence is designed so any step can be reverted without a database rollback.

For a traditional web app I prefer server-managed sessions in an HttpOnly, Secure, SameSite cookie, because JavaScript cannot read the cookie and the browser handles expiry. For a mobile client or a public API I use short-lived access tokens with a refresh flow. In both cases the server is the only authority: hiding a button in the UI is a convenience, not a permission check, so every protected route re-verifies the session or token. I handle refresh on the client with a single-flight mechanism so ten parallel requests do not trigger ten refreshes. Logout invalidates the server-side session or revokes the refresh token, rather than only deleting local storage. I also make sure errors do not reveal whether an account exists, since that turns a login form into a user enumeration tool.

Production-only bugs are usually data, configuration or timing, so I start by narrowing which of those it is. I collect the affected user identifiers, device and approximate time, then look at request logs, the error tracker and the database state for that specific account. If it works for most users, the difference is usually in the data: a null field, a very long string, a timezone, or a record a migration missed. If it works in staging but not production, I compare environment variables, feature flags and third-party credentials, because a missing key is a common cause. Once I have a hypothesis I add temporary logging at the boundary and observe the real request. After the fix I add a regression test at the lowest layer that can catch it.

I estimate the full cost of building, not just the first version: ongoing maintenance, edge cases and the on-call surface it creates. If the feature is core to the product, like the pricing engine, I build it because I need control. If it is commodity infrastructure that many companies solve the same way, such as transactional email, payments or search, buying is usually cheaper and better tested than anything I would write. I then check the constraints that are easy to miss: where the data is stored, whether the contract allows my use case, and what the bill looks like at ten times the volume. I always ask about the exit path, because a cheap integration with no route out is an expensive decision. Finally I build a small prototype against the real API before committing, because documentation and reality often differ.

I put the contract in one authoritative place, either an OpenAPI schema or a shared TypeScript types package, and I generate or validate both the client and the server against it. That way a field rename becomes a compile error instead of a runtime surprise in production. I also add a contract test in CI that calls the real endpoint and validates the response shape, because generated types only go as far as the code that uses them. For breaking changes I add a new version or a new field rather than mutating the existing one, and I announce a deprecation window. The practice that keeps this alive is treating the contract as a product surface with its own review, not as an implementation detail either side can change unilaterally.

We needed a real-time notification feature, and I had never worked with WebSockets at scale. I started by reading the protocol basics, then built the smallest possible prototype to learn where the hard parts were: connection lifecycle, reconnection and fan-out across multiple servers. That prototype told me which part I could own, the server-side connection registry, and which part I needed help with, namely the load balancer and sticky-session configuration. I asked a platform engineer for a short pairing session instead of trying to reverse-engineer it from documentation, which saved several days. The feature shipped and held under a few thousand concurrent connections. What I retained was a working model of the failure modes, which is why I could debug it later without help.

Lead with the delivered feature and mention the layers inside it, so the reader sees one story instead of two unrelated skill lists.

Name what stayed stable, such as URLs, analytics events or the public API, because that stability is what makes a migration credible.

Show at least one test type per layer you claim, from unit tests on business rules to an end-to-end journey, since breadth without tests reads as prototype work.