Field note: take-home deletion dates

A rejected candidate's take-home often lives much longer than the decision it supported.

The submission may remain in a shared drive, private GitHub organization, assessor fork, downloaded ZIP, local clone, screen recording, plagiarism service, AI review tool, ATS attachment, email thread, and calibration deck. Deleting the ATS record does not touch most of that graph.

The ICO's current recruitment and selection data guidance covers the recruitment lifecycle through deleting candidate information and emphasizes that recruitment processes involve several organizations and increasingly large amounts of personal information. Retention law differs by jurisdiction, so the operational rule should be reviewed locally; the product principle is simpler: purpose and deletion need to be designed before collection.

I would tell candidates how long source files, evaluation notes, derived scores, and audit evidence remain; give assessors one controlled workspace; remove extra clones; and retain only the narrow record justified after the review window closes.

A deletion date turns respectful intent into an operating promise.

State the purpose before collection

Each artifact should support a named selection, calibration, accommodation, security, or record-keeping purpose rather than future usefulness in general.

I would pressure-test that decision with four questions:

• Why is this collected?
• Which decision uses it?
• Who needs access?
• When does the purpose end?

The failure mode here is collecting full project material because storage is cheap. In technical and design hiring exercises where candidate code, documents, recordings, repositories, credentials, comments, derived scores, plagiarism checks, AI-use notes, reviewer clones, and vendor copies spread beyond the applicant tracking system, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a purpose-by-artifact inventory. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is every retained category tied to an active documented need. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a purpose-by-artifact inventory beside the question “Why is this collected?” before the first implementation review. The next pass would use “Which decision uses it?” to test the boundary, then “Who needs access?” to expose the state most likely to be missed. I would keep “When does the purpose end?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports every retained category tied to an active documented need.

Separate retention categories

Source code, design files, recordings, reviewer notes, derived scores, communications, accommodations, credentials, and final rationale should not inherit one blanket period.

The practical review starts here:

• Which artifact is necessary after decision?
• Does it contain sensitive context?
• Can a summary replace it?
• Which rule sets the period?

Those questions keep keeping the entire exercise bundle as one ATS attachment from becoming the default. I would capture the decision in a category-specific retention schedule, then use it while the work is still cheap to change. For hiring exercises that stop retaining candidate work by default, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like minimum material retained for each justified purpose. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a category-specific retention schedule part of the working surface. I would use it to answer “Which artifact is necessary after decision?” while scope is still flexible, and “Does it contain sensitive context?” before code or content becomes expensive to unwind. During QA, “Can a summary replace it?” and “Which rule sets the period?” become concrete checks rather than discussion prompts. That sequence turns hiring exercises that stop retaining candidate work by default into something the team can operate and gives me a specific outcome to report: minimum material retained for each justified purpose.

Tell the candidate plainly

The invitation should explain data collected, tools and processors, viewers, AI or plagiarism analysis, retention periods, reuse limits, rights route, and how to avoid including secrets.

Before implementation, I would answer:

• What will be uploaded?
• Which tools process it?
• Will work train anything?
• How can questions be raised?

The artifact is a take-home privacy and handling notice. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is burying material handling in a generic corporate privacy policy; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is informed participation before candidate labor and data leave their device. That connects a purpose-bound exercise retention protocol that tells candidates what is collected, sets category-specific deletion dates before submission, inventories copies and processors, preserves only justified decision records, executes and verifies deletion, and handles exceptions visibly to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “What will be uploaded?” easy to answer. The boundary should force a decision about “Which tools process it?” and “Will work train anything?.” I would record both in a take-home privacy and handling notice, including the part that stayed unresolved after the first pass. The final check, “How can questions be raised?,” is where the artifact earns its place: it either supports informed participation before candidate labor and data leave their device, or it shows exactly why another iteration is needed.

Contain the review workspace

Provide a controlled repository or portal, least-privilege assessor access, time-bounded credentials, safe sample data, and a clear prohibition on unmanaged copying and external analysis tools.

I would use these prompts during the working review:

• Where may reviewers work?
• Can forks be created?
• Which credentials exist?
• Does local tooling upload code?

If the team slips into emailing ZIP files to a rotating panel, the product can still look complete while its operating rule stays ambiguous. I would make an assessor handling agreement the shared reference and keep it small enough to update as evidence changes.

