

Ask HN: How do you showcase work from previous jobs? - jit_hacker

I&#x27;ve worked for a few enterprise software companies on big products in the past and am currently working for a startup that may not be around in a few years (hopefully it will be, but that&#x27;s reality).<p>Lately, I&#x27;ve been wondering how I could preserve my work to showcase in the future. I don&#x27;t think it&#x27;s always practical, or legal, to assume keeping a copy of the code is a good showcase. And screenshots are, well, shallow.<p>Anyways, I was curious if any of you have done the same? And what route you took for preserving your work.<p>EDIT: I&#x27;m not just referring to interviewing purposes. I think in general it would be great to reflect back on the things you&#x27;ve done from time to time. Who knows where you&#x27;ll be in 20 years, but in a digital age it seems desirable to keep some kind of log of what you&#x27;ve done of the course of your career. Perhaps the word, &quot;showcase&quot;, was a bad choice.<p>EDIT 2: My comment about keeping the code was poorly worded and being misinterpreted. I have no interest in keeping any former code, it&#x27;d be dated within a year or two. The heart of this question is about showcasing&#x2F;archiving great innovations and cool things you&#x27;ve built that aren&#x27;t easily available.
======
wiremine
This is an awesome question.

> I've been wondering how I could preserve my work to showcase in the future.
> I don't think it's always practical, or legal, to assume keeping a copy of
> the code is a good showcase.

I agree. I see a lot of organizations asking for open source as a litmus test
for the candidate.

As a former manager who has hired dozens of programmers, I think that's
stupid, because it vastly limits your pool of candidates to people who have
time to contribute to open source. I've found that there are lots of very
gifted people who have never worked on anything they can share. And "side
projects" tend to show you what the candidate wants you to see: well crafted
code that didn't have external requirements or hard deadlines. (Note: I'm not
suggesting you _don't_ use open sourced code in the interview process, just
that you don't use it as a gateway into the larger interview process).

Looking forward to watching this thread!

Edit: fixed a confusing sentence.

~~~
TallGuyShort
The other side of this is that I, as a candidate, use open source as a litmus
test for the employer. If the company contributes heavily to open-source, the
culture is more likely to be compatible with me, AND it's legal for me to show
my work to future employers. A lot of open-source work is done with corporate
backing, so if one doesn't want to contribute outside of work, I'd suggest
looking for an employer that will let them work on open-source projects, at
least part-time.

~~~
TallGuyShort
Adding this a bit late for it to be an edit, but I'd add that I think it's
unfair for employers to have open-source work as a de-facto requirement if
they don't contribute to open-source themselves. Open source is also a chance
for you to see how the company's existing employees comport themselves, how
they work through problems, and what kind of day-to-day problems they're
working to solve.

------
yanowitz
When interviewing people, I don't need to see previous work product. I need
them to talk about what they've built, why it was satisfying and what was hard
about it. I've found that in less than 10 minutes I can establish whether
someone worked deeply on something and understands what they've done. After
30, I can tell whether they're exceptionally proficient and if we'd enjoy
collaborating.

As to coding chops, I think that has to be solved via asking them to code a
solution to something on the spot (or perhaps in advance). That's far from
perfect, but I don't think you need a portfolio, per se.

Although, if you have lots of stuff that's publicly available, that's clearly
a bonus. But that's not an option for many people.

~~~
daenz
Maybe I'm an outlier, but I cannot talk proficiently about a project I haven't
worked on in months. When it's in my brain, I am living and breathing it, but
afterwards if I'm asked to talk about it, it stumbles out as I try to recall
the pieces. I can rehearse beforehand, but it becomes clear as soon as the
interviewer does any digging, that I don't remember the details.

Ask me to code something beforehand and I'll excel at it, but ask me "what's
going through your mind" as I'm coding it and I'll sound like a scatterbrain.
I need time, low pressure, and privacy to code well.

~~~
mcovey
>I need time, low pressure, and privacy to code well.

Me too. I've had jobs where I had to work in areas with high foot traffic,
lots of distractions, I could never get in "the zone" and never got any real
work done. Well, looking back, I did get some work done, but I always felt
like I was too distracted to focus, and it definitely took me a lot longer
than it would have otherwise.

------
krschultz
It is a difficult problem. I worked at a defense contractor where I can't talk
about what I did at all, so interviewing afterwards was tough. One thing I did
was write down a bunch of notes for myself, that way I can refresh my memory
before future interviews. I don't pass it to the employer. I try to cover the
typical questions:

