AI-generated illustration. When past work cannot be disclosed, an authorized artifact or fresh exercise can make engineering judgment visible without exposing confidential material.
Assess confidential engineering work samples through authorized artifacts or clearly labeled synthetic exercises. Record what the candidate demonstrates separately from what the evidence supports about past work. Unavailable evidence is unknown, not proof of weak engineering ability.
The question is whether the candidate has demonstrated the judgment required for the role. Repository access alone cannot answer it.
Set the disclosure boundary before requesting evidence
Work samples can include architecture diagrams, incident timelines, metrics, screenshots, tickets, and design discussions. These may contain restricted information even when no source code is involved.
Set the boundary before asking for an artifact:
Share only material you are authorized to disclose for this assessment. If permission is absent or unclear, we will use an alternative exercise. Do not send confidential material for us to redact.
Redaction is not permission. Removing names or customer identifiers may still leave restricted architecture, business logic, or operational details.
Check each proposed artifact:
- Provenance: Where did it come from, and who controls disclosure?
- Scope: Is this version authorized for this audience and purpose?
- Contents: Does it contain third-party code, personal data, credentials, or restricted details?
- Handling: What limits apply to access, storage, reuse, and retention?
- Fallback: What nonconfidential exercise would assess the same skill?
Do not ask candidates to resolve contractual ambiguity in an interview. Where appropriate, refer permission questions to the rights holder or a qualified adviser. Meanwhile, use another assessment path.
Synthetic work needs a boundary too. It should be a fresh example built from general principles, not a disguised copy of restricted implementation details. If that distinction is unclear, provide the scenario yourself.
Choose paths that assess the same judgment
Candidates have different access to shareable work. Offer comparable ways to demonstrate the required skills, rather than rewarding access to production material.
| Assessment path | What to request | What it can support | What it cannot establish alone |
|---|---|---|---|
| Authorized past artifact | A permitted design note, code excerpt, or public contribution | Understanding of an implementation; contribution where supporting evidence exists | Sole authorship, decision ownership, or business results |
| Fresh synthetic example | Invented requirements and data, clearly labeled | Present reasoning, technical choices, and validation design | That a corresponding system was built or shipped previously |
| Interviewer-provided exercise | A bounded scenario with explicit constraints | Reasoning under shared conditions and responses to follow-ups | Historical performance or production ownership |
Equivalent does not mean identical. A design role may call for a design exercise; implementation skills may require a small coding task. State the deliverable, allowed tools, preparation effort, and criteria in advance.
Keep the core questions consistent:
- What constraints shape the decision?
- What alternatives are plausible, and why choose one?
- What could fail?
- How would you validate the choice?
- What evidence would make you change your mind?
For senior roles, probe conflicting constraints, uncertain requirements, rollout risk, and coordination. System size and architectural complexity are not substitutes for judgment.
Use a claim-to-evidence worksheet
Assess specific claims, not the portfolio as a whole.
“Led a migration” is too broad. Separate “selected the migration strategy,” “implemented reconciliation,” and “defined rollback criteria.” Each needs its own evidence.
Copy this worksheet into the review notes:
| Candidate claim | Disclosure permission | Available evidence | What the evidence supports | What remains unknown | Next fair follow-up |
|---|---|---|---|---|---|
| State the claim narrowly | Authorized, unresolved, or unavailable | Artifact, observed behavior, or authorized corroboration | Record only the supported conclusion | List unknown attribution, outcome, or scope | Ask a targeted question or offer an equivalent task |
Be concrete. “Explained a duplicate-delivery failure mode and designed a test for it” is more useful than “seemed experienced.”
Apply the same discipline to concerns. “Could not identify a recovery strategy after the failure condition was clarified” records an observation. “Has never operated a reliable service” goes beyond it.
Candidates can use the worksheet too: identify what can be shared, what remains self-reported, and what fresh demonstration could make the reasoning visible.
AI-generated illustration. In the fictional migration exercise, the new database accepts additional writes after cutover. Recovery must account for those writes as well as the incorrectly transformed records; simply switching back is insufficient.
Separate demonstrated capability from historical support
Use two assessments. A single score can blur technical judgment, artifact access, and verified delivery history.
Demonstrated engineering judgment
Rate each dimension below:
- Demonstrated: Gives a coherent, constraint-aware explanation and handles relevant follow-ups.
- Partial: Offers a plausible approach but leaves material gaps unresolved.
- Observed concern: After a clear opportunity to respond, makes or defends a choice that conflicts with an explicit requirement without accounting for the tradeoff.
- Unknown: The assessment provided too little relevant evidence to judge.
| Dimension | Evidence to look for |
|---|---|
| Constraints | Identifies requirements, assumptions, dependencies, and missing information |
| Alternatives | Compares plausible options and explains the chosen tradeoffs |
| Validation | Connects tests or measurements to failure modes and acceptance criteria |
| Operational judgment | Addresses rollout, observability, and recovery appropriate to the scenario |
| Contribution boundaries | Distinguishes personal decisions and deliverables from team work |
Clarity about contribution is observable. Historical accuracy may still need corroboration; a convincing explanation is not proof of authorship.
Support for historical claims
Label each past-work claim separately:
- Corroborated within scope: Authorized evidence supports the specific claim. Record exactly which part.
- Self-reported: The candidate describes the work, but independent support is unavailable.
- Unresolved discrepancy: Accounts or artifacts conflict and need clarification.
- Not assessed: The process did not attempt to establish the claim.
An authorized design note might show that a candidate proposed a strategy, not that it shipped. A result chart might show an outcome without establishing who caused it.
Worked example: a confidential migration project
Hypothetical scenario: A candidate says they led a database migration and reduced service interruptions. Their former employer’s code, design documents, and operational metrics cannot be shared.
Do not request screenshots with names removed. Split the claims instead.
| Claim | Available evidence | Assessment | Fair follow-up |
|---|---|---|---|
| “I can reason about migration safety.” | Interviewer-provided design exercise | Capability can be demonstrated in the session | Ask about reconciliation, cutover, and recovery |
| “I led the previous migration.” | Candidate’s account only | Historical contribution remains self-reported | Seek a permitted description of responsibilities or authorized corroboration if needed |
| “The migration reduced interruptions.” | No shareable measurements | Past outcome remains unverified | Ask how it was measured, without requesting restricted values or records |
Then offer an exercise with explicit fictional assumptions:
An invented order service must move from one database to another. Writes must remain available during copying. Copy operations may be retried, and updates may occur while records are being copied. Temporary reconciliation lag is acceptable, but losing an acknowledged write is not. Produce a migration outline, cutover criteria, and a recovery plan. Use only fictional data and diagrams; no live systems are involved.
Introduce a complication: after cutover, a field is found to have been transformed incorrectly, and the new database has accepted additional writes.
A useful answer should investigate what information was preserved, how affected records can be identified, and how post-cutover writes affect recovery. “Switch back” is insufficient unless it accounts for those writes and the faulty transformation.
The exercise makes reasoning visible, not history verifiable. Strong migration judgment today does not corroborate past leadership or results.
Turn the notes into a fair decision
Before comparing candidates, decide which capabilities the role requires and whether any historical claim needs corroboration. Apply that requirement consistently, not only when someone cannot share code.
For each material unknown, choose an action:
- Assess it directly with a bounded, nonconfidential task.
- Seek authorized corroboration when past attribution or delivery is essential.
- Leave it unresolved if it is not material to the role.
If essential evidence remains unavailable, record “insufficient evidence for this requirement,” not “weak engineer.” That distinction does not compel a hiring decision. It makes the basis accurate.
A final note can be brief:
Demonstrated: constraint-aware migration design and recovery reasoning. Partial: validation criteria need more detail. Historical support: leadership and interruption-reduction claims remain self-reported. Next action: request a focused validation plan using the same fictional scenario.
To take the next step in presenting your work, explore Skills Tech Network.