@shaykec/bridge 0.4.25 → 0.4.27

package/modules/git/walkthrough.md

@@ -0,0 +1,92 @@
+# Git Walkthrough — Learn by Doing
+
+## Step 1: Your First Repository
+
+Let's start by creating a Git repository from scratch.
+
+<!-- hint:terminal -->
+
+**Task:** Create a new directory and initialize it as a Git repository.
+
+**Question:** Before we run any commands — what do you think `git init` actually creates? What would you expect to find in the directory afterward?
+
+**Checkpoint:** The user should mention the `.git` hidden directory and understand it stores Git's internal data.
+
+---
+
+## Step 2: Understanding the Three Areas
+
+Now let's explore how Git tracks changes.
+
+<!-- hint:diagram mermaid-type="flowchart" topic="Git three areas: working directory, staging area, repository" -->
+
+**Task:** Create a file called `hello.txt` with some content. Then run `git status`.
+
+**Question:** Git says your file is "untracked." What do you think that means? Where does the file live in Git's three-area model (working directory, staging area, repository)?
+
+**Checkpoint:** The user should explain that untracked means Git sees the file but isn't tracking changes to it yet. It exists only in the working directory.
+
+---
+
+## Step 3: Staging and Committing
+
+<!-- hint:terminal -->
+
+**Task:** Stage `hello.txt` with `git add`, then commit it.
+
+**Question:** Why do you think Git has a separate staging area instead of committing directly from the working directory? What advantage does this give you?
+
+**Checkpoint:** The user should understand that staging lets you choose exactly which changes to include in a commit — you can have 10 modified files but only commit 3.
+
+---
+
+## Step 4: Making Changes
+
+<!-- hint:terminal -->
+
+**Task:** Edit `hello.txt` to add a second line. Run `git diff` to see the changes.
+
+**Question:** What does the `+` and `-` notation in the diff output mean? Can you read the diff and predict exactly what changed?
+
+**Checkpoint:** The user can read diff output and explain additions (`+`) and removals (`-`).
+
+---
+
+## Step 5: Branching
+
+<!-- hint:card type="concept" title="Branches are lightweight pointers to commits — no files copied" -->
+
+**Embed:** https://learngitbranching.js.org/
+
+**Task:** Create a new branch called `feature` and switch to it. Make a change and commit it.
+
+**Question:** When you created the branch, did Git copy all your files? What actually happened under the hood?
+
+**Checkpoint:** The user should understand that a branch is just a pointer to a commit — no files are copied. It's extremely lightweight.
+
+---
+
+## Step 6: Merging
+
+<!-- hint:diagram mermaid-type="flowchart" topic="Fast-forward vs three-way merge" -->
+
+**Task:** Switch back to `main` and merge your `feature` branch.
+
+**Question:** What kind of merge happened — fast-forward or three-way? How can you tell?
+
+**Checkpoint:** The user should be able to identify the merge type from the output and explain why that type was used.
+
+---
+
+## Step 7: Handling Conflicts
+
+<!-- hint:celebrate -->
+
+**Task:** Create a conflict scenario:
+1. On `main`, edit line 1 of `hello.txt` and commit
+2. Create a branch, edit the same line differently, and commit
+3. Try to merge
+
+**Question:** When you see the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), what does each section represent? How do you decide which version to keep?
+
+**Checkpoint:** The user can resolve a conflict manually, understanding that the top section is their current branch and the bottom is the incoming branch.

package/modules/git/workshop.yaml