\- How big was the team?

\- What was your role on the team?

\- Project scope / length / budget?

\- Did you meet that timeline & budget?

\- What kind of work? (Building new features? Maintenance? Replacing legacy
project?)

\- Major technical challenges?

\- Lessons learned?

\- Technologies used?

\- What would you do differently next time?

If you can speak to all of that, it generally doesn't matter that you can't
actually show off the product. In my case I can answer all of those without
even telling you what the product was.

The one exception would be if you are doing heavily UI based work. Then I
would think recording some screencasts might be good, and putting it in a
gallery. That's not the kind of work I do, so it generally doesn't apply for
me.

------
cpfohl
Well...unfortunately you don't really own your work in most cases when working
for someone else. Your best bet (as far as I know) is to describe the software
and its impact on the business. A company will understand that you can't show
them your previous code that is someone else's intellectual property: they
wouldn't want you doing the same with their code.

~~~
jit_hacker
Yea, this is definitely true. My comment about the code was more in terms of
being able to actually run a live version of what you've done in the past,
either as a demo or just a refresher for your own purposes.

And also, part of my concern that wasn't well pointed out, was in some cases
those previous companies may not even exist. You couldn't even "point to the
company" and say I worked there, on that.

~~~
qeorge
"being able to actually run a live version of what you've done in the past"

This is a non-starter. Its not your IP; you can't keep a copy around (even if
its just for archival purposes).

------
napoleond
I agree with what others have said; this is a great question. I think there
are a few answers (most of which have already been touched on at least a bit)
which complement each other:

