Full Stack Developer

How the web works Core

Every feature you build crosses the network. A browser resolves a domain to an IP address through DNS, opens a TCP connection, sets up TLS for HTTPS, and sends an HTTP request with a method, path, headers and maybe a body. The server returns a status code, headers and a body. Learn the methods (GET, POST, PUT, PATCH, DELETE), the status classes (2xx, 3xx, 4xx, 5xx), and the headers you will meet daily: Content-Type, Authorization, Cookie, Set-Cookie and Cache-Control.

A full stack developer sees both ends of every request, so this model is how you debug: is the bug in the browser, the network, the API or the database?

Practice. Use the browser network panel and curl to make the same API request, and compare the headers each sends.

HTML Core

HTML gives a page its structure and meaning. Use semantic elements: header, nav, main, article, footer, headings in order, lists, and table for tabular data. Use button for actions and links for navigation. Forms need labels tied to inputs, the right input types and autocomplete attributes.

Good HTML gives you accessibility and search visibility for free and makes your React components simpler, because each element already has the right behaviour. Many full stack developers neglect this layer; interviewers notice when a candidate builds a clickable div.

Practice. Build a three-page static site with a contact form using only semantic HTML, and navigate it by keyboard.

CSS and Tailwind CSS Core

Learn the box model, the cascade and specificity, Flexbox for one-direction layouts and Grid for two-dimensional ones, and responsive design with mobile-first media queries and relative units. Custom properties hold colours and spacing so themes are easy to change.

Tailwind CSS is a utility-first framework that many full stack teams use because it is fast to work with and keeps styles next to markup. Each class maps to one or two CSS declarations, such as flex, gap-4 or md:grid-cols-2. Learn plain CSS first so you understand what the utilities do, then use Tailwind to move quickly. The CSS Roadmap goes deeper into layout and the cascade.

Practice. Build a responsive pricing page twice, once in plain CSS and once in Tailwind CSS, and compare the result.

JavaScript Core

JavaScript runs in the browser and, through Node.js, on the server, which is why it is the most common full stack language. Learn values and types, let and const, functions and arrow functions, objects and arrays, destructuring and spread, modules with import and export, and the array methods map, filter, reduce and find.

Then learn closures, the meaning of this, classes, error handling with try and catch, and the DOM: selecting elements, handling events and updating content safely with textContent. The JavaScript Roadmap covers the language in depth.

Practice. Build an interactive to-do list in plain JavaScript that saves items to localStorage.

Asynchronous code and the event loop Core

Both browsers and Node.js run JavaScript on a single main thread. Slow work such as network calls, timers and file reads happens outside it, and callbacks are queued to run later. The event loop runs one task at a time and drains the microtask queue (promise callbacks) after each task.

Write async code with promises and async/await. Run independent requests in parallel with Promise.all instead of awaiting them one by one, handle rejections, and add timeouts and cancellation with AbortController. On the server the same rule applies: never block the thread with heavy synchronous work, or every user waits.

Practice. Write a script that calls three APIs in parallel with a timeout and logs which ones failed.

Git and GitHub Core

Git tracks every change to your code. Learn to commit small, focused changes with clear messages, create branches, merge and rebase, resolve conflicts, undo mistakes with revert and restore, and inspect history with log and blame.

GitHub hosts repositories and adds pull requests, code review, issues and GitHub Actions for automation. Most teams work on short-lived branches merged through reviewed pull requests with required checks. Your GitHub profile is part of your application, so keep projects tidy with clear READMEs. The Git and GitHub Roadmap covers branching strategies and advanced Git.

Practice. Contribute a small fix to a friend's repository through a fork, a branch and a pull request.

Linux / Unix and the command line Core

Servers almost always run Linux, and full stack developers touch them for deployment, debugging and scripting. Learn to move around the file system, read and edit files, use pipes and redirection, search with grep and find, and check processes, ports and disk with ps, top, ss and df.

Understand users, groups and file permissions, environment variables, package managers such as apt, SSH with key pairs, and how services are started and restarted with systemd. Being comfortable in a Linux/Unix shell makes everything later, from Docker to cloud servers, much easier.

Practice. Set up a small Linux virtual machine, log in over SSH with a key, and find which process is listening on port 80.

npm and front end tooling Core

npm installs packages from the registry and runs scripts defined in package.json. Learn dependencies versus devDependencies, semantic version ranges, and why the lock file must be committed. pnpm and Yarn are alternatives with the same ideas.

