If I'm looking to hire a front end web developer, I want a candidate that fulfils two key requirements. Firstly that they can build a site that looks right and secondly that they have built it well. Some people don't worry so much about the second requirement but writing clean, elegant and above all flexible code is an aspect of web development that I consider a vital part of efficiently maintaining a website in the long term.
With that in mind, the first thing I look for on a candidate's CV is a list of what sites they have built. Thanks to the way the internet works it's possible to examine any website in detail to assess the person who built it in terms of both of my requirements - appearance and coding skill. I'm not so interested in someone's work history, education or interests - what I care about most is whether their website's code is built correctly, cleanly and efficiently. There's not a lot of jobs where it's possible to assess someone in such detail like this.
A portfolio of work is therefore hugely important if you're a front end web developer. Building one, however, can be problematic.
Big sites are often collaborative
The first problem is that for a lot of developers the number of sites that they are entirely responsible for is quite small. Even if you are the only FED on a professional site build, eventually changes will be made to the site by someone else, meaning that the line between what is and isn't your own work gets blurred - which can either be good or bad for you depending on the relative quality of the later work.
If the site is not entirely your own work, your portfolio should state plainly what parts of it were yours. You should also make sure to keep your portfolio up to date. If the site you built gets overhauled by someone else, you may not want to claim credit for it anymore.
Sites aren't always publically available
Sometimes you can spend months working on a really nice site that would look great on a portfolio, only for it to end up being locked away behind a company-employees-only login. In that situation it's a bit of a tough call on whether it should go on a portfolio or not. If you can, provide screenshots and detail of what the site does, or links to prototypes or mock-ups of eventual pages. If you've written something that could be demonstrated separately, such as a plugin or a particular chunk of HTML, that could be something else to show off.
Whatever you decide to demonstrate, make sure that doing so is allowed, particularly if you've signed an NDA.
Most of the everyday work isn't glamourous
Sometimes a new site build arrives that I can really get my teeth into and make my own, try out new techniques and technologies and do a thoroughly good job of. But I also live in the real world, where a lot of a developer's daily work involves fixing small problems on an existing site, or building an email to advertise a product or offer that I'm not particularly interested in.
If all of your work falls into the latter category, don't panic. There's plenty to be said for a developer who can reliably churn out fixes to other people's problems or switch seamlessly from one discipline to another. Take another look at the work you've done this week. There might be something that you consider run of the mill and straightforward that would really impress a potential employer.
Maybe not everything is suitable
I worked on a huge front end build recently that was a great choice to go on my portfolio apart from one small problem - I didn't like it. Other people do, so this is entirely my opinion, but I think it just doesn't look good. The front end is clean, flexible and does some really impressive stuff, I just don't like the design, and I struggled for a long time over whether to add it to my portfolio.
The thing to remember in this situation is that how well you built the design is more important than what you think about it. As long as you provide adequate explanation in your portfolio, you get to talk about what's impressive about the site.
I didn't write it like that, honest
Here's something you might have experienced. You labour day and night to produce stunning, perfect HTML, but somehow it arrives completely mangled in your web browser. The site still looks okay, but look at the underlying code and you'll wince and wonder what happened. Sometimes this is the fault of backend developers who weren't given clear enough instructions on how to integrate your front end into their system (or are too busy to care) or sometimes it's the fault of the system itself, in the way it outputs HTML.
If this has never happened to you, you're either very lucky or haven't been working in the industry long enough. However this happens there are usually ways around it, but it's always worth checking before you try to show it off to someone who'll look beneath the surface.
Final thoughts
A portfolio is hugely important for a web developer. Some employers won't look twice at your CV if you don't have one. It's therefore important to make sure that your portfolio is accurate, detailed, up to date, and provides enough explanation to only give you credit for what you deserve. On top of all that, you should probably make it interesting, easily navigable and fun to explore.
If you're looking at someone else's portfolio, it's also worth bearing in mind some of the above points.