Proof of Work When Your Best Work Is Under NDA

What you can show, and what you cannot

There is a particular kind of career frustration that belongs almost exclusively to engineers who are good at their jobs. You have spent three years building retrieval systems that serve real users at real scale. You have run the evaluations, argued the architecture, cut the latency, absorbed the incident at two in the morning. And when someone asks to see your work, you have nothing to point at, because all of it lives behind a corporate single sign-on and a confidentiality agreement you signed on your first day without reading closely.

The standard advice at this point is to go and build a portfolio project. That advice is written for people who lack experience. You do not lack experience. You lack permission to show the experience you have, which is an entirely different problem with an entirely different solution, and treating the second as if it were the first is why so many strong engineers end up with a GitHub profile full of half-finished tutorials that make them look weaker than they are.

The market makes this expensive. As of August 2026 the competition for AI roles is severe in both of the markets this site covers: job postings have roughly tripled while applications have surged roughly tenfold, so the ratio of applicants to openings has moved sharply against candidates even as the number of openings grew. Recruiters filling those roles have responded by looking for proof rather than potential. A portfolio of a few production-grade projects with live demonstrations and measurable impact now outperforms a CV, which is an uncomfortable sentence to read if everything you have built is invisible.

So the question worth answering is narrow and practical. Given that a real proportion of your best work can never be published, what can be published, and how do you assemble it into something a hiring manager will read as credible? The rest of this article answers exactly that, in this order: where the disclosure line actually sits, then the four categories of shareable evidence ranked by how much signal they carry, then how to describe the confidential work honestly on a profile, then the contractual caution nobody mentions, then a plan you can run alongside a full-time job.

• The line is narrower than people assume. What is protected is specific information, not the general category of work you do.
• Open source is the strongest substitute because someone other than you verified it.
• Reproductions demonstrate the same skills as your day job on material that belongs to nobody.
• Judgement is the thing the NDA hides, and writing is the only way to show it.
• Shape and outcome can be described where specifics cannot.
• Check your contract before you contribute, because IP-assignment clauses vary and some of them are broad.

The disclosure line, and a test you can actually apply

Most engineers hold confidentiality as a vague dread rather than a defined boundary. That vagueness is costly in both directions. It stops people sharing things that were never protected, and occasionally it lets someone share a number that genuinely was. Getting precise about the line is the first and highest-leverage step.

What confidentiality agreements typically protect is information that is specific to your employer or their clients and not otherwise public: the identity of a client, the data itself and anything derived closely from it, internal performance metrics, cost figures, proprietary architecture that constitutes a genuine trade secret, and anything on an unreleased roadmap. What they typically do not protect, because they cannot, is the general body of technique that exists in public documentation, the patterns the whole industry uses, your own reasoning about trade-offs, work derived from published papers, and contributions you make to open-source projects under their own licence.

Here is the test. For any fact you are considering publishing, ask: could a competent stranger with no access to my employer have arrived at this same statement from public sources plus their own thinking? If yes, it is almost certainly shareable. If arriving at that statement required access to something inside the company — a dataset, a dashboard, a contract, an internal document, a customer conversation — treat it as confidential until someone with authority says otherwise.

Two clarifications matter here. First, paraphrasing does not launder a confidential number. Writing that your system achieved "well over ninety per cent" when the internal figure is 91.4 per cent is still disclosure of an internal metric. Second, the reverse trap is just as real: engineers routinely withhold things that were never protected — the fact that they work on agent evaluation, that retrieval is the pattern they use, that they have opinions about chunking. Retrieval-augmented generation is the dominant production pattern in AI engineering as of 2026, and LangChain, retrieval-augmented generation and PyTorch are among the most commonly listed skills on AI engineer profiles. Naming those on your own profile discloses nothing whatsoever. It merely says you do the job you do.

Open-source contribution: the highest-signal substitute

If you only do one thing from this article, do this one. A merged pull request in a tool that other engineers actually use is the strongest public evidence available to someone whose day job is invisible, and it is stronger for a reason that has nothing to do with the size of the change.

