How to Prep for a 6-Session On-Site Interview

Six sessions. Seven interviewers. One day. Each interviewer comes in with a different lens: VP Quality cares about defect culture and regulatory posture. The Sr. Principal Reliability Engineer wants to see if you can derive the Weibull likelihood function with right-censored data. The Test Engineering Director is thinking about ML monitoring on the shop floor. The CIO is mapping your experience to their analytics roadmap. HR wants to know if you'll stay.

You're not supposed to wing this. But most advice — "research the company," "prepare STAR stories" — doesn't scale to this complexity. It treats the on-site as a monolithic event when it's actually a sequence of six distinct conversations, each with its own stakes and vocabulary.

I just went through this at a power electronics manufacturer where reliability engineering was core to the role. Before the on-site, I built a prep system using AI and Obsidian zettels. It compressed days of manual research into hours, gave me tailored talking points for every session, and turned the interview from an interrogation into a diagnostic conversation. Here's the methodology.

The Problem with On-Sites

A multi-round on-site isn't one interview repeated six times. It's six different interviews that happen to share a schedule and a candidate. Each interviewer: - Has a different role and incentive structure - Evaluates different competencies - Speaks a different professional language - Will compare notes afterward (and they will)

Generic prep fails because it prepares you for an average interviewer who doesn't exist. You need to prepare for each interviewer, in their language, addressing their priorities — while maintaining a coherent narrative across all six sessions.

What I Built: A Prep System, Not a Cheat Sheet

The system had three layers in an Obsidian vault, managed as a zettel cluster:

1. Interviewer Bios (One Note Each)

Each note contained: - Name, title, LinkedIn summary, tenure - Publications, patents, conference talks (if any) - Inferred priorities from role and company context - Likely questions based on their function

2. Session Mapping

A single note mapping the schedule: | Session | Interviewer | Role | Likely Focus | My Core Experience to Lead With | |---------|-------------|------|--------------|----------------------------------| | 1 | Sr. Principal Reliability Eng | Statistical rigor, Weibull/ALT, censored data | EDA platform reliability metrics, Weibull analysis | | 2 | VP Quality | Defect culture, regulatory, quality systems | CertainTeed/Saint-Gobain quality delivery, SPC | | 3 | Test Eng Director | Shop-floor ML, SPC, real-time monitoring | Manim Math Pad, JMP add-in, production ML | | 4 | CIO / VP IT | Data architecture, MES/SCADA, analytics | EDA Explorer, Snowflake/Azure ML, data platforms | | 5 | Sr. Dir Test Eng & Sustaining | Sustaining engineering, field returns, ALT | Low-freq ultrasound ML, field data analysis | | 6 | HR Director | Cultural fit, development, retention | AuDHD/neurodiversity advocacy, mentorship |

3. Talking Points per Session

For each session: 3–5 tailored talking points mapping my core experience to their vocabulary. Not scripts — fluency pathways.

4. Live Note Templates

A structured capture format for each session: - Key points made (what they emphasized) - Knowledge gaps revealed (what I need to brush up on) - Follow-up actions (specific research or prep items) - Self-assessment (connection quality, what to repeat/adjust)

The Research Phase: AI as Research Assistant

The manual version of this prep takes days: LinkedIn stalking, piecing together org charts, guessing priorities from job descriptions. AI compressed it to hours.

Prompt Pattern: Interviewer Dossier

Research [Name], [Title] at [Company]. Given that [Company] does [power electronics / reliability engineering / manufacturing], and this person's title is [Title], what are their likely top 3 priorities? What technical language do they probably speak? What would they care about in a candidate for a Principal Data Analysis Engineer role? Provide specific, non-generic talking points.

Prompt Pattern: Company Context

[Company] is a [power electronics manufacturer] known for [high-reliability power modules]. Their tech stack includes [JMP, MES systems, shop-floor test]. What are the top 5 reliability/data challenges a company like this faces in 2026? Be specific about Weibull, ALT, SPC, FIT rates, and field return analysis.

The Key: You Verify, AI Synthesizes

The AI retrieved and synthesized. I verified every claim against sources I controlled: - Company public pages, press releases - Interviewer LinkedIn profiles (manually checked) - My own knowledge of the domain (Weibull, SPC, JMP) - The interview schedule Diane sent