Modern projects use Vite or a framework's own tooling to run a dev server with hot reloading and to build optimised bundles. Add ESLint to catch bugs and Prettier or Biome to format code automatically, and run both in CI. Before adding a package, check its size, maintenance and licence, because every dependency is code you now ship and must keep updated.

Practice. Create a Vite React project with ESLint and Prettier configured, and add an npm script that runs both.

TypeScript Core

TypeScript adds static types to JavaScript and is now standard in full stack work. Its biggest benefit for full stack developers is sharing types across the boundary: the same Order type describes the database row, the API response and the React props, so a change in one place surfaces errors everywhere.

Learn type annotations, interfaces and type aliases, unions and narrowing, generics, and utility types such as Partial and Pick. Turn on strict. Types disappear at runtime, so validate incoming data at the edges with a schema library such as Zod and infer types from the schema. The TypeScript Roadmap covers advanced types.

Practice. Define a Zod schema for an API payload, infer its TypeScript type and use it on both client and server.

React Core

React builds interfaces from components: functions that take props and return JSX. Learn useState for local state, useEffect for syncing with outside systems, useRef, useContext, and useMemo and useCallback for caching. Lists need stable keys. Prefer deriving values during render to copying them into state.

Think in components: split a screen into small pieces with clear props, lift shared state to the nearest common parent, and compose with children. Most full stack interviews include building or extending a small React feature, so practise until the basics are automatic. The React Roadmap covers hooks and patterns in depth.

Practice. Build a filterable, sortable table of products from a JSON file using only derived state.

Data fetching and state on the client Core

Every screen that loads data has four states: loading, empty, error and success; handle each one. Data from the server is best managed with a server-state library such as TanStack Query or SWR, which caches responses, deduplicates requests, refetches stale data and makes invalidation after a mutation simple.

Keep other state where it belongs: local state in components, filters and pagination in the URL, and only truly global values such as the current user in context or a small store. Optimistic updates show a change immediately and roll back if the server rejects it, which makes apps feel fast.

Practice. Build a comments list that loads with TanStack Query and adds comments optimistically with rollback on error.

Routing, forms and accessible UI Core

Single-page apps change views by updating the URL with client-side routing, for example with React Router; meta-frameworks such as Next.js use file-based routes. Learn nested layouts, route parameters, protected routes and lazy loading.

Forms are the heart of most business apps. Use labelled inputs, clear inline errors, schema validation shared with the server, and protection against double submission. A form library such as React Hook Form keeps large forms fast. Make every control keyboard accessible with visible focus, enough colour contrast and responsive layouts that work on a phone.

Practice. Build a sign-up and profile-edit flow with shared validation, routing between pages and full keyboard support.

Node.js Core

Node.js runs JavaScript outside the browser using the V8 engine and an event loop backed by libuv. It handles many concurrent connections well because I/O is non-blocking, which suits APIs that mostly wait on databases and other services. It is a poor fit for heavy CPU work on the main thread; move that to worker threads, a queue or another service.

Learn the module system (ES modules and CommonJS), the built-in modules for files, paths, streams and HTTP, environment variables through process.env, and how to handle errors so one bad request cannot crash the process. The Node.js Roadmap covers the runtime in depth.

Practice. Write a Node.js script that streams a large CSV file line by line and counts rows without loading it into memory.

HTTP servers and frameworks Core

You can build a server with the built-in http module, but teams use frameworks. Express is the long-standing minimal choice with a huge middleware ecosystem. Fastify is faster and has schema-based validation built in. NestJS adds structure with modules, controllers and dependency injection, popular in larger teams. Hono is small and runs on Node.js, Bun and edge runtimes.

The core ideas are the same: routes map methods and paths to handlers, middleware runs before handlers for logging, authentication and parsing, and errors flow to a central handler. Structure code in layers (routes, services, data access) so business logic does not depend on the framework.

Practice. Build the same small API in Express and Fastify, each with logging middleware and a central error handler.

REST API design Core

REST models your API as resources addressed by URLs and manipulated with HTTP methods. Use plural nouns (/orders, /orders/42), the right methods, and accurate status codes: 201 for created, 204 for no content, 400 for invalid input, 401 for unauthenticated, 403 for forbidden, 404, 409 for conflicts and 422 for validation failures where your team uses it.