A solo demonstration repository is a claim you make about yourself. The reviewer must take on trust that it works, that anyone needed it, and that you wrote it unaided. A merged contribution is a claim someone else accepted. A maintainer with no reason to be generous read your code, made you justify it, probably asked for changes, and then shipped it to their users. That transaction demonstrates a specific and hard-to-fake cluster of behaviours: reading an unfamiliar codebase, respecting a design you did not choose, writing to someone else's standard, taking review without defensiveness, and following through to completion. Those are precisely the behaviours a hiring manager is trying to infer from an interview and usually cannot.

The selection rule is straightforward: pick a repository adjacent to your actual day work. If you build retrieval systems, contribute to a vector store client, an embedding evaluation library, a chunking utility or a document parser. If you run agents in production, contribute to a tracing library, a tool-calling framework or a sandbox runner. Adjacency does the work here. It means your existing expertise transfers immediately, the contribution is credible because you genuinely understand the problem domain, and any reviewer looking at your profile sees a coherent line between what you contribute to and what you claim to do. It also means you are fixing bugs you have personally been bitten by, which is the single best source of a first issue.

A good first contribution is small, complete and slightly boring. Fix the bug you hit last month and worked around. Correct the documentation that was wrong and cost you an afternoon. Add the missing type hints to a module you read closely. Improve an error message that told you nothing. None of these are glamorous, and all of them are the standard route to becoming a recognised contributor. Do not open with a redesign proposal; maintainers read that as a stranger creating work for them.

The practical sequence, from a standing start, is: read the contributing guide properly, reproduce the issue locally and post the reproduction as a comment before writing any code, keep the diff focused on one thing, include a test that fails without your change, and respond to review comments within a day or two so the thread does not go cold. The failure mode that wastes most people's first attempt is a large unsolicited pull request that touches ten files and receives no response for six weeks.

Notice the shape of that table. The two lowest rows are where most people put their effort, because they are the two that can be finished in a weekend and require nobody's approval. The top row costs perhaps ten hours spread over a month and outperforms all of them combined. The wider case for working in the open is covered in our guide to building in public as an AI engineer; this article is specifically about the version of that problem where most of your material is off-limits.

Reproductions and teardowns: your day-job skills on public material

The second category is the one almost nobody uses, and it maps most closely onto what you actually do at work. Take a published paper or a vendor's public benchmark claim, rebuild it on your own harness, and write up what happened.

The value is not in confirming the result. Anyone can rerun a published notebook and observe the headline number. The value is in the delta — the gap between what was claimed and what you measured, and your account of why. Which parts reproduced cleanly. Which did not. Which undocumented implementation detail turned out to be load-bearing. Whether the evaluation set was doing more work than the method. What happened when you changed the one variable the authors held fixed.

That write-up demonstrates, on entirely public material, the exact competencies your NDA'd work would demonstrate: setting up a controlled comparison, instrumenting it honestly, debugging a system you did not design, and reporting a result that is inconvenient. It also demonstrates something rarer, which is willingness to publish a negative finding. Hiring managers weight real-world problem framing far above reproduced tutorials, and a reproduction with a genuine finding attached is problem framing rather than tutorial work.

Vendor benchmark claims are especially fertile ground because they are public, they are marketing, and they are frequently measured under conditions that do not resemble yours. Rebuilding one on your own repository and reporting where it holds and where it falls apart is a genuinely useful artefact, and it is the same discipline described in our piece on benchmarking coding agents against your own repository. Keep the harness itself public even if the conclusion is unremarkable — the harness is the reusable part.

Public evals and datasets you own outright

The third category is the most technically substantial, and it happens to sit on top of a genuinely scarce skill. A comparatively rare and highly valued capability in production AI teams is designing the rubric, the pairwise comparison, the preference panel and the eval set that make quality judgements repeatable rather than dependent on one person's opinion on a Tuesday afternoon. Most teams have someone who can call a model output good or bad. Far fewer have someone who can make that judgement reproducible across a team, a quarter and a model change.