@@ -0,0 +1,145 @@
+scenarios:
+  - id: git-init
+    title: "Initialize a Repo and Make Your First Commit"
+    difficulty: beginner
+    xp: 20
+    setup: []
+    files:
+      - name: README.md
+        content: "# My Project"
+        language: markdown
+        readonly: false
+    task: "Initialize a new Git repository here, add README.md to staging, and make your first commit with message \"Initial commit\"."
+    validations:
+      - label: ".git directory exists"
+        check: output-contains
+        pattern: "Initialized empty Git repository|\.git"
+      - label: "First commit made"
+        check: output-contains
+        pattern: "Initial commit|\[master.*\] Initial"
+    hints:
+      - "What command creates a new Git repository in the current directory?"
+      - "You'll need to stage files before committing. What does git add do?"
+      - "git init, then git add README.md, then git commit -m \"Initial commit\""
+    agent_prompts:
+      on_start: "Before we run any commands — what do you think happens when you initialize a Git repository? What gets created?"
+      on_complete: "You've made your first commit. What's the difference between the working directory, staging area, and repository? How does git add fit in?"
+
+  - id: branching
+    title: "Create and Switch Between Branches"
+    difficulty: beginner
+    xp: 25
+    setup:
+      - "git init && git branch -M main"
+      - "echo 'line 1' > notes.txt"
+      - "git add notes.txt && git commit -m 'First commit'"
+      - "echo 'line 2' >> notes.txt && git add notes.txt && git commit -m 'Second commit'"
+    files: []
+    task: "Create branch feature/notes, switch to it, add \"line 3\" to notes.txt, commit, then switch back to main. Use git branch to confirm both branches exist."
+    validations:
+      - label: "Feature branch created"
+        check: output-contains
+        pattern: "feature/notes|Switched to branch"
+      - label: "Commit on feature branch"
+        check: output-contains
+        pattern: "line 3|Third|feature"
+    hints:
+      - "Git has a shortcut to create and switch in one step. What might git checkout -b do?"
+      - "After making changes on the branch, commit them before switching back."
+      - "git checkout -b feature/notes, edit notes.txt, git add, git commit, then git checkout main"
+    agent_prompts:
+      on_start: "Why might you want multiple branches? What problem does branching solve when several people work on the same project?"
+      on_complete: "When you switched back to main, did notes.txt still have 'line 3'? Why or why not?"
+
+  - id: merge-conflict
+    title: "Resolve a Merge Conflict"
+    difficulty: intermediate
+    xp: 35
+    setup:
+      - "git init && git branch -M main"
+      - "echo 'Hello World' > greeting.txt"
+      - "git add greeting.txt && git commit -m 'Initial commit'"
+      - "git checkout -b feature-a"
+      - "echo 'Hello from branch A' > greeting.txt"
+      - "git add greeting.txt && git commit -m \"A's version\""
+      - "git checkout main"
+      - "git checkout -b feature-b"
+      - "echo 'Hello from branch B' > greeting.txt"
+      - "git add greeting.txt && git commit -m \"B's version\""
+      - "git checkout main"
+      - "git merge feature-a -m 'Merge A'"
+    files: []
+    task: "Merge feature-b into main. Resolve the conflict in greeting.txt by editing the file, removing conflict markers, staging, and completing the merge."
+    validations:
+      - label: "Merge attempted"
+        check: command-match
+        pattern: "git merge"
+      - label: "Conflict resolved"
+        check: output-contains
+        pattern: "Merge made|merge successful|Automatic merge"
+      - label: "Merge committed"
+        check: output-contains
+        pattern: "Merge branch|merge commit"
+    hints:
+      - "Run git merge feature-b. When you see CONFLICT, open greeting.txt and look for <<<<<<<, =======, >>>>>>>."
+      - "Edit the file to remove the markers and keep the content you want, then git add greeting.txt."
+      - "After staging the resolved file, run git commit (Git will suggest a default merge message)."
+    agent_prompts:
+      on_start: "When two branches change the same line in the same file, Git can't decide automatically. What would you look for in a conflicted file to understand what each branch changed?"
+      on_complete: "Could you have avoided this conflict? How might rebasing have changed the situation?"
+
+  - id: interactive-rebase
+    title: "Squash Commits with Interactive Rebase"
+    difficulty: intermediate
+    xp: 40
+    setup:
+      - "git init && git branch -M main"
+      - "echo 'fix 1' > changelog.txt && git add . && git commit -m 'wip'"
+      - "echo 'fix 2' >> changelog.txt && git add . && git commit -m 'typo fix'"
+      - "echo 'fix 3' >> changelog.txt && git add . && git commit -m 'oops forgot'"
+      - "echo 'fix 4' >> changelog.txt && git add . && git commit -m 'all done'"
+    files: []
+    task: "Use git rebase -i HEAD~4 to squash the 4 commits into 2. Change the second and fourth 'pick' to 'squash', save, and complete the rebase."
+    validations:
+      - label: "Rebase started"
+        check: command-match
+        pattern: "git rebase -i|git rebase --interactive"
+      - label: "Commit count reduced"
+        check: output-contains
+        pattern: "Successfully rebased|2 commits|2 files changed"
+    hints:
+      - "Interactive rebase lets you edit, squash, or reorder commits. Try git rebase -i HEAD~4."
+      - "In the todo list, 'pick' keeps a commit, 'squash' (or 's') combines it with the previous one."
+      - "Change lines 2 and 4 from 'pick' to 'squash', save and close. Git will then prompt for new commit messages."
+    agent_prompts:
+      on_start: "Why might you want to squash commits before pushing? What's the trade-off between a detailed history and a clean one?"
+      on_complete: "When would you avoid rebasing? Think about commits that others have already pulled."
+
+  - id: cherry-pick
+    title: "Cherry-Pick a Specific Commit Between Branches"
+    difficulty: advanced
+    xp: 40
+    setup:
+      - "git init && git branch -M main"
+      - "echo 'base' > config.txt && git add . && git commit -m 'base'"
+      - "git checkout -b feature"
+      - "echo 'A' >> config.txt && git add . && git commit -m 'Commit A'"
+      - "echo 'B' >> config.txt && git add . && git commit -m 'Commit B - the fix we need'"
+      - "echo 'C' >> config.txt && git add . && git commit -m 'Commit C'"
+      - "git checkout main"
+    files: []
+    task: "The feature branch has 3 commits (A, B, C). Cherry-pick only the middle one (Commit B) onto main. Use git log feature to find its hash."
+    validations:
+      - label: "Cherry-pick command used"
+        check: command-match
+        pattern: "git cherry-pick"
+      - label: "Correct commit applied"
+        check: output-contains
+        pattern: "Commit B|the fix we need|cherry-pick"
+    hints:
+      - "git log feature --oneline will show the commit hashes. The middle one is Commit B."
+      - "Cherry-pick applies a specific commit from another branch onto your current branch."
+      - "git cherry-pick <hash-of-B>. Use the full hash or the short 7-character prefix."
+    agent_prompts:
+      on_start: "Sometimes you want one commit from a branch but not the whole branch. What Git operation would you use? How is it different from merge?"
+      on_complete: "When might cherry-picking cause problems? Consider what happens if the picked commit depends on earlier commits from its branch."

