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

81 点作者 jit_hacker将近 11 年前

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.

25 条评论

wiremine将近 11 年前

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.

评论 #8042214 未加载

评论 #8042114 未加载

评论 #8042238 未加载

评论 #8041903 未加载

yanowitz将近 11 年前

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.

评论 #8043348 未加载

krschultz将近 11 年前

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 年前

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.

评论 #8041766 未加载

napoleond将近 11 年前

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将近 11 年前

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.

评论 #8042100 未加载

评论 #8041816 未加载

wooptoo将近 11 年前

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

评论 #8041877 未加载

评论 #8041927 未加载

msutherl将近 11 年前

A few portfolios I like to refer back to as good examples of different approaches:- mason.js-style grid of experiments and projects, filterable: <a href="http://hakim.se/" rel="nofollow">http://hakim.se/</a> – direct links to demos- short-description + screenshots: <a href="http://www.robbiemanson.com/" rel="nofollow">http://www.robbiemanson.com/</a>- a full blog post per project: <a href="http://www.minimallyminimal.com/" rel="nofollow">http://www.minimallyminimal.com/</a>

w0rd-driven将近 11 年前

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.

评论 #8042074 未加载

bcooke将近 11 年前

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 screenshotI 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 年前

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 年前

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将近 11 年前

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 reference4. 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将近 11 年前

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?

评论 #8042028 未加载

pjc50将近 11 年前

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将近 11 年前

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 年前

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将近 11 年前

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将近 11 年前

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将近 11 年前

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 年前

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

_pmf_将近 11 年前

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 年前

patio11 has a great blog post tangentially related to this:<a href="https://training.kalzumeus.com/newsletters/archive/do-not-end-the-week-with-nothing" rel="nofollow">https://training.kalzumeus.com/newsletters/archive/do-not-en...</a>

th3iedkid将近 11 年前

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 年前

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