Human Interest Interview Prep v4 STAR (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: The Pipeline Tester lived inside an Airflow UI plugin, with its logic coupled to the routes. Engineers and an AI agent needed to run tests without the browser. T: Make the core reusable behind one validation path. A: 1) Structural-only extraction first: no behavior change, old code removed, no duplicates. 2) Cut the plugin routes over to the new service. 3) Built the CLI: one JSON object on stdout, logs on stderr, a stable failure envelope, distinct exit codes, lazy imports. 4) Preview and submit share the same gate sequence, with parity tests. R: Plugin code down ~67%. The agent (Ned) completed real runs on Aug 3 and 4 (~6.5 min), recovering 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: The Pipeline Tester builds a temporary DAG from the jobs between a start job (root) and an 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 job-selection logic and user flow so that bad state can't be submitted. A: I proposed descendants(root) INTERSECT ancestors(leaf) for the in-between jobs, plus a connectivity check at the form before submit. My manager and a teammate said right idea, add detail, and suggested a fix. The problem: that check is full downstream + full upstream + intersection BEFORE submit, then the same work AGAIN after submit. Their suggestion, which I adopted: after the user picks the root, the end-job dropdown lists only jobs downstream of it. The intersection then runs once, after submit. The dropdown refreshes when the root changes; descendants(root) is computed in one traversal. R: Invalid pairs can't be submitted, the expensive check isn't duplicated, and no scheduler/compute is wasted. Server-side validators still enforce it, since the UI alone isn't enforcement. L: Make invalid states unrepresentable in the UI, fail early and cheaply, and write the design down so reviewers can sharpen it.

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

S: New to Airflow, Databricks, Spark SQL and Delta Lake, coming from strong Java/backend. T: Get productive on the Data Platform team fast enough to take on a real tool. 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, and asking my mentor focused questions. R: Ramped from small fixes to ~27 PRs between Jun 22 and Aug 3 (brag doc; recount before saying). L: Build a working map and validate it against real behavior. Same habit at Bread: I mimicked an existing screen end to end to learn the architecture.

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

S: The tester built a one-shot (@once) DAG from jobs that normally run on recurring prod schedules. T: Keep the job logic faithful while making execution valid for a one-off test. A: Plan that failed: reuse prod macros as-is. That raised a TypeError (NoneType minus timedelta) during Jinja render, because following_schedule() is None on @once. I 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: The Nextdoor bridge module had duplicated file-path logic, and I consolidated it onto the shared get_bridge_job. T: Centralize path resolution without breaking callers. A: The PR was reviewed, approved and merged, then Backfill regressed. I told the team in Slack, pinged my mentor and manager, and investigated so I came with an initial cause and a possible fix. R: A follow-up PR fixed Backfill [CONFIRM symptom, fix, how verified, who noticed, how fast]. L: Shared-function changes need a check of every caller, including adjacent tools [CONFIRM what you now actually do]. Own it in the first sentence; do not blame review.

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

S: Software-dev course; my team was split on the architecture for a self-driving system, and some were already drafting a proposal. T: Get one coherent architecture without delay or tension. A: Proposed a meeting. Each person explained their reasoning, we compared tradeoffs, and combined the strongest parts. R: A unified proposal and smoother teamwork afterwards. L: Surface assumptions early and give people space to explain technical reasoning. [WEAK: add the actual design choices in dispute and what the final proposal chose, or swap for a work example]

[story] INFLUENCED SOMEONE MORE SENIOR

S: JSS review: expert reviewer 2 asked why BERT-style models were excluded and wanted comparisons. T: Decide whether to concede, include them, or defend the scope. A: We conceded the search-breadth critique but held the BERT exclusion, with evidence: those models mostly classify (e.g. detect smells) while generative LLMs produce the refactoring. We wrote the reasoning and examples into the methods and offered a comparison if the reviewer gave specifics. [CONFIRM your role] R: Accepted without changing that scope [CONFIRM reviewer outcome]. L: Concede what's right, defend scope with evidence. Not influence: the RFC dropdown change (I accepted senior feedback). No Nextdoor influence story yet; don't invent one.

[story] RECEIVED FEEDBACK / CHANGED MY DESIGN

S: In the Pipeline Tester RFC I proposed a connectivity check on the form, using the full downstream + upstream intersection, before submit. T: Get the design approved and make it sound. A: My manager and a teammate said the idea was right but to add detail, and suggested the end-job dropdown list only jobs downstream of the root. That avoids running the expensive check twice (before and after submit). I adopted it and updated the RFC. R: The design changed, not just the wording; invalid pairs can't be submitted and the check isn't duplicated. L: I treat review as design input. More examples: June 17 mentor review (build a BridgeJob from the YAML path instead of regex-parsing task IDs; fixed non-unique filename stems). July 22: split a prod-macro change by root cause. JSS major revision (33 to 50 studies, new RQ). [CONFIRM which is primary]

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

S: Stevens Blueprint (since Aug 2024): open-source validator + transformer for Open Referral HSDS. T: Build the validator API and shared validation, then extend the transformer. A: 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. L: [CONFIRM: a teammate/reviewer whose feedback changed a design, and one lesson]

[story] RAISED A RISK / QUESTIONED A RESULT

S: Bread intern on Core Platform, told to mimic an existing screen end to end (UI to DB) in a web app managing records for 300+ credit-card brand partners. T: Build it and test CRUD on my local copy. A: A delete threw "cannot delete a row that doesn't exist" (JDBC, Spring Boot). I read the logs and traced it to a file where the delete ran twice. Removing the duplicate call locally made it work. I documented and reproduced it, 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. Alt (confirm you spotted them): Nextdoor test-validity fixes, PR #30452 (warn when root table has no prod data at the picked date) and PR #30629 (stale scratch tables corrupting results).

[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 with Luo Xu) on a systematic review of LLM-driven refactoring submitted to JSS; the editor returned a MAJOR REVISION. T: Address 3 reviewers: too few studies (33) and a narrow search, LLM-heavy / refactoring-light, raw hard-to-read tables, and a discussion that listed conflicting findings without synthesis. A: Broadened the search string (code refinement, code restructure…) and searched abstracts/keywords, going from 33 to 50 primary studies. Added a research question on refactoring characteristics. Added summary tables + frequency figures. Rewrote the discussion into an Actionable Insights section. Wrote a point-by-point response letter. [CONFIRM which sections YOU owned and how you and Luo split work] R: Accepted Dec 24, 2025; JSS vol 235 (2026). L: Treat each reviewer comment as a requirement and show where it was addressed. Also: 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 the scope. A: We agreed on the search-breadth critique and changed it, but kept the BERT exclusion: those models mostly classify (e.g. detect smells) while generative LLMs produce the refactoring, and 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]. 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: Bread intern on Core Platform, told to mimic an existing screen end to end (UI to DB) in a web app managing records for 300+ credit-card brand partners. T: Build it and test CRUD on my local copy. A: A delete threw "cannot delete a row that doesn't exist" (JDBC, Spring Boot). I read the logs and traced it to a file where the delete ran twice. Removing the duplicate call locally made it work. I documented and reproduced it, 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 che