Skill detail

hiring

Structure the interview process, calibrate the hiring bar, counter bias, and evaluate a new hire's first 90 days.

Why we recommend it: Structures interview loops, hiring bar calibration, bias countering, and new-hire 90-day evaluation — core EM people-management work.

MatchDirectRecommended for Engineering Managers
Sourcemanager-dot-dev/​manager-skillsExternal source
Reported installsNot reportedPopularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: hiring
description: Helps structure the interview process, calibrate the hiring bar, counter interview bias, and decide between promoting internally vs. hiring externally. Also covers evaluating a new hire's fit during their first 90 days. Use when the user says "interview," "hire," "job description," "JD," "interview loop," "debrief," "hiring bar," "offer," "reject," "sourcing," "recruiter," "headcount," "should I hire a junior," "promote from within," or "new hire isn't working out." Do NOT use for ongoing performance management of an established team member (use performance-reviews).
metadata:
  version: 2.1.2
---

# Hiring

## Before Starting

Check for EM context first. If `.agents/em-context.md` exists, read it.

If `.agents/em-context.md` does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and `.agents/reports/[name].md` does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update `.agents/em-context.md` or `.agents/reports/[name].md` automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.
---

## Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:
- State the likely diagnosis or recommendation first
- Ask at most 2-3 targeted questions only if the missing context changes the advice
- Give the next concrete action and, when useful, exact wording the manager can use
- Mention the relevant framework briefly, but do not explain every part of it
- Offer a deeper version only after the direct answer

---

## How to Use This Skill
Identify the situation first:

- **Structuring the interview or deciding on a work sample** → See the Work Before You Hire
- **Calibrating seniority level / case for hiring juniors** → Why You Should Hire Juniors
- **Worried about cultural bias affecting the evaluation** → The Beer Test Bias
- **Deciding between internal promotion and external hire for a management role** → Internal vs. External
- **New hire isn't meeting expectations — wondering if you should act** → Setting Up New Hires for Objective Evaluation

---

## Default Response Shape

When helping with hiring, turn the advice into a hiring artifact:

1. **Hiring goal:** what problem this role or hire must solve.
2. **Bar / evidence:** what evidence should prove the candidate can do it.
3. **Process:** interview loop, work sample, debrief, or 30/60/90 plan.
4. **Bias check:** where the decision may be distorted by similarity, urgency, or sunk cost.
5. **Decision language:** concise recommendation: hire, reject, calibrate, or gather more evidence.

For new-hire concerns, shift from candidate evaluation to objective 30/60/90 success criteria.

---

## Setting Up New Hires for Objective Evaluation

The most common new manager mistake is tolerating underperformers because they're improving. The fix starts on day one.

**Define success in advance.** Before the person starts, write down concrete expectations:
- How long before they can complete a task in repo X without help?
- What type and size of tasks do you expect at 30 / 60 / 90 days?
- When should they be contributing to on-call? To technical design?
- For senior hires: what inputs and initiative do you expect from them?

Without this, you'll drift toward forgiveness. A small improvement will feel like success because you have no anchoring standard.

**Use the "would I hire today?" checkpoint.** At 30 days (and again at 60 and 90), ask yourself one question: "Knowing what I know now, would I hire this person?"
- If yes: tell them. It builds real commitment.
- If no: act. Every da
Read the full source on GitHub (opens external page)
Context

Related work