The standard is fewer copies with known owners and access history. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft an assessor handling agreement, review it against “Where may reviewers work?,” implement the narrowest useful path, and then return with evidence for “Can forks be created?.” I would use “Which credentials exist?” to inspect product consequence and “Does local tooling upload code?” to decide whether the result is stable enough to ship. This keeps emailing ZIP files to a rotating panel visible as a known risk and makes fewer copies with known owners and access history the release receipt rather than a hopeful conclusion.

Inventory derived data

Plagiarism flags, AI summaries, transcripts, screen captures, rubric scores, comments, telemetry, and embeddings are new candidate records with their own provenance and deletion path.

I would pressure-test that decision with four questions:

• Which outputs are generated?
• Can candidates correct them?
• Who stores the model input?
• Does deletion cascade?

The failure mode here is deleting source while retaining every automated inference. In technical and design hiring exercises where candidate code, documents, recordings, repositories, credentials, comments, derived scores, plagiarism checks, AI-use notes, reviewer clones, and vendor copies spread beyond the applicant tracking system, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a derived-artifact lineage map. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is complete visibility into what the exercise created. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a derived-artifact lineage map beside the question “Which outputs are generated?” before the first implementation review. The next pass would use “Can candidates correct them?” to test the boundary, then “Who stores the model input?” to expose the state most likely to be missed. I would keep “Does deletion cascade?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports complete visibility into what the exercise created.

Control reviewer copies

Local clones, downloads, IDE caches, screenshots, cloud backups, and notes need prevention where possible and a realistic cleanup workflow where prevention is not possible.

The practical review starts here:

• Can download be disabled?
• Which devices are managed?
• How are clones discovered?
• What proof is proportionate?

Those questions keep assuming private repository deletion removes laptop copies from becoming the default. I would capture the decision in a reviewer-copy cleanup checklist, then use it while the work is still cheap to change. For hiring exercises that stop retaining candidate work by default, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like reviewer-held material closed with the central record. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a reviewer-copy cleanup checklist part of the working surface. I would use it to answer “Can download be disabled?” while scope is still flexible, and “Which devices are managed?” before code or content becomes expensive to unwind. During QA, “How are clones discovered?” and “What proof is proportionate?” become concrete checks rather than discussion prompts. That sequence turns hiring exercises that stop retaining candidate work by default into something the team can operate and gives me a specific outcome to report: reviewer-held material closed with the central record.

Bind vendors and subprocessors

Exercise platforms and analysis vendors should expose storage locations, subprocessors, model-use rules, logs, deletion APIs, backup expiry, incidents, and confirmation evidence.

Before implementation, I would answer:

• Where is data processed?
• Can it train models?
• How is deletion requested?
• When do backups expire?

The artifact is a candidate-data processor register. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is adding a convenient code-analysis service during review without procurement context; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is third-party copies governed by the same candidate promise. That connects a purpose-bound exercise retention protocol that tells candidates what is collected, sets category-specific deletion dates before submission, inventories copies and processors, preserves only justified decision records, executes and verifies deletion, and handles exceptions visibly to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Where is data processed?” easy to answer. The boundary should force a decision about “Can it train models?” and “How is deletion requested?.” I would record both in a candidate-data processor register, including the part that stayed unresolved after the first pass. The final check, “When do backups expire?,” is where the artifact earns its place: it either supports third-party copies governed by the same candidate promise, or it shows exactly why another iteration is needed.

Design exception handling

A complaint, legal hold, security incident, or candidate request may justify preserving a narrow immutable subset, but the exception needs authority, scope, segregation, review date, and final deletion.

I would use these prompts during the working review:

• What triggers an exception?
• Which artifacts are necessary?
• Who approves access?
• When is it reviewed?

If the team slips into pausing deletion for the whole candidate profile indefinitely, the product can still look complete while its operating rule stays ambiguous. I would make a retention-exception record the shared reference and keep it small enough to update as evidence changes.

The standard is bounded preservation without converting exceptions into defaults. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a retention-exception record, review it against “What triggers an exception?,” implement the narrowest useful path, and then return with evidence for “Which artifacts are necessary?.” I would use “Who approves access?” to inspect product consequence and “When is it reviewed?” to decide whether the result is stable enough to ship. This keeps pausing deletion for the whole candidate profile indefinitely visible as a known risk and makes bounded preservation without converting exceptions into defaults the release receipt rather than a hopeful conclusion.

Automate deletion and reconciliation

Scheduled jobs should enumerate expected artifacts, delete by category, revoke credentials, call vendor APIs, record failures, retry safely, and escalate copies that require human cleanup.

