Job application answers

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 side project, a relevant interest, something that completes the picture. If nothing strong, leave it blank; padding hurts more than it helps.

"Where do you see yourself in 5 years?" The trap is either too vague ("growing as an engineer") or too rigid ("VP of Engineering"). The answer that works: a direction, not a destination. Name a problem space or capability the user wants to go deep on, connect it to the role ("this role is the right next step because it's exactly where that work happens"), and keep the horizon honest. If the user genuinely doesn't know, that's workable — name the kind of work rather than the title.

"What motivates you?" Don't answer with "I love solving hard problems" — everyone says this. Instead, anchor to a specific type of moment: when did the user last feel locked in? Was it a tricky debugging session, shipping something users reached for immediately, or explaining a complex system clearly? Name the moment type and let it answer the question. One example beats five adjectives.

"Describe your ideal work environment" Read the company's JD tone and culture signals first (from Step 1). Mirror what you see: a startup that says "you'll own this" wants "I do my best work with clear ownership and room to make calls." An enterprise posting will value "I like structure around decision-making with collaborative review." Don't invent preferences that contradict the role — this question is partly a fit screen.

"What's your biggest failure?" Distinct from "weakness." The failure question wants a story, not a trait. Structure: what you tried → what went wrong → what you'd do differently now. The failure should be real and meaningful, not a disguised success ("my biggest failure was shipping too fast and having to fix bugs"). The "what you'd do differently" line is the actual signal — it shows judgment. Don't pick a failure that would disqualify you for this specific role.

Cover letter opening paragraph Not the same as "why this role." It's the hook — the reason a recruiter keeps reading. One pattern that works: open with a specific thing you noticed about the company or role (from Step 2 research), then make one concrete claim about what you bring. Avoid: "I am writing to apply for..." (obvious), "I am passionate about..." (every applicant), and name-dropping the company in the first word (they know who they are). Length: 3-4 sentences. The full cover letter is out of scope for this skill unless the user asks for it.

5. Humanizer pass

Drafts almost always come out with AI-writing tells. Apply the humanizer pass before showing the user anything.

Read references/humanizer-rules.md for the full pattern list. Quick version of what to cut:

• Significance inflation: "pivotal", "testament to", "underscores", "stands as a", "marks a turning point"
• Promotional adjectives: "groundbreaking", "robust", "cutting-edge", "seamless", "powerful"
• -ing trailers: "...highlighting X", "...reflecting Y", "...ensuring Z"
• Rule of three: "fast, reliable, and scalable" (cut to one or two)
• Em dashes that aren't doing real work — use a period or comma instead
• Negative parallelism: "It's not just X, it's Y"
• Filler openers: "At its core", "In essence", "Ultimately"
• Generic conclusions: "Exciting times ahead", "the future looks bright"
• Even sentence rhythm — vary length, let some land short

Then do the audit step. Ask yourself: "What would still flag this as AI-written?" Whatever remains, fix it. Most common surviving tells: too-tidy structure, overly even cadence, missing first-person ownership.

6. Output

Show the user:

1. The final answer(s), labeled by question if there are multiple
2. Word/character count for each, if there was a limit
3. A short "I assumed X — let me know if that's off" note for any gap you filled in
4. An offer to adjust tone, length, or specific phrasing
5. Memory capture offer — If the user named a specific project, role, or story that came up strongly and isn't already captured in memory, offer to save it: "Your [project/story] came up well here — want me to save it to memory so future applications can pull from it without re-explaining?" Only offer this once per session, for the most substantive piece of background. Don't offer for generic claims.

Don't show the unhumanized draft. Don't narrate the process. The user wants the answer, not the audit trail.

Revision mode

When the user asks to adjust a delivered answer ("make it shorter", "less formal", "cut the last sentence"):

• Don't re-research. Don't re-run company search or memory retrieval.
• Don't re-humanize from scratch. Take the existing draft as the base.
• Apply the specific requested change only.
• Output the revised answer with the updated word count. No before/after comparison unless asked.

Common revision types:

• "Shorter" — cut the wind-up sentence first. Then tighten the result line. Preserve the concrete artifact; that's the one thing that can't go.
• "More casual" — break a long sentence into two, add a contraction, swap one formal word for its plain equivalent ("utilized" → "used", "leverage" → "use").
• "More formal" — remove contractions, convert personal asides to declarative statements, cut any hedging.
• "Stronger ending" — delete the generic conclusion, replace with a specific forward signal or a concrete fact about the user's next move.
• "Different story" — this is a re-draft, not a revision. Ask which project or story to use, then re-run from Step 3.

Things to push back on

• Fabrication requests. If the user asks you to claim something memory contradicts ("say I led a team of 10" when memory shows solo work), flag it and offer a true alternative framing. Recruiters check.
• Underselling. The reverse problem. If the user frames their contribution as smaller than what they've described ("just write it as if I was one of the devs"), flag it: "From what you've described, you made the core architecture call here — framing it as 'one of the devs' undersells you. Want me to write it accurately?" Offer the accurate framing. Don't comply with a deflated version.
• Visa / sponsorship claims. Never invent policy statements about the user's work authorization. If a question touches sponsorship, let the user supply the literal answer.
• Compensation or availability claims. Same — these are facts the user owns, not material to invent.

Edge cases

• Tight word limits (under 100 words): cut hard. One concrete fact plus the angle beats three vague sentences. Often the first sentence of the draft is wind-up; delete it.
• No memory, no past chats, user gives nothing: ask once for one specific thing, then write the best generic-but-clean answer you can with a clear note that it'll be stronger if they add detail X.
• Multiple questions, conflicting angles: pick a different concrete story for each — don't reuse the same project across every answer in the same application.
• The question is unclear or trick-ish ("Tell us something interesting"): ask the user how they want to play it before drafting.

Brief example

Input:

"Tell us about a project you're most proud of. (200 words)"

Process: Check memory → user has a SaaS product they built with specific tech stack and traffic numbers → draft using the compact arc → humanizer pass → output.

Output (draft, post-humanizer):

I built [Product] because I kept hitting the same friction myself: [problem]. The version that exists now is a [stack] app handling [traffic metric]. The piece I'm proudest of isn't the feature list — it's the [specific technical decision] I made early on. [Brief reason why it mattered.] [What it enabled later.] Shipping it taught me [specific lesson], which has shaped how I scope every project since.

(199 words. Anchored to a real project, first-person, no significance inflation, no rule of three, varied rhythm.)