Design for clients: consistent JSON shapes, a standard error format, cursor pagination for long lists, filtering and sorting through query parameters, idempotency keys for payments and retries, and versioning when breaking changes are unavoidable. Document the API with OpenAPI. The API Design Roadmap covers this in depth.

Practice. Write an OpenAPI description for a small blog API, then implement it and check responses against the spec.

Validation and error handling Core

Never trust input. Validate every request body, query string and header at the edge of your API with a schema, and return clear 4xx errors that say which field is wrong. Normalise data (trim strings, parse dates) once, at the boundary.

Separate expected errors, such as "email already taken", from unexpected ones, such as a database outage. Expected errors map to specific status codes and messages. Unexpected errors return a generic 500 to the client while the full details, including a request ID, go to your logs. Never leak stack traces or SQL errors to users, because they reveal internals to attackers.

Practice. Add schema validation and a central error handler to your API that returns a consistent JSON error shape.

Background jobs, queues and scheduled tasks Recommended

Some work should not happen inside an HTTP request: sending emails, resizing images, generating reports or calling slow third-party services. Put it on a queue and let a worker process handle it. In Node.js, BullMQ on Redis is a common choice; cloud queues such as Amazon SQS work the same way.

Design jobs to be idempotent, because they may run more than once. Add retries with backoff, a dead-letter queue for jobs that keep failing, and monitoring of queue length. Scheduled tasks, such as nightly clean-ups, can use cron-style schedulers, but make sure only one instance runs each job.

Practice. Move sending a welcome email out of the sign-up request into a queued job with three retries.

Real-time features: WebSockets and server-sent events Recommended

Chat, notifications, live dashboards and collaborative editing need the server to push data. WebSockets give a two-way, long-lived connection. Server-sent events stream one-way updates over plain HTTP and reconnect automatically, which is simpler when only the server sends. Polling still works for low-frequency updates.

Real-time features complicate scaling: each server only knows its own connections, so use a shared channel such as Redis pub/sub to broadcast between instances. Authenticate connections, handle reconnects and missed messages, and limit how much each client can send.

Practice. Add live notifications to an app with server-sent events, and make them work across two server instances using Redis.

Relational data modelling Core

Most full stack apps store their core data in a relational database. Model entities as tables with a primary key, connect them with foreign keys, and choose the right relationship: one-to-many (a user has many orders) or many-to-many through a join table (orders and products through order items). Normalise to avoid storing the same fact twice, then denormalise deliberately where reads need it.

Use constraints to protect data: NOT NULL, UNIQUE, CHECK and foreign keys. The database is the last line of defence when application code has a bug. Draw an entity diagram before writing code; interviewers often start a design round this way.

Practice. Design the schema for a course platform with users, courses, lessons and enrolments, including all constraints.

SQL Core

SQL is how you read and change relational data. Learn SELECT with WHERE, ORDER BY and LIMIT; joins (inner, left and when each drops rows); GROUP BY with aggregates and HAVING; subqueries and common table expressions; window functions such as ROW_NUMBER; and INSERT, UPDATE, DELETE and upserts.

Always use parameterised queries, never string concatenation, to prevent SQL injection. Watch for NULL behaviour and join fan-out that duplicates rows. Full stack interviews regularly include a SQL question, such as "top three customers by spend this month". The SQL Roadmap covers the language in depth.

Practice. Write ten queries against your course schema, including one with a window function and one with a CTE.

PostgreSQL Core

PostgreSQL is the most common open-source relational database for new products. Beyond standard SQL it offers JSONB columns for semi-structured data, full-text search, arrays, generated columns, row-level security and many extensions.

Learn the operational basics: indexes (B-tree by default, GIN for JSONB and full-text), reading EXPLAIN ANALYZE output to see whether a query uses an index, transactions and isolation levels, and connection pooling, because each connection uses server memory. Serverless functions can exhaust connections quickly, so use a pooler such as PgBouncer or a provider's pooled endpoint. Back up regularly and test restores.

Practice. Load a million rows into PostgreSQL, time a filtered query, add the right index and compare EXPLAIN ANALYZE before and after.

Transactions, indexes and concurrency Core

A transaction groups statements so they all succeed or all fail. ACID describes the guarantees: atomicity, consistency, isolation and durability. Concurrency bugs appear when two requests read and write the same data at once, such as two users booking the last seat. Fix them with a unique constraint, a conditional update (UPDATE ... WHERE seats_left > 0), row locks with SELECT ... FOR UPDATE, or a stricter isolation level.

