skills/technical-interview-copilot/references/behavioral_experience_deep_dive.md

# Behavioral and Experience Deep-Dive Framework

## Purpose

Use this file to prepare behavioral answers and probe resume/project claims without inventing experience.

The goal is a natural, defensible spoken answer—not a memorized script.

---

# 1. Evidence-first rule

Use only:
- the user’s supplied resume/profile;
- project descriptions;
- interview context;
- facts the user explicitly confirms.

Never invent:
- metrics;
- team size;
- architecture ownership;
- incidents;
- leadership;
- business impact;
- technologies;
- customer outcomes.

If an important result is unknown, phrase it honestly or ask for the missing detail.

---

# 2. Natural answer structure

Internally check:

1. Context — what was happening?
2. Responsibility — what were you responsible for?
3. Action — what did you personally do?
4. Reasoning — why did you choose that approach?
5. Result — what changed?
6. Learning — what would you repeat or change?

Do not force the user to say “Situation, Task, Action, Result” aloud unless requested.

---

# 3. Experience deep dive

For every meaningful resume claim, be ready to ask:

- What problem were you solving?
- What did you personally own?
- What did the team own?
- What was the architecture?
- Why did you choose that technology?
- What alternatives did you consider?
- What was difficult?
- What failed?
- How did you debug it?
- How did you validate correctness?
- What was the measurable result?
- What trade-off did you make?
- What would you change now?

For senior roles, also ask:
- Who disagreed and why?
- How did you influence the decision?
- How did you reduce operational risk?
- How did you handle migration or rollout?
- How did you make the design easier for others to operate?

---

# 4. Behavioral topic bank

Use only topics relevant to the role.

## Ownership
- difficult problem owned end to end;
- ambiguous requirement;
- incident or production issue;
- project rescued or simplified.

## Conflict / influence
- technical disagreement;
- stakeholder pushback;
- cross-team dependency;
- influencing without authority.

## Failure / learning
- failed implementation;
- missed estimate;
- production issue;
- wrong assumption;
- feedback that changed behavior.

## Prioritization
- competing deadlines;
- technical debt vs feature work;
- reliability vs speed;
- cost vs performance.

## Leadership
- mentoring;
- design review;
- standards;
- delegation;
- unblock others;
- leading through ambiguity.

Do not ask people-management questions merely because the title is senior.

---

# 5. Technical-behavioral hybrid

Strong technical interviews often combine experience with technical depth.

Example sequence:

1. “Tell me about a pipeline you owned.”
2. “What was the data volume and SLA?”
3. “Why did you choose streaming?”
4. “What happened when the sink slowed down?”
5. “How did you measure recovery?”
6. “What would you redesign now?”

This is often more realistic than isolated trivia.

---

# 6. Answer quality rubric

Score internally or explicitly when useful:

## Correctness
Are technical claims accurate and internally consistent?

## Specificity
Does the answer describe a real event rather than generic behavior?

## Ownership
Is the candidate’s contribution clear?

## Reasoning
Does the answer explain why choices were made?

## Impact
Is the outcome clear without invented metrics?

## Reflection
Does the candidate show learning?

## Concision
Can the answer be followed easily?

Suggested 1–5 scale:
1 = weak
2 = incomplete
3 = acceptable
4 = strong
5 = excellent

Do not inflate scores to be encouraging.

---

# 7. Strengthening a weak answer

Fix in this order:

1. Answer the actual question.
2. Remove generic filler.
3. Clarify personal ownership.
4. Add the key technical decision.
5. Add evidence/result.
6. Add trade-off or lesson.
7. Shorten anything not helping the answer.

---

# 8. Spoken-answer lengths

## Short
20–30 seconds:
direct answer + one supporting detail.

## Standard
60–90 seconds:
context + action + reasoning + result.

## Deep
2–3 minutes:
include architecture, trade-offs, failure handling, and lessons.

Do not make every answer 3 minutes long.

---

# 9. Honest gaps

When the user lacks direct experience:

Do not fabricate.

Use one of these patterns:
- “I haven’t owned that directly, but I have worked with…”
- “My closest experience is…”
- “I haven’t used that in production; here is how I would approach it based on…”

Then prepare for follow-up.

---

# 10. Feedback language

Prefer:
- “The strongest part is…”
- “The weak point is…”
- “An interviewer may challenge…”
- “Make your ownership clearer by…”
- “This claim is too broad unless you can support…”

Avoid empty praise.