Interview Prep

Appearance

Optional topics — cheat sheet ​

Optional in the roadmap, but worth having a one-liner ready for each — a mock interview can easily poke at these even if they weren't the main focus. Source: roadmap.md section "Optional Topics".

General programming knowledge ​

  • Java generics: let you parameterize a class/method by type (List<T>), giving compile-time type safety and reusable code without casts. E.g. a generic filter(List<T> list, Predicate<T> test) works for any T.
  • Concurrency:
    • Thread: an independent path of execution within a process; lets a program do multiple things without one blocking task freezing everything else.
    • Process vs thread: a process is an isolated running program with its own memory; threads run inside a process and share its memory.
    • Creating a thread in Java: extend Thread, implement Runnable, or (preferred) submit work to an ExecutorService / use CompletableFuture.
    • Sync vs async HTTP request: synchronous blocks the caller until the response arrives; asynchronous returns immediately and the response is handled later (callback/future). Async avoids tying up a thread waiting on I/O — better throughput.
    • RestTemplate/TestRestTemplate calls are synchronous/blocking by default.
    • Concurrency vs parallelism: concurrency is dealing with multiple tasks making progress over overlapping time (not necessarily simultaneous, e.g. interleaved on one core); parallelism is literally running multiple tasks at the same instant (needs multiple cores).
  • More git:
    • Branch: a movable pointer to a commit, letting you develop features/fixes in isolation from main.
    • Create/rename/delete local: git branch <name>, git branch -m <old> <new>, git branch -d <name>.
    • Push/pull vs local: a local branch only exists on your machine; git push origin <branch> publishes it; git pull fetches + merges remote changes into your local one.
    • Merge: combines another branch's changes into yours (fast-forward, or a merge commit if histories diverged).
    • Rebase: replays your branch's commits on top of another branch's tip — rewrites history into a straight line, instead of merge's history-preserving merge commit.
    • Merge conflict: git can't auto-reconcile changes to the same lines/file; you edit the conflicted file(s) to the intended result, then stage and commit (or continue the rebase).
    • Pull/merge request (GitHub): a request to merge one branch into another with review/discussion/CI attached — created from a pushed branch via GitHub's UI or gh pr create.
  • CI/CD: Continuous Integration = automatically build/test every change (catch integration bugs early); Continuous Delivery/Deployment = automatically get that tested code ready for (or directly into) production. Point is catching problems earlier and shipping faster/more reliably.