Indexes speed up reads but slow writes and use space. A composite index on (user_id, created_at) helps queries filtering by user and sorting by date, but not queries filtering only by date. Index the columns your real queries filter and join on.

Practice. Simulate two concurrent bookings for the last seat and prevent overselling with a conditional update.

ORMs, query builders and migrations Core

Most Node.js teams access the database through a library. ORMs such as Prisma generate a typed client from a schema file. Drizzle and Kysely are type-safe query builders that stay close to SQL. TypeORM and Sequelize are older ORMs you will still find in existing code. Whatever you use, learn to read the SQL it generates.

The N+1 problem is the classic ORM mistake: loading a list, then running one query per item for related data. Fix it with joins or batched loading. Schema changes go through migrations, versioned files committed with the code and applied automatically in deployment. Make migrations backwards compatible so old and new code can run during a release.

Practice. Find and fix an N+1 query in an ORM-based endpoint, and measure the query count before and after.

Redis Core

Redis is an in-memory data store used for caching, sessions, rate limiting, queues, leaderboards and pub/sub. Its data types include strings, hashes, lists, sets, sorted sets and streams, and keys can expire automatically.

The most common pattern is cache-aside: read from Redis, and on a miss read from the database and store the result with a time-to-live. The hard part is invalidation: delete or update the cached value when the data changes, and protect against stampedes, where many requests miss at once and overload the database. Redis is not a primary store for data you cannot lose unless configured carefully for persistence.

Practice. Add cache-aside caching with a TTL to a slow endpoint, invalidate it on update, and add a Redis-based rate limiter.

NoSQL and choosing a database Optional

Document databases such as MongoDB store JSON-like documents with flexible schemas, which suits data that varies per record or is read as a whole. Key-value stores, wide-column stores and search engines such as Elasticsearch solve other specific problems. Vector databases, or the pgvector extension in PostgreSQL, store embeddings for AI search features.

For most full stack products, start with PostgreSQL: it handles relational data, JSON and full-text search well. Add a specialised store only when you have a clear need that PostgreSQL cannot meet. Be ready to explain this reasoning in interviews.

Practice. Store the same product catalogue in PostgreSQL and MongoDB and write a short comparison of queries and constraints.

Sessions, cookies and JWT Core

There are two main ways to remember a signed-in user. Server sessions store state on the server (often in Redis) and give the browser a random session ID in a cookie. They are easy to revoke. JWT (JSON Web Token) puts signed claims, such as the user ID and expiry, in a token the server can verify without a lookup. They suit stateless APIs and service-to-service calls but are hard to revoke before expiry.

For browser apps, keep the session ID or token in an HttpOnly, Secure, SameSite cookie so JavaScript cannot read it. If you use JWTs, keep access tokens short-lived, use refresh tokens with rotation, verify the signature and algorithm, and never put secrets in the payload, which is only encoded, not encrypted.

Practice. Implement login twice, with Redis sessions and with short-lived JWTs plus refresh tokens, and compare logout behaviour.

Passwords, OAuth and sign-in options Core

If you store passwords, hash them with a slow, salted algorithm designed for passwords, such as Argon2id or bcrypt, never with plain SHA-256 or reversible encryption. Add rate limiting on login, account lockout or delays, secure password reset links that expire, and multi-factor authentication for sensitive actions.

Many apps avoid storing passwords altogether. OAuth 2.0 with OpenID Connect lets users sign in with Google, GitHub or a company identity provider, using the authorisation code flow with PKCE. Passkeys use public-key cryptography and resist phishing. Auth libraries and hosted identity services save a lot of work; understand what they do even if you do not build it yourself.

Practice. Add sign-in with GitHub through OpenID Connect or OAuth to an app, alongside email and password with Argon2id.

Authorisation and multi-tenancy Core

Authentication says who you are; authorisation says what you may do. Broken access control is one of the most common serious flaws: an API that returns /invoices/123 to any logged-in user, without checking the invoice belongs to them. Check ownership or permission on every request, on the server, in one consistent place.

With role-based access control, each role such as admin, editor or viewer carries a fixed set of permissions. Attribute-based rules add conditions such as team or region. In multi-tenant SaaS, every query must be scoped to the tenant; PostgreSQL row-level security can enforce this as a second layer. Write tests that try to access another user's data.