package/modules/hiring-interviews/content.md

@@ -0,0 +1,130 @@
+# Technical Hiring — Structured Interviews That Find Signal
+
+<!-- hint:slides topic="Structured interview pipeline: scorecard, question types, rubrics, independent scoring, and bias mitigation" slides="6" -->
+
+## Why Structured Interviews Matter
+
+Unstructured interviews are **poor predictors** of job performance. They favor charisma, similarity bias, and the "gut feel" that often reflects our own biases. **Structured interviews**—same questions, same rubrics, independent scoring—improve reliability, fairness, and legal defensibility. The goal: **find signal, reduce noise.**
+
+Sources: *Who* (Smart & Street), *Work Rules!* (Laszlo Bock, ex-Google). Both emphasize: define what you need, ask the same questions, score against a rubric.
+
+## Designing a Scorecard
+
+Before writing questions, define the **scorecard**: what competencies matter, and how you'll evaluate them.
+
+**Must-have vs. nice-to-have:**
+- **Must-have** — Non-negotiable. Missing one = no hire.
+- **Nice-to-have** — Strengths that differentiate; can compensate elsewhere.
+
+**Example scorecard for a mid-level engineer:**
+
+| Competency | Must/Need | How We Assess |
+|------------|-----------|---------------|
+| Problem-solving | Must | Technical screen, system design |
+| Communication | Must | Behavioral, technical (explain reasoning) |
+| Collaboration | Must | Behavioral (STAR) |
+| Domain experience | Nice | Resume, technical depth |
+| Culture add | Nice | Behavioral, values alignment |
+
+**Rule:** Scorecard first. Questions and rubrics flow from it.
+
+## Interview Types
+
+| Type | Purpose | Format |
+|------|---------|--------|
+| **Behavioral** | Past behavior predicts future | STAR format; same questions for all |
+| **Technical** | Technical skill, problem-solving | Coding, debugging, or architecture; clear rubric |
+| **System design** | Architecture, trade-offs, scale | Whiteboard or diagram; scenario-based |
+| **Take-home** | Async signal; work sample | Bounded task; blind or semi-blind review |
+
+**Balance the mix:** Don't over-index on any one. Behavioral + technical + one other is typical.
+
+## Writing Good Questions
+
+### Behavioral: STAR Format
+
+- **S**ituation — Context
+- **T**ask — Their responsibility
+- **A**ction — What they did
+- **R**esult — Outcome, what they learned
+
+**Example:** "Tell me about a time you disagreed with a technical decision. What was the situation, what did you do, and what was the result?"
+
+**Rubric:** Strong answer = specific situation, clear ownership, concrete action, reflective outcome. Weak = vague, someone else did it, no reflection.
+
+### Technical: Clear Rubric
+
+- **Question:** Bounded, unambiguous. "Given an array of integers, find two that sum to target."
+- **Rubric:** What does strong/medium/weak look like? Edge cases? Optimization?
+- **Follow-ups:** Pre-prepared so interviewers probe consistently.
+
+**Example rubric:** Strong = correct solution, handles edge cases, discusses complexity. Medium = correct with hint. Weak = stuck, wrong approach, can't explain.
+
+## Conducting the Interview
+
+1. **Rapport (2–3 min)** — Brief intro, set expectations, put them at ease.
+2. **Calibration** — If multiple interviewers, align on rubric before the day.
+3. **Note-taking** — Take notes *during*; don't rely on memory. Quote key phrases.
+4. **Time management** — Reserve 5–10 min for their questions.
+5. **No leading** — Don't hint at answers; let them perform.
+
+**Candidate experience:** Start and end on time. Explain what's next. Thank them.
+
+## Evaluation: Independent Scoring and Debrief
+
+1. **Independent scoring** — Each interviewer scores *before* the debrief. No groupthink.
+2. **Debrief meeting** — Compare scores, discuss evidence, resolve discrepancies.
+3. **Hire/no-hire** — Based on scorecard; must-haves must be met.
+4. **Document** — Notes and scores for legal and calibration.
+
+**Calibration:** Periodically review: Are we too lenient? Too harsh? Use data.
+
+## Common Biases
+
+| Bias | What It Is | Mitigation |
+|------|------------|------------|
+| **Halo effect** | One strength overshadows weaknesses | Score each competency separately |
+| **Similarity bias** | Prefer people like us | Structured questions; diverse panel |
+| **Anchoring** | First impression dominates | Independent scoring; evidence-based |
+| **Recency** | Remember the end of the interview | Take notes throughout |
+| **Confirmation** | Seek evidence that matches initial view | Rubric first; look for disconfirming evidence |
+
+**Inclusive hiring:** Reduce unnecessary requirements (e.g., "CS degree"); focus on competency. Diverse interview panels. Bias training.
+
+## Candidate Experience
+
+- **Clear communication** — What to expect, how long, who they'll meet.
+- **Respect their time** — Start on time; don't overrun.
+- **Feedback** — If you reject, provide brief constructive feedback (where legally appropriate).
+- **Speed** — Don't leave them hanging for weeks.
+
+## Hiring Pipeline Flow
+
+```mermaid
+flowchart TD
+    A[Define scorecard] --> B[Screen resumes]
+    B --> C[Phone/technical screen]
+    C --> D[On-site: Behavioral]
+    C --> E[On-site: Technical]
+    C --> F[On-site: System design]
+    D --> G[Independent scoring]
+    E --> G
+    F --> G
+    G --> H[Debrief meeting]
+    H --> I{Hire/No-hire}
+    I -->|Hire| J[Offer]
+    I -->|No-hire| K[Reject + feedback]
+
+    style A fill:#3fb950
+    style G fill:#58a6ff
+    style H fill:#f85149
+```
+
+## Key Takeaways
+
+1. **Structured > unstructured** — Same questions, same rubric, independent scoring.
+2. **Scorecard first** — Define competencies before writing questions.
+3. **STAR for behavioral** — Situation, Task, Action, Result.
+4. **Clear rubrics for technical** — What does strong/medium/weak look like?
+5. **Mitigate bias** — Separate scoring, diverse panel, evidence-based.
+6. **Candidate experience** — Clear, respectful, timely.

