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

81 points by jit_hacker 11 years ago | 61 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.

wiremine 11 years ago |

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.

simmons 11 years ago | |

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

TallGuyShort 11 years ago | |

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 11 years ago | | |

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.

jammycakes 11 years ago | |

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

wiremine 11 years ago | | |

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

dreamfactory2 11 years ago | |

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.

jit_hacker 11 years ago | | |

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.

yanowitz 11 years ago |

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 11 years ago | |

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 11 years ago | | |

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

mattm 11 years ago | | |

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

krschultz 11 years ago |

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 11 years ago |

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 11 years ago | |

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 11 years ago | | |

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

PeterisP 11 years ago | | |

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.

pjc50 11 years ago | | |

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.

jeremya 11 years ago |

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.

jakejake 11 years ago | |

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.

user24 11 years ago | |

That's a really good idea.

kasey_junk 11 years ago | | |

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

GFischer 11 years ago | | |

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

prima-facie 11 years ago |

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

danielweber 11 years ago | |

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 11 years ago | | |

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?

jamieomatthews 11 years ago | | |

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

antimagic 11 years ago | | |

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?

driverdan 11 years ago | | |

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.

logicallee 11 years ago | | |

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.

Tepix 11 years ago | |

I think that's a pretty good idea!

napoleond 11 years ago |

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.

w0rd-driven 11 years ago |

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 11 years ago | |

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.

msutherl 11 years ago |

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/

bcooke 11 years ago |

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 11 years ago |

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 11 years ago |

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.

TezzellEnt 11 years ago |

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 11 years ago | |

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

pjc50 11 years ago |

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.

nanoscopic 11 years ago |

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

igaape 11 years ago |

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 11 years ago |

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.

spiritplumber 11 years ago |

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.

maxaf 11 years ago |

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.

chrisbennet 11 years ago |

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 11 years ago |

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.

_pmf_ 11 years ago |

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 11 years ago |

patio11 has a great blog post tangentially related to this:

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

th3iedkid 11 years ago |

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 11 years ago |

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