Skills Transfer Evidence Map

# Skills Transfer Evidence Map

Use this to translate experience from one role, industry, stack, or career path into evidence for a target role. It is designed for candidates, recruiters, and hiring managers to use from role definition through the recruiter screen.

Transfer is not a claim that two contexts are identical. A credible map shows the shared behavior, the evidence that proves it, the material differences, and the smallest bridge needed to perform in the new context.

## Two Ways To Use This File

### Candidate

1. Start with three to five outcomes from the target role.
2. Map evidence from your real work to each outcome.
3. name the context difference instead of hiding it.
4. build one translation artifact that makes the connection inspectable.
5. prepare a concise screen answer and a deeper evidence path.

### Recruiter Or Hiring Team

1. Separate essential first-day skills from skills that can be learned.
2. replace title, company, degree, and exact-stack proxies with observable behavior.
3. use the same structured prompts and anchors for every candidate.
4. record counter-evidence and confidence, not only a positive impression.
5. hand the next interviewer a specific question, not a vague concern.

---

## 1. Target Role Outcomes

Write outcomes as work the person must accomplish, not a list of technologies.

```md
Role:
Team:
Product or system:
Users:
First 90-day outcome:
First 12-month outcome:
Most important constraint:
Highest-consequence decision:
Primary collaborators:
Hiring owner:
```

### Outcome Table

| # | Required outcome | Observable behavior | Useful artifact | Failure consequence |
| --- | --- | --- | --- | --- |
| 1 |  |  |  |  |
| 2 |  |  |  |  |
| 3 |  |  |  |  |
| 4 |  |  |  |  |
| 5 |  |  |  |  |

Examples of outcome language:

- Diagnose why customers abandon onboarding and ship a measurable improvement.
- Change a shared frontend flow without breaking accessibility or downstream teams.
- Turn an ambiguous request into a bounded technical plan with explicit risk.
- Review AI-assisted code and produce independent evidence that the change is safe.
- Explain a production failure to technical and non-technical partners and improve the system.

## 2. Essential, Teachable, And Proxy

Classify each requirement with the people who do the work.

| Requirement | Essential on day one | Teachable in role | Proxy to remove | Why |
| --- | --- | --- | --- | --- |
|  | Yes / no | Yes / no | Yes / no |  |

### Proxy Test

For every credential, title, employer, industry, or exact-stack requirement, ask:

```md
What behavior do we believe this predicts?
How else could a candidate prove that behavior?
Can the team teach the context faster than it can teach the underlying judgment?
Would a high performer in the role agree this is essential?
What qualified people could this proxy hide?
```

## 3. Candidate Context

```md
Current / prior role:
Industry or domain:
Team shape:
System scale:
Primary users:
Owned decisions:
Typical constraints:
Consequences managed:
Artifacts available:
Results available:
Confidentiality limits:
Target-role context not yet experienced:
```

## 4. Transfer Map

Complete one row per target outcome. Use direct links or artifact names where possible.

| Target outcome | Source situation | Shared behavior | Evidence / artifact | Result | Material difference | Bridge |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |

### Transfer Sentence

Use this structure for each row:

```md
In [source context], I [observable behavior] under [constraint], producing
[artifact or result]. The target role requires the same underlying judgment in
[new context]. The meaningful difference is [delta], which I am bridging through
[specific proof, practice, or learning plan].
```

Avoid: “I am a fast learner.”

Prefer: “I had not used the team’s queueing system, so I mapped its delivery and retry semantics against a webhook system I had operated, built a small failure harness, and documented the remaining production differences.”

## 5. Evidence Strength

Rate evidence by inspectability, not polish.

| Level | Evidence | Interpretation |
| --- | --- | --- |
| E0 | Self-description only | A claim requiring follow-up |
| E1 | Specific example with role and constraint | Plausible behavior, limited verification |
| E2 | Artifact showing the work | Inspectable process or output |
| E3 | Artifact plus result, tradeoff, and collaborator context | Strong evidence of applied judgment |
| E4 | Repeated evidence across contexts, including recovery or failure | Durable signal with transfer credibility |

```md
Evidence level claimed:
Why:
What a reviewer can inspect:
What remains unverified:
```

