Job Application Answers

Draft personalized, human-sounding answers to job application questions, grounded in what the user has actually done.

Why this skill exists

Most job application answers fail in one of two ways: they're generic ("I am passionate about building scalable systems"), or they're obviously AI-written (em dashes, "pivotal", "testament to", rule-of-three everywhere). Recruiters and hiring managers spot both instantly. This skill produces answers that are specific to the user's real background and free of AI-writing tells.

Process

Walk through these steps in order. Don't skip step 3 — it's the difference between a generic answer and one that gets a callback.

1. Capture inputs

Pull these from the user's message:

• The question(s) — the literal text of what's being asked
• The role / company — if mentioned; if not, ask once
• The job description — if attached or pasted, read it carefully (it tells you what to emphasize)
• Format constraints — word limits, character limits, paragraph counts
• ATS keywords — If a JD is present, scan for the 3-5 terms that appear most often in the requirements/responsibilities section (e.g., "distributed systems", "cross-functional", "Python async"). Note them. Before finalizing any answer, verify each keyword appears at least once, placed naturally. One mention per keyword is enough — keyword-stuffing is detectable and reads worse than omission.
• Tone signal — Skim the JD's first few sentences. "You'll own..." is casual startup voice. "The candidate will be responsible for..." is formal enterprise voice. Note the register and mirror it in the draft.

If the user dropped multiple questions at once, batch them and produce all answers in one response. Don't ping-pong.

2. Company research (if company is named, and only then)

Skip this step entirely if the question is purely behavioral and doesn't reference a company ("tell us about a time you..."). Skip if no company name has been mentioned. The point is to make "Why this company?" and "Why this role?" answers reference specifics the user couldn't have written about any other company.

When the company is named:

One search, then one targeted fetch. Don't do exhaustive research — you have a ~30-second budget. Run a single web_search like "[company name] engineering blog" or "[company name] recent product launch". Look for:

• Recent product launches or feature ships (last 6 months)
• The company's own framing of what they do (read 2-3 sentences from their site, not the press releases written about them)
• Tech stack mentions in their engineering blog or job listings
• Recent funding, team size, growth signal
• A specific technical problem they've written about solving

If one good URL surfaces (their engineering blog, an "About" page, a recent announcement), use web_fetch on it. One fetch, not five.

What to extract: one or two concrete things the user can name in the answer. "I've been following your work on [specific thing]" only works if it's a real thing they actually do. Generic ("I love your mission") signals zero research.

What to skip: their Crunchbase profile, their Wikipedia entry, their LinkedIn About page. These are too generic to add signal. Engineering blogs, product launch posts, and the company's own product pages are where the gold is.

Don't fabricate signal from absence. If the company has no public engineering blog and no recent announcements, say so to the user. Don't invent technical depth that isn't there.

3. Build the background (fallback ladder)

Use this ladder. Stop as soon as you have enough material to write a specific, evidence-backed answer.

Environment note: Steps 3a and 3b assume access to Claude's memory and conversation_search, which exist in Claude.ai but not in Claude Code or OpenCode. In environments without these, skip straight to 3c — ask the user narrowly for what you need. The skill still works; it just leans more on the user for context.

Step 3a — Read Claude's memory. Memory is already in your context. Look for: projects the user has built, technical strengths, prior roles, education, side projects, recent learning, problems they've debugged, decisions they've made. If memory already contains a story or fact that fits the question, you're done with retrieval — move to drafting.

Step 3b — Search past conversations. If memory is thin on the specific angle the question wants (e.g. the question asks about a time the user disagreed with a teammate, and memory has no such story), call conversation_search with 1-3 distinctive keywords tied to the question — not generic terms like "story" or "experience." Examples:

• Question about debugging → search "debug", "production bug", or a tech they use
• Question about leadership → search "led", "mentored", "owned"
• Question about a hard tradeoff → search the domain (e.g. "auth", "latency")

Read the snippets that come back; pull concrete details.

Step 3c — Ask the user, narrowly. If 3a and 3b still leave a gap, ask the user for the specific thing missing. Not "tell me about yourself." Not "what are your strengths." Ask:

• "What's a specific bug or hard debugging session you've worked on recently?"
• "Which project from your background has the clearest metrics I can name?"
• "Have you had a disagreement on a technical decision you can walk me through?"

Only ask for what you actually need. One precise question beats five vague ones.

4. Draft the answer

Every answer must anchor to a specific thing the user has actually done — a system they built, a metric they moved, a tradeoff they made, a problem they solved. The failure mode is abstract enthusiasm ("I love building scalable systems"). The fix is concrete artifacts ("I built X, which handled Y, and the tricky part was Z").

Question-type patterns:

"Why this role?" Connect a specific aspect of the role (pulled from the JD if available) to something the user has actually built or learned. Keep the excitement to one sentence; spend the rest on evidence. If the JD mentions a specific tech or problem space the user has touched, name it.

"Why this company?" This is the answer that most benefits from step 2's research. Two angles work: (a) a technical thing the company does that the user has engaged with as a user or builder, or (b) a specific product decision, thesis, or recent shipped feature that matches what the user wants to work on. Name the thing you found in research — a specific blog post they wrote, a feature they shipped, a problem they've talked about solving. Avoid generic mission praise ("I believe in your mission to..."). The test: if the answer would work for any of their competitors, rewrite it.

"Tell us about a project you're most proud of" Compact arc: problem (1 line) → user's specific contribution (the bulk, in first person — "I built", not "we built") → what shipped → outcome with numbers if available. If memory shows a clear flagship project, use it. If multiple, pick the one most relevant to the role.

Behavioral: "Tell us about a time you..." Compressed STAR: Situation (1 line) → Action (most of the answer) → Result (1 line). Skip the "Task" — fold it into Situation. Keep the action specific to what the user did, not what the team did.

Strengths Pick one strength + one concrete artifact that proves it. "I'm fast at picking up new stacks — I shipped my first production FastAPI service two weeks after first touching Python async."

Weaknesses Pick something real the user is actively addressing. Never the disguised-strength ("I'm too detail-oriented"). Show the awareness and the work, not the hedge.

"Why should we hire you?" The most underrated answer: pick one thing about the role/team that you uniquely match, name it, prove it with one artifact. Don't list five strengths.

Open-ended ("Anything else you'd like us to know?") Default to a short, specific signal — a