This is how I put it

"For 9 months I led development on a project that did x, y, an z. I delegated work to 5 other engineers and spent about 30% of my time coding/architecting. The released product took in $15M in revenue the following year."

"For the last 2 years I've been on a team of 5 software engineers who work on one of my company's top portfolio products, which nets a revenue of $200M per year. I was the architect of one particular feature which boosted sales $25M the following year, and coded half of it while leading 2 other engineers to finish it to completion."

It helps not to think of $$ as being a direct tie-in to what value the engineer provides, because again, we aren't _that_ close. It does help to understand that there is some tie-in - ie. as an engineer, that you get that you are essentially building stuff to make money and you are cognizant of the consequences of your work. On another level it demonstrates that you have status to be in positions of that much importance. But you don't want it to come off like bragging, it simply is some metric that could easily be read off from a project post-mortem.

Good managers know that it takes more than the sales guy to close the deal to make that $5MM deal work. The sales people know this, too. Aftermarket support and/or production issues mid-stream are the bane of our existence. When it goes well everyone deserves the credit.

Now that I have that experience if I saw a non sales person place something like the above on their resume I would be very intrigued. Not because they're claiming responsibility (which I don't read into that) but because it says to me that they see their place in the whole system and how they contribute. That is really rare and really valuable. Like you say it's harder to see it when you're not in front of the customer, but if you do see it I think it means you're probably an "A" player.

For example, I used to sell heavy equipment to the concrete industry. In the back shop there was a manager of a unit that did about 25% of the work that needed to be done to build any machine that I would sell. He didn't have any direct contact with the customers. He didn't sit in on any sales meetings, and didn't have a very good idea of the forecast that was coming (unfortunately). He was absolutely critical to making each sale happen and each customer happy and he seemed to understand this. Without him it would have been very difficult to land the deals that we did. He absolutely deserves to place that he was critical to building an $8_figs business area on his resume. And by doing so I think it shows that he has vision beyond his area. I'd work with him again in a second.

He was "far" from the money but it didn't seem that way to me. He could just write on his resume that he was a Tool and Die Maker that managed a small machine shop of about 6 people. And it's true, but it doesn't do him justice.

The other problem is what happens if you ended up on a project that didn't make any money or one that lost money.

You might spent 3 years working on something and produced the most excellent work of your life but for whatever reason the end product sucked. It might not have been your fault , the marketing might have been terrible , it could have been mismanaged or it might just have been an awful idea from the start.

It probably sucks for the guy who programmed microsoft clippy..

This is why everybody should study science for a while. ;) The tack to take is "we did this experiment, and we built the best thing we could, a thing that accomplished feats X and Y and Z, but the experiment didn't yield the results we hoped for."

Considering that figures floating around say that as many as 90% of software projects fail, there's probably many of us in that group. (I consider myself one of them.)

There's got to be a way to put a positive spin on a project that was late, over-budget, rejected by the customer, poorly specified, technically misdirected, utterly mismanaged, and ultimately written off as a huge waste of time, money, and energy. But just saying "I learned a lot about how not to do things" doesn't really impress anyone.

Just addressing the technical misdirection:

"We made a number of technical errors. We decided to try using a brand new datastore called NoDB. Unfortunately, it turned out that our learning curve on NoDB v1.234 was steeper than we expected. It's an amazing product, but it's new and not yet well documented so it took us a long time to learn its quirks. I became an expert on NoDB because of all the tuning I had to do to try to improve performance and it's a fantastic product. I think that YesDB would have been much faster to learn but by the time we realized that, the project was cancelled.

However, with what I learned from that experience and what you've told me about your project, I think that NoDB would be a perfect fit. It has yaddayaddayadda features. What do you think?"

Yep. It's seen as bad form to criticize former or current co-workers at a job interview but sometimes the only honest answer is "all my co-workers were either lazy or incompetent but I'm better than them hence why I'm looking for another job".

It also sucks when you do client work in web development and build a good website for somebody who then proceeds to use the CMS to create pages full of spelling errors and nasty images their nephew created in pirate photoshop so you cannot use it as a portfolio piece.

OK, this may be harsh, but it's true.

You come into an interview with me and say that, and you've just talked yourself out of a job. I don't care how impressive your resume is; don't care if otherwise you walk on water. If you can't even avoid expressly criticizing your teammates in a job interview, it sends signals that you don't know when to keep your mouth shut; that you have no idea what it means to be tactful. That in turn suggests to me that you're going to be a pain in the ass to work with and are more focused on "who's right" in a discussion than coming to a consensus.

I really, really, really hate the phrase "not a team player" but right or wrong, that's exactly what that statement would advertise.

I'll back that one up. That exact attitude is something I'm personally working on right now, mostly as a result of discovering how much it affects people's perception of my work and abilities.

Talking crap about your previous co-workers is a great way to waste interview time and convince someone you will be difficult to work with. You're in a job interview. This is best-foot-forward, "paint me a picture of how awesome you could be" time. Don't bitch about your last job, we aren't here to talk about that.

If the honest answer truly was "everyone else was incompetent", just talk about your role in the project. If everyone was really that terrible and you were really that good, you should have some awesome stories about how you helped keep things on track. Maybe the whole damn thing was a sinking ship, but you have to have done something to help keep it afloat. Tell those stories.

Anyone with half a brain will catch on that you're talking around a bad work environment. They'll appreciate your tact and file away a note that letting you talk to customers/sales/management/whoever may not be as horrible as it would with most engineers. That's a very good mark in your favor.

Oh, don't get my wrong I'd be way way more tactful than that in an actual interview.

It just sucks when you feel like you might have to defend a lot of bad decisions that were made by others and all your good ideas were overruled, I don't want to sound like "Mr Hindsight".

I believe the proper euphemism for this situation is “I am looking for new challenges”.

If a client taints the beautiful layout, maybe prototype screenshots can be used for your portfolio?

Curiosity: Have you actually been in the position of interviewing people who said things like that and being unimpressed, or do you just feel like they're not impressive things to say about yourself?

The latter.

> So the $5M in sales? It wouldn't have happened without them! (that's the perception)

Maybe there was a either a strict deadline or a challenging technical issue to overcome such that that sale couldn't have happened without your contribution.

Maybe that software was sold for $5M because it was way more stable, responsive and easy to deploy and use than its competition.

Maybe, thanks to good engineering and best practices, bugs and requests for improvement were quickly answered.

Maybe, again thanks to good engineering, that software was easily tailored to each customer's need, and customers were willing to pay (way) more.

Maybe... Start to look at your job and at your product with sales goggles and find other selling points.