Discussing a candidate portfolio with confidential work

Candidates in design, engineering, and product roles often have useful work they do not freely share. A recruiter still helps them present relevant experience. Begin with permission, not a request for files. Ask what the candidate is permitted to discuss, what they want excluded, and which skills are safe to describe without exposing a former employer’s materials. The hiring client needs a clear view of experience. The candidate keeps control over confidential information and over any description sent in their name.

Set the conversation up before a hiring manager asks for evidence. Review the job description with the candidate and identify the work areas most relevant to the role. Then ask, “Which projects show work related to these areas?” Follow with, “What parts of each project are safe for you to describe?” A candidate might share a public case study, a portfolio item approved for public viewing, or a general account of their contribution. Another candidate might have no shareable artifact. Both situations deserve a careful conversation.

Avoid treating a portfolio as a collection of proof files. A meaningful account of work often gives a hiring manager useful context without exposing restricted material. Ask the candidate to describe the problem in general terms, their role, the tools or methods used, the decision they influenced, and how they worked with others. Do not ask for screenshots, customer names, source files, documents, or internal metrics unless the candidate says those items are public and available for sharing. When in doubt, leave the detail out and ask the candidate what wording feels safe.

Use open questions instead of filling gaps with your own assumptions. “What decision did your team need to make?” invites a useful answer. “Did you improve the reporting process?” leads the candidate toward language they might not choose. Ask what they personally did, what their team handled, and what level of detail fits a client review. Their answers help you distinguish an individual contribution from a group effort. This distinction matters when you prepare a summary for a hiring manager.

Use a fictional situation for practice. Recruiter Sonia speaks with candidate Mark about a role involving reporting for an operations team. Sonia says, “The hiring manager asked for examples of your launch work. Which parts of your past work are you comfortable discussing?” Mark replies, “The dashboards include customer data, so I will not send them.” Sonia says, “Understood. Tell me about the audience, your contribution, and the reporting problem without naming the company or users.” Mark explains he worked with a regional operations group and helped define recurring reporting needs.

Sonia asks Mark what evidence is available. Mark has a public presentation about reporting methods, though none of the prior dashboard screens are public. Sonia does not assume the presentation meets the manager’s needs. She asks Mark whether he wants her to propose a short summary for review. Mark agrees. Sonia writes a draft: “Mark supported a regional operations reporting effort by gathering recurring questions from team leads and helping shape a reporting approach for those needs. He has a public presentation about his general reporting methods.” The draft names no former employer, customer, screen, data set, or outcome claim.

Send the proposed language to the candidate before sharing any version with the client. Ask for a direct approval or a requested revision. A review message might say, “Please read this summary for accuracy and for any detail you prefer to remove. I will wait for your approval before I send a version to the hiring team.” This step gives the candidate a real chance to correct an overstatement or remove a detail they did not expect to see in writing. Do not treat a prior verbal conversation as approval for every later version.

When a hiring manager requests an original file, respond with a boundary and a useful question. Sonia might say, “Mark is not sharing confidential materials from prior work. He has approved a general description of his contribution and a public presentation about his methods. What type of evidence would help your review?” The manager might explain a need to understand how Mark made reporting decisions, worked with stakeholders, or approached an unfamiliar data question. Sonia then returns to Mark with the precise request and asks whether a safe example exists.

Do not pressure a candidate to produce a substitute artifact. A new example made solely for a hiring process needs the candidate’s time and choice. A candidate who declines still deserves accurate representation. If Mark says he has no additional public material, Sonia tells the client what he has approved for discussion. The hiring client decides how to evaluate the available information. Sonia does not create a fake screen, imply access to prior work, or place confidential details into a verbal conversation.

Keep notes narrowly focused on permission and process. Record which topic Mark approved, which details stay out, whether a public link or presentation exists, and when he approved the summary. Avoid pasting sensitive project notes into broad account records. If a colleague needs context before a client conversation, share only the approved description and the candidate’s stated boundary. Careful notes reduce confusion when a different recruiter joins the process later.

The same approach fits several job types. A designer might describe a general audience need, their research contribution, and a public design sample without exposing internal screens. An engineer might describe an integration problem, their area of ownership, and a public technical talk without sharing source material. A product professional might describe how they gathered feedback and supported a planning decision without naming a product, company, or metric. Each description should come from the candidate’s own approved account rather than a recruiter’s inference.

Watch for details appearing harmless alone but identifying a restricted project when combined. A company name, an unusual launch date, a customer segment, and a feature description might point back to one employer. Ask the candidate whether the combination feels too specific. If yes, broaden the language. “Regional operations group” gives less detail than a named client unit. “Recurring reporting needs” gives less detail than a distinctive internal project label. The candidate decides where their boundary sits.

If the client requests a follow up interview, prepare Mark for questions about his experience without asking him to rehearse restricted facts. Sonia asks, “Which parts of your role are you prepared to discuss live?” Mark says he will discuss how he gathered questions from team leads and how he organized reporting needs. Sonia sends the hiring manager an approved note before the interview: Mark will discuss his approach in general terms and will not share confidential dashboards or customer information. This prevents surprise during the conversation.

Practice with a fictional restricted project. Write a short candidate statement about a design, engineering, or product task. Include the general problem, individual contribution, and one safe method. Remove company names, customer names, screens, internal files, exact metrics, and distinctive project labels. Read the statement aloud as if a hiring manager asked for more detail. Notice where a follow up question might draw the candidate toward a restricted fact.

Then write Sonia’s next message in the fictional situation. Ask Mark to approve the statement, name the public presentation he chose to share, and ask whether a general discussion of reporting methods fits his boundary. Wait for Mark’s reply before sending the approved version to the hiring manager.