I wanted to know how others are best showcasing projects that are work-related in their portfolios?

I'm currently a Systems Analyst/Developer and have created quite a few UI, Batch, and Automation scripts for my job. My concern is that I work for a financial institution, and while I could show samples of my work without data, from a security standpoint I want to showcase what I've done without it being a liability/risk.

Would it be more ideal to just provide screenshots and an explanation of technologies used?

Appreciate any feedback

  • 1
    In what context are you trying to showcase your work? As part of a job search? On a profile for some type of professional social media? Something else?
    – dwizum
    Commented Nov 18, 2019 at 17:46
  • Did you sign an NDA? If not, could you ask your manager what you can show? (i.e. if this doesn't give away you're searching for a job)
    – Llewellyn
    Commented Nov 18, 2019 at 18:24

1 Answer 1


I've been a part of several large-scope, big-budget projects over the past few years, and although I've always referenced my contributions, successes, challenges faced, etc. I've never provided screenshots, code, or anything else to prospective employers. And I do not think I will ever start doing so:

  • First of all, my former employers, most of whom I'm still on good terms with, might not appreciate it.

  • Second, as you've noticed, there's typically a lot of context that may need to be provided, and it gets very tedious.

  • Third, most early interview rounds are with people who essentially play buzz-word bingo with your resume, and have no actual idea of what they're looking at when confronted with anything more complicated than Microsoft Office or their email client.

Furthermore, more complications can arise when some third party looks at code or interfaces you've designed:

  • Interfaces, like art, are often subjective. One set of users / managers think it's great, others will think the colors are tacky, etc.

  • Great code is often complex, relies on libraries, etc. and takes a long time to understand. Maybe the person reviewing it doesn't like some of the techniques you've used, or feels intimidated by the complexity, and thus ranks you lower.

By far the best approach (IMO), is to do describe the projects you've been a part of, and your role in them. Describe the problems you've solved, and how you handled new challenges, etc.

Example: I was the senior technical specialist assigned to designed a new order system for so-and-so. Over the 12 months that I was a part of the project, I participated in numerous requirements gathering meetings, with managers and employees from 3 different departments. My role was to translate user requirements into technical ones, and to write comprehensive documentation. Later, when we had a solid idea of what was required, I was the one who created mock-ups of how the system would look, and how the process flow would work. This was an iterative process, with our users providing input, and our vision changing over the months. At the end of those 12 months, the project went into the implementation stage, and my role switched to ...

Being able to communicate your successes will do a lot more for you than simply relying on your audience to understand how great you are based on some code samples, or screenshots.

Similarly, your resume should read as a compressed version of that (too many times I see short bullet points that do not help candidates stand out at all), and you should be ready to explain your accomplishments/role at length in interviews.

Practice your explanations such that you can keep it short and sweet. Play a little buzzword bingo of your own, such that HR or recruiters can tick their check-boxes.

Most importantly, learn to tailor your explanations to your audience. Your contributions to the exact same project can be tailored to emphasize your team-working abilities, your communication skills, or your technical prowess. You have to understand which one you need to highlight based on who you're talking to.

For example, you may look at the technical interviewer when discussing code and technical challenges, then change focus and give the HR rep your attention when discussing how you handled user's fears that the system would replace them, etc. If the HR person is not in the room, but the manager is, instead mention the techniques you used to meet your deadlines, and how you communicated and accounted for any complications, etc.

You must log in to answer this question.