AI hallucinates org charts and priorities. You don't. The division of labor: AI does the heavy lifting of synthesis; you do the verification and contextualization.

Tailoring Talking Points: One Core Experience, Six Framings

I didn't invent six different stories. I had one coherent narrative — "I build data systems that make manufacturing reliable" — and reframed it for each audience:

The pattern: core achievement → their vocabulary → their priority.

What AI Can't Do (And Where You Must Show Up)

This is the part most "AI interview prep" posts miss.

1. Domain Expertise

AI can explain the Weibull hazard function. It cannot tell you whether, for this company's capacitor failure mode, a mixture model is warranted or if a simple two-parameter Weibull suffices. That judgment requires knowing the physics of the failure mode, the maturity of their test program, and the regulatory context. You bring that. AI doesn't.

2. Judgment Calls

Competing risks vs. mixture models. Median rank regression vs. MLE. Profile likelihood vs. Wald confidence intervals. AI can define them. It cannot choose the right one for your specific conversation with the Sr. Principal Reliability Engineer who's been doing this for 25 years.

3. Contextual Nuance

Which JMP platforms they license. Whether their IT department prefers point-and-click over scripting. Whether their field return data has interval censoring. These live in organizational knowledge, not textbooks.

4. Verification Responsibility

Every formula the AI generates, you check. Every claim about their tech stack, you verify. The AI is a research assistant; you're the principal investigator.

5. The Interview Itself

AI can't sit in the room. It can't read the room. It can't pivot when the VP Quality asks an unexpected follow-up about FDA 21 CFR Part 11. That's all you.

The Template: Reproducible Zettel Structure

Create a folder for the interview. Inside:

interview-prep-[company]-[date]/
├── 00-schedule.md              # Session map with times, names, roles
├── 01-company-context.md       # Products, challenges, tech stack, org
├── bios/
│   ├── [name]-[title].md       # One per interviewer
│   └── ...
├── talking-points/
│   ├── session-01-[role].md    # Tailored points for this session
│   └── ...
├── templates/
│   └── live-note-template.md   # Reusable capture format
├── post-session/
│   ├── session-01-reflection.md
│   └── ...
└── verification-ledger.md      # What you verified, sources, gaps

Live Note Template (per session)

# Session N: [Interviewer Name] — [Role]

## Key Points Made
- 
- 

## Knowledge Gaps Revealed
- 
- 

## Follow-Up Actions
- [ ] Research X
- [ ] Prepare Y
- [ ] Send Z

## Self-Assessment
- Connection quality (1-5): 
- What worked: 
- What to adjust next session: 
- Energy level: 

Post-Session Reflection Prompts

• What did they care about that I didn't expect?
• Where did I feel fluent vs. where did I hesitate?
• What vocabulary did they use that I should adopt?
• What follow-up would demonstrate I was listening?

The Result

Six sessions. Seven interviewers. I walked in with a prep system that mapped my experience to their worldviews. When the Reliability Engineer asked about profile likelihood confidence intervals for η, I didn't recite a textbook — I explained why I'd choose them over Wald intervals for their field return data. When the CIO asked about MES integration, I described the EDA Explorer's SQL/Snowflake pipeline in their architecture language.

The prep didn't just make me knowledgeable. It made me conversant. Each session built on the last because my notes from Session 1 informed my talking points for Session 3. The live capture templates turned the day from a gauntlet into a diagnostic conversation where I learned as much as they did.

Your Turn

If you're facing a multi-round on-site: 1. Get the schedule (names, titles, order) 2. Build the zettel cluster — one note per interviewer, one session map 3. Use AI for research synthesis — but verify everything 4. Map your core experience to their vocabulary — same story, six framings 5. Bring live note templates — capture in real time, adapt between sessions 6. Own the gaps — AI can't fake domain expertise. Know where your knowledge ends and say so.

The zettel structure is reproducible. The OpenClaw skills that help (zettel management, AI research synthesis) are in the registry. Adapt the template to your role, your company, your interviews.

You're not preparing for an interview. You're preparing for six conversations. Build a system that scales to that.

This is Post 3 of the "Building with AI" series. Post 1: "I Let AI Audit My Own Site — And Found 12 Real Vulnerabilities." Post 2: "How AI Compresses Technical Prep — A Weibull Refresher Case Study."