Human Interest Interview Prep v3 (Nov 11)

[opener] Tell me about yourself (~75 sec)

1 WHO: Sofia, Stevens CS senior, graduating Dec; backend/platform work where reliability helps other engineers | 2 NEXTDOOR: Data Platform intern; designed + shipped first local end-to-end Pipeline Tester for a 4,424-job Airflow pipeline; headless service + CLI so an AI agent can run tests | 3 BREAD: Java/JSF/Spring Boot, internal access-management app for 300+ brand partners | 4 RESEARCH: first author on a peer-reviewed JSS paper (systematic review of 50 LLM-refactoring studies) + co-author on CASCON paper | 5 BLUEPRINT: open-source validator + transformer for Open Referral | 6 CLOSE: reliable systems that simplify complex work -> Human Interest retirement access

[opener] Why Human Interest?

1 MISSION: retirement affects everyone; 401(k) was hard/expensive for SMBs | 2 PERSONAL: parents near retirement; hometown small-business employees lacked same access | 3 ENGINEERING: complex system (payroll integrations, money, compliance) -> simple customer experience; correctness matters because it is people's savings | 4 CULTURE: small, fast-moving, autonomous + accountable teams, ownership | 5 TIE: Nextdoor taught me reliable infra/testing lets people move with confidence

[opener] Why this role / what are you looking for?

• Backend, infrastructure, data-heavy systems where reliability and scale matter | - More end-to-end ownership moving from internships to full-time | - LINE: "I'm looking for engineering problems where reliability isn't just a technical goal; it directly affects the customer."

[opener] What do you know about Human Interest?

• 401(k)/403(b) for small + medium businesses, zero transaction fees | - Traditional + Roth, Safe Harbor, profit sharing | - Integrates with payroll; automates contributions, eligibility, recordkeeping, compliance, filings | - 47,000+ businesses (careers page) [re-check before] | - Mission: retirement access "in all lines of work" | - KEY LINE: the complexity didn't disappear, they built tech that handles it so the employer doesn't have to

[opener] Why should we hire you?

1 STRENGTH A: ramp up fast in unfamiliar systems -> Airflow/Databricks, built the first local E2E tester | 2 STRENGTH B: reliable, reusable tools -> dependency/edge-case handling, then headless service + CLI | 3 PROOF OUTSIDE NEXTDOOR: Bread Java/SQL, Blueprint APIs | 4 FIT: ownership + learning + reliability for consequential financial workflows

[opener] Why software? (your 'why')

• Accessibility: Papa's Freezeria / Stack the States taught me states + capitals | - FIFA + Minecraft made soccer and building accessible when not physically possible | - Hard to get materials for projects in many fields, but software is available to almost anyone | - Link: HI makes retirement benefits accessible

[opener] Do you have fintech experience? 401(k) knowledge?

BREAD: access/permissions for 300+ brand partners; Java/JSF, JDBC/SQL, CI/CD; exposure to security, correctness, compliance side. Say: products differ, but Bread gave me high-stakes data/access experience. | 401(k) BASICS: Traditional = pre-tax, taxed on withdrawal; Roth = after-tax, qualified withdrawals tax-free; employer match; ERISA governs private plans; IRS + DOL; eligibility, reporting, fiduciary, compliance testing. | TIE BACK: correctness, auditability, security in regulated workflows.

[story] INITIATIVE / OWNERSHIP (Pipeline Tester -> headless service + CLI)

S: tester lived in an Airflow UI plugin with logic coupled to routes; engineers and an AI agent needed to run tests without the browser | T: make the core reusable, one validation path | A: structural-only extraction first (no behavior change, old code removed, no duplicates) -> cut plugin routes over to the service -> CLI: one JSON object on stdout, logs on stderr, stable failure envelope, distinct exit codes, lazy imports; preview and submit share the same gate sequence + parity tests | R: plugin code down ~67%; agent (Ned) completed real runs Aug 3 + 4 (~6.5 min, recovered from expired AWS creds) | L: when an agent is the caller, output shape and failure semantics are product features | [CONFIRM: what you designed vs implemented]

[story] DIFFICULT TECHNICAL PROBLEM / DESIGN (RFC: user flow + jobs between root and leaf)