I would pressure-test that decision with four questions:

• Which inventory drives deletion?
• Are retries idempotent?
• What cannot be automated?
• Who owns failures?

The failure mode here is running one profile-delete call and declaring completion. In technical and design hiring exercises where candidate code, documents, recordings, repositories, credentials, comments, derived scores, plagiarism checks, AI-use notes, reviewer clones, and vendor copies spread beyond the applicant tracking system, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a deletion workflow and exception queue. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is all known copies reaching a durable terminal state. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a deletion workflow and exception queue beside the question “Which inventory drives deletion?” before the first implementation review. The next pass would use “Are retries idempotent?” to test the boundary, then “What cannot be automated?” to expose the state most likely to be missed. I would keep “Who owns failures?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports all known copies reaching a durable terminal state.

Verify the promise

Sample repositories, forks, permissions, device acknowledgements, vendor confirmations, backup documentation, audit events, and candidate requests to prove retention policy works in practice.

The practical review starts here:

• Can expired material still be found?
• Are deletion failures visible?
• Do dates match the notice?
• Which copy escaped inventory?

Those questions keep measuring compliance only by the configured ATS setting from becoming the default. I would capture the decision in an exercise-retention QA receipt, then use it while the work is still cheap to change. For hiring exercises that stop retaining candidate work by default, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like evidence that candidate work actually leaves the hiring system. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make an exercise-retention QA receipt part of the working surface. I would use it to answer “Can expired material still be found?” while scope is still flexible, and “Are deletion failures visible?” before code or content becomes expensive to unwind. During QA, “Do dates match the notice?” and “Which copy escaped inventory?” become concrete checks rather than discussion prompts. That sequence turns hiring exercises that stop retaining candidate work by default into something the team can operate and gives me a specific outcome to report: evidence that candidate work actually leaves the hiring system.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a purpose-by-artifact inventory
• a category-specific retention schedule
• a take-home privacy and handling notice
• an assessor handling agreement
• a derived-artifact lineage map

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because a purpose-bound exercise retention protocol that tells candidates what is collected, sets category-specific deletion dates before submission, inventories copies and processors, preserves only justified decision records, executes and verifies deletion, and handles exceptions visibly becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# scope
candidate c_842 / frontend exercise
Repository, two authorized reviewers, recording disabled, rubric notes, ATS decision, code-check vendor, credential set, review closes 2026-08-02.
# action
delete source day 30 / rationale day 180
Repo and forks removed, reviewer cleanup acknowledged, tokens revoked, vendor request confirmed, backup expiry documented, exception none.
# proof
inventory 9/9 closed
Automated checks plus sampled device attestation, deletion event IDs, processor confirmation, owner sign-off, and candidate request route retained.

Resource path

The practical follow-up I would build is a take-home exercise retention checklist with purpose, data categories, candidate notice, collection path, assessor access, repository and clone inventory, vendor subprocessors, category-specific retention, decision record, legal-hold exception, deletion job, manual cleanup, candidate copy, verification sample, owner, and audit fields. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• Why is this collected?
• Which artifact is necessary after decision?
• What will be uploaded?
• Where may reviewers work?
• Which outputs are generated?
• Can download be disabled?
• Where is data processed?
• What triggers an exception?
• Which inventory drives deletion?
• Can expired material still be found?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For hiring exercises that stop retaining candidate work by default, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• reviewer-held material closed with the central record
• third-party copies governed by the same candidate promise
• bounded preservation without converting exceptions into defaults
• all known copies reaching a durable terminal state
• evidence that candidate work actually leaves the hiring system

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• Retention starts before the upload link is sent.
• Different artifacts deserve different lifetimes.
• Candidate material fragments into several control zones.
• The deletion receipt accounts for material, not just profile state.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to technical and design hiring exercises where candidate code, documents, recordings, repositories, credentials, comments, derived scores, plagiarism checks, AI-use notes, reviewer clones, and vendor copies spread beyond the applicant tracking system: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through a purpose-bound exercise retention protocol that tells candidates what is collected, sets category-specific deletion dates before submission, inventories copies and processors, preserves only justified decision records, executes and verifies deletion, and handles exceptions visibly. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

An exercise-retention protocol is a hiring signal because it shows I can connect candidate experience, privacy, recruiting operations, developer tooling, vendor boundaries, records management, and verifiable cleanup.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.