You cannot publish your employer's eval set. You can absolutely build and publish your own, on a task you choose, over data you own outright or that is openly licensed. The artefact is small: a task definition, a set of cases, a rubric that a second person could apply and reach the same answer, a runner, and results committed as data rather than as a screenshot. That is a weekend to a first version and a few evenings to something respectable.

A minimal skeleton worth forking looks roughly like this. It deliberately keeps the rubric, the cases and the results as separate files, because that separation is the part reviewers notice.

# eval/run.py — minimal public eval harness skeleton
# Cases and rubric live as data, not as code. Results are committed.

import json, pathlib, datetime

CASES  = json.loads(pathlib.Path("eval/cases.json").read_text())
RUBRIC = json.loads(pathlib.Path("eval/rubric.json").read_text())

def score(output, case):
    """Return one dict per rubric dimension. No hidden judgement."""
    return {
        dim["id"]: dim["check"](output, case)   # deterministic where possible
        for dim in RUBRIC["dimensions"]
    }

def run(system, tag):
    rows = []
    for case in CASES:
        out = system(case["input"])
        rows.append({
            "case_id": case["id"],
            "output": out,
            "scores": score(out, case),
        })
    result = {
        "tag": tag,
        "run_at": datetime.datetime.utcnow().isoformat() + "Z",
        "n_cases": len(CASES),
        "rubric_version": RUBRIC["version"],
        "rows": rows,
    }
    path = pathlib.Path(f"results/{tag}.json")
    path.write_text(json.dumps(result, indent=2))
    return result

if __name__ == "__main__":
    import sys
    run(system=__import__(sys.argv[1]).system, tag=sys.argv[2])

Three details make the difference between a harness that reads as serious and one that reads as a toy. Version the rubric, so a reader can tell whether a score moved because the system improved or because you changed the marking. Commit the results as JSON rather than posting a screenshot, so anyone can diff two runs. And write down what the eval does not measure, in the README, in plain language — the honest limitations section is the single strongest signal in the whole artefact, because it is the part that cannot be produced by someone who has not thought hard about the problem.

For a reproduction, the equivalent scaffold is a run manifest that pins everything, so that a reader can distinguish a real disagreement from a configuration difference:

# repro/manifest.yaml — pin everything a reader would need to argue with you
source:
  paper: "arXiv:XXXX.XXXXX"
  claim: "Reported figure and the exact table it came from"
  code: "https://github.com/original/repo @ commit abc1234"

environment:
  python: "3.12.4"
  hardware: "1x consumer GPU, 24GB"
  seeds: [0, 1, 2]

deviations:
  - "Ran 3 seeds instead of 5 (compute budget)"
  - "Used the public split; the paper's private split is unavailable"

measured:
  our_figure: null      # fill in after the run, before writing the prose
  delta_vs_claim: null

If evaluation is the direction you want to take this, the longer treatment is in our guide to shipping a public agent eval harness as proof of work, which goes deeper on case selection and rubric design than there is room for here.

Writing as evidence: judgement is the thing the NDA hides

Consider what confidentiality actually removes from view. It hides the artefacts, obviously. But the thing it hides that matters most to a reviewer is your judgement — the reasoning that led you to chunk the way you did, to reject the obvious architecture, to spend three weeks on evaluation before writing any retrieval code. Nobody can see that reasoning, and it is the most valuable thing about a senior engineer.

Writing is the only mechanism that restores it. A technique write-up on a public dataset shows exactly the same reasoning your internal design document shows, minus every protected fact. You are not describing a system; you are describing how you decide, which is portable across employers and belongs entirely to you.

Two thousand words on a narrow, real problem — how you would evaluate a reranker when relevance judgements are expensive, why hybrid search underperformed in a case you can demonstrate publicly, what the actual trade-off is between chunk size and citation precision — will do more for a reader than a repository dump. Be specific enough to be wrong. Vague writing signals nothing, because anyone can produce it. A piece that commits to a position a knowledgeable reader could argue with is the piece that gets you a reply from someone who knows the field.

Where you publish matters less than that it exists and is findable. What matters is that it is linked from the profile a recruiter lands on, which is a separate discipline covered in the LinkedIn playbook for recruiter search. The writing is the evidence; the profile is the distribution.