## 6. Translation Artifact Builder

Choose the smallest artifact that makes the transfer visible.

- [ ] Before / after system map
- [ ] Decision record with rejected alternatives
- [ ] Pull-request or code-review excerpt
- [ ] State, data, or permission map
- [ ] Incident timeline and corrective action
- [ ] Experiment plan and result
- [ ] Customer or support taxonomy
- [ ] API or component contract
- [ ] Handoff, release, or QA note
- [ ] Small target-context prototype
- [ ] Other: ___

### Artifact Brief

```md
Artifact title:
Target outcome it proves:
Source context:
Constraint:
Candidate contribution:
Key decision:
Alternative rejected:
Result or learning:
Target-context translation:
Difference that remains:
Reviewer question this should answer:
Link or attachment:
```

### Confidential Work

When the original artifact cannot be shared:

- Reconstruct the structure with fictional names and values.
- Preserve the real decision, constraint, and tradeoff.
- Label recreated material clearly.
- Remove customer, employer, security, and personal data.
- Explain what was changed and what remains authentic.
- Never imply that a reconstruction is the original production artifact.

## 7. Context Delta

Transfer is more credible when the differences are explicit.

| Difference | Why it matters | Current evidence | Bridge action | Proof date | Owner |
| --- | --- | --- | --- | --- | --- |
| Scale |  |  |  |  |  |
| Regulation / risk |  |  |  |  |  |
| User type |  |  |  |  |  |
| Technical stack |  |  |  |  |  |
| Team structure |  |  |  |  |  |
| Operational ownership |  |  |  |  |  |

### Bridge Quality

- [ ] The bridge targets a real difference, not a generic course.
- [ ] The action produces inspectable evidence.
- [ ] The candidate can explain what the bridge still does not prove.
- [ ] The timeline matches the role's urgency.
- [ ] A qualified person can review the result.

## 8. Recruiter Screen Plan

Use the same core prompts in the same order for every candidate. Follow-up can vary to clarify evidence.

### Prompt 1 — Outcome

> Tell me about a time you produced an outcome similar to **[target outcome]**, even if the product, industry, or technology was different.

Listen for:

- the user or system outcome;
- the candidate's actual ownership;
- a concrete constraint;
- an artifact or observable action;
- the result and what remained uncertain.

### Prompt 2 — Decision

> What decision did you personally make, what alternatives existed, and what evidence changed your direction?

Listen for framing, tradeoffs, evidence, and the boundary between individual and team work.

### Prompt 3 — Difference

> What is materially different about doing that work here, and how would you close the gap?

Listen for honest context comparison, relevant learning strategy, and non-defensive uncertainty.

### Prompt 4 — Recovery

> Show me a time the first approach failed, received difficult feedback, or met an unexpected constraint. What changed afterward?

Listen for diagnosis, collaboration, correction, and durable improvement.

### Prompt 5 — Evidence

> What artifact could you walk the next interviewer through to make this behavior concrete?

Listen for inspectability rather than presentation polish.

## 9. Structured Evidence Anchors

Score each outcome independently. Do not average away a missing essential behavior.

| Score | Anchor |
| --- | --- |
| 1 — No evidence | Generic claim, unrelated example, or ownership cannot be established |
| 2 — Partial | Related behavior appears, but evidence, consequence, or transfer is unclear |
| 3 — Credible | Specific behavior and artifact map to the outcome; meaningful differences are understood |
| 4 — Strong | Repeated or high-quality evidence; tradeoffs, recovery, and bridge are explicit |

### Outcome Scorecard

| Outcome | Score | Evidence | Counter-evidence | Confidence | Next question |
| --- | ---: | --- | --- | --- | --- |
|  |  |  |  | Low / medium / high |  |

### Confidence Is Not Score

```md
Score describes: strength of observed evidence against the anchor.
Confidence describes: how complete and reliable the observation is.

High score / low confidence example:
One strong story with no inspectable artifact or follow-up time.

Moderate score / high confidence example:
Clear repeated evidence of a bounded skill, with an explicit target-context gap.
```

## 10. Bias And Consistency Check

Complete before advancing or rejecting.