Practice. Add roles and per-tenant scoping to an API and write tests proving one tenant cannot read another's records.

Web security for full stack apps Core

Learn the main attacks and their defences. SQL injection: always use parameterised queries. Cross-site scripting: let the framework escape output, sanitise any HTML you render, and add a Content Security Policy. Cross-site request forgery: use SameSite cookies and CSRF tokens for cookie-authenticated forms. Server-side request forgery: never fetch arbitrary URLs supplied by users without an allow list.

CORS is a browser rule controlling which origins may read your API responses; configure it narrowly, and remember it does not protect your API from non-browser clients. Also apply rate limiting, security headers, dependency audits and the principle of least privilege for database users. The OWASP Top Ten is a good checklist.

Practice. Run a dependency audit and a security header scan on your app, and fix every high-severity finding.

Secrets and configuration Recommended

Configuration that changes between environments, such as database URLs, API keys and feature flags, belongs in environment variables or a secrets manager, never in the repository. Commit a .env.example with placeholder names, and add .env to .gitignore.

In production, use the platform's secret store or a service such as AWS Secrets Manager or Parameter Store, grant each service only the secrets it needs, and rotate keys regularly. Remember that anything sent to the browser is public: front end environment variables in Next.js or Vite are bundled into client code, so only expose values meant to be public.

Practice. Move all secrets in a project into environment variables, add secret scanning to CI and rotate one key.

Next.js as a full stack framework Core

Next.js lets one codebase serve both the UI and the server logic. The App Router uses React Server Components, which run only on the server and can query the database directly; Client Components handle interactivity. Server Actions let a form call a server function without writing a separate API endpoint. Route handlers expose REST endpoints for mobile apps or third parties.

Learn where code runs, how to keep secrets out of client bundles, how caching and revalidation work, and how to handle loading and error states with layouts and Suspense. Many startups ship their whole product this way. The Next.js Roadmap covers the framework in depth.

Practice. Build a notes app in Next.js where a Server Component lists notes from PostgreSQL and a Server Action creates them.

Rendering strategies Core

Choose rendering per page. Client-side rendering builds the page in the browser, good for dashboards behind a login. Server-side rendering builds HTML per request, good for fresh, personalised or search-indexed pages. Static generation builds pages at deploy time, the fastest and cheapest option for content that rarely changes. Incremental regeneration refreshes static pages after a set time or on demand. Streaming sends the page shell first and fills in slow sections as data arrives.

Each choice moves cost between the browser, your servers and the CDN, and affects caching and SEO. Interviewers expect you to justify a choice for a given page.

Practice. Pick three pages of an app you know and write which rendering strategy each should use and why.

API styles: REST, GraphQL and RPC Recommended

REST is the default for public and general-purpose APIs because it is simple and works with HTTP caching. With GraphQL, the client names the fields it wants from a typed schema and gets them through one endpoint, which helps when many clients need different shapes of data; it adds complexity in caching, authorisation per field and query cost limits. RPC styles call named procedures: gRPC is common between back end services, and tRPC gives end-to-end types between a TypeScript server and client in the same repository.

Pick based on clients and team: a single web app in a monorepo might use tRPC or server actions, while a platform with partners needs a documented REST or GraphQL API.

Practice. Expose the same two operations through REST and tRPC, and compare the client code and type safety.

Project structure and monorepos Recommended

Full stack codebases grow quickly. Group code by feature rather than by technical type once the app is larger than a few screens, so everything about billing lives together. Keep business logic in plain functions or services that do not depend on the web framework, which makes them easy to test.

Monorepos hold the web app, API, shared types and UI library in one repository, managed with workspaces in npm, pnpm or Yarn and a build tool such as Turborepo or Nx that caches and runs tasks only for changed packages. Shared validation schemas and types are the main benefit for full stack teams.

Practice. Restructure a project into a pnpm workspace with web, api and shared packages, sharing one validation schema.

Architecture: monoliths, services and caching layers Recommended

Start with a well-structured monolith: one deployable app with clear internal modules. It is simpler to build, test, deploy and debug. Split out services only for clear reasons, such as very different scaling needs, separate teams or isolation of risky components. Microservices add network failures, distributed data and operational cost.