package/modules/hiring-interviews/exercises.md

@@ -0,0 +1,88 @@
+# Technical Hiring — Exercises
+
+## Exercise 1: Create an Interview Scorecard
+
+**Task:** For a "Senior Backend Engineer" role, create a scorecard. Include: 4–5 competencies, must-have vs. nice-to-have, and how each will be assessed. Make it specific enough that two hiring managers would agree on what "strong" looks like.
+
+**Validation:**
+- [ ] 4–5 competencies
+- [ ] Must vs. nice clearly marked
+- [ ] Assessment method for each (behavioral, technical, system design)
+- [ ] At least one competency has a concrete "strong" description
+
+**Hints:**
+1. Common competencies: technical depth, problem-solving, communication, collaboration, ownership
+2. Must-have: can't ship without it. Nice: differentiates top candidates
+3. "How assessed" prevents overlap (e.g., don't assess "communication" in 3 different interviews)
+
+---
+
+## Exercise 2: Write Behavioral Questions
+
+**Task:** Write 3 behavioral questions using STAR format. Each should target a different competency (e.g., conflict, failure, collaboration). For one question, write a 3-level rubric (strong, medium, weak).
+
+**Validation:**
+- [ ] All 3 questions are open-ended and STAR-friendly
+- [ ] Questions don't overlap
+- [ ] Rubric has distinct levels with observable differences
+- [ ] Rubric is usable by another interviewer
+
+**Hints:**
+1. "Tell me about a time when..." — forces specificity
+2. Strong: specific situation, clear ownership, concrete action, reflection
+3. Weak: vague, someone else did it, no outcome, defensive
+
+---
+
+## Exercise 3: Design a Technical Screen
+
+**Task:** Design a 45-minute technical phone screen. Include: the question (or question type), rubric (strong/medium/weak), time allocation (setup, problem, follow-ups, candidate Q&A), and how you'd communicate the format to the candidate beforehand.
+
+**Validation:**
+- [ ] Question is bounded (solvable in 30–35 min)
+- [ ] Rubric covers correctness, approach, communication
+- [ ] Time allocation is realistic
+- [ ] Candidate gets clear pre-interview instructions
+
+**Hints:**
+1. Bounded: "Find two numbers that sum to target" not "Build a social graph"
+2. Follow-ups: edge cases, optimization, alternate approaches
+3. Pre-email: "You'll have 45 min. We'll share a doc; you can use any language. Camera on for discussion."
+
+---
+
+## Exercise 4: Bias Mitigation Checklist
+
+**Task:** Create a 5-item "bias mitigation" checklist for your interview process. Each item should be concrete and actionable (e.g., "Score each competency before debrief"). For each, explain which bias it addresses.
+
+**Validation:**
+- [ ] 5 items, each actionable
+- [ ] Each linked to a specific bias (halo, similarity, anchoring, etc.)
+- [ ] Checklist could be used by any interviewer
+- [ ] Items are implementable without major process change
+
+**Hints:**
+1. Independent scoring → reduces anchoring, groupthink
+2. Same questions for all → reduces similarity bias
+3. Rubric-first evaluation → reduces halo effect
+4. Diverse panel → reduces similarity bias
+5. Note-taking during → reduces recency bias
+
+---
+
+## Exercise 5: Candidate Experience Audit
+
+**Task:** Audit a hypothetical or real hiring pipeline from application to offer. List 5 touchpoints. For each, identify: what the candidate experiences, one potential pain point, and one improvement.
+
+**Validation:**
+- [ ] 5 touchpoints identified
+- [ ] Pain point is specific (not "could be better")
+- [ ] Improvement is concrete
+- [ ] Covers: application, screening, onsite, follow-up, offer
+
+**Hints:**
+1. Application: Is the form long? Is there a way to track status?
+2. Screening: How long do they wait? Do they get feedback?
+3. Onsite: Is the schedule clear? Are they left alone in a room?
+4. Follow-up: How quickly do you decide? Do you communicate?
+5. Offer: Is the process clear? Is the timeline respectful?

package/modules/hiring-interviews/module.yaml

@@ -0,0 +1,41 @@
+slug: hiring-interviews
+title: "Technical Hiring — Structured Interviews That Find Signal"
+version: 1.0.0
+description: "Conduct fair, structured technical interviews: scorecards, question design, bias mitigation, and candidate experience."
+category: leadership
+tags: [hiring, interviews, recruiting, structured-interviews, evaluation, team-building]
+difficulty: intermediate
+
+xp:
+  read: 15
+  walkthrough: 40
+  exercise: 25
+  quiz: 20
+  quiz-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 20
+  guided: 50
+
+prerequisites: []
+related: [one-on-ones, technical-mentoring]
+
+triggers:
+  - "How do I conduct technical interviews?"
+  - "How do I evaluate candidates fairly?"
+  - "What makes a structured interview?"
+  - "How do I avoid bias in hiring?"
+
+visuals:
+  diagrams: [diagram-flow, diagram-mermaid]
+  quiz-types: [quiz-drag-order, quiz-timed-choice]
+  slides: true
+
+sources:
+  - label: "Who by Geoff Smart and Randy Street"
+    type: book
+    url: "https://whothebook.com/"
+  - label: "Work Rules! by Laszlo Bock"
+    type: book
+    url: "https://www.workrules.net/"

package/modules/hiring-interviews/quick-ref.md

@@ -0,0 +1,68 @@
+# Technical Hiring — Quick Reference
+
+## Why Structured
+
+**Same questions, same rubric, independent scoring.** Improves reliability, fairness, legal defensibility.
+
+## Scorecard First
+
+1. Define competencies (4–6)
+2. Must-have vs. nice-to-have
+3. How each is assessed
+4. Write questions from scorecard
+
+## Interview Types
+
+| Type | Purpose |
+|------|---------|
+| Behavioral | Past behavior → future; STAR |
+| Technical | Coding, problem-solving, rubric |
+| System design | Architecture, trade-offs |
+| Take-home | Async work sample |
+
+## Behavioral: STAR
+
+- **S**ituation — Context
+- **T**ask — Their responsibility
+- **A**ction — What they did
+- **R**esult — Outcome, learning
+
+**Example:** "Tell me about a time you disagreed with a technical decision. Situation, task, action, result?"
+
+## Technical Rubric
+
+- **Strong** — Correct, edge cases, explains reasoning, optimization
+- **Medium** — Correct with hint, partial edge cases
+- **Weak** — Stuck, wrong approach, can't explain
+
+## Conducting
+
+1. Rapport (2–3 min)
+2. Calibrate before the day
+3. Take notes during
+4. Reserve time for candidate questions
+5. No leading — let them perform
+
+## Evaluation
+
+1. **Independent scoring** — Before debrief
+2. **Debrief** — Compare, discuss evidence
+3. **Hire/no-hire** — Must-haves met
+4. **Document** — Notes and scores
+
+## Common Biases
+
+| Bias | Mitigation |
+|------|------------|
+| Halo effect | Score each competency separately |
+| Similarity bias | Structured questions; diverse panel |
+| Anchoring | Independent scoring first |
+| Recency | Notes throughout |
+| Confirmation | Look for disconfirming evidence |
+
+## Candidate Experience
+
+- Clear communication (what to expect)
+- Start and end on time
+- Feedback when possible
+- Don't leave them hanging

package/modules/hiring-interviews/quiz.md

@@ -0,0 +1,73 @@
+# Technical Hiring — Quiz
+
+## Question 1
+
+Why do structured interviews outperform unstructured ones?
+
+A) They take less time
+B) They improve reliability, fairness, and legal defensibility
+C) They are easier to design
+D) They require fewer interviewers
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Structured interviews use the same questions and rubrics for all candidates. This improves reliability (consistent evaluation), fairness (reduces bias), and legal defensibility (documented, job-related criteria). Unstructured interviews favor charisma and similarity bias. -->
+
+## Question 2
+
+When should you define the interview scorecard?
+
+A) After writing the first question
+B) Before writing any questions
+C) During the debrief
+D) After the first candidate
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Scorecard first. Define what competencies matter and how you'll assess them before writing questions. Questions and rubrics flow from the scorecard. This ensures alignment and prevents ad-hoc, inconsistent evaluation. -->
+
+## Question 3
+
+What does STAR stand for in behavioral interviews?
+
+A) Skill, Task, Action, Result
+B) Situation, Task, Action, Result
+C) Strategy, Time, Analysis, Response
+D) Standard, Test, Assess, Review
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: STAR = Situation (context), Task (their responsibility), Action (what they did), Result (outcome, what they learned). It's a framework for getting specific, past-behavior examples that predict future performance. -->
+
+## Question 4
+
+Which bias occurs when one positive trait overshadows weaknesses?
+
+A) Similarity bias
+B) Halo effect
+C) Anchoring
+D) Recency bias
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: The halo effect: one strength (e.g., charisma, pedigree) leads us to overlook weaknesses. Mitigation: score each competency separately; use a rubric; look for disconfirming evidence. -->
+
+## Question 5
+
+When should interviewers score candidates?
+
+A) During the debrief, together
+B) After the debrief, individually
+C) Before the debrief, independently
+D) Only the hiring manager scores
+
+<!-- ANSWER: C -->
+<!-- EXPLANATION: Interviewers should score independently before the debrief. This prevents groupthink and anchoring—if you hear others first, you may adjust your score. Independent scoring preserves each person's judgment, then the debrief reconciles. -->
+
+## Question 6
+
+What is a key principle of inclusive hiring?
+
+A) Require a CS degree
+B) Focus on competency; reduce unnecessary requirements
+C) Prioritize "culture fit" above all
+D) Use only technical interviews
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Inclusive hiring focuses on competencies that predict performance. Unnecessary requirements (e.g., CS degree when equivalent experience works) exclude qualified candidates. Diverse panels, structured questions, and rubric-based evaluation support fairness. -->