More on databases/JPA ​

  • Normalization: structuring tables/columns to reduce redundancy and avoid update/insert/delete anomalies, typically by splitting data across related tables (1NF, 2NF, 3NF, ...).
  • SQL joins: combine rows from two+ tables via a related column.
    • INNER JOIN — only rows matching in both tables.
    • LEFT (OUTER) JOIN — all rows from the left table, matched rows from the right (else null).
    • RIGHT JOIN — mirror of left.
    • FULL OUTER JOIN — all rows from both sides, matched where possible.
    • Useful any time you need data spanning multiple related tables in one query (e.g. posts with their author's name).
  • ACID: Atomicity (a transaction is all-or-nothing), Consistency (a transaction takes the DB from one valid state to another, respecting constraints), Isolation (concurrent transactions behave as if run one at a time), Durability (once committed, data survives a crash).
  • NoSQL: non-relational databases in various shapes (document/key-value/wide-column/ graph). E.g. MongoDB stores JSON-like documents instead of fixed-schema table rows — more schema flexibility, different consistency/relational trade-offs.
  • @OneToMany/@ManyToMany in JPA: relationship annotations mapped to a foreign key (@OneToMany) or a join table (@ManyToMany, via @JoinTable, which names the join table and its two foreign key columns).
    • @ManyToMany(fetch = FetchType.EAGER) means the related collection is always loaded together with the owning entity, even when not accessed — can hurt performance for large collections, hence LAZY being the default here.

Security ​

  • Authentication vs authorization: authentication = verifying who you are (login, credentials); authorization = verifying what you're allowed to do (roles/permissions), and happens after authentication.
  • HTTP Basic Auth: username:password sent base64-encoded in the Authorization header on every request. In Postman: the "Basic Auth" tab sets this header for you.
  • Spring Security basics:
    • @Configuration — marks a class as a source of bean definitions (Java-based config).
    • @Bean — marks a method whose return value gets registered as a bean.
    • SecurityFilterChain — the chain of servlet filters Spring Security runs on every request to handle authentication/authorization/CSRF/etc.; you define it to say which endpoints need auth, which are public, and how (basic auth, form login, ...).
    • Excluding endpoints: matcher rules in that config, e.g. .requestMatchers("/public/**").permitAll().
    • PasswordEncoder: hashes passwords before storing (e.g. BCryptPasswordEncoder) and verifies login input against the hash — plaintext passwords should never be stored.
    • UserDetailsService: an interface Spring Security calls to load a user's username/password-hash/roles during login; you implement it to plug in your own user store (in-memory or DB-backed).
    • Roles: labels (e.g. ROLE_ADMIN) attached to a user, used to gate access to specific endpoints/methods.
    • @EnableGlobalMethodSecurity(securedEnabled = true) + @Secured("ROLE_ADMIN"): enables and applies method-level security so individual service/controller methods can restrict who can call them.
    • Excluding security from unit tests: either mock the security beans (@MockBean) or swap in a simplified test security config via @Profile/@ActiveProfiles.
  • Spring Security + database:
    • Implement UserDetailsService backed by a JPA repository to store credentials/roles in the DB.
    • Keep a separate class implementing UserDetails, rather than having the @Entity User implement it directly — the persistence model shouldn't have to satisfy an unrelated framework contract just because Spring Security needs it.
    • Use @JsonIgnore or @JsonProperty(access = JsonProperty.Access.WRITE_ONLY) on the password field so it's never serialized back out in API responses.
  • Cookies: small pieces of data the server asks the browser to store and resend on later requests; a session cookie typically holds a session ID so the server can recognize a logged-in user across requests, since HTTP itself is stateless.
  • CORS: covered in 01-web-http.md.
  • CSRF: Cross-Site Request Forgery — tricking a logged-in user's browser into submitting an unwanted state-changing request to a site it's authenticated on (cookies get sent automatically). Defended against with CSRF tokens: a per-session/per-form secret an attacker can't know, required on state-changing requests.

Containerization ​

  • Docker: packages an app with all its dependencies into a portable, isolated container that runs the same way across environments.
  • WSL/WSL2 on Windows: Docker needs a Linux kernel; WSL2 provides a real lightweight Linux VM on Windows, so Docker runs containers with near-native performance (vs the older, slower approach).
  • Image vs container: an image is a read-only template (filesystem + config); a container is a running (or stopped) instance created from an image.
  • docker ps — running containers. docker ps -a — all containers, including stopped.
  • docker run <image> — create + start a container from an image. docker stop / docker rm — stop/delete a container. docker rmi — delete an image.
  • Dockerfile: a text file of instructions (base image, copy files, install deps, entrypoint) describing how to build an image.
  • Docker Compose: defines and runs a multi-container app (e.g. app + DB) together, via a docker-compose.yml.
  • Kubernetes: a container orchestration platform that deploys, scales, and manages many containers across a cluster automatically (restarts, load balancing, autoscaling).

DevOps basics ​

  • AWS/GCP/Azure: cloud providers renting compute/storage/networking on demand, billed by usage. Vs buying and managing your own server: elastic scaling, no hardware upkeep, pay-as-you-go — at the cost of ongoing fees and some vendor lock-in.
  • EC2 (AWS virtual machines), S3 (AWS object/file storage), Route53 (AWS DNS). Rough equivalents: GCP Compute Engine / Cloud Storage / Cloud DNS; Azure VMs / Blob Storage / Azure DNS.
  • CDN: a geographically distributed network of servers caching static content close to users, cutting latency and origin load. Examples: Cloudflare, Amazon CloudFront, Akamai.
  • Infrastructure as Code: defining/managing infrastructure through versioned config files instead of manual console clicks — reproducible, reviewable, automatable. Tools: Terraform (cloud-agnostic provisioning), Ansible/Chef/Puppet (configuring existing servers).

More frontend ​

This part of the roadmap is "go learn more", not Q&A: TypeScript (typed JS, learn it and you get JS along the way), deeper CSS (try recreating an existing design pixel-for-pixel), and a frontend framework (React is the recommended starting point). Worth doing if a target role leans full-stack, otherwise lower priority than the backend fundamentals above.