AI-generated illustration. Permission is the first gate: removing names or improving a sample does not authorize disclosure. What the sample proves remains a separate question.
An engineering portfolio under NDA can include material cleared for disclosure and independent demonstrations that reveal no protected information. Removing names is not permission. A new demonstration can show present skill, but it does not prove ownership of a past system or its business impact.
Keep two questions separate: What may I disclose? And what can a reviewer verify from it?
Choose the claim first
Start with the capability you want a reviewer to assess:
- Implementation skill: Can you build and explain a working solution?
- Engineering judgment: Can you compare alternatives, reason about failure, and identify missing information?
- Historical contribution: What did you personally do on a particular project?
- Business impact: What changed because of that work, and how was it measured?
An original project can provide inspectable evidence for the first two. It cannot, by itself, establish the last two.
For example, a new queue-processing demonstration may reveal how you handle duplicate delivery. It does not verify that you designed a former employer’s system, operated it at a particular scale, or reduced its costs.
Use a work-sample selection matrix
Treat permission as a gate, not a score. Technical quality cannot compensate for unclear authorization.
| Evidence type | Permission and provenance | Individual contribution | Reviewer can verify | Remaining uncertainty |
|---|---|---|---|---|
| Historical artifact cleared for sharing | Confirm the exact version, audience, channel, and any third-party restrictions | State what you authored, changed, reviewed, or inherited | The disclosed contents and your explanation | Authorship, production use, and outcomes may need separate corroboration |
| Authorized public material | Link to the authorized public version, not unpublished supporting files | Distinguish your role from the team’s work | What the public material documents | Public availability does not establish your contribution or permit further disclosure |
| Independent demonstration | Use original work, permitted public references, and synthetic data | Identify collaborators, dependencies, and any generation assistance | Implementation, reasoning, and reproducible behavior | Historical ownership, production experience, and business impact remain unverified |
| Permitted career narrative | Share only the description you are authorized to give | Bound your role carefully | Your explanation, not the underlying work | Role and outcome claims need separate authorized support |
If permission is unclear, leave the artifact out while seeking clarification. A private interview, restricted folder, or screen share still discloses information to another party.
Check permission before polishing
Anonymization is not enough. A nameless diagram may still reveal architecture, customer relationships, or a distinctive incident. Rewriting code from memory can also reproduce protected information.
Permission
- [ ] Identify applicable confidentiality, ownership, security, and third-party restrictions.
- [ ] Establish a clear basis for sharing this specific material. Authorship alone is not enough.
- [ ] Get any required approval in writing from someone authorized to give it.
- [ ] Confirm the permitted audience, channel, redactions, expiry conditions, and redistribution limits.
Provenance
- [ ] Explain where the code, diagrams, text, and data came from.
- [ ] Separate your contribution from team work and third-party material.
- [ ] Check for credentials, private logs, customer data, and hidden confidential metadata.
- [ ] Create demonstrations independently, rather than lightly renaming an internal implementation.
Claims
- [ ] Distinguish claims about this sample from claims about historical work.
- [ ] Include the method, environment, and limitations for any measurements.
- [ ] State what the reviewer cannot verify.
This checklist is an evidence-handling process, not legal clearance. If contractual scope is uncertain, ask an authorized legal or compliance contact, or obtain independent legal advice. Do not infer permission from silence.
AI-generated illustration. An independent task-processor exercise can expose reasoning about duplicate messages, retries, and failed-task inspection. These are proposed checks, not verified results or evidence of past production work.
Label every sample
Use a short evidence label in the README or portfolio entry:
Evidence type: Cleared historical artifact / authorized public material / independent demonstration / permitted narrative only
Capability demonstrated: The specific skill or judgment this sample exposes.
Origin and disclosure basis: Where it came from and why it may be shared. Keep confidential approval records private.
My contribution: What I personally designed, implemented, tested, or documented, plus relevant help and dependencies.
Reviewer can inspect: Code, decisions, tests, or other evidence actually included.
Verification boundary: What this sample does not establish.
Limitations: Simplifications, omitted conditions, and tests not performed.
Be precise about “recreated” examples. A newly invented exercise is an independent demonstration. A reconstruction of an employer’s actual design still needs disclosure review. The label grants no permission.
Worked example: demonstrate reliability judgment
Hypothetical situation: An engineer wants to demonstrate reliability judgment but cannot share code, diagrams, or incident details from a previous role.
Instead, design a small task processor using synthetic messages and a mock destination.
Explicit assumptions:
- Input may deliver the same message more than once.
- The mock destination can simulate temporary failures.
- The demonstration runs locally, without employer systems or data.
- Requirements are invented for the exercise, not reconstructed from an employer’s architecture.
Keep it small. Expose decisions about message identity, retry limits, duplicate handling, and failed-task inspection. Add a design note explaining one rejected alternative and when you would reconsider it.
Give reviewers instructions to explore these questions:
- What happens if a message arrives twice?
- What happens if the process stops after the mock side effect but before recording completion?
- Where does the deduplication guarantee stop?
- Which assumptions would need revisiting outside this exercise?
Record test results only after running the tests. Until then, call these proposed checks, not verified behavior.
If accurate, the completed sample’s label could read:
Independent demonstration. Original code with synthetic messages and a mock destination. Demonstrates retry and duplicate-handling decisions. Contains no former-employer artifacts and does not substantiate historical system ownership, production scale, or business outcomes.
The value is not resemblance to a secret production system. It is the reasoning a reviewer can inspect.
Give reviewers a comparable assessment path
Confidentiality should be neither a penalty nor a credential. Missing public evidence does not prove weak ability, and invoking an NDA does not validate an achievement claim.
Candidates can offer an original sample or a bounded design discussion. Reviewers should make the expected effort and permitted tools clear, then assess candidates against comparable job-relevant criteria rather than demanding identical portfolio formats.
| Dimension | What to look for |
|---|---|
| Implementation evidence | Inspectable behavior, appropriate tests, and an accurate explanation of limitations |
| Engineering judgment | Explicit constraints, meaningful alternatives, failure analysis, and reasons for changing course |
| Historical corroboration | Authorized records or references supporting the claimed role and outcomes |
For senior-level work, ask what drove a decision, what evidence would reverse it, and what remains unknown about the operational risk. Complexity alone is not evidence of judgment.
Record historical claims separately as corroborated, partly corroborated, or unverified. If references are appropriate, seek the candidate’s consent and stay within what the reference is authorized to discuss. Never invite a candidate to “just show it privately.”
Assess the capability the sample reveals. Keep the remaining uncertainty visible.
For a next step, explore Skills Tech Network as you plan how to present your evidence.