Know the layers where caching can happen: the browser, a CDN, the application (Redis or in memory) and the database's own cache. Each layer needs a plan for invalidation. Event-driven patterns, where services publish events to a queue, decouple work but make flows harder to trace.

Practice. Draw the architecture of an app you built, mark every cache layer and write how each is invalidated.

Testing strategy Core

Tests let you change code safely. A good mix has many fast unit tests for pure logic, a solid set of integration tests that exercise an API endpoint against a real database or a React component with mocked network calls, and a few end-to-end tests of critical journeys such as sign-up and checkout. Types and linting are the cheapest layer of all.

Test behaviour, not implementation details, so refactors do not break tests. Make tests deterministic: control time, random values and network responses. A flaky test that sometimes fails is worse than none, because people learn to ignore failures.

Practice. Write a test plan for one feature listing which checks belong at unit, integration and end-to-end level.

Unit and integration tests Core

Vitest and Jest run JavaScript and TypeScript tests with assertions, mocks and coverage. For the API, start the app in a test and send real HTTP requests with a library such as Supertest, against a real PostgreSQL database started in Docker or with Testcontainers. Reset data between tests with transactions or truncation. This catches SQL, migration and validation bugs that mocks hide.

On the front end, Testing Library renders components and finds elements by role and label, the way users do. Mock the network at the request level with Mock Service Worker so components use their real fetching code.

Practice. Write integration tests for a create-and-list endpoint against a PostgreSQL container, covering validation errors.

End-to-end tests Core

End-to-end tests run a real browser against the running app and database. Playwright is the common choice: it supports Chromium, Firefox and WebKit, waits for elements automatically and records traces for debugging. Cypress is another popular option.

Keep the suite small and focused on the journeys that make money or would be disastrous to break. Seed data through APIs or the database, not through the UI. Run the tests in CI against a fresh environment or preview deployment for each pull request.

Practice. Write Playwright tests for sign-up, login and creating a record, and run them in CI against a seeded database.

Code review and quality gates Recommended

Every change on a team goes through a pull request. Keep pull requests small and focused, with a description of why, screenshots for UI changes and notes on how you tested. As a reviewer, check correctness, security, data migrations and naming before style, and phrase comments as questions or suggestions.

Automate what machines can check: formatting, linting, type checking, tests and dependency audits run on every pull request, and branch protection blocks merging until they pass. AI review tools can flag likely bugs early but do not replace a human who understands the product.

Practice. Review a classmate's or open-source pull request and leave five specific, kind comments.

Deployment basics and hosting options Core

Deployment turns code in Git into a running service. Platforms such as Vercel and Netlify build front ends and serverless functions from each push with preview URLs. Render, Railway and Fly.io run long-lived Node.js servers, workers and managed databases with little configuration. Cloud providers such as AWS give full control and more responsibility.

Whatever the platform, learn the essentials: separate environments (development, staging, production), environment variables, database migrations as part of the release, health checks, zero-downtime rollouts, and a fast rollback. Start on a platform, then learn AWS so you understand what the platform does for you.

Practice. Deploy a full stack app with a managed PostgreSQL database to a platform, with a staging and a production environment.

Docker Core

Docker packages an app and its dependencies into an image that runs the same way on a laptop, in CI and in production. A Dockerfile lists the steps to build the image; a container is a running instance of it. Docker Compose starts several containers together, such as your API, PostgreSQL and Redis, for local development.

FROM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
CMD ["node", "dist/server.js"]

Multi-stage builds keep images small, and running as a non-root user limits damage. The Docker Roadmap covers images, networking and volumes.

Practice. Write a Docker Compose file that runs your API, PostgreSQL and Redis together with one command.

Checkpoint — CI / CD with GitHub Actions Core

Continuous integration runs checks on every push; continuous delivery deploys every change that passes. GitHub Actions defines workflows in YAML files under .github/workflows: triggers such as push and pull_request, jobs that run on hosted runners, and steps that install dependencies, lint, type check, test, build a Docker image and deploy.

Treat this as a checkpoint in your learning: by now every project should build, test and deploy automatically. Cache dependencies to keep pipelines fast, store credentials as encrypted secrets or use OIDC to assume a cloud role without long-lived keys, and require a manual approval before production if your team needs one.

Practice. Create a GitHub Actions pipeline that tests every pull request and deploys main to staging automatically.

Basic AWS Services Core

