Writing Methodology Inputs

Given a vague self-description, transform it into a high-scoring methodology input by answering: What do you do first, second, third? With what tools? Using what criteria? Can you walk through a real example?

Low-scoring input:

"tech recruiter, 8 years exp. i source, screen, and close engineering candidates. good at passive outreach and salary negotiation."

High-scoring rewrite:

"I'm a technical recruiter specializing in engineering roles at early-stage startups. My process: I source candidates through LinkedIn boolean searches and GitHub activity, screen them with my MATCH framework (Motivation, Aptitude, Technical depth, Culture fit, Hunger), then guide them through the full interview loop. I always prep candidates before each round and debrief hiring managers after."

Progress:

• Step 1: Extract the raw claim (what they say they do)
• Step 2: Interrogate for process — ask "what's step 1, 2, 3?"
• Step 3: Interrogate for tools — ask "what specific software/framework/technique?"
• Step 4: Interrogate for criteria — ask "how do you decide good vs. bad?"
• Step 5: Interrogate for a real example — ask "walk me through one actual case"
• Step 6: Interrogate for edge cases — ask "what do you do when it breaks?"
• Step 7: Rewrite combining at least 3 of the above elements into flowing prose
• Step 8: Check against anti-patterns and strip vague/identity-only language

Step details

1. Identify the raw claim. Take the input at face value — job title, years of experience, general skills. This is your baseline; it's usually thin.

2. Extract process. Push for sequence: "First I do X, then Y, then Z." If they only give a list of duties, ask which duty comes first and what triggers the next one.

3. Extract tools and named frameworks. Generic tool lists ("Python, JavaScript, React") don't score well alone — pair each tool with how it's used. Named frameworks (even personal ones, like "MATCH") score especially high.

4. Extract decision criteria. Look for if/then logic: "If the candidate fails the technical screen, I loop back to sourcing; otherwise I schedule the panel." Decision trees are high-impact.

5. Extract a real example with numbers. Quantified outcomes ("Screened 50, interviewed 15, placed 3") make the methodology concrete and verifiable.

6. Extract edge cases. What happens when the standard process fails? This shows depth beyond the happy path.

7. Synthesize. Weave process + tools + criteria + example into a single natural paragraph or two — not a bullet list of disconnected facts.

8. Filter anti-patterns. Remove vague goals, identity statements, undifferentiated tool lists, and pure philosophy (see Common Pitfalls).

Example 1: Program Manager Input (medium, ~40-70):

"Program manager focused on product launches. I coordinate engineering, design, marketing, and legal. I'm good at identifying dependencies early and keeping stakeholders aligned without endless meetings."

Extraction questions to ask: How exactly do you identify dependencies — a tool, a template, a ritual? What replaces the meetings — async updates, a specific doc format? Walk through one launch start to finish.

Rewrite (high):

"I run product launches by first building a dependency map across engineering, design, marketing, and legal in a shared RACI doc during kickoff week. I flag cross-team blockers before sprint planning by running a 15-minute async Loom review instead of a status meeting. If a dependency slips, I escalate directly to the owning lead within 24 hours rather than waiting for the next sync. On my last launch, I coordinated 6 teams and shipped on the original date despite 3 major scope changes."

Example 2: Sales Engineer Input (low):

"SE at a devtools company. I do demos, POCs, and help close technical deals. good at translating features into business value"

Rewrite (high):

"I'm a sales engineer who runs technical demos and POCs for enterprise SaaS deals. My approach: I never demo features, I demo outcomes. Before any call I research the prospect's tech stack, identify their likely pain points, and build a custom demo environment that mirrors their setup. During the call I ask discovery questions first, then show only the 3-4 features that solve THEIR problems. I always leave time for hands-on exploration. Post-demo I send a personalized follow-up with a Loom walkthrough of their specific use case."