Skip to content
Alexander

How to talk about an NDA project in an interview

How to explain your work through constraints and decisions without breaking an NDA, how to anonymize a project, and what to say if the interviewer pushes.

How to talk about an NDA project in an interview

"Tell me about your last project." But you work at a bank, for a government client, or on a product covered by an NDA. Usually one of two things happens next. Either "Sorry, I can't talk about it", and the conversation ends there. Or the candidate gets carried away and shares names, numbers, and internal details they really shouldn't have.

There's a third option. The interviewer doesn't need the client's name or the exact number of transactions. They need to understand what problems you solved, under what conditions, and what you did yourself. You can share all of that without revealing anything confidential.

What's usually fine and what isn't

Your contract sets the exact boundaries. If you're unsure, reread it or ask your manager what's okay to say publicly. A good rule of thumb: anything the company has already talked about in its tech blog, at conferences, or in job postings is no longer a secret.

Usually off limits:

  • names of clients and partners;
  • internal names of systems and services;
  • exact business numbers: revenue, user counts, transaction volumes;
  • how security works, and anything else security-related;
  • code and documents.

Usually fine to talk about:

  • the domain: fintech, retail, logistics;
  • scale in orders of magnitude: "thousands of requests per second", "tens of millions of records";
  • your role and responsibilities;
  • widely used technologies;
  • problems, decisions, and trade-offs.

Anonymize, but don't strip out the substance

The goal is to remove anything identifying and keep the substance. In practice, it looks like this:

As it is How you can say it
Fraud detection for Bank X A fraud detection system at a large bank
12,340,000 payments a day Tens of millions of payments a day
Our "Orion" rules engine An internal rules engine
Fraud losses dropped by $200K a month Losses dropped noticeably, I can't share exact numbers
Each check must finish within 80 ms A strict response-time limit, tens of milliseconds

Don't go too abstract either. "I built an internal service for a company" sounds like you're either hiding something or didn't do much.

Tell it through constraints and decisions

When the details are closed, build your story on two pillars: what the constraints were and what decisions you made. Constraints are the most interesting part for the interviewer, and they're almost never confidential.

Example:

I work in fintech, on a system that checks payments for fraud. I can't share the product name or the numbers, but I can walk you through the problem.

Here were the constraints. A check had to finish within tens of milliseconds, otherwise the payment went through without it. Data couldn't leave our perimeter, so external cloud services were out. And the rules were changed by analysts, not developers, so they had to be rolled out without a release.

I was responsible for how rules get loaded and applied. I proposed storing them separately from the code and loading them on the fly, and moving the heaviest checks to a review that runs after the payment. Now analysts change rules themselves in a few minutes, and we consistently stay within the time limit.

There isn't a single name or exact number here, yet it's clear what the problem was, what made it hard, and what the candidate did.

How to say "I can't" without killing the conversation

A flat "that's under NDA" sounds like a wall. Offer what you can share instead, right away:

I'm bound by an NDA here, so no names or numbers. But I can explain how the problem was structured and what I decided.

I can't show you the actual diagram, but I can sketch a simplified one without internal names.

If the interviewer pushes

Sometimes you'll hear "just roughly, it stays between us". Answer calmly, without making excuses:

I'd rather not break my agreements with my current employer. I think you wouldn't want your own employees to do that either.

Usually the question gets dropped after that. And the interviewer gets one more reason to trust you: you're someone who can be trusted with internal information.

If there's almost nothing you can share

Sometimes nearly everything is closed. In that case, add what you can show: a side project, open source contributions, a talk, or an article. And say more about how the team worked: processes, code review, how decisions were made. That's usually not confidential and says a lot about you too.

Prepare the anonymized version in advance

Coming up with wording on the fly is risky: when you're nervous, it's easy to let something slip. Write the anonymized version of your project in advance and say it out loud a couple of times. Check that no names or exact numbers sneak in.

If you use Sobes Copilot, put only the anonymized version into your context and notes. Then the hints during the interview won't include extra details either.

How to fit your intro into two minutes is covered in “Tell me about yourself”: examples for developers. And how to pick a story for the question about your hardest task, in “Tell me about a challenging task”: how to answer.