AWS is the largest cloud provider and appears in many full stack job posts. You do not need all of it. Learn IAM first: users, roles and policies, and the rule of least privilege. Then the core building blocks: EC2 for virtual servers, S3 for file storage, VPC for private networking, Route53 for DNS, SES for sending email, RDS for managed PostgreSQL, CloudFront as a CDN, and Lambda for serverless functions.

Also learn the AWS CLI, how billing works and how to set a budget alert on day one, because forgotten resources cost real money. Other clouds such as Google Cloud and Azure have equivalent services with different names.

Practice. Create an AWS account with a budget alert, an IAM user with limited rights, and deploy a static site to S3 behind CloudFront.

EC2 and VPC Recommended

EC2 gives you virtual machines. You choose an instance type (CPU and memory), an operating system image and storage, and connect with SSH or AWS Systems Manager. Security groups act as firewalls that allow traffic only on chosen ports from chosen sources.

A VPC is your private network in AWS. It is split into subnets across availability zones: public subnets for load balancers, private subnets for app servers and databases with no direct internet access. Route tables, an internet gateway and a NAT gateway control traffic. A typical web app puts an Application Load Balancer in public subnets, EC2 instances or containers in private ones, and RDS in private database subnets.

Practice. Build a VPC with public and private subnets, run your API on EC2 in a private subnet behind a load balancer.

S3, Route53 and SES Recommended

S3 stores files as objects in buckets. Use it for user uploads, static assets and backups. Keep buckets private and give browsers presigned URLs to upload or download directly, so large files never pass through your API servers. Lifecycle rules move old files to cheaper storage or delete them.

Route53 is AWS's DNS service: point your domain at a load balancer or CloudFront distribution with alias records, and use health checks for failover. SES sends transactional email such as password resets and receipts. You must verify your domain, set up SPF, DKIM and DMARC records so mail is not marked as spam, and handle bounces and complaints.

Practice. Add direct-to-S3 uploads with presigned URLs to your app, and send a verification email through SES from your own domain.

Terraform and infrastructure as code Recommended

Clicking through a cloud console does not scale and cannot be reviewed. Infrastructure as code describes resources in files kept in Git. Terraform is the most widely used tool: you write HCL describing resources such as a VPC, an RDS database and an S3 bucket, then terraform plan shows what would change and terraform apply carries it out. State records what exists; store it remotely with locking so teammates do not overwrite each other.

Use modules to reuse patterns, separate state per environment, and review plans in pull requests like code. OpenTofu is an open-source fork with the same language; AWS CDK and Pulumi let you write infrastructure in TypeScript.

Practice. Describe your S3 bucket, CloudFront distribution and Route53 record in Terraform, then destroy and recreate them.

Ansible, Monit and running servers Optional

When you run your own servers rather than containers on a managed platform, you need to configure them repeatably and keep processes alive. Ansible is a configuration management tool: playbooks written in YAML describe packages, files, users and services, and Ansible applies them over SSH to many servers. Running a playbook twice should change nothing the second time.

Monit is a small utility that watches processes, ports, files and disk space, restarts a crashed service and sends alerts. Many teams now use systemd for restarts and a monitoring service for alerts instead, but you may still meet Monit on older Linux servers. Process managers such as PM2 keep Node.js apps running and restart them on failure.

Practice. Write an Ansible playbook that installs Node.js, deploys your app as a systemd service and configures Monit to restart it.

Front end performance Core

Users feel performance in the browser. Core Web Vitals measure it: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. Common fixes are rendering important content on the server, splitting JavaScript by route, optimising images with modern formats and correct sizes, setting long cache lifetimes on hashed assets, and removing heavy third-party scripts.

Measure with Lighthouse and the browser Performance panel, then confirm with real user data after release. A full stack developer can also fix the cause on the server, such as a slow API response that delays the main content.

Practice. Measure Core Web Vitals for your app, fix the largest problem and record before and after numbers.

Back end and database performance Core

Most slow endpoints are slow because of the database. Log slow queries, read their EXPLAIN ANALYZE plans, add missing indexes, remove N+1 patterns, select only needed columns and paginate large results. Use connection pooling so the database is not overwhelmed by connections.

Then look at the application: run independent calls in parallel, cache expensive results in Redis, move slow work to background jobs and compress responses. Profile before changing code, and measure percentiles such as p95 and p99 latency, not only the average, because the slowest requests are what users complain about.