* Open source whatever you can. I have had the good fortune of being self-employed for the last few years (although I was also in school for part of that time), and one of the huge benefits of that was being able to open-source almost everything. (My client agreements usually allowed me to open-source anything that wasn't unique to their line of business.) Obviously not everyone is that fortunate, but it often makes good business sense to open-source internal libraries and such (more eyes on the code base, currying favour with developers, etc) so it definitely can't hurt to ask and try making a case for it.

* Take screenshots and video. Sure, maybe shallow by themselves (especially if you're not a UX/front end person) but it is a neat part of the package, even if only for yourself to review 10 or 20 years down the road. Some people have pointed out that you may need permission to take a video of the software... it seems to me that if you were working on that sort of software you'd know it.

* Keep a journal. This is helpful on a lot of personal levels. You might also want to blog, for similar reasons. 10 or 20 years down the road, it will help you remember what you did. Information from the journal can be helpful in portfolios and resumes, and you might also find yourself using your own journal down the road when you run into similar problems.

Regarding your second edit, I think turning the above information into a
"showcase" probably just means building a small portfolio for yourself. Have
"case studies" where you talk about what you did for a certain
project/company/whatever. Or, depending on the nature of the work, you might
choose more of a "memoir" style--either way, the point is you pick a few
things you worked on and write about them, using your journal (if available)
as a memory aid and screenshots/video/open source contributions as supporting
material, if available.

------
jeremya
How about a recorded screencast or youtube video showing the solution in use?
It will not be interactive, but will show some of the interactivity of the
solution.

~~~
user24
That's a really good idea.

~~~
kasey_junk
Actually, this is a pretty terrible idea in a lot of contexts. This could
easily be interpreted as stealing from your prior employer.

~~~
danielweber
I almost want to use the "flag" button for people suggesting this, given how
colossally bad an idea it is. (But they are posting something on-topic, in
earnest, so I don't.)

------
wooptoo
Record screencasts of the applications that you worked on. Keep them under 3
minutes, showing only the major features.

~~~
danielweber
No, this is a very bad idea. If your old employer would ever accuse you of
stealing software, it would be extremely bad for your case for a video you
made of the application to show up in any documentation.

I don't know where that "3 minute" rule comes from. It smells like the "you
are allowed to download these ROMs only for 24 hours" nonsense that emulator
sites (used to?) say. That only increases my suspicion of this advice.

~~~
riffraff
I don't understand this comment. Why would me having a video of an app I built
be a hint that I copied it? Also, would I even have to provide such a video as
evidence?

The 3 minute thing seemed to me a simple example of "keep it short to keep
viewer attention".

EDIT: maybe you interpreted GP as meaning take a screencast of the code, while
I am thinking of the working app?

~~~
danielweber
A lot of "enterprise software" is stuff that you will never ever get on your
home PC. Your employer only let you have access to the software under the NDA
and IP agreement you signed, and unless they explicitly say otherwise, that
also includes showing how it runs.

This isn't like showing off the feature you wrote for MS Word.

------
msutherl
A few portfolios I like to refer back to as good examples of different
approaches:

\- mason.js-style grid of experiments and projects, filterable:
[http://hakim.se/](http://hakim.se/) – direct links to demos

\- short-description + screenshots:
[http://www.robbiemanson.com/](http://www.robbiemanson.com/)

\- a full blog post per project:
[http://www.minimallyminimal.com/](http://www.minimallyminimal.com/)

------
w0rd-driven
The implementation details of this idea are the problematic part, I think.
Everything you can conceivably think of starts to skirt along ethical/legal
lines but I think it's an important discussion to have.

Ideally, as developers, we would have some sort of standardized process to
archive the important parts of our career. I personally don't _need_ this for
future employers but with this weird fear I have that if I ever did have
early-onset alzheimers, I'd want to remember at least _some_ aspects of my
life. It may be a highly irrational fear but archiving my work life in a
relatively meaningful way that I may archive my personal life seems like
nothing but a good idea to me. These ideas may be completely impractical in
most scenarios but at least having the discussion seems like a good idea.

As a hypothetical employer, I would want my employees to feel they can share
the interesting parts of their career with my company. It promotes enthusiasm,
showcases important work we're doing as a company, and a host of other
benefits. I'm sure there are a series of downsides I can't think of at the
moment but conceptually this seems like a good idea. It's just standardizing
on what really works in most situations that'll likely be the biggest
challenge.

~~~
jarek
As a developer, I want to have a record of my work just as an artist wants a
photo or a mould of a sculpture they sold.

I'm not about to not do it based on someone on the internet's interpretation
of IP.

If a programmer is working on super proprietary high-tech stuff like HFT, sure
- but most of us are just pushing bits and most value we add is from processes
and experience.

------
bcooke
In realizing that a lot of my best work was effectively walled, I've started
taking it upon myself to build up a showcase of work that's strictly my own.

I think you should look to have a portfolio online and an active Github
account.

I have 3 things on my portfolio (www.bcooke.net):

1) Side projects I never finished or am still working on 2) Freelance sites I
built alone (where my good relationship with the client meant I could openly
share the work) 3) Brief blurbs about the salaried roles in my career, with a
screenshot

I haven't updated it in a while but it's something.

Do you have a portfolio? Is your Github active? StackOverflow? You need things
you can show!

It sucks because your best work - the stuff you spent the most time on - isn't
always available to share. And even if you could, there'd be questions about
which part you did.

Having a site you can point to and say, "I did that" is a good way to showcase
your abilities, and if all your work is owned by your employer, you should
probably start thinking about ways you can change that.

------
dkrich
I think you can speak in terms of the technology you used, what you liked
about it, what you disliked about it, the business objectives and how you
helped achieve them and still do fine without showing an actual code
repository.

Most interviewers come in with a list of questions they want to ask, so if you
can talk about your work in terms of the answers you know they want, you're
probably better off than a candidate who can demo a project that the
interviewer may or may not care to see.

For keeping a log of what you've done, I don't think there's too much you can
do about this. Part of your agreement when being hired is that you are being
paid to build something that belongs to your employer. The only way around
this I could see is if you were able to extract some abstract tool that could
have wider use and get permission to distribute it or at least keep a copy for
yourself (a lot of employers won't agree to this, however).

------
mightybyte
My answer to your initial post was: be able to converse about your previous
work in-depth.

To your first edit, I say I do keep a log of what I've done over the course of
my career. That log is my resume. I typically update my resume multiple times
while I'm at a job even when I have no plans to leave any time soon. I do this
to keep it up to date while projects are fresh on my mind.

Some comment about edit 2. That's what the resume is for. It's my list of
great innovations and cool things I've built. For me, this includes personal
projects. This is where open source contributions can be really useful because
they're public and everyone can look at them. IMO open source projects are one
of the most impressive resume builders out there.

------
nanoscopic
1\. Document what you do extensively, including explanative screenshots if it
involves UI components.

2\. Give the documention to your employer ( it will be greatly appreciated )

3\. Ask your direct superior if you can keep a copy just for personal
reference

4\. Unless your superior is a jerk, this will likely be given the ok.

5\. Do so ( strictly speaking this is often illegal; but if superior
approves... )

6\. Use said documentation to write -new- documentation based off it off work
hours ( clean room rewrite of docs essentially ) ( note that depending on what
you signed, even these conceptual documentation rewrites may be illegal to
share; you'll need to read what you sign )

7\. Give rewritten un-infringing documentation to whoever you wish

------
TezzellEnt
It's definitely tough showcasing some of your work, and this is a question
that I was curious about as well. In my case, there have been certain projects
that I have worked on in the past where I have been under a confidentiality
agreement. However, what I built is something that I'm immensely proud of and
would love to show off.

I do like some of the suggestions other people have mentioned about recording
a screencast of the product (if you're allowed to do it). Its definitely a
great idea, although if you're programming something in say Ruby On Rails or
PHP on the backend, how can you show off code that you wrote and then
refactored?

I'm curious what the more seasoned hiring managers would want to see?

~~~
danielweber
A seasoned hiring manager isn't going to demand a portfolio.

------
pjc50
It's difficult. If you're under NDA then there's very little you can say.
Sadly this is what we have to work with in a digital strong-IP work-for-hire
world: you don't own your work, you can't archive it, your employer probably
won't archive it properly, and in a decade or so it may not exist. All you get
to keep is the salary and the memories.

Pragmatically the easiest thing might be to take your own copies of company
publicity materials about the product. That way you avoid NDA problems.
Technically a screen shot of the product information page from 3 years ago is
infringing but not in a way that anyone is likely to care about.

------
igaape
I personally like the idea of keeping a personal journal. I usually just
describe what i'm working on and write it in a document which goes into a
folder that is month / year stamped. Just be descriptive in what project you
worked. How you overcame certain problems. What were the pain points and your
solution. Rather than using actual code you can use Pseudo Code or write it in
descriptive english so its a reference point to your coding efforts and
nothing to do with the IP.

------
kasey_junk
I don't want to rain on your parade, but having worked in a lot of highly IP
sensitive jobs, don't attempt to showcase your work from previous jobs. There
is virtually no way to do this that can't be interpreted incorrectly. Unless
your employer has granted an open source license on your work product even
talking about technical details can be tricky.

I've literally stopped interviews when the applicant starts getting too close
to what appears to be protected output.

------
maxaf
Endeavor internally to drive your employer towards open sourcing pieces of the
codebase (incidentally ones you've worked on) that are also irrelevant to your
core business. This helps keep code more modular while also building up a
public record of the employees' doings.

If nothing else the experience itself will probably turn out to be quite
healthy for your team.

------
spiritplumber
I show people screenshots of the designs (I'm an EE). It's not like they can
reverse engineer a multilayer PCB from a screen grab of the CAD program. The
only people who had a problem with this were NASA, but other customers have
been understanding of the "I can't show you much of my NASA work because they
wouldn't let me keep copies" line.

------
chrisbennet
I have a very basic web site that with my portfolio. It has images of products
I've made or worked on as well as interesting side projects. I put a link to
it in my cover letters and resume'.

I have a video of one of products I made - a virtual oscilloscope but other
than that one, they are just images with a little blurb about the technology
used.

------
amac
If you've done any design work or at least contributed in some way to a
creative project you could try [http://behance.net](http://behance.net).
Alternatively, [http://github.com](http://github.com) would be your best bet
if you've done mostly back-end work.

------
_pmf_
To contrast the interviewer side: when I do interviews, I take depth over
breadth, and depth can easily be evaluated by the interviewer asking specific
questions along the line of: what was the most specific problem you
encountered in your work on this specific problem and how did you solve it /
work around it.

------
exhaze
patio11 has a great blog post tangentially related to this:

[https://training.kalzumeus.com/newsletters/archive/do-not-
en...](https://training.kalzumeus.com/newsletters/archive/do-not-end-the-week-
with-nothing)

------
th3iedkid
one way of archiving good innovations is to have a open-source fork of the
innovative design artifact you might want to archive.

These needs understanding the underlying IP law motivations.Most things like
mathematical processes around things cannot be IP'd.So , can't we have an
open-source implementation around the same?

------
userone
When we are working for an Organization, your efforts makes how much impact on
business, timely and correctly providing the deliverables as defect free, this
leads to Business owner satisfaction. So automatically Company will recognize
you and will reach your aspirations as soon as. We con't show the previous
code becoz intellectual property of someone else and being a security or
software professional we need to keep in mind that "Data Privacy policy".

