AI-generated illustration. Confidential work can remain closed while authorized samples, independent exercises, and consent-based corroboration provide different kinds of evidence.
Assess engineering work samples under NDA by offering three routes: an authorized artifact, an independently designed synthetic exercise, or consent-based corroboration. Record what each supports. Score demonstrated engineering judgment separately from confidence in historical claims, and mark unavailable evidence insufficient evidence, not poor performance.
The question is not whether a candidate has something impressive to show. It is whether the available evidence supports the role's requirements without breaching confidentiality.
Establish permission before reviewing the work
Redaction is not permission. Removing names, customer identifiers, or credentials does not necessarily make code, architecture diagrams, or incident reports shareable. A private interview or restricted upload does not resolve that issue.
Before requesting an artifact, establish three boundaries:
- What may be shared: What permits disclosure to this audience for this purpose?
- How it may be handled: May interviewers retain it, circulate it internally, or upload it to an assessment or AI tool?
- What alternative is available: Can the candidate demonstrate the skill through a fresh exercise?
Do not ask candidates to disclose confidential agreement text to prove permission. If authorization is unclear, set the artifact aside. Questions about legal authorization belong with the appropriate rights holder or qualified adviser, not an interviewer's guess.
A useful invitation is:
Please do not share confidential material or anything you are unsure you may disclose. You may use an authorized sample or a fresh exercise based on the role. We will assess technical reasoning separately from claims about previous work.
Match each evidence type to the claim it supports
This matrix is a proposed assessment tool, not a validated hiring instrument. It helps keep conclusions within the evidence.
| Evidence type | What it can support | What remains unverified | Appropriate follow-up |
|---|---|---|---|
| Artifact explicitly permitted for this use | Visible technical qualities and the candidate's explanation | Authorship, individual contribution, deployment, and outcomes unless separately supported | “Which parts were yours, and what supports that attribution?” |
| Independent synthetic sample using invented requirements and data | Present-day problem solving, implementation choices, tradeoffs, and validation | Historical work and claimed results | “Which assumptions drive this design, and what if one fails?” |
| Fresh collaborative exercise on an isolated test problem | Observed reasoning, clarification, adaptation, and communication | Long-term ownership, production execution, and historical contribution | “What would you investigate before approving this approach?” |
| Consent-based corroboration from someone able and authorized to discuss the work | Contribution or responsibility claims within that person's direct knowledge | Details they did not observe, cannot disclose, or recall only approximately | “What did you directly observe the candidate decide or deliver?” |
These routes complement one another; they are not interchangeable. A strong synthetic sample can demonstrate judgment while leaving past ownership unverified. A reference may corroborate ownership without establishing code quality.
Public availability does not establish authorship either. Distinguish what a repository or published document shows from what the candidate contributed.
AI-generated illustration. In the hypothetical exercise, a ledger update can occur before acknowledgment fails. Redelivery then tests reasoning about duplicate handling and recovery, not claims about past production work.
Keep skill assessment and historical confidence on separate records
Polished code alone may not answer the questions a senior engineering role raises. Examine problem framing, uncertainty, consequences, and validation too.
Use consistent dimensions and follow-up opportunities across evidence routes. Adapt the exercise to the role, but do not raise the bar because a candidate cannot show employer-owned work.
Record observed engineering judgment
For each dimension, record a concrete observation and one label:
- 1, Material weakness observed: A consequential gap remains after clarification.
- 2, Adequate reasoning demonstrated: The approach is coherent and appropriate to the stated requirements.
- 3, Strong reasoning demonstrated: The candidate examines consequential uncertainty, compares alternatives, and explains how evidence would change the decision.
- IE, Insufficient evidence: The dimension was not meaningfully observed. This is not a zero.
| Dimension | What to look for | Useful prompt |
|---|---|---|
| Problem framing | Goals, non-goals, success conditions, and unclear requirements | “What must we clarify before selecting a design?” |
| Constraints | Effects of security, reliability, cost, operations, and organizational limits | “Which constraint would most change your recommendation?” |
| Tradeoffs | Credible alternatives and reasons for accepting their costs | “What did you reject, and when would it become preferable?” |
| Validation | Tests, failure cases, observability, and evidence needed before use | “What result would make you revise this design?” |
| Ownership and collaboration | Responsibility boundaries, coordination, and handling disagreement | “Which decisions require another owner?” |
A fluent answer about teamwork does not establish sustained collaboration. A hypothetical response shows reasoning, not necessarily behavior over months of delivery.
Record the basis for historical claims
Keep a separate claim ledger. These illustrative entries show how support and limits can sit together:
| Claim | Available support | Status and limit |
|---|---|---|
| “I led the migration design.” | Candidate account only | Self-reported; ownership not independently supported |
| “I wrote the retry component.” | Authorized artifact and attributable contribution record | Supported within the record's scope; broader ownership not established |
| “I coordinated the rollout.” | Consented account from a direct collaborator | Corroborated within that person's observations |
| “The change reduced incidents.” | No shareable measurement or authorized corroboration | Insufficient evidence for the outcome claim |
Do not turn this ledger into a numerical credibility score. Missing records do not demonstrate dishonesty. Nor does a corroborated contribution establish every claimed outcome.
Worked example: evaluate reliability judgment without production code
Hypothetical scenario: A candidate says they redesigned a confidential background-job system. The hiring team needs evidence of reliability judgment, but the original code and incident records cannot be shared.
Offer an independently designed exercise, not a disguised reconstruction. State the assumptions:
- Jobs update a local mock account ledger using invented data.
- The queue may deliver a job more than once.
- A worker may stop after updating the ledger but before acknowledging the job.
- Job ordering is not guaranteed.
- Live external services, production credentials, and customer data are out of scope.
Ask the candidate to sketch or implement an approach, identify failure cases, and propose tests. Agree beforehand on allowed tools, preparation, and whether executable code is necessary. For design judgment, a structured walkthrough may be more relevant than a coding-speed constraint.
Then add a simulated external dependency that cannot participate in the ledger's transaction. Keep it local and mocked. Ask what guarantees remain possible and what recovery mechanism would be needed.
The central problem is concrete: an intended effect can occur even when processing appears incomplete. A useful response connects failure behavior to transaction boundaries, duplicate handling, recovery, and validation rather than merely naming a reliability pattern.
If those behaviors were observed, an assessment note could read:
The candidate identified the update-before-acknowledgment failure window, compared duplicate-handling approaches, and proposed tests around worker interruption. This supports reliability reasoning in the exercise. It does not verify ownership of the previous employer's system or its reported outcomes.
If historical ownership matters to the decision, request a narrowly scoped reference conversation with the candidate's consent. Do not contact a current employer without explicit permission or ask a reference to disclose confidential details.
Make the decision from requirements, not portfolio access
Before deciding, check:
- Permission: Was every artifact appropriate to share and handle here?
- Comparability: Was there a reasonable route to demonstrate each required capability?
- Observation: Does every skill rating cite something actually observed?
- Attribution: Are individual contributions distinguished from team results?
- Uncertainty: Are unsupported claims and unobserved skills explicitly marked?
- Next evidence: Could one focused, safe follow-up resolve a material gap?
Insufficient evidence can still limit a hiring decision. Fairness does not require assuming an unobserved capability exists. It requires distinguishing “we did not establish this requirement” from “the candidate performed poorly,” and offering a relevant alternative before treating the gap as decisive.
Candidates can use the same checklist for a portfolio entry: state the sharing basis, label synthetic samples, explain what each demonstrates, and keep historical claims within their support.
To organize evidence you are permitted to share, build a proof-backed profile with Skills Tech Network.