career-interview

Files (1)

• SKILL.md

SKILL.md (first lines)

# /career-interview - fill the gaps by asking well

The record is never finished, so this never fully stops. But the user controls the volume, and the fastest way to make this worthless is to ignore that.

Optional argument: an area to focus on (`spine`, a role name, `wins`, `praise`, `preferences`, `voice`, `skills`).

## Before asking anything

1. Read `STATE.md`: `question_intensity`, `motivation`, the open questions queue, the coverage table, and the thin claims list.
2. Read enough of `Roles/`, `Wins/`, and `Praise/` to know what you already have. **Never ask for something the vault already contains.** Being asked twice is the clearest possible signal that nothing is being retained, and it is the most common reason people abandon a tool like this.
3. Pick the area with the highest ratio of value to effort. Order of precedence: an incomplete spine beats everything; a thin claim that `PROFILE.md` currently leans on beats a new topic; a role the user has shown energy about beats a role they have not.

## Intensity

| Setting | Behaviour |
| --- | --- |
| `high` | Long sessions. Follow interesting threads sideways. Six to eight questions per batch. |
| `normal` | Three to five questions per batch. Stop when the topic is covered rather than when it is exhausted. |
| `low` | Only ask what blocks work in progress. No exploratory questions. Two questions maximum. |
| `paused` | Ask nothing unprompted. File what is volunteered. Say once, at the end, that questions are paused and how to resume them. |

**Lowering is durable.** "Ease off", "fewer questions", "that's enough for now", "let's move on", "can we just do the job search" all mean: write the lower setting into `STATE.md`, confirm in one short line, and continue at that level in this and every future session. Do not drift back up. Do not ask them to confirm they really meant it.

**Watch for unstated fatigue** too. Answers getting shorter, "I guess", "sure", "whatever you think", or hedged non-answers three times running. When you see it, do not push through the batch. Say you have enough for now, offer to switch to something with visible output like `/career-synthesize` or `/career-jobs`, and drop the setting one level.

**Raising requires an explicit ask.** "Ask me more", "go deeper", "I've got time".

## Asking well

- **Reflect before you ask.** Open with what you already believe, from the ingested sources, and invite correction. "From your LinkedIn and two Granola calls, it looks like you owned the docs rewrite and the partner integrations at Acme, and that the community work was Priya's. Right?" People correct far more readily than they volunteer, and a correction carries more information than an answer to an open question.
- **Ask about a specific thing, not a category.** "Tell me about your achievements at Acme" produces nothing. "You shipped the SDK in March and then the numbers doubled by June. What did you personally do in those three months?" produces a win note.
- **Use AskUserQuestion for anything enumerable** - preferences, ratings, which of several roles to go deep on, dealbreakers, yes or no calls. Use plain prose questions for stories, because multiple choice flattens exactly the detail you want.
- **One story at a time.** Batching works for facts and preferences. It destroys stories, because the user answers the last question and forgets the first two.
- **Chase the beneficiary.** When someone describes an achievement, they almost always omit who it helped. "Who was better off afterwards, and how would they have noticed?" is the highest-yield follow-up in this entire skill.
- **Chase the counterfactual.** "What would have happened if you had not been there?" separates work they did from work that needed them specifically. This is what seniority actually is, and almost nobody writes it down.
- **Take the verbatim.** When they say why they are proud of something, or why they hated something, keep their exact words. That phrasing is the raw material for anything that later needs to sound human.
- **Let silence stand.** If they say "I don't know", accept it, log it as an open question, and move on. Pushing produces invented answers, and invented answers poison a record whose only value is that it is true.

## What only a person can tell you

Ingestion gets dates, titles, projects, and public output. Spend the interview on what it cannot get:

- What they are proudest of, and why that one rather than the bigger one
- What they were good at that nobody noticed
- What they got credit for that was really someone else's
- What broke, what they did about it, what they learned
- The constraints that made an ordinary result impressive
- What people come to them for, unprompted
- What drains them even though they are good at it
- What they would refuse to do again, and why
- How a role really ended, as distinct from the public version
- Which decisions were genuinely hard, and how they made them

## Area guides

**Spine** (do first, always). Every role stubbed: employer, title, dates, employment type, company stage and size, who they reported to, team size. Include contracts, founding, volunteering, and significant side work. Gaps in the timeline get a note explaining them, because an unexplained gap on a record is a question you want answered on your own terms.

**Per role.** Why they were hired, what they owned outright versus influenced, how the role changed, the constraints, how it ended. Then two to four wins.

**Wins.** Situation, their specific contribution, who benefited, what changed, evidence, what they learned, why they are proud. Rate `evidence` honestly. A win with no external evidence is still worth having, and is also the best possible target for `/career-ingest` to go looking.

**Developer relations specifics.** Talks and workshops, with venue, size, and what came of them. Content and docs, and whether anyone can tell it worked. Community: what they built, what the real numbers were, and what they thought of the metrics they were held to. The feedback loop: times they changed the product, not just described it - this is the single most undersold thing in developer relations and the thing that separates a strong candidate from a content producer. Internal influence: getting engineering or product to act without authority. Events and budget ownership. Hiring and mentoring.

**Skills.** Derive candidates from the wins rather than asking for a list, then confirm level and whether they enjoy it. Self-reported skill lists are worthless; skills backed by a specific win are not.

**Preferences.** Best and worst working conditions, with the role each came from. Energy audit: which parts of a normal week they look forward to. Dealbreakers with reasons.

**Voice.** Only if `Voice/Voice Profile.md` is thin and there is nothing in `Incoming/`. Prefer asking them to drop old cover letters into `Incoming/` over asking them to describe how they write, because nobody describes their own writing accurately.

## Filing

File each answer as it arrives, before asking the next question. Never batch to the end of the session; sessions get interrupted and the work is lost.

- New role, win, praise, skill, or person: create the note from the matching template in `<vault>/Templates/`.
- Existing note: update it, refresh `updated`, and keep their phrasing where it is better than yours.
- Anything unresolved: add it to the open questions queue with a note on why it matters.
- Anything volunteered that is off-topic: file it correctly anyway, confirm in one line, and return to where you were.

Keep confirmations short. "Filed that under Wins as the docs rewrite" is enough. Reading back a full formatted note after every answer makes a twenty minute session feel like an hour.

## Ending

Update `STATE.md`: coverage table, open questions, ingestion log if relevant, and a one line session log entry. Commit.

Then tell them, in prose: what got added, the most interesting thing that came out of it, and one specific next step. If the session produced enough new evidence to change the positioning, say that `/career-synthesize` will now say something different, and why.

From bendechrai/career-brain, MIT.

More from bendechrai/career-brain