Ask HN: How do you showcase work from previous jobs? | Hacker News Reader

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

81 pointsjit_hacker61 comments

I'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's reality).

Lately, 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. And screenshots are, well, shallow.

Anyways, I was curious if any of you have done the same? And what route you took for preserving your work.

EDIT: I'm not just referring to interviewing purposes. I think in general it would be great to reflect back on the things you've done from time to time. Who knows where you'll be in 20 years, but in a digital age it seems desirable to keep some kind of log of what you've done of the course of your career. Perhaps the word, "showcase", was a bad choice.

EDIT 2: My comment about keeping the code was poorly worded and being misinterpreted. I have no interest in keeping any former code, it'd be dated within a year or two. The heart of this question is about showcasing/archiving great innovations and cool things you've built that aren't easily available.

View on HN

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.

Going a bit off-topic here but open source is partly a cultural test. There are great programmers who are 9-5 and there are terrible enthusiasts, but involvement does mean that people are going to be speaking the same language to a large extent - and the biggest overhead in delivery teams is usually communication.

In fairness, there are a lot of great programmers who work on projects they really believe in and spend all of their available free time dedicated to them. Even if they're for the company/enterprise/startup they work for.

Are they by some chance mostly male, under 35 and without families?

Yes, but so are most programmers that do open source work or side projects in their spare time.

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.

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.

> 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.

That's an interesting observation. Sadly, I feel that my side projects are of lower code quality than my paid work, since they are constrained by whatever scraps of time I have left over after making a living. I sometimes wonder if I'm doing myself a disservice by sharing code on github before it has been polished.

> 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.

This is a fairly common point of view that I've come across when discussing this issue recently.

Personally, I think it's a bit of a fallacy, because you don't actually need a lot of time to contribute to open source. I find it hard to believe that anyone who is serious about their career can't afford as little as one or two evenings a year to establish some kind of online presence. Yet that is all you need to set yourself way above the overwhelming majority of the competition -- especially in .net -- who have absolutely nothing online whatsoever anywhere to substantiate the claims on their CVs or LinkedIn profiles.

The point about "side projects" showing what the candidate wants you to see is true, but you could make the same claim about artists, photographers or architects -- and you simply wouldn't hire one of them who didn't have some kind of portfolio, end of story.

The real reason why we don't expect programmers to have any kind of portfolio or other online footprint is a cultural one more than anything else. It's still so uncommon -- especially in the .net world -- that if you limited your recruitment pool to developers with online portfolios, then you'd have trouble hiring anyone. However, I expect that will no doubt change in the coming years.

