Hiring Interview Notes

---
name: Hiring Interview Notes
description: 'A shape for hiring loops that survive past the offer. Roles, candidates,
  rubric scores, decisions. Claude and ChatGPT compare candidates against your real
  rubric, not vibes.

  '
tags:
- role
- candidate
- rubric
- decision
- reference
containers:
- name: Hiring Interview Notes
  description: The memory of every hiring loop. Candidates, rubric, decisions, references.
  llm_instructions: |
    This is a hiring repository. The goal is to make hiring decisions traceable to real evidence and to keep loops consistent across roles.
    - When asked to compare candidates, read the Rubric for the relevant role first, then the Candidate notes. Score against the rubric explicitly.
    - Never invent quotes, references, or score justifications. If the Candidate note does not contain the detail, say so plainly.
    - Be discreet. Never include personal information outside what was shared during the interview process.
    - When the user closes a role, suggest writing a Decision note that captures who was hired, why, and what the runners-up did better.
    - This is a notes system, not an ATS. Do not pretend to send emails, schedule, or track applicants externally.
  children:
  - name: Roles
    description: One note per open or closed role. Job description, must-haves, nice-to-haves.
    llm_instructions: |
      Use this folder for the role itself.
      - One note per role. Title format: "<Role> <Year>".
      - Include: Reason for hiring, Must-haves, Nice-to-haves, Comp band, Hiring panel.
      - When a role closes, link the matching Decision note.
      - Tag every note with "role".
  - name: Candidates
    description: One note per candidate. Background, panel notes, rubric scores.
    llm_instructions: |
      Use this folder for candidate notes.
      - One note per candidate, scoped to one role. Title format: "<First Last> for <Role>".
      - Use the shipped skeleton: Background, Panel notes per round, Rubric scores, Strengths, Concerns, Reference check, Outcome.
      - Always cite the round and interviewer when quoting from panel notes.
      - When the candidate is referenceable, suggest creating a note in References for future re-engagement.
      - Tag every note with "candidate".
  - name: Rubric
    description: Scoring criteria per role. Definitions of what each level means.
    llm_instructions: |
      Use this folder for the standard a candidate is measured against.
      - One rubric per role. Title format: "Rubric: <Role>".
      - For each criterion, define what a low, medium, and high score looks like in plain language.
      - Treat the rubric as binding. When scoring a candidate, point to the level definition that justifies the score.
      - Tag every note with "rubric".
  - name: Decisions
    description: Hiring outcomes per role. Why the chosen candidate beat the runners-up.
    llm_instructions: |
      Use this folder for closing-the-loop notes.
      - One note per closed role. Title format: "Decision: <Role> <Year>".
      - Include: Who was hired, Why, Runners-up and their strengths, What the loop got right, What to change next time.
      - Cross-link to the Role note and to the Candidate notes for all finalists.
      - Tag every note with "decision".
  - name: References
    description: Candidates worth re-engaging on a future role.
    llm_instructions: |
      Use this folder for strong candidates who did not get the role.
      - One note per person. Include: When you met, Which role, Why they were strong, What kind of future role would fit, How they prefer to be re-engaged.
      - Be honest and discreet. Frame strengths and fit, not weaknesses.
      - Tag every note with "reference".
  notes:
  - title: Senior Backend Engineer 2026
    body: |
      A starter role note. Replace with a real role.

      ## Reason for hiring
      Our existing backend engineer is bottlenecked on infrastructure work. We want one senior hire to own the API and queue layer.

      ## Must-haves
      - 5+ years building production backend services.
      - Comfortable owning a system end to end, including on-call.
      - Strong written communication.

      ## Nice-to-haves
      - Experience with Ruby on Rails.
      - Familiarity with SQLite at scale.

      ## Comp band
      Replace with your real range.

      ## Hiring panel
      Founder, existing backend engineer, generalist.

      This is a starter note. Replace it with a real role.
    tags:
    - role
    container_path: Hiring Interview Notes > Roles
  - title: 'Rubric: Senior Backend Engineer'
    body: |
      A starter rubric. Replace with your real scoring criteria.

      ## Systems thinking
      - Low: solves the local problem, does not ask how it interacts.
      - Medium: identifies upstream and downstream effects when prompted.
      - High: proactively maps blast radius before writing code.

      ## Code quality
      - Low: works but is hard to follow.
      - Medium: clear, idiomatic, lightly commented.
      - High: clear, idiomatic, plus tests that pin down the contract.

      ## Communication
      - Low: gives short answers that hide the reasoning.
      - Medium: explains decisions clearly when asked.
      - High: writes the decision down without being asked.

      ## Ownership
      - Low: hands work off at PR submit.
      - Medium: follows up after merge.
      - High: monitors the production impact and writes the postmortem if it breaks.

      This is a starter note. Replace it with your real rubric.
    tags:
    - rubric
    container_path: Hiring Interview Notes > Rubric
  - title: Alex Martinez for Senior Backend Engineer
    body: |
      A starter candidate note. Replace with a real candidate.

      ## Background
      Eight years at two mid-stage SaaS companies. Last two years owning the billing service end to end.

      ## Panel notes
      ### Phone screen (Founder)
      Strong written portfolio. Clear about why they want to leave their current role.

      ### Technical (Backend engineer)
      Walked through the design exercise without prompting. Asked about our queue choice unprompted.

      ### Communication (Generalist)
      Clear, concise, asked what success looks like in the first 90 days.

      ## Rubric scores
      - Systems thinking: High.
      - Code quality: Medium.
      - Communication: High.
      - Ownership: High.

      ## Strengths
      Asks about blast radius before writing code. Strong written.

      ## Concerns
      Code in the exercise had minor style drift. Easy to coach.

      ## Reference check
      Past manager confirmed billing service ownership and postmortem authorship.

      ## Outcome
      Replace with the real outcome.

      This is a starter note. Replace it with a real candidate.
    tags:
    - candidate
    container_path: Hiring Interview Notes > Candidates
  - title: 'Decision: Senior Backend Engineer 2026'
    body: |
      A starter decision note. Replace with a real one.

      ## Who was hired
      Replace with the real name.

      ## Why
      Highest combined score on Systems thinking and Ownership. Reference check confirmed both.

      ## Runners-up
      - Strong communicator with weaker systems thinking. Better fit for a future product engineer role.

      ## What the loop got right
      Rubric-first scoring made the final comparison clear.

      ## What to change next time
      Move the design exercise earlier. Two candidates dropped after they realized the scope.

      See [[Senior Backend Engineer 2026]].

      This is a starter note. Replace it with a real decision.
    tags:
    - decision
    container_path: Hiring Interview Notes > Decisions
  - title: 'Reference: Priya Shah'
    body: |
      A starter reference note. Replace with a real strong candidate.

      ## When we met
      Final round for Senior Backend Engineer 2026.

      ## Why she was strong
      Top of the panel on Communication. Wrote the cleanest design doc we have ever seen from a candidate.

      ## What kind of future role would fit
      A platform or developer experience role where the writing matters as much as the code.

      ## How she prefers to be re-engaged
      Email, with a clear role description attached, not a recruiter pitch.

      This is a starter note. Replace it with a real reference-worthy person.
    tags:
    - reference
    container_path: Hiring Interview Notes > References