Capstone Do this the day before an interview

Interview Capstone

Thirteen lessons of knowledge is worth nothing if it doesn't come out of your mouth under pressure. This page is drills, not reading. Every section asks you to speak first and compare afterwards.

1. The 90-second pitch

The first question is always some version of "tell me about this project." You get roughly ninety seconds before they decide whether to dig in. Structure it: problem → what it does → stack → the hardest part → hook.

Drill 1
Say the pitch out loud. Target: 90 seconds.
1:30

"Studily is a study planner for university students. The problem it solves is sprawl — your calendar app knows when your classes are but nothing about what's due, your notes doc has the assignments but won't remind you, and your group chat has your classmates but isn't attached to any course.

You enter your courses once and it becomes a weekly schedule, a calendar of assignments and exams with grade tracking, flashcards with spaced repetition, a Pomodoro timer, and real-time messaging with classmates it finds automatically by matching normalised course codes at your school. It imports from Canvas and any iCalendar feed, and it installs as a PWA with push notifications.

It's Spring Boot and Postgres on the backend, React and TypeScript on the front, shipping as a single Docker image so there's one origin and no CORS in production. Twenty-eight Flyway migrations, about 190 tests.

The part I found most interesting was calendar import — taking a URL from a user and fetching it server-side is server-side request forgery by construction, so I had to build the whole defence stack around it. Happy to go into that, or into how I handle real-time messaging, whichever's more useful."

The hook is the last sentence

Ending with two options hands them a steering wheel and guarantees the conversation goes somewhere you've prepared. Never end a pitch on a full stop — end it on an offer.

2. The architecture whiteboard

"Draw me your architecture." Draw this, in this order, narrating as you go. Boxes and arrows, nothing fancy. 

   Browser / installed PWA
        │  HTTPS, Bearer JWT              ┌──────────────┐
        │  WebSocket (subprotocol auth) ──┤ service      │
        ▼                                 │ worker: push │
   ┌─────────────────────────────────┐    └──────────────┘
   │  ONE Docker image on Railway    │
   │                                 │
   │  React SPA  (static resources)  │  ← same origin: no CORS in prod
   │  ───────────────────────────    │
   │  Filter chain                   │  ← rate limit → JWT auth → rate limit → verify
   │  Controllers  (HTTP only)       │
   │  Services     (rules, @Transactional, ownership)
   │  Repositories (Spring Data)     │
   └─────────────┬───────────────────┘
                 │ JDBC
                 ▼
          ┌─────────────┐        ┌──────────┐   ┌────────┐
          │ PostgreSQL  │        │ Resend   │   │ Sentry │
          │ 28 Flyway   │        │ (email)  │   │ errors │
          │ migrations  │        └──────────┘   └────────┘
          └─────────────┘
Drill 2

Draw it from memory on paper. Then check: did you include the filter chain, the layer split, and the fact that it's one image?

Those three are what make it an architecture diagram rather than a box labelled "backend".

3. The endpoint walkthrough

The single highest-value drill in this entire study set. Pick an endpoint and narrate its full lifecycle, naming what can reject it at each stage.

The classic
POST /api/flashcard-sets/{id}/cards/{cardId}/review

Filter chain → ownership check → SM-2 → dirty checking → commit → React Query invalidation.

The hard one
POST /api/canvas/feed

Rate limit → SSRF-guarded fetch → line unfolding → RRULE expansion → course matching ladder → external_uid upsert → counters. Touches every layer.

Drill 3
Narrate POST /api/todos. Target: under 3 minutes.
3:00

Tick each stage off as you say it. If you miss more than two, reread lesson 02.

0 of 12 stages

4. Twenty-four likely questions

Grouped by what they're probing. Answer out loud before opening any of them. The answers are compressed — you're checking that you hit the same beats, not memorising wording.

5. On your resume

A resume bullet should carry a technical noun and an outcome. "Built a study app with React" carries neither.

Draft bullets — pick three or four
Rule

Never put a term on your resume you can't discuss for two minutes. Every noun above is a thing an interviewer may ask you to explain — and every one is covered in a lesson here. If a bullet makes you nervous, cut it.

6. Things that read badly

AVOID
  • "It's secure." — nothing is; name your residual risks
  • "There aren't really any trade-offs."
  • Claiming a technology you can't explain
  • Blaming a framework for your own design
  • Listing eight of your own bugs unprompted
  • "I'd rewrite it in <language>" as an answer to anything
DO
  • Say "I don't know" then reason out loud from what you do
  • Name the alternative you rejected
  • Give the condition that would change your mind
  • Volunteer one or two defects, with mechanism and fix
  • Ask which direction they'd find most useful
  • Use concrete numbers: 28 migrations, 61 queries, 200-row cap
The single most useful sentence

"I don't know, but here's how I'd find out." Interviewers hire people who can make progress on unfamiliar problems. Confident wrongness is the thing that actually fails interviews — not gaps.

7. Final mixed quiz

Twelve questions drawn from across all thirteen lessons. No warnings, no grouping by topic — the way it comes at you in a real conversation.

Keep the flashcard deck warm in the days before an interview — ten minutes a day beats an hour the night before.

Flashcard review → Back to the hub