(Edit: fixed sentence that didn't quite make sense)

> The real reason why we don't expect programmers to have any kind of portfolio or other online footprint is a cultural one more than anything else.

I'm not sure I agree with that. Two follow up points:

1. I think an online portfolio is a great idea: I've hired a number of designers, too, and their portfolio is the first thing I've looked for.

The difference is a designer portfolio can include their professional work, whereas a programmer is limited to their open source contributions. I wouldn't judge a designer on their personal projects: "Hey, designer, I want to see your work, but only the stuff you've done on weekends and in the evening." It doesn't do them justice, and I'm basing my hiring decision on a subset of the work. In the same way, requiring open source contributions to gain entrance to the interview process is limiting.

2. If the programming culture required an online portfolio, that is essentially requiring programmers to have a second, unpaid, part-time job. I do not think you can generate enough great code in a few days to get noticed.

I do agree that some sort of portfolio would be handy: I just don't think an open source only portfolio is the way to do it.

> I do not think you can generate enough great code in a few days to get noticed.

I'd agree that you can not generate enough great code in a few days to get noticed by the open source community in general. However, you can generate enough great code in a few days to get noticed by a hiring manager who is sifting through a couple of dozen CVs, all of which look pretty much the same as yours, deciding who to call in for an interview. A modest amount of code can also give a hiring manager a first-order indication as to its quality.

What I'm talking about here are developers who have nothing at all whatsoever. That should be a massive red flag. Unfortunately, because so many job candidates have nothing at all out there, it can't be.

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.

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.

Same here. In fact I just had an interview today where I completely stumbled through explaining what I did.

>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.

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.

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.

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.

"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).

At least if the company doesn't exist they're not going to complain about it. Although whoever ended up with the IP in the liquidation sale might.

Running a live version of old software is often surprisingly hard, as it will depend on other old software or nonexistent systems. VMs make this a bit easier, but if it's a distributed or embedded system that doesn't work either.

For most business line apps (i.e., the majority of code that's being written in the world) there's small chance a developer would be able to run a live demo of their code. If the code was freely available, it wouldn't meaningfully run without all the other connected systems and [semi-]live data - a live demo can exist (and often does, to be shown to potential customers or such), but it usually requires a bunch of dedicated servers and periodic work from operations team to configure & maintain it.

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.

That's a really good idea.

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

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.)

I'm not sure about that being legal.

If it's legal, make 100% sure it only has test data.

Still, it's probablly a better alternative to showing code (which is usually owned by the company).

Edit: it apparently isn't legal by looking at the sibling comments :)

It also has the disadvantage of not showcasing the back-end. In my case, most of my work doesn't show on a screen :) .

I would only do that with written permission from the employer. Even if the system didn't have any major technical secrets, you could inadvertently reveal subscriber statistics or some other information that was considered private. And even if you feel that you didn't reveal anything, the employer might still consider it as theft of trade secrets.

If the company has public demo or instructional videos, on the other hand, you could use those.

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

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.

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?

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.

But if your employer ever accuses you of murder (wrongful death), the fact that you were narrating a video from home at the time might provide a fortuitous alibi.

Call it a wash.

I can't tell if this is a total joke post like reddit, or a sarcastic attempt at saying "well the employer can accuse you of ANYTHING" because the poster has never heard of employers accusing former employees taking things.

You aren't supposed to take private work materials with you when you leave. I know for a fact that I've seen "screenshots" explicitly listed as one of the things I'm not supposed to take in several very reasonable employee agreements I've received over the years.

Having been presented with very unreasonable employee agreements (once a security company tried to get me to sign "we own all your IP while you work here, and for a year after you leave" agreement), that doesn't mean the company doesn't get to keep the private stuff it owns private.

It's theirs, not yours. You signed an agreement not to take it. Don't take it.

My company makes this easy by putting a demo video out every 6 months or so. It's always a bit behind in the feature set but its better than nothing.

I guess my point is try to look for resources your company puts out before trying to create your own

Yes, anything that the company has publicly released is fine. If you want to show off the feature you wrote for MS Word, buy a copy of MS Word as a consumer and show it off on your laptop.

Do you have any legal knowledge to back up this position, or is it just baseless fearmongering? The laws we have are already restrictive enough, without making stuff up. So, what is the legal basis for your position?

You have the burden of evidence flipped. Contracts are valid unless found otherwise by law. There have been a variety of exceptions carved out from what's allowed in employee agreements over the years. The right to generate a portfolio of one's work history is not, yet, in that list of exceptions.

As a programmer I don't make videos, I write source code. We're not talking about me waltzing off with the git repository, but of me videoing my software as it does what it does. I for one, after 20 years experience mind you, have never signed a contract explicitly forbidding me to make a video of the product that I worked on running. I think that most other programmers are in the same boat. Which means that for most programmers, unless you are aware of a specific legal protection afforded to viewing software in action, your advice is scaremongering, and not helpful.

This doesn't make sense. If you stole the software why would a demo video work against you? Why bother with a demo video if you have the real thing to demo? You'd demo functionality not code.

I think that's a pretty good idea!

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.

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.

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.

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/ – direct links to demos

- short-description + screenshots: http://www.robbiemanson.com/

- a full blog post per project: http://www.minimallyminimal.com/

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.

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).

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.

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?

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

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.

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

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.

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.

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.

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.

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.

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

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.

patio11 has a great blog post tangentially related to this:

https://training.kalzumeus.com/newsletters/archive/do-not-en...

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?

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".

Reply on news.ycombinator.com