Practice. Profile your slowest endpoint, reduce its p95 latency by half and write down which change mattered most.

Scaling web applications Recommended

Scale vertically (a bigger machine) until it stops being simple, then horizontally (more machines behind a load balancer). Horizontal scaling needs stateless app servers: keep sessions in Redis or cookies, and files in S3, not on local disk. Put static assets and cacheable pages behind a CDN.

For the database, add read replicas for read-heavy loads, cache hot data, and only consider sharding when one primary truly cannot cope. Queues absorb spikes so a sudden burst of orders does not overload downstream services. Rate limiting protects the system from abusive or buggy clients.

Practice. Run two instances of your API behind a load balancer and prove sessions and uploads still work.

Observability: logs, metrics and traces Core

You cannot fix what you cannot see. Write structured logs in JSON with a request ID that follows the request across services. Collect metrics such as request rate, error rate and latency per endpoint, plus queue length and database connections. Distributed tracing, often with OpenTelemetry, shows where time goes across front end, API, database and third-party calls.

Front end error monitoring captures JavaScript exceptions with source maps. Set alerts on symptoms users feel, such as error rate or latency above a threshold, not on every CPU spike. Dashboards should answer "is the app healthy right now" at a glance.

Practice. Add structured logging with request IDs, an error rate metric and one alert to a deployed app.

Incidents and reliability Recommended

Things will break in production. When they do, the first job is to reduce user impact: roll back, disable a feature flag or scale up. Then find the root cause. Communicate status clearly to the team and affected users while you work.

After the incident, write a blameless review: timeline, impact, root cause and actions such as tests, alerts or design changes that stop it happening again. Prevent incidents with safe practices: small releases, feature flags, backwards-compatible migrations, health checks, automatic rollbacks and regular, tested database backups.

Practice. Run a game day: break one dependency on your staging app on purpose and practise detecting, mitigating and writing up the incident.

Data structures and algorithms Core

Many companies include a general coding round. Full stack candidates usually face easy to medium problems: arrays and strings, hash maps, two pointers, sliding windows, stacks and queues, recursion, trees and basic graph search. Explain your approach before coding, state time and space complexity, and test edge cases out loud.

Some companies prefer practical tasks instead, such as implementing a rate limiter, an LRU cache, pagination logic or a debounced search. Prepare both. Practise in coding practice and follow a structured plan of patterns rather than random problems.

Practice. Solve two problems a day for four weeks, including an LRU cache and a token-bucket rate limiter.

Full stack system design Core

Mid and senior candidates usually get a design round: a URL shortener, a booking system, a chat app, a file-sharing service or a job board. Use a steady structure: clarify requirements and scale, define the API, design the data model, sketch the architecture (client, CDN, load balancer, app servers, database, cache, queue, object storage), then go deep on the hardest part.

Full stack interviewers value end-to-end thinking: how the UI handles loading and failure, how pagination works from SQL to the screen, how uploads go straight to S3, and how concurrency is handled in the database. Practise with system design practice.

Practice. Design a ticket booking system in 45 minutes, covering the API, schema, double-booking prevention and the checkout UI.

AI-assisted development Recommended

AI coding assistants such as GitHub Copilot, Cursor and Claude Code can scaffold endpoints, write tests, explain unfamiliar code and refactor across many files. They are most useful when you give clear context and have tests to check their work.

Generated code often looks right and is subtly wrong: missing authorisation checks, SQL built from strings, unhandled errors or outdated APIs. Review every change as if a new teammate wrote it. Interviewers increasingly ask how you use these tools; a good answer shows speed with judgement, and a clear sense of what you would never accept without checking.

Practice. Use an AI assistant to add a feature with tests, then review the diff and list every issue you had to fix.

Building AI features into products Optional

Many full stack roles now include adding AI features: summarising, search over company documents, drafting replies or extracting data from uploads. The usual pattern is your server calling a model provider's API, never the browser holding the key. Stream responses to the UI for a responsive feel, store conversations, and enforce per-user rate limits and cost controls.

Retrieval-augmented generation stores embeddings of your documents, often in PostgreSQL with pgvector, finds relevant passages for each question and includes them in the prompt. Treat model output as untrusted input: validate structured output against a schema and never render it as raw HTML.

Practice. Add a "summarise this document" feature that streams the result to the UI and limits each user to ten calls a day.