S: Pipeline Tester builds a temp DAG from the jobs between a start job (root) and end job (leaf) in a ~4,400-job graph. Submitting two UNCONNECTED jobs wastes real resources: the intersection runs, a DAG is built, the Airflow scheduler picks it up, and it fails | T: in the RFC, design the selection logic + user flow so that bad state can't be submitted | A: proposed descendants(root) INTERSECT ancestors(leaf) for the in-between jobs, plus a connectivity check at the form before submit. Manager + teammate: right idea, add detail, and they suggested a fix. The problem: that check = full downstream + full upstream + intersection BEFORE submit, then the same work AGAIN after submit. Fix (their suggestion, which I adopted): after the user picks the root, the end-job dropdown only lists jobs downstream of it, so a connected pair is the only pair they can pick; the intersection runs once, after submit | R: invalid pairs can't be submitted, expensive check not duplicated, no wasted scheduler/compute runs; server-side validators still enforce it (UI alone isn't enforcement) | L: make invalid states unrepresentable in the UI; fail early and cheaply; write the design down so reviewers can sharpen it | DETAILS: dropdown refreshes when the root changes; descendants(root) computed in one traversal

[story] LEARNED QUICKLY (Nextdoor ramp-up; Bread before it)

S: new to Airflow, Databricks, Spark SQL, Delta Lake; strong Java/backend | A: started with scoped quality-of-life fixes (YAML button, external-task button), then Task Instance Notes: traced a 500 error to a type mismatch between Okta auth and Airflow/FAB, fixed with an Alembic migration + tests; then the Pipeline Tester, tying each new concept to a requirement; focused questions to mentor | R: ramped from small fixes to ~27 PRs between Jun 22 and Aug 3 (brag doc; recount before saying) | L: build a working map, validate against real behavior | SAME HABIT AT BREAD: mimicked an existing screen end to end to learn the architecture

[story] ADAPTED WHEN A PLAN DIDN'T WORK (@once DAG macros)

S: tester built a one-shot (@once) DAG from jobs that normally run on recurring prod schedules | T: keep job logic faithful, make execution valid for a one-off test | A: PLAN THAT FAILED: reuse prod macros as-is -> TypeError (NoneType minus timedelta) during Jinja render, because following_schedule() is None on @once; derived the next boundary from the job's real cadence; second layer: history/partition lookups had to read the prod catalog; review asked me to split the prod-macro change into a focused PR and test before/after in Coder + staging | R: selected jobs run without harness-caused failures; unchanged prod path verified [CONFIRM how] | L: a harness must keep the semantic inputs prod code relies on | TECHNICAL CHALLENGE, not a personal failure

[story] FAILURE / MISTAKE (Backfill regression after shared-function refactor)

S: Nextdoor bridge module had duplicated file-path logic; I consolidated onto shared get_bridge_job | T: centralize path resolution without breaking callers | A: PR reviewed, approved, merged -> Backfill regressed. Told team in Slack, pinged mentor + manager, investigated so I came with an initial cause and possible fix | R: follow-up PR fixed Backfill [CONFIRM symptom, fix, how verified, who noticed, how fast] | L: shared function changes need a check of every caller, incl. adjacent tools [CONFIRM what you now actually do] | OWN IT in first sentence; do not blame review

[story] WORKED THROUGH DISAGREEMENT (course architecture, self-driving system)

S: software-dev course, team split on architecture; some already drafting proposal | T: one coherent architecture without delay/tension | A: proposed a meeting; each person explained reasoning; compared tradeoffs; combined strongest parts | R: unified proposal, smoother afterwards | L: surface assumptions early; give space to explain technical reasoning | [WEAK: add the actual design choices in dispute + what the final proposal chose, or swap for a work example]

[story] INFLUENCED SOMEONE MORE SENIOR

BEST CANDIDATE: BERT-exclusion response in the JSS review (held a scoped position with evidence vs expert reviewers) [CONFIRM your role]. | NOT influence: the RFC leaf-dropdown change (you accepted senior feedback). | No Nextdoor influence story yet. Do not invent one.

[story] RECEIVED FEEDBACK / CHANGED MY DESIGN

1 RFC: manager + teammate said the idea was right, add detail; they suggested the end-job dropdown only list jobs downstream of the root, which avoids running the expensive connectivity check twice (before and after submit); I adopted it | 2 JUNE 17 REVIEW: mentor pushed me off regex-parsing task IDs -> build a BridgeJob from the YAML path and ask it for the task ID; also fixed non-unique filename stems (wrong-job resolution) | 3 JULY 22: split a production-macro change by root cause; test before/after in Coder + staging | 4 JSS MAJOR REVISION: 3 reviewers; 33 -> 50 studies, new research question, rewritten discussion | PATTERN: I treat review as design input; the design changed, not just the syntax | [CONFIRM which is primary]

[story] COLLABORATED / OWNED WORK (Stevens Blueprint, Open Referral HSDS)

S: Blueprint (since Aug 2024): open-source validator + transformer for Open Referral | VALIDATOR (Sep-Oct 2025, verified commits): set up the API; zip validation; schema validation with structured errors; nested files + system-file filtering in zip input; universal API error responses; shared lib.validate behind both CLI and API; condensed errors (PR #18) | TRANSFORMER (Nov 2025-Mar 2026): row filters, strip column + escape sequences, drop blank fields, schema fetch from URL, API with zip input (PR #73), optional transform column | R: foundation handed off and extended by the team | [CONFIRM: a teammate/reviewer whose feedback changed a design]

[story] RAISED A RISK / QUESTIONED A RESULT

PRIMARY: Bread double-delete: found a bug in existing code while learning, documented + reproduced it, flagged manager, asked to fix. | ALT (confirm you spotted them): Nextdoor test-validity fixes: warn when root table has no prod data at the picked date (PR #30452); stale scratch tables corrupting results (PR #30629). | Shape: noticed -> why it mattered -> who I told -> fix -> now it can't fail silently. | Don't reuse Backfill if used for failure.

[story] CURIOSITY: what are you curious to learn next?

1 TECH: design decisions for systems handling millions of requests that stay reliable, maintainable, adaptable | 2 WHAT I ENJOY: talking to users/teams, learning their workflow, building something that removes a pain point | 3 HI-SPECIFIC: how do you go from a new customer to a working solution fitted to their business? | 4 AI: using AI-assisted dev responsibly (my refactoring research: generated code still needs context, tests, review) | 5 OUTSIDE: music production class (one sentence max)

[story] WHAT WOULD YOU DO DIFFERENTLY ON THE NEXTDOOR PROJECT?

• Inventory prod dependencies earlier: reuse vs adapt for a one-off run | - Add a few representative tests early: recurring schedules, dates/snapshots, downstream dependency selection | - Map all callers before changing shared bridge behavior | - Fidelity to production = explicit contracts, not copying the whole environment | (Say 'I would', it's a reflection, not a result)

[story] RESEARCH (JSS first author): major revision

S: first author (equal contribution w/ Luo Xu) on a systematic review of LLM-driven refactoring submitted to JSS; editor returned MAJOR REVISION | T: address 3 reviewers: too few studies (33) + narrow search, LLM-heavy / refactoring-light, raw hard-to-read tables, discussion listed conflicting findings without synthesis | A: broadened the search string (code refinement, code restructure…) + searched abstracts/keywords -> 33 to 50 primary studies; added a research question on refactoring characteristics (identifying opportunities, types, behavior preservation, abstraction layer); added summary tables + frequency figures; rewrote the discussion into an 'Actionable Insights' section on when/why each prompting strategy works; wrote a point-by-point response letter | R: accepted Dec 24 2025; JSS vol 235 (2026) | L: reviewer feedback improved the paper; treat each comment as a requirement and show where it was addressed | [CONFIRM: which sections/responses YOU owned; how you and Luo split work] | CASCON 2025: co-author, 100+ ChatGPT-developer interactions -> prompt template.

[story] HELD A POSITION WITH EXPERTS (BERT exclusion in peer review)

S: reviewer 2 asked why BERT-style models were excluded and wanted comparisons | T: decide whether to concede, include them, or defend scope | A: we agreed on the search-breadth critique (changed it) but kept the BERT exclusion: those models mostly classify (e.g. detect smells) while generative LLMs produce the refactoring; mixing them would break one analysis framework. We documented the reasoning + examples in the methods, noted that included studies still use BERT baselines, and offered to add a comparison if the reviewer gave specifics | R: accepted without changing that scope [CONFIRM reviewer outcome + your role in this decision] | L: concede what's right, defend scope with evidence, put the reasoning in writing | USE FOR: disagreement, influencing experts, handling feedback

[story] BREAD: reproduce, trace, escalate with evidence

S: Core Platform intern; web app managing records for 300+ credit-card brand partners; told to mimic an existing screen end to end (UI -> DB) to learn the architecture | T: build it, test CRUD on my local copy | A: delete threw 'cannot delete a row that doesn't exist' (JDBC, Spring Boot); read the logs, traced it to a file where the delete ran twice; removed the duplicate call locally -> worked; documented + reproduced; told my manager with evidence and asked permission to push the fix | R: [CONFIRM: fix merged? other screens affected? how verified?] | L: reproduce first, bring evidence, ask before changing code outside my scope

[variation] Proudest accomplishment?

Pipeline Tester (primary). Lead with the result, then the hard part (job selection).

[variation] Biggest technical challenge?

Job-selection intersection logic; alt: @once scheduling mismatch.

[variation] Time you owned something end to end?

Headless service + CLI extraction.

[variation] Time you had to learn something fast / unfamiliar tech?

Nextdoor ramp-up (small fixes first, then Pipeline Tester). Alt: Bread mimic-a-screen onboarding.

[variation] Time a project didn't go as planned?

@once DAG scheduling (plan = reuse prod schedule). Alt: Backfill regression, or JSS major revision.

[variation] Tell me about a mistake you made / what did you learn from it?

Backfill regression. Own it first, then communication, then repair, then changed habit.

[variation] Time you received difficult feedback?

JSS major revision (primary: 3 reviewers) or RFC leaf-dropdown change / BridgeJob-not-regex review.

[variation] Time you worked with someone difficult / disagreed?

Reviewer disagreement (BERT) or course architecture (weak). Find a Nextdoor/Blueprint one if you have it.

[variation] Time you worked on a team?

Blueprint (primary); JSS paper with Luo, Mariam, Eman (alt).

[variation] Time you persuaded someone / pushed back?

BERT exclusion in JSS review (primary, confirm role). Nextdoor: none yet.

[variation] How do you handle ambiguity?

Blueprint early-stage unclear requirements; Pipeline Tester scoping. [confirm]

[variation] Time you went above and beyond / improved a process?

Headless service + CLI; Bread double-delete escalation.

[variation] How do you prioritize / manage competing deadlines?

[NO STORY YET] school + internship/research? confirm.

[variation] How do you use AI tools when coding?

Take-home answer: AI for planning, debugging, implementation help, reviews; I still read the diff, check the schema, run tests, decide what to commit. Example: caught card model missing DB fields; changed concurrency UI after noticing it blocked valid requests.

[variation] Why not just let agents run unattended?

Tree-in-the-forest: if no engineer understands/inspects what's merged, did we make progress? Future fixes become guesswork, nothing transfers to new problems, and we don't know how it fits the system.

[ask] Your questions for them (pick 2-3)

• How is your org using AI day to day? Where are agents working, where are human engineers essential? | - Humans still have to understand, verify, test, maintain agent-written code: do agents test other agents? Rough share of verification by AI vs humans? | - Specific implementation or recent partnership/development you read about | - Based on what we discussed, any concerns about my fit? | - How is working here different from other places you've worked? What keeps you motivated? | - What would the rest of the process look like, and any advice?

[tech] Take-home walkthrough: 60-second spine

HSA simulation: create account, deposit, issue card, purchase (declined if no card / non-qualified category / insufficient funds) | STACK: React -> /api via nginx -> FastAPI + Pydantic -> SQLAlchemy/psycopg -> Postgres; Docker Compose + seed data | MONEY: integer cents, no float rounding | DECISION: backend decides purchases; balance update + transaction written together | CONCURRENCY: row lock; $100 acct, $80 + $50 at once -> one approves, one declines | TESTS: API tests w/ separate DB, frontend tests, lint, prod build, DB inspection, manual | NEXT: auth/ownership, migrations, safer card credentials, server-side transaction feed, e2e + a11y

[tech] Take-home: what would you do differently / add?

Login + account ownership; proper migrations; safer card-credential handling; server-side global transaction feed for scale; more end-to-end + accessibility testing. | For 'add a feature live': clarify user-visible behavior + edge cases -> find closest existing flow -> smallest useful change -> run the most relevant check.