package/modules/hiring-interviews/resources.md

@@ -0,0 +1,36 @@
+# Technical Hiring — Resources
+
+## Books
+
+- **Who: The A Method for Hiring** by Geoff Smart and Randy Street — Scorecard, structured interviews, topgrading.
+- **Work Rules!** by Laszlo Bock — Google's hiring practices; structured interviews, bias reduction.
+- **The Manager's Path** by Camille Fournier — Hiring for eng managers; interviewing, calibration.
+- **Hiring for the Startup** by Y Combinator — Practical hiring for early-stage teams.
+
+## Articles
+
+- [Google — How We Hire](https://rework.withgoogle.com/) — Re:Work guides on structured interviewing.
+- [First Round Review — Interviewing](https://review.firstround.com/) — Aggregated hiring and interview best practices.
+- [Lara Hogan — Demystifying the Engineering Manager](https://larahogan.me/blog/) — Hiring, interviewing, bias.
+- [Triplebyte Blog](https://triplebyte.com/blog) — Technical interviewing, bias, candidate experience.
+- [Workable — Structured Interview Guide](https://resources.workable.com/) — How to design and run structured interviews.
+
+## Videos
+
+- [LeadDev — Technical Hiring](https://leaddev.com/) — Conference talks on hiring.
+- [InfoQ — Hiring in Tech](https://www.infoq.com/) — Panels and talks.
+- [Laszlo Bock — Work Rules! Talk](https://www.youtube.com/results?search_query=laszlo+bock+work+rules) — Key concepts from the book.
+
+## Podcasts
+
+- [Engineering Culture by InfoQ](https://www.infoq.com/podcasts/engineering-culture/) — Hiring, interviews.
+- [LeadDev podcast](https://leaddev.com/podcast) — Hiring, team building.
+- [Lenny's Podcast](https://www.lennyspodcast.com/) — Hiring leaders, interview design.
+
+## Tools
+
+- [Lever](https://www.lever.co/) — ATS with structured interview support, scorecards.
+- [Greenhouse](https://www.greenhouse.io/) — Hiring software; structured interview kits.
+- [Interviewing.io](https://interviewing.io/) — Anonymous technical interviewing practice.
+- [Lattice](https://lattice.com/) — Performance and hiring; scorecards.
+- [Notion](https://www.notion.so/) — Scorecard templates, interview guides.