Describing NDA'd work honestly: the shape-and-outcome pattern

Now the part that most directly affects your profile and CV. You still need to describe three years of invisible work, and there is a pattern for doing it that is both safe and considerably more persuasive than what most people write.

State four things and no more: the domain in general terms, the scale band rather than the exact figure, the constraint that made the problem hard, and the outcome band in business terms. Name no client, no dataset, no internal metric, no proprietary mechanism. What remains is a sentence that tells a reviewer precisely what you can do while disclosing nothing they could not have guessed from your job title.

Outcomes framed in business terms land considerably harder than bare technical metrics — "reduced manual review time by 40 per cent" does more work than "achieved 91 per cent F1", and it has the useful property of being far less likely to be a protected internal figure in the first place. If even the business figure is sensitive, band it: "roughly a third", "single-digit percentage of revenue", "cut a two-day process to under an hour". Bands are almost never confidential and they are entirely honest.

Read the right-hand column as a reviewer would. Not one of those sentences is weaker than the version that leaks. Several are stronger, because banding forces you to state the outcome in terms a non-specialist decision-maker understands. And the final row carries a signal that is easy to miss: an engineer who visibly knows where the line sits is an engineer a hiring manager can put in front of a client. Discretion reads as seniority.

Why this is worth the evenings, in both markets

It is reasonable to ask whether any of this pays. The market data from both of AI Tech Connect's markets says it does, and says something about the direction of travel.

In the United Kingdom, job adverts for AI engineering rose about 1,133 per cent between 2024 and 2026, and postings mentioning generative AI rose about 350 per cent across all industries in 2026. Median UK AI engineer salary sits at around £56,614, with a range running from roughly £32,461 to £102,496 — a spread wide enough that where you land inside it is worth several years of incremental pay rises. Contract work has moved too: AI engineers ranked ninth among top contracting skills in June 2026, at an average day rate of about £550, and day-rate markets are unusually responsive to demonstrable public work because there is no long interview process to compensate for a thin profile.

In India, demand for AI engineers is rising about 40 per cent year on year while the skilled talent pool grows only 15 to 20 per cent, which is the structural gap that makes credible evidence disproportionately valuable. Around 11.7 per cent of Indian job postings now explicitly require AI skills, up from 8.2 per cent a year earlier. Salaries range from about ₹6 LPA at fresher level to ₹80 LPA and above at senior level, with Glassdoor data from May 2026 putting average base pay around ₹10 LPA. The distance between the fresher band and the senior band is the distance that verifiable evidence helps you cross faster.

Set that against the applicant ratio described at the top of this article. Postings roughly tripled; applications surged roughly tenfold. In a market shaped like that, the differentiator is not another line of experience — everyone applying has experience. It is externally verifiable evidence, which is exactly what the invisible-work problem denies you and exactly what the four categories above restore. Teams that raised money recently are hiring builders directly on this basis, as our coverage of the August 2026 funded teams now hiring sets out.

A 30-60-90 day plan you can run alongside a full-time job

The constraint that matters is not talent, it is hours. Assume three to five a week, most weeks, with some weeks lost entirely. The plan below is built for that reality: each phase produces one finished artefact rather than three started ones, because completion is the entire signal.

At day ninety you have a merged contribution someone else accepted, a reproduction with an honest finding, and an eval harness that demonstrates the rubric-design skill most teams are short of. That is more verifiable evidence than the overwhelming majority of applicants present, and none of it required you to disclose a single protected fact. If you want the general portfolio-construction case alongside this, the AI engineer proof-of-work portfolio guide covers the ground for people whose work is not restricted.

One last observation, and it is the reason this article sits on a directory rather than in a vacuum. Everything above assumes a place for the evidence to live where the people hiring will encounter it. A repository nobody links to and a write-up on a platform nobody searches are not proof of work; they are proof of effort. The public record has to be findable, in one place, attached to a name, with the shape-and-outcome descriptions sitting alongside the artefacts that back them up. That is not an incidental detail. It is the half of the problem most engineers skip after doing the hard part properly.