Even if a great C.V. is a good advantage, during an interview, it can be useful to try to explain you're good at work to get the job.
However, how can you do it without seeming pretentious?
I'm currently sitting on the other side of the table, building up a team.
Maybe it's not the norm but for me, if you 'talk the talk' as they say, I can get a feeling for whether candidates are good on the job and ultimately I'll form my picture working with a candidate on a trial day, or pair programming session.
So, if you genuinely are good at a job, display it not by preening yourself on something but by having an honest conversation, being interested in what problems you would be facing and - if you can - Current producer supplier, on how you would approach those difficulties, regardless of whether you would be hired.
Would work with me, at least.
Speak Softly, and Carry a Big C.V.
If you have done nothing of value, you aren't going to have much success promoting yourself to employers. The best way to explain you are good at work is not through explaining to the interviewer how you are good at work, but by having great work experience, demonstrable accomplishments, and good references from previous employers.
You Can Lead an Interviewer to Water...
Everyone is going to have areas they are stronger in, and areas they are weaker in. If I'm Steve Jobs, I probably don't want to be focusing an interview on how I handle interpersonal relations and conflicts with my coworkers. Instead it would be much better to try to focus questions on inspiring passion and having vision for future direction or some such. So if the interviewer asks, "Could you explain how you address conflict with members of your team?" you want to lead the interviewer off that track and steer them toward asking about your strength. For instance:
The point is that you are taking a question that could paint you in a bad light, and shifting the discussion to something you are better at, which is how to lead people to have a common goal. By leading the interviewer to ask about your strengths, you don't need to promote yourself, you can just answer honestly based on your accomplishments, and get the interviewer to think more highly while making the interviewer seem like they are the one leading.
Don't Toot Your Own Horn
Conversation should be natural and flow based on the questions being asked. When you try to stick in accomplishments or anything that comes across as overt self-promotion, it makes it seem like your skills/accomplishments aren't relevant to the discussion. If the discussion isn't allowing you to talk about things you are proud about or have experience with, you need to shift the discussion (see above section).
Even when you are discussing your accomplishments, I recommend avoiding sounding like you did everything yourself (unless of course you did). Any time you've worked with a team, using language that includes them ("We" instead of "I", etc.) will make you sound better to many employers because you are giving credit to people who have nothing to gain from you including them in the discussion. I'm not a fan of people who pass off the team's work as their personal accomplishments, and seen it backfire when the team members they put as references didn't react as expected when asked about them.
Putting it All Together
Interviews go best when the discussion feels natural. If you seem confident, relaxed, and have substance to your answers, you will come across well. If you are reaching, or if you are forcibly trying to throw out things you are good at that don't quite fit, you will likely seem pretentious or less qualified than you are.
The only way to get good at interviewing is to practice. When you have a chance to go to an interview, try to take it (even if you don't think you'll take the job). By getting practice when there's nothing on the line, you'll end up being much better at it when it really counts.
The best solution I've seen so far is to explain what you've done in the past. Show that you've got a proven track record of success and overcoming adverse situations.
Usually this is done by explaining problems you've faced in previous positions and how you worked through them. You're not trying to show that you did everything yourself; you're trying to show how you utilized the resources you had on hand (including other coworkers) to come to the solution.
In all honesty, I'd say there is no one in the world is guaranteed to be good on every team. So the fact that you've been good at work, is not a 100% assurance that you'll be good at this job, in this company or on this team.
The best you can do is:
Don't push to mention any of these things - see where the interview takes you. But if you walk in the door primed with memories of successful accomplishments, good team experiences, and work you've been passionate about - then it's quite likely that the first time they say "can you give me an example of...?" it'll be one of these things that leaps to mind.
I generally don't want to hear from a candidate just how great they think they are, or just how wonderful they've been on the job. I'd like to think that most people will have enough self-confidence to think they are good at their jobs... I want to know that the person has done some hard work, had the drive to tackle stuff even when the path to success wasn't clear, and then learned from their mistakes. That means I need to hear both the challenge and the final success to feel like I've got a good one.
Saying you're good at C# - Ho Hum.
"One of the things I noticed with the old mainframe style screens was that they had a 'search mode' and an 'edit mode'. Now that we have much larger screens I set this up so that the 'search' is on the left and one can select a record for edit, the edit panel is on the right. The search user control allows search parameters and presents a list, the edit user control is populated with the currently selected item on the list."
The above quote is what I would tell someone if I was migrating old 80x25 character screens to a GUI interface. This is easy to write in most current languages. Defining a consistent design pattern is something an employer would expect from developers with a few years of experience.