I don't. My job application e-mail contains a file titled "project experience" (well, actually it's called "Projekterfahrungen", because I currently search a new job in Germany). In that file, I describe each (larger) project I've ever worked on. Something like this:

Blinking Box is the new and enhanced Enterprise class control panel of BigCompany. It features buttons, more buttons, and even colored buttons. And it has nice blinking lights.

My tasks:

• Port from a rotten piece of Fortran to Perl
• Polish buttons and rewire lights
• Set up version control using Subversion
• Documentation
• Whip and spank the trainees

Blinking Box today:

• Lights more shiny than ever before
• Custom buttons for each client
• Best selling product of BigCompany

During the interview, I explain a little more of the details, and how the projects were implemented. And of course, I can always tell them that I wrote the initial Unicode patch for DBD::ODBC. Unfortunately, that's all I could publish from my paid work so far, and it's hard to explain to a full-time interviewer without software developing experience.

Alexander

"Yes!!! "x1000

You could also head over to http://www.oswd.org/ and pick up a free website template and make some simple mind-blower web-based doohickey on a website that doesn't look half bad.

While you're at it, release some good code that YOU OWN on CPAN and link to it from your homepage.

Create a blog and write a few entries about something that interests you - programming related or not. Something that would show up favorably when your prospective employer Googles your name.

Create a LinkedIn profile and take 20 minutes to seek-n-find-n-connect previous co-workers who might also be on LinkedIn. More associates & recommendations are better.

Contribute to some kind of "cool" project. For example, Kamaitachi is a Perl-based Flash Media Server that provides the ability to interact with webcams via a web server. It could use some new features, tests and/or documentation. There are a thousand projects out there just waiting for something in your position to take a day or two to really make a difference and gain some accolades in the process.

P.S. - Good luck on the job hunt!

In many locations, including much of the USA, by default any code that a professional programmer writes belongs to the employer even if that code is written on personal time on a personal machine. Furthermore in such legal jurisdictions it is standard boiler plate for employment contracts to reaffirm that all such software is owned by your employer, and not you.

Given this, arranging to actually own some of the code you wrote is not always easy.

My advice would be to do a little hobby programming to show off your style and skill. Put that on CPAN.

Even if it's not of the same scope and caliber of your closed source work, it will give them an idea. Most likely you will have learned things, in a generalized sense, that you can share with others -- who might then benefit from your showing off.

Yes uploading to CPAN helps I can assure you that, but it must be worthy to upload IMHO. Being served from CPAN.org does not transform crappy code into some beauty. And one can always use the public repositories (GitHub, BitBucket, LaunchPad, SourceForge, etc.) to serve code and have some sort of portfolio page.

That is difficult. How about-

• Get those who have seen the proprietary stuff to recommend you on LinkedIn; target the recommendations to what you can't show. Coworkers/managers who liked your work may endorse/sign anything you present so don't be shy about paraphrasing what you want in a recommendation (if you're sure it will be well received).
• Write white-paper-ish treatments of what you've done; discuss the problem space, approaches, related tools, and technologies; making sure not to cross disclosure lines. This will not show code but demonstrate your understanding and ability to self-manage. Brevity and clarity make this kind of tech reading enjoyable for the widest audience.

Don,

Excellent question -- instead of being able to show them code, I talk enthusiastically (that doesn't need much prompting) about the cool thing that I did -- or one of them -- the challenge involved, my derivation of the solution, some tinkering, and the eventual, gorgeous and complicated solution.

In my case, it was a mod_perl request handler that communicated over a named pipe to a daemon that would spawn off child processes to run a piece of proprietary code to generate page images. After some idle time, the idle children (sound familiar?) would get terminated.

While I couldn't show the code that did all this (for reasons such as you've just described), I was able to talk about how I used IPC::Run to do part of this, and how a watched display of ps axf would show a tree of processes expanding and contracting as the daemon process got busy, then idled off.

> "Amusing footnote: As it happens, I know 'Don' from University, and we played in a band together after that..."

And only modesty has kept me from using that as the opening line in my cover letters - "I knew talexb back when..." - far more impressive than any of my code. :-)

I'd start with asking "what do you need done?". Focus on the client rather than yourself. More than anything else potential clients and employers want to know that you understand their goals, are enthusiastic about helping them reach them, and will do what it takes to make it happen.

Once you know what they want, you will also be in a much better position to reassure the potential client that you can contribute to the project. If this is a coding project, you can write a targeted bit of code that shows you have the skills they are concerned about and can apply them to some small part of their problem. That is much easier than a demo website or CPAN module aimed at any-potential-customer-in-the-whole-wide-world.

You will also be in a much better position to decide if a code sample is even needed. For example, if you want a design or project management role on your next project, the client will most likely be far more concerned about how you scope a project. They will want to know whether or not you can identify the time and resources needed to complete it and make a cogent case to support your conclusions. If you are looking for a job as technical lead, explaining how you approach coding standards and a sample that illustrates you can practice what you preach may be more important than showing off the cool stuff you did on your last project. If the primary concern is algorithm development, your problem solving skills can be demonstrated in many ways.

Finally, these days development is often a team sport. The way you demonstrate your ability to communicate and work with others during the interview may be far more important to the hiring decision than any code sample you could leave behind, no matter how amazing.

Best, beth

If you want to get hired by a top company (Google and the like) I guess you should do non-trivial open source contributions to make an impression

If you just want to do contracting you don't normally need a lot of code-exhibits - you need to be able to sell yourself in an interview situation and then communication skills are just as important as technical skills (but the people that interview you probably are more desperate to find someone then you are finding a project).