Behavioral — your 7 stories, tailored
📖 Walk me through it — plain English
This lesson is not about code — it's about the talking half of an interview. A "behavioral" question is any prompt that starts with "Tell me about a time you…" — proud of a project, owned a hard call, hit a bug, disagreed with someone. The interviewer is checking how you think and work with others, not whether you can invert a binary tree. The core trick: you do not invent a fresh answer for each question on the spot. You prepare a small bank of real stories from your own work and reuse them, bending the same story to fit whatever angle they ask.
The frame for telling each story is STAR — four parts, in order. Situation = the backdrop in one or two sentences ("I was bombing the verbal part of mock interviews"). Task = what specifically you had to do ("ship a minimal v1 that proves the core experience"). Action = what you personally did and, crucially, why you chose it — this is where most of your words go. Result = the payoff and the lesson, delivered last as the punchline ("the verbal gap closed; I learned to ship the thin slice first"). Aim for about 3 minutes per story, with Action eating roughly two-thirds of it.
Everyday analogy: think of a chef with a few signature dishes. A good chef doesn't reinvent the menu for every customer — they keep five great dishes ready and plate them slightly differently depending on what the table wants tonight. "A project you're proud of" and "a hard decision you owned" can be the same dish (here, the SoloMock or all-in-one-URL story) garnished differently. STAR is just the standard plating order so every dish arrives looking deliberate instead of dumped on the plate.
How to use this page in the room:
- Pre-pick your stories. The page drafts 7 stories tied to your real projects (SoloMock, all-in-one-URL, the portfolio hydration bug, web-dev-tutorial, this guide). Know them cold so you're recalling, not inventing.
- Map question → story fast. Use the lookup table at the bottom: "Tell me about a failure" → the hydration-mismatch story; "Hardest technical problem" → all-in-one-URL architecture. That removes the panic of choosing under pressure.
- Spend your words on Action + why. Anyone can list what they built; the interesting part is the tradeoff you weighed and the call you made. Name what you cut, not just what you shipped.
- Land the lesson last. End each story with one sentence on what it taught you — that's what the interviewer actually remembers.
- Fill the one gap. The "disagreed with a teammate" story is flagged because your projects are solo — that's the one to draft yourself before any onsite, so you're not improvising the weakest answer live.
Why this works: behavioral rounds reward preparedness and self-awareness, and reuse buys you both. A handful of well-rehearsed STAR stories, each mapped to several possible questions, means you almost never get a question you can't answer with something true and concrete — and concrete beats generic every time.
Stop improvising. Reuse stories across questions. The drafts below are personalized to To Yin Yu using the projects in sts2/ and toyinyu.com — refine the wording in your voice before the interview.
tonyx1998.
Situation · Task · Action · Result. Spend most words on A. Result is the punchline; deliver it last. Target ~3 minutes total per story.
"I was solving LeetCode well on paper but bombing the verbal part of mock interviews. The gap was reps — scheduling friction with Pramp kept me from drilling. So I built SoloMock: an AI-driven mock interviewer that practices the verbal part the way LeetCode drills the written part."
"Ship a minimal v1 that proves the core experience — an AI interviewer that watches my code in real time, asks Socratic questions, and lets me practice solo whenever I want. A proof, not a product."
"The key design call was making the AI a real interviewer, not a helpful assistant — Socratic hints only, no praise, no spoilers. To make that work I structured each problem as a ProblemBrief — clarifying questions, hint ladder, edge cases, follow-ups — so behavior was content-driven, not ad-hoc prompt engineering. Stack: Next.js 15 + OpenAI Realtime API (the GA gpt-realtime model) over WebRTC, with Monaco editor streaming debounced snapshots over the data channel so the AI reacts to code in flight, not just speech. Auth is an email allowlist + a server route that mints an ephemeral client_secret so the browser never sees the long-lived OpenAI key. I deliberately skipped dashboards, multi-tenancy, and pricing — the core had to land first."
"I used it for weeks; the verbal-narration gap closed faster than any solo grind. The bigger takeaway — when I felt the urge to productize, I shipped a thin slice first. That's the instinct I'd bring to a team: ship the smallest thing that tests the hypothesis."
"I built all-in-one-URL — a URL shortener with QR/barcode generation and per-resource analytics. The defaulty thing to do as a solo dev is one Next.js app with a serverless DB. I chose differently: split FastAPI backend + React+Vite frontend + Postgres + Redis, on Render + Vercel + Neon + Upstash."
"Pick an architecture that actually exercises the production patterns I want on a resume — a real API surface, a real cache layer, a real deploy pipeline — not just one Vercel function."
"The tradeoff was deployment complexity vs. learning surface. I made the calls explicitly: FastAPI + Pydantic for the API because type-safe contracts plus auto-generated OpenAPI docs is the modern Python stack; Redis not as 'a cache' but for two specific jobs — rate limiting via slowapi and short-TTL caching of scraped titles for OG previews; Postgres with a normalized schema for the analytics rows since I wanted to do real SQL aggregates, not key-value. The frontend is React 19 with TanStack Query so server state and cache invalidation are first-class. The deploy story: push to main auto-deploys both halves; Render free tier spins down after idle but the cold-start cost was acceptable for a portfolio app. The architecture rationale lives in docs/STACK.md so a reviewer can read the why."
"App is live; I touched every layer I wanted to — async Python, cache invalidation, SQL aggregates, a real CI/CD path. The lesson: 'simpler' isn't always better when the goal is to learn. Naming the goal first changes the tradeoff."
"On my portfolio site — toyinyu.com, Next.js 16 with the App Router — the contact form was throwing React hydration errors in production. Worked perfectly on my machine. Classic 'works in dev' failure mode."
"Stop the recoverable errors and figure out the root cause, not just suppress the warning."
"First instinct was to blame my code — I'd seen hydration mismatches from Date.now() and Math.random() before. But the diff between server and client HTML showed extra data-* attributes I'd never added. The culprit was the user's browser — password managers and form-fill extensions inject DOM into form inputs before React hydrates. SSR shipped 'no inputs,' the extension added attributes, React saw a mismatch on hydration. The fix wasn't to fight the DOM — it was to make sure the form didn't exist in SSR at all. I dynamic-imported the ContactForm with ssr: false, so SSR HTML has zero inputs, the extension has nothing to inject into, and hydration is clean. I also moved the dark-mode setup off a FOUC script onto a cookie + server-set className, since React 19 warns louder about that pattern."
"Zero hydration errors in prod since. The takeaway: when a bug only reproduces in real environments, the diff between dev and prod is almost always the user — extensions, network, locale. Reading the actual diff between server HTML and client HTML pointed at the cause in minutes; blaming my code would have eaten a day."
SoloMock — drafted above. Punchline: "shipped the thin slice instead of productizing."
all-in-one-URL — drafted above. Or alternate: SoloMock's WebRTC + ephemeral key choice over simpler HTTP-polling audio.
personal-site hydration mismatch — drafted above. Alternate: any debugging story from the URL shortener's cache invalidation.
web-dev-tutorial — wrote a ~9,000-line Docusaurus guide covering 11 chapters of modern web dev (foundations → stack → workflows → AI integration → career). Frame it as: "I wanted to make legible the journey I'd just taken, so the next person could skip the wrong-tutorial-rabbit-hole stage." Result: a public guide at modernwebdevguide.com with search and Mermaid diagrams.
SoloMock's "no behavioral chit-chat, technical-focus only" decision — the conventional move for an interview app is friendly persona + small talk. You chose Socratic + code-watching + no praise. Why: the gap candidates have is verbal precision under pressure, not warmth. Frame as "I named the actual job-to-be-done instead of defaulting to the consumer-friendly shape."
this swe-interview-guide — could have been a React app with auth, sync, a backend. You chose a single self-contained HTML file with localStorage persistence. Result: deploys to GitHub Pages in one click; a single self-contained HTML file that anyone can fork and modify. Punchline: "the constraint forced clearer thinking about what the product actually was — a syllabus, not a SaaS." (Note: your default instinct is to under-engineer; interviewers asking "tell me about over-engineering" usually want the inverse — the lesson learned about scope. Spin accordingly.)
Gap to fill. Your projects so far are solo, so you don't have a clean version of this yet. Options: (1) a UMD group project where you pushed back on a tech choice; (2) a side-project collaboration; (3) reframe as "disagreed with prevailing convention" — picking single-file HTML for this guide vs. the React default. If you have any real team disagreement story, even small, that's preferred over the reframe. Draft this one yourself before any onsite.
AI-native loops (Anthropic, Sierra, Decagon, Cursor, founding-eng) ask these constantly. Each has a right and wrong shape — bullet-points below are the angle to draft before the onsite.
SoloMock — when the Realtime model started over-praising candidates (drift after a model update). You traced it to the system prompt + few-shot exemplars no longer matching the new model's default tone. Fix wasn't "be more strict" — it was adding 3 explicit do-not-do exemplars + tightening the persona. Lesson: LLM bugs live in the prompt-as-spec, not in the code path.
SoloMock — moving "stay silent for 3 seconds after the candidate stops talking" from the system prompt into the turn-detection config on the Realtime API. Same intent, different layer, fixed the over-interruption problem the prompt alone couldn't. Lesson: the right fix is sometimes one layer below the prompt.
all-in-one-URL architecture decisions — stack choice (split FastAPI + React, why Redis, why Postgres) is a judgment call across constraints, not a generation task. You asked Claude to enumerate options but did the weighing yourself. Or: not using an LLM for the URL-slug generator (a deterministic 7-char base62 hash is the right answer; LLM is the wrong tool). Lesson: LLMs are great at suggestion, weaker at multi-constraint judgment.
SoloMock's grading is itself the eval design — how do you grade "verbal precision" objectively? You broke it down into measurable sub-dimensions (used technical terms correctly, narrated reasoning out loud, summarized at the end) instead of one fuzzy "communication" score. Then ran a few sessions through both human + LLM-judge to check correlation. Lesson: decompose subjective into measurable sub-criteria, then validate the judge.
SoloMock — Realtime API isn't cheap. Cost per session was [your real number]. You considered: (a) text-only with TTS (cheaper but loses the natural interruption flow), (b) batching transcripts for analysis instead of live, (c) capping session length. You chose to keep the live audio loop because the product is verbal-under-pressure — that's the whole point — but added session caps. Lesson: name what the product cannot compromise on, then cut everything else.
SoloMock — built and shipped in [your real number, weeks]. What you cut: behavioral feedback, multi-language support, the social/leaderboard layer, account auth (used anonymous sessions). What you kept: the Socratic loop, real-time audio, the technical-only focus. Lesson: shipping is a series of explicit no-decisions. Naming what you cut is more interesting than naming what you built.
See the ai-collab lesson — but the short version: specific tools for specific jobs (Claude for prose + thinking-out-loud + code review, Cursor/Copilot for in-editor completion, ChatGPT-image for quick mockups), always verified for anything load-bearing, never blindly accepted. Frame as collaborator with known failure modes, not oracle. Wrong answer: "ChatGPT for everything" or "I don't trust AI."
| If they ask… | Lead with |
|---|---|
| "Tell me about yourself" | UMD CS '22 → built portfolio of full-stack + AI projects (name SoloMock + all-in-one-URL) → looking for SWE roles across backend / frontend / applied AI. |
| "Project you're proud of" | SoloMock (Story 1). |
| "Hardest technical problem" | all-in-one-URL architecture (Story 2). Or SoloMock's WebRTC + ephemeral key flow. |
| "Tell me about a failure" | personal-site hydration mismatch (Story 3). |
| "Why this company?" | Specific to each — research the team, find one product detail + one engineering value to name back. |
| "Tell me about AI experience" | SoloMock (Realtime API + WebRTC), roofing-site (AI voice booking agent), and tasteful use of LLMs in everyday dev — drafted with verification, not vibes. |
| "Time AI got you in trouble / steered you wrong" | personal-site hydration story works — reframe as "I almost accepted the model's suggestion to suppress the hydration warning; the real fix needed me to read the actual diff myself." Or: any time you caught a model hallucinating an API. |
| "When did you choose NOT to use AI" | Architecture decisions on all-in-one-URL — the stack choice (split FastAPI + React, why Redis, why Postgres) is a judgment call, not a generation task. Model can suggest options; the weighing is yours. |
| "How do you handle disagreement?" | ⚠ Gap — develop before the onsite. |
| "Why you?" | "Three things: I ship — six deployed projects in a year; I think in stacks — Python + TS + Postgres + Redis + LLMs together, not in isolation; I write so the next person can follow — see the web-dev-tutorial." |