- [ ] The evidence was evaluated against a role outcome, not “similarity to us.”
- [ ] Job title and employer prestige were not treated as proof.
- [ ] Exact-stack familiarity was separated from underlying system judgment.
- [ ] Communication style was not confused with communication effectiveness.
- [ ] Career gaps, non-linear paths, and industry changes were not treated as negative evidence by default.
- [ ] The same core prompts and anchors were used for every candidate.
- [ ] Positive and negative evidence were both recorded.
- [ ] A missing signal was converted into a next question before becoming a rejection reason.
- [ ] Accommodations and accessible assessment options were available.

## 11. Recruiter Handoff

Do not hand the next interviewer “seems smart” or “not technical enough.” Hand over a testable evidence question.

```md
Candidate:
Target role:

Strongest mapped outcome:
Evidence:
Confidence:

Most important unresolved outcome:
Why unresolved:
Specific next-stage prompt:
Artifact to inspect:

Material context difference:
Candidate's bridge:

Do not re-test:
Accessibility / accommodation note:
```

## 12. Candidate One-Page Translation

```md
# [Name] → [Target Role]

## Role outcome I can support
[One sentence]

## Closest evidence
Situation:
Constraint:
My behavior:
Artifact:
Result:

## Why it transfers
Shared judgment:
Material difference:
Bridge already completed:
Remaining learning:

## Inspect next
[Link to one artifact and a question it answers]
```

## 13. Decision Record

```md
Decision: [advance / hold for evidence / redirect / reject]
Essential outcomes demonstrated:
Essential outcomes not demonstrated:
Teachable gaps:
Non-teachable gap, with evidence:
Strongest counter-evidence:
Overall confidence:
Decision owner:
Date:
```

Reject on the missing essential outcome, not on the unfamiliar path used to reach the interview.

---

## Worked Example: Commerce Operator To Product Engineer

```md
Target outcome: Diagnose a customer workflow problem and ship a measurable
product improvement across frontend, backend, and operations.

Source situation: A small commerce brand had repeated support contacts and
abandoned checkouts around delivery expectations.

Shared behavior: Combined support themes, analytics events, storefront state,
and fulfillment constraints; bounded the problem; changed product copy and
logic; verified the release in production.

Evidence: Support taxonomy, event funnel, checkout-state map, implementation
diff, QA note, and before/after contact rate.

Result: Fewer delivery questions and a more accurate promise at checkout.

Material difference: The work happened in a founder-operated commerce system,
not a multi-team B2B SaaS platform with formal service ownership.

Bridge: Recreated the flow as a service-boundary diagram, documented API and
ownership assumptions, and reviewed it with an engineer who operates a shared
platform.

Recruiter screen score: 3 — credible transfer evidence.
Confidence: High for product diagnosis and end-to-end delivery; medium for
multi-team change management.

Next-stage question: Walk through how the same change would be planned if three
teams owned checkout, promise calculation, and fulfillment data.
```

## Prompt For An AI Agent

```md
Use this Skills Transfer Evidence Map to analyze the candidate and role below.

1. Convert the role description into three to five observable outcomes.
2. Separate essential first-day skills, teachable context, and removable proxies.
3. Map only evidence present in the candidate material; do not infer missing experience.
4. Name the shared behavior, artifact, result, material difference, and bridge.
5. Score each outcome with the 1-4 anchors and record confidence separately.
6. Write structured recruiter prompts for unresolved evidence.
7. Flag title, pedigree, exact-stack, style, and similarity bias.
8. Produce both a candidate one-page translation and a recruiter handoff.
9. Do not recommend advance or rejection without tying the decision to an essential outcome.

Target role:
[PASTE ROLE]

Candidate evidence:
[PASTE RESUME, PORTFOLIO, NOTES, OR ARTIFACTS]
```

## Research Basis

- [LinkedIn guidance for moving toward skills-based hiring](https://business.linkedin.com/hire/resources/talent-acquisition/adopting-skills-based-hiring)
- [LinkedIn Future of Recruiting research](https://business.linkedin.com/hire/resources/future-of-recruiting)

This map supports structured judgment; it does not replace trained interviewers, accessible assessment design, legal review, or validation that the selected criteria actually predict success in the role.