Mixing
Should I mention an interesting but failed task in my resume as an achievement?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
19
down vote
favorite
I recently implemented a very interesting feature - centralized logging system with the help of Logstash, Elasticsearch and Kibana.
But after a few days I had to revert it, remove from the project, because it turned out, we had no powerful enough servers for this feature, and no one was going to provide us additional servers.
So, the questions is: should I include this feature on my resume (it was very interesting and challenging), even if it's not working now, but not because of my fault? The project took about 3 days.
resume failure
edited Dec 18 '14 at 14:24
Stephan Kolassa
8,35532850
asked Dec 18 '14 at 10:06
Alexander Guz
20427
 |Â
show 1 more comment
up vote
19
down vote
favorite
I recently implemented a very interesting feature - centralized logging system with the help of Logstash, Elasticsearch and Kibana.
But after a few days I had to revert it, remove from the project, because it turned out, we had no powerful enough servers for this feature, and no one was going to provide us additional servers.
So, the questions is: should I include this feature on my resume (it was very interesting and challenging), even if it's not working now, but not because of my fault? The project took about 3 days.
resume failure
edited Dec 18 '14 at 14:24
Stephan Kolassa
8,35532850
asked Dec 18 '14 at 10:06
Alexander Guz
20427
4
related: Is it worth to tell a “Samaritan†(company mentor) about my story of particular failure? "If you plan for a career in software development, you'd better drop that attitude and instead, learn how to present your past project failures in a mature way and how to show what you have learned from these. Thing is..."
– gnat
Dec 18 '14 at 11:02
2
This sounds like an interesting example for a "please tell me about a particular failure in your work" type of question.
– Michael Kjörling
Dec 18 '14 at 14:59
I had a pilot project to evaluate a piece of software and the conclusion was to not use the software. They read that as pilot failed and I would have to explain the software company later went out of business - it was the correct conclusion.
– paparazzo
Dec 18 '14 at 15:22
I mentioned several failed projects I undertook during my sabbatical, but I doubt they'd have wanted to know if I had 'wasted' my employers time.
– SBoss
Dec 18 '14 at 16:11
Do you really mention every project that took 3 days on your resume? Or any such? How much "experience" do you think that you can claim after 3 days? At best you have a warm fuzzy feeling - not much more understanding than can be gleaned by reading a Wikipedia overview. If you mention it & don't mention 3 days, then when I learn that it was only 3 days I will think that you cheated/exaggerated/misled me. If you do mention that it was only 3 days then I will feel that you are trying to pad your resume and have nothing better to offer. Keep it to real achievements.
– Mawg
Dec 19 '14 at 9:13
 |Â
show 1 more comment
up vote
19
down vote
favorite
up vote
19
down vote
favorite
I recently implemented a very interesting feature - centralized logging system with the help of Logstash, Elasticsearch and Kibana.
But after a few days I had to revert it, remove from the project, because it turned out, we had no powerful enough servers for this feature, and no one was going to provide us additional servers.
So, the questions is: should I include this feature on my resume (it was very interesting and challenging), even if it's not working now, but not because of my fault? The project took about 3 days.
resume failure
edited Dec 18 '14 at 14:24
Stephan Kolassa
8,35532850
asked Dec 18 '14 at 10:06
Alexander Guz
20427
I recently implemented a very interesting feature - centralized logging system with the help of Logstash, Elasticsearch and Kibana.
But after a few days I had to revert it, remove from the project, because it turned out, we had no powerful enough servers for this feature, and no one was going to provide us additional servers.
So, the questions is: should I include this feature on my resume (it was very interesting and challenging), even if it's not working now, but not because of my fault? The project took about 3 days.
resume failure
edited Dec 18 '14 at 14:24
Stephan Kolassa
8,35532850
asked Dec 18 '14 at 10:06
Alexander Guz
20427
edited Dec 18 '14 at 14:24
Stephan Kolassa
8,35532850
edited Dec 18 '14 at 14:24
Stephan Kolassa
8,35532850
edited Dec 18 '14 at 14:24
Stephan Kolassa
8,35532850
8,35532850
asked Dec 18 '14 at 10:06
Alexander Guz
20427
asked Dec 18 '14 at 10:06
Alexander Guz
20427
asked Dec 18 '14 at 10:06
Alexander Guz
20427
20427
4
related: Is it worth to tell a “Samaritan†(company mentor) about my story of particular failure? "If you plan for a career in software development, you'd better drop that attitude and instead, learn how to present your past project failures in a mature way and how to show what you have learned from these. Thing is..."
– gnat
Dec 18 '14 at 11:02
2
This sounds like an interesting example for a "please tell me about a particular failure in your work" type of question.
– Michael Kjörling
Dec 18 '14 at 14:59
I had a pilot project to evaluate a piece of software and the conclusion was to not use the software. They read that as pilot failed and I would have to explain the software company later went out of business - it was the correct conclusion.
– paparazzo
Dec 18 '14 at 15:22
I mentioned several failed projects I undertook during my sabbatical, but I doubt they'd have wanted to know if I had 'wasted' my employers time.
– SBoss
Dec 18 '14 at 16:11
Do you really mention every project that took 3 days on your resume? Or any such? How much "experience" do you think that you can claim after 3 days? At best you have a warm fuzzy feeling - not much more understanding than can be gleaned by reading a Wikipedia overview. If you mention it & don't mention 3 days, then when I learn that it was only 3 days I will think that you cheated/exaggerated/misled me. If you do mention that it was only 3 days then I will feel that you are trying to pad your resume and have nothing better to offer. Keep it to real achievements.
– Mawg
Dec 19 '14 at 9:13
 |Â
show 1 more comment
4
related: Is it worth to tell a “Samaritan†(company mentor) about my story of particular failure? "If you plan for a career in software development, you'd better drop that attitude and instead, learn how to present your past project failures in a mature way and how to show what you have learned from these. Thing is..."
– gnat
Dec 18 '14 at 11:02
2
This sounds like an interesting example for a "please tell me about a particular failure in your work" type of question.
– Michael Kjörling
Dec 18 '14 at 14:59
I had a pilot project to evaluate a piece of software and the conclusion was to not use the software. They read that as pilot failed and I would have to explain the software company later went out of business - it was the correct conclusion.
– paparazzo
Dec 18 '14 at 15:22
I mentioned several failed projects I undertook during my sabbatical, but I doubt they'd have wanted to know if I had 'wasted' my employers time.
– SBoss
Dec 18 '14 at 16:11
Do you really mention every project that took 3 days on your resume? Or any such? How much "experience" do you think that you can claim after 3 days? At best you have a warm fuzzy feeling - not much more understanding than can be gleaned by reading a Wikipedia overview. If you mention it & don't mention 3 days, then when I learn that it was only 3 days I will think that you cheated/exaggerated/misled me. If you do mention that it was only 3 days then I will feel that you are trying to pad your resume and have nothing better to offer. Keep it to real achievements.
– Mawg
Dec 19 '14 at 9:13
4
4
related: Is it worth to tell a “Samaritan†(company mentor) about my story of particular failure? "If you plan for a career in software development, you'd better drop that attitude and instead, learn how to present your past project failures in a mature way and how to show what you have learned from these. Thing is..."
– gnat
Dec 18 '14 at 11:02
related: Is it worth to tell a “Samaritan†(company mentor) about my story of particular failure? "If you plan for a career in software development, you'd better drop that attitude and instead, learn how to present your past project failures in a mature way and how to show what you have learned from these. Thing is..."
– gnat
Dec 18 '14 at 11:02
2
2
This sounds like an interesting example for a "please tell me about a particular failure in your work" type of question.
– Michael Kjörling
Dec 18 '14 at 14:59
This sounds like an interesting example for a "please tell me about a particular failure in your work" type of question.
– Michael Kjörling
Dec 18 '14 at 14:59
I had a pilot project to evaluate a piece of software and the conclusion was to not use the software. They read that as pilot failed and I would have to explain the software company later went out of business - it was the correct conclusion.
– paparazzo
Dec 18 '14 at 15:22
I had a pilot project to evaluate a piece of software and the conclusion was to not use the software. They read that as pilot failed and I would have to explain the software company later went out of business - it was the correct conclusion.
– paparazzo
Dec 18 '14 at 15:22
I mentioned several failed projects I undertook during my sabbatical, but I doubt they'd have wanted to know if I had 'wasted' my employers time.
– SBoss
Dec 18 '14 at 16:11
I mentioned several failed projects I undertook during my sabbatical, but I doubt they'd have wanted to know if I had 'wasted' my employers time.
– SBoss
Dec 18 '14 at 16:11
Do you really mention every project that took 3 days on your resume? Or any such? How much "experience" do you think that you can claim after 3 days? At best you have a warm fuzzy feeling - not much more understanding than can be gleaned by reading a Wikipedia overview. If you mention it & don't mention 3 days, then when I learn that it was only 3 days I will think that you cheated/exaggerated/misled me. If you do mention that it was only 3 days then I will feel that you are trying to pad your resume and have nothing better to offer. Keep it to real achievements.
– Mawg
Dec 19 '14 at 9:13
Do you really mention every project that took 3 days on your resume? Or any such? How much "experience" do you think that you can claim after 3 days? At best you have a warm fuzzy feeling - not much more understanding than can be gleaned by reading a Wikipedia overview. If you mention it & don't mention 3 days, then when I learn that it was only 3 days I will think that you cheated/exaggerated/misled me. If you do mention that it was only 3 days then I will feel that you are trying to pad your resume and have nothing better to offer. Keep it to real achievements.
– Mawg
Dec 19 '14 at 9:13
 |Â
show 1 more comment
5 Answers
5
active
oldest
votes
up vote
44
down vote
accepted
Future employers will rarely care about whether you did an interesting project. They care about results achieved and problems solved.
Don't give the impression of someone who likes to work on interesting projects that fail and don't deliver real results. Instead, explain how you can learn even from failures and improve your methods.
You could cast this as follows:
- We wanted to solve problem X, using centralized logging.
- I implemented a feature using technologies Y and Z.
- It turns out our servers were not up to the task, so we scrapped this approach.
And now it becomes interesting:
- How did you solve the problem in the end? (For instance, you may have decided that centralized logging was not really the best way to approach whatever original problem you had.)
What did you learn from this experience?
- Could you have done the hardware sizing earlier? Can you point to a later project where you did do the sizing earlier?
- It seems like you pulled the rip cord pretty early, so little time was lost. Was there a process involved? How did you decide on stopping this approach? Did you change anything about milestone definition for future projects?
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
10
+1 Taking into account the needed infrastructure is part of a software project. Be careful that a potential employer does not get the impression that you only developed this because you found it interesting, but the needed infrastructure requirements did not matter to you.
– prockel
Dec 18 '14 at 13:20
2
Depending on the organization, it may not have been practical to size the hardware requirements up front. I've been in organizations where infrastructure was outsourced and the admins were walled off -- so scaling up hardware was only ever done after the fact / in "reactive" mode. I'm not saying that's a good approach ... but for some of us it's unfortunately the reality. (As per your answer, this can make a good "lesson learned" type of talking point.)
– David
Dec 18 '14 at 14:14
suggest improvements |Â
up vote
13
down vote
I would, but be careful how you phrase it and how you answer questions about it. You could say something like "I designed this, though they haven't quite got the infrastructure in place to go live with it." Ultimately, your task was set out and was successful - as you say, it's not your fault if external influences prevented it from being useful in the end.
I have a similar story in that I spent months (at the request of my manager) designing a system that was eventually scrapped by the higher ups because of political reasons. I still mentioned it on my CV, though because nobody can take away the fact I engineered it and it worked.
answered Dec 18 '14 at 10:21
Dan
8,74133636
suggest improvements |Â
up vote
11
down vote
The project took about 3 days.
This seems to me to provide a (semi-roundabout) answer to your question. Let's say you work for a particular employer for five years. That's about 1,800 days, minus weekends and some vacation time. Let's pretend that the employer gives you European-style vacations and call that a nice, round 1,200 days actually worked. The exact number is going to be different between countries and possibly between employment forms, but globally, that seems a reasonable guesstimate.
The project you mention would then have taken all of 0.25% of your time working for this employer.
Sure, it may have been interesting or challenging, but remember that your résumé is a sales pitch. Lots of engineer types in particular tend to forget about that. The purpose of your résumé is to make the employer interested enough in you for you to get your foot in the door for an interview. The purpose is not to list everything you ever worked on.
So, you want to paint with broad strokes, but at the same time be specific. Technologies. Numbers. How what you did helped your employer's bottom line. Describing something that you spent a fraction of a percent of the time you worked for the employer doing, then, seems counterproductive. If my math is right and this is the median length of a project of yours, your résumé will list a few hundred projects of that size or larger. No prospective employer is likely to read through such a list. They would put your résumé in the "to be read later" pile (also known as the Round Archive).
Hence, unless the project actually adds something specific to your experience which you believe a future employer might be interested in, I would suggest that you leave out the specific mention of it. It was a minor project in the grand scheme of things and it didn't turn out to provide any significant benefit to your employer; in fact, since it didn't work out and was reverted, it was essentially wasted money for them. (Not to say they didn't learn from the experience, but it didn't improve their business case toward their customers.) If you learned additional technologies or something like that through it, you may want to mention those as "also worked with" or something similar. It might make a good conversation piece during an interview if the interviewer asks "what did you do that used Kibana?", but I wouldn't consider the failed, relatively small assignment to be something that actively sells you to an employer.
However, as I also mentioned in a comment to the question, this type of experience sounds like a good answer to the classic "please tell me about a particular failure in your work" type of question: you were asked to do something, did it, it worked, but in the end it didn't work out for reasons unrelated to your work performance. There is a lot of learning potential from an experience like that; show the prospective employer that you learned from it. But my suggestion would definitely be to not make the specific mention until you've got your foot in the prospective employer's door by being there for an interview.
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
"European-style vacations" is pretty vague, with a minimum of 20 day in the Netherlands and Germany, up to 30 in France or Finland. Considerung public holidays, the range is even more interesting, with 41 in Lithuania, 40 in Russia, down to 28 in the Netherlands. With those public holidays, the US have it almost like the Netherlands, with 25 days in total. -- source: edition.cnn.com/2011/WORLD/asiapcf/07/29/…
– phresnel
Dec 18 '14 at 16:26
Also, weekends alone would bring the number of days down to 1280, with holidays still to be deducted. I concur with the rest of your answer though :)
– user29632
Dec 18 '14 at 17:21
Good points both. The point wasn't a mathematically exact calculation, though, but rather to show how small a fraction of the total worked time the OP's project amounted to. For all I know, OP has worked ten years for this employer. Or half a year.
– Michael Kjörling
Dec 18 '14 at 19:55
suggest improvements |Â
up vote
2
down vote
I would say 'yes', if you successfully built it. Even if the people reading your resume have access to the project and see that the logging system is not there, you can explain why is was withdrawn (if they ask).
The whole point of putting things on your resume is that future employers can see what (knowledge, experience) you bring to them, and this certainly is one.
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
suggest improvements |Â
up vote
2
down vote
You can mention the project, and the accomplishments you made during it, as part of your work experience and capabilities.
Don't feel obliged to mention that the project was scrapped unless they specifically ask, or if you know for certain that it will be brought up by someone else (if you used your previous employer as a contact, for example).
If they ask, or if you know they'll be calling your previous employer and might ask about the project, tactfully mention that you were successful in implementing your project, but that forces outside your control (you have no control over how much server space you get allocated) meant you had to revert the process.
You should also turn this into a positive in itself - being able to do a project and revert it when needed is a skill, not a flaw. And the fact that it had to be reverted because of factors outside your control means you can focus entirely on the tasks you accomplished, while tactfully mentioning that there were other circumstances that resulted in you having to revert it in the first place (don't throw anyone else under the bus - you may need them for a reference after all).
In short, not only is it perfectly fine to mention it, but the fact that you accomplished it AND knew how to revert it when tasked to is two accomplishments, not one accomplishment and a failure.
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
44
down vote
accepted
Future employers will rarely care about whether you did an interesting project. They care about results achieved and problems solved.
Don't give the impression of someone who likes to work on interesting projects that fail and don't deliver real results. Instead, explain how you can learn even from failures and improve your methods.
You could cast this as follows:
- We wanted to solve problem X, using centralized logging.
- I implemented a feature using technologies Y and Z.
- It turns out our servers were not up to the task, so we scrapped this approach.
And now it becomes interesting:
- How did you solve the problem in the end? (For instance, you may have decided that centralized logging was not really the best way to approach whatever original problem you had.)
What did you learn from this experience?
- Could you have done the hardware sizing earlier? Can you point to a later project where you did do the sizing earlier?
- It seems like you pulled the rip cord pretty early, so little time was lost. Was there a process involved? How did you decide on stopping this approach? Did you change anything about milestone definition for future projects?
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
10
+1 Taking into account the needed infrastructure is part of a software project. Be careful that a potential employer does not get the impression that you only developed this because you found it interesting, but the needed infrastructure requirements did not matter to you.
– prockel
Dec 18 '14 at 13:20
2
Depending on the organization, it may not have been practical to size the hardware requirements up front. I've been in organizations where infrastructure was outsourced and the admins were walled off -- so scaling up hardware was only ever done after the fact / in "reactive" mode. I'm not saying that's a good approach ... but for some of us it's unfortunately the reality. (As per your answer, this can make a good "lesson learned" type of talking point.)
– David
Dec 18 '14 at 14:14
suggest improvements |Â
up vote
44
down vote
accepted
Future employers will rarely care about whether you did an interesting project. They care about results achieved and problems solved.
Don't give the impression of someone who likes to work on interesting projects that fail and don't deliver real results. Instead, explain how you can learn even from failures and improve your methods.
You could cast this as follows:
- We wanted to solve problem X, using centralized logging.
- I implemented a feature using technologies Y and Z.
- It turns out our servers were not up to the task, so we scrapped this approach.
And now it becomes interesting:
- How did you solve the problem in the end? (For instance, you may have decided that centralized logging was not really the best way to approach whatever original problem you had.)
What did you learn from this experience?
- Could you have done the hardware sizing earlier? Can you point to a later project where you did do the sizing earlier?
- It seems like you pulled the rip cord pretty early, so little time was lost. Was there a process involved? How did you decide on stopping this approach? Did you change anything about milestone definition for future projects?
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
10
+1 Taking into account the needed infrastructure is part of a software project. Be careful that a potential employer does not get the impression that you only developed this because you found it interesting, but the needed infrastructure requirements did not matter to you.
– prockel
Dec 18 '14 at 13:20
2
Depending on the organization, it may not have been practical to size the hardware requirements up front. I've been in organizations where infrastructure was outsourced and the admins were walled off -- so scaling up hardware was only ever done after the fact / in "reactive" mode. I'm not saying that's a good approach ... but for some of us it's unfortunately the reality. (As per your answer, this can make a good "lesson learned" type of talking point.)
– David
Dec 18 '14 at 14:14
suggest improvements |Â
up vote
44
down vote
accepted
up vote
44
down vote
accepted
Future employers will rarely care about whether you did an interesting project. They care about results achieved and problems solved.
Don't give the impression of someone who likes to work on interesting projects that fail and don't deliver real results. Instead, explain how you can learn even from failures and improve your methods.
You could cast this as follows:
- We wanted to solve problem X, using centralized logging.
- I implemented a feature using technologies Y and Z.
- It turns out our servers were not up to the task, so we scrapped this approach.
And now it becomes interesting:
- How did you solve the problem in the end? (For instance, you may have decided that centralized logging was not really the best way to approach whatever original problem you had.)
What did you learn from this experience?
- Could you have done the hardware sizing earlier? Can you point to a later project where you did do the sizing earlier?
- It seems like you pulled the rip cord pretty early, so little time was lost. Was there a process involved? How did you decide on stopping this approach? Did you change anything about milestone definition for future projects?
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
Future employers will rarely care about whether you did an interesting project. They care about results achieved and problems solved.
Don't give the impression of someone who likes to work on interesting projects that fail and don't deliver real results. Instead, explain how you can learn even from failures and improve your methods.
You could cast this as follows:
- We wanted to solve problem X, using centralized logging.
- I implemented a feature using technologies Y and Z.
- It turns out our servers were not up to the task, so we scrapped this approach.
And now it becomes interesting:
- How did you solve the problem in the end? (For instance, you may have decided that centralized logging was not really the best way to approach whatever original problem you had.)
What did you learn from this experience?
- Could you have done the hardware sizing earlier? Can you point to a later project where you did do the sizing earlier?
- It seems like you pulled the rip cord pretty early, so little time was lost. Was there a process involved? How did you decide on stopping this approach? Did you change anything about milestone definition for future projects?
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
answered Dec 18 '14 at 11:08
Stephan Kolassa
8,35532850
8,35532850
10
+1 Taking into account the needed infrastructure is part of a software project. Be careful that a potential employer does not get the impression that you only developed this because you found it interesting, but the needed infrastructure requirements did not matter to you.
– prockel
Dec 18 '14 at 13:20
2
Depending on the organization, it may not have been practical to size the hardware requirements up front. I've been in organizations where infrastructure was outsourced and the admins were walled off -- so scaling up hardware was only ever done after the fact / in "reactive" mode. I'm not saying that's a good approach ... but for some of us it's unfortunately the reality. (As per your answer, this can make a good "lesson learned" type of talking point.)
– David
Dec 18 '14 at 14:14
suggest improvements |Â
10
+1 Taking into account the needed infrastructure is part of a software project. Be careful that a potential employer does not get the impression that you only developed this because you found it interesting, but the needed infrastructure requirements did not matter to you.
– prockel
Dec 18 '14 at 13:20
2
Depending on the organization, it may not have been practical to size the hardware requirements up front. I've been in organizations where infrastructure was outsourced and the admins were walled off -- so scaling up hardware was only ever done after the fact / in "reactive" mode. I'm not saying that's a good approach ... but for some of us it's unfortunately the reality. (As per your answer, this can make a good "lesson learned" type of talking point.)
– David
Dec 18 '14 at 14:14
10
10
+1 Taking into account the needed infrastructure is part of a software project. Be careful that a potential employer does not get the impression that you only developed this because you found it interesting, but the needed infrastructure requirements did not matter to you.
– prockel
Dec 18 '14 at 13:20
+1 Taking into account the needed infrastructure is part of a software project. Be careful that a potential employer does not get the impression that you only developed this because you found it interesting, but the needed infrastructure requirements did not matter to you.
– prockel
Dec 18 '14 at 13:20
2
2
Depending on the organization, it may not have been practical to size the hardware requirements up front. I've been in organizations where infrastructure was outsourced and the admins were walled off -- so scaling up hardware was only ever done after the fact / in "reactive" mode. I'm not saying that's a good approach ... but for some of us it's unfortunately the reality. (As per your answer, this can make a good "lesson learned" type of talking point.)
– David
Dec 18 '14 at 14:14
Depending on the organization, it may not have been practical to size the hardware requirements up front. I've been in organizations where infrastructure was outsourced and the admins were walled off -- so scaling up hardware was only ever done after the fact / in "reactive" mode. I'm not saying that's a good approach ... but for some of us it's unfortunately the reality. (As per your answer, this can make a good "lesson learned" type of talking point.)
– David
Dec 18 '14 at 14:14
suggest improvements |Â
up vote
13
down vote
I would, but be careful how you phrase it and how you answer questions about it. You could say something like "I designed this, though they haven't quite got the infrastructure in place to go live with it." Ultimately, your task was set out and was successful - as you say, it's not your fault if external influences prevented it from being useful in the end.
I have a similar story in that I spent months (at the request of my manager) designing a system that was eventually scrapped by the higher ups because of political reasons. I still mentioned it on my CV, though because nobody can take away the fact I engineered it and it worked.
answered Dec 18 '14 at 10:21
Dan
8,74133636
suggest improvements |Â
up vote
13
down vote
I would, but be careful how you phrase it and how you answer questions about it. You could say something like "I designed this, though they haven't quite got the infrastructure in place to go live with it." Ultimately, your task was set out and was successful - as you say, it's not your fault if external influences prevented it from being useful in the end.
I have a similar story in that I spent months (at the request of my manager) designing a system that was eventually scrapped by the higher ups because of political reasons. I still mentioned it on my CV, though because nobody can take away the fact I engineered it and it worked.
answered Dec 18 '14 at 10:21
Dan
8,74133636
suggest improvements |Â
up vote
13
down vote
up vote
13
down vote
I would, but be careful how you phrase it and how you answer questions about it. You could say something like "I designed this, though they haven't quite got the infrastructure in place to go live with it." Ultimately, your task was set out and was successful - as you say, it's not your fault if external influences prevented it from being useful in the end.
I have a similar story in that I spent months (at the request of my manager) designing a system that was eventually scrapped by the higher ups because of political reasons. I still mentioned it on my CV, though because nobody can take away the fact I engineered it and it worked.
answered Dec 18 '14 at 10:21
Dan
8,74133636
I would, but be careful how you phrase it and how you answer questions about it. You could say something like "I designed this, though they haven't quite got the infrastructure in place to go live with it." Ultimately, your task was set out and was successful - as you say, it's not your fault if external influences prevented it from being useful in the end.
I have a similar story in that I spent months (at the request of my manager) designing a system that was eventually scrapped by the higher ups because of political reasons. I still mentioned it on my CV, though because nobody can take away the fact I engineered it and it worked.
answered Dec 18 '14 at 10:21
Dan
8,74133636
answered Dec 18 '14 at 10:21
Dan
8,74133636
answered Dec 18 '14 at 10:21
Dan
8,74133636
answered Dec 18 '14 at 10:21
Dan
8,74133636
8,74133636
suggest improvements |Â
suggest improvements |Â
up vote
11
down vote
The project took about 3 days.
This seems to me to provide a (semi-roundabout) answer to your question. Let's say you work for a particular employer for five years. That's about 1,800 days, minus weekends and some vacation time. Let's pretend that the employer gives you European-style vacations and call that a nice, round 1,200 days actually worked. The exact number is going to be different between countries and possibly between employment forms, but globally, that seems a reasonable guesstimate.
The project you mention would then have taken all of 0.25% of your time working for this employer.
Sure, it may have been interesting or challenging, but remember that your résumé is a sales pitch. Lots of engineer types in particular tend to forget about that. The purpose of your résumé is to make the employer interested enough in you for you to get your foot in the door for an interview. The purpose is not to list everything you ever worked on.
So, you want to paint with broad strokes, but at the same time be specific. Technologies. Numbers. How what you did helped your employer's bottom line. Describing something that you spent a fraction of a percent of the time you worked for the employer doing, then, seems counterproductive. If my math is right and this is the median length of a project of yours, your résumé will list a few hundred projects of that size or larger. No prospective employer is likely to read through such a list. They would put your résumé in the "to be read later" pile (also known as the Round Archive).
Hence, unless the project actually adds something specific to your experience which you believe a future employer might be interested in, I would suggest that you leave out the specific mention of it. It was a minor project in the grand scheme of things and it didn't turn out to provide any significant benefit to your employer; in fact, since it didn't work out and was reverted, it was essentially wasted money for them. (Not to say they didn't learn from the experience, but it didn't improve their business case toward their customers.) If you learned additional technologies or something like that through it, you may want to mention those as "also worked with" or something similar. It might make a good conversation piece during an interview if the interviewer asks "what did you do that used Kibana?", but I wouldn't consider the failed, relatively small assignment to be something that actively sells you to an employer.
However, as I also mentioned in a comment to the question, this type of experience sounds like a good answer to the classic "please tell me about a particular failure in your work" type of question: you were asked to do something, did it, it worked, but in the end it didn't work out for reasons unrelated to your work performance. There is a lot of learning potential from an experience like that; show the prospective employer that you learned from it. But my suggestion would definitely be to not make the specific mention until you've got your foot in the prospective employer's door by being there for an interview.
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
"European-style vacations" is pretty vague, with a minimum of 20 day in the Netherlands and Germany, up to 30 in France or Finland. Considerung public holidays, the range is even more interesting, with 41 in Lithuania, 40 in Russia, down to 28 in the Netherlands. With those public holidays, the US have it almost like the Netherlands, with 25 days in total. -- source: edition.cnn.com/2011/WORLD/asiapcf/07/29/…
– phresnel
Dec 18 '14 at 16:26
Also, weekends alone would bring the number of days down to 1280, with holidays still to be deducted. I concur with the rest of your answer though :)
– user29632
Dec 18 '14 at 17:21
Good points both. The point wasn't a mathematically exact calculation, though, but rather to show how small a fraction of the total worked time the OP's project amounted to. For all I know, OP has worked ten years for this employer. Or half a year.
– Michael Kjörling
Dec 18 '14 at 19:55
suggest improvements |Â
up vote
11
down vote
The project took about 3 days.
This seems to me to provide a (semi-roundabout) answer to your question. Let's say you work for a particular employer for five years. That's about 1,800 days, minus weekends and some vacation time. Let's pretend that the employer gives you European-style vacations and call that a nice, round 1,200 days actually worked. The exact number is going to be different between countries and possibly between employment forms, but globally, that seems a reasonable guesstimate.
The project you mention would then have taken all of 0.25% of your time working for this employer.
Sure, it may have been interesting or challenging, but remember that your résumé is a sales pitch. Lots of engineer types in particular tend to forget about that. The purpose of your résumé is to make the employer interested enough in you for you to get your foot in the door for an interview. The purpose is not to list everything you ever worked on.
So, you want to paint with broad strokes, but at the same time be specific. Technologies. Numbers. How what you did helped your employer's bottom line. Describing something that you spent a fraction of a percent of the time you worked for the employer doing, then, seems counterproductive. If my math is right and this is the median length of a project of yours, your résumé will list a few hundred projects of that size or larger. No prospective employer is likely to read through such a list. They would put your résumé in the "to be read later" pile (also known as the Round Archive).
Hence, unless the project actually adds something specific to your experience which you believe a future employer might be interested in, I would suggest that you leave out the specific mention of it. It was a minor project in the grand scheme of things and it didn't turn out to provide any significant benefit to your employer; in fact, since it didn't work out and was reverted, it was essentially wasted money for them. (Not to say they didn't learn from the experience, but it didn't improve their business case toward their customers.) If you learned additional technologies or something like that through it, you may want to mention those as "also worked with" or something similar. It might make a good conversation piece during an interview if the interviewer asks "what did you do that used Kibana?", but I wouldn't consider the failed, relatively small assignment to be something that actively sells you to an employer.
However, as I also mentioned in a comment to the question, this type of experience sounds like a good answer to the classic "please tell me about a particular failure in your work" type of question: you were asked to do something, did it, it worked, but in the end it didn't work out for reasons unrelated to your work performance. There is a lot of learning potential from an experience like that; show the prospective employer that you learned from it. But my suggestion would definitely be to not make the specific mention until you've got your foot in the prospective employer's door by being there for an interview.
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
"European-style vacations" is pretty vague, with a minimum of 20 day in the Netherlands and Germany, up to 30 in France or Finland. Considerung public holidays, the range is even more interesting, with 41 in Lithuania, 40 in Russia, down to 28 in the Netherlands. With those public holidays, the US have it almost like the Netherlands, with 25 days in total. -- source: edition.cnn.com/2011/WORLD/asiapcf/07/29/…
– phresnel
Dec 18 '14 at 16:26
Also, weekends alone would bring the number of days down to 1280, with holidays still to be deducted. I concur with the rest of your answer though :)
– user29632
Dec 18 '14 at 17:21
Good points both. The point wasn't a mathematically exact calculation, though, but rather to show how small a fraction of the total worked time the OP's project amounted to. For all I know, OP has worked ten years for this employer. Or half a year.
– Michael Kjörling
Dec 18 '14 at 19:55
suggest improvements |Â
up vote
11
down vote
up vote
11
down vote
The project took about 3 days.
This seems to me to provide a (semi-roundabout) answer to your question. Let's say you work for a particular employer for five years. That's about 1,800 days, minus weekends and some vacation time. Let's pretend that the employer gives you European-style vacations and call that a nice, round 1,200 days actually worked. The exact number is going to be different between countries and possibly between employment forms, but globally, that seems a reasonable guesstimate.
The project you mention would then have taken all of 0.25% of your time working for this employer.
Sure, it may have been interesting or challenging, but remember that your résumé is a sales pitch. Lots of engineer types in particular tend to forget about that. The purpose of your résumé is to make the employer interested enough in you for you to get your foot in the door for an interview. The purpose is not to list everything you ever worked on.
So, you want to paint with broad strokes, but at the same time be specific. Technologies. Numbers. How what you did helped your employer's bottom line. Describing something that you spent a fraction of a percent of the time you worked for the employer doing, then, seems counterproductive. If my math is right and this is the median length of a project of yours, your résumé will list a few hundred projects of that size or larger. No prospective employer is likely to read through such a list. They would put your résumé in the "to be read later" pile (also known as the Round Archive).
Hence, unless the project actually adds something specific to your experience which you believe a future employer might be interested in, I would suggest that you leave out the specific mention of it. It was a minor project in the grand scheme of things and it didn't turn out to provide any significant benefit to your employer; in fact, since it didn't work out and was reverted, it was essentially wasted money for them. (Not to say they didn't learn from the experience, but it didn't improve their business case toward their customers.) If you learned additional technologies or something like that through it, you may want to mention those as "also worked with" or something similar. It might make a good conversation piece during an interview if the interviewer asks "what did you do that used Kibana?", but I wouldn't consider the failed, relatively small assignment to be something that actively sells you to an employer.
However, as I also mentioned in a comment to the question, this type of experience sounds like a good answer to the classic "please tell me about a particular failure in your work" type of question: you were asked to do something, did it, it worked, but in the end it didn't work out for reasons unrelated to your work performance. There is a lot of learning potential from an experience like that; show the prospective employer that you learned from it. But my suggestion would definitely be to not make the specific mention until you've got your foot in the prospective employer's door by being there for an interview.
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
The project took about 3 days.
This seems to me to provide a (semi-roundabout) answer to your question. Let's say you work for a particular employer for five years. That's about 1,800 days, minus weekends and some vacation time. Let's pretend that the employer gives you European-style vacations and call that a nice, round 1,200 days actually worked. The exact number is going to be different between countries and possibly between employment forms, but globally, that seems a reasonable guesstimate.
The project you mention would then have taken all of 0.25% of your time working for this employer.
Sure, it may have been interesting or challenging, but remember that your résumé is a sales pitch. Lots of engineer types in particular tend to forget about that. The purpose of your résumé is to make the employer interested enough in you for you to get your foot in the door for an interview. The purpose is not to list everything you ever worked on.
So, you want to paint with broad strokes, but at the same time be specific. Technologies. Numbers. How what you did helped your employer's bottom line. Describing something that you spent a fraction of a percent of the time you worked for the employer doing, then, seems counterproductive. If my math is right and this is the median length of a project of yours, your résumé will list a few hundred projects of that size or larger. No prospective employer is likely to read through such a list. They would put your résumé in the "to be read later" pile (also known as the Round Archive).
Hence, unless the project actually adds something specific to your experience which you believe a future employer might be interested in, I would suggest that you leave out the specific mention of it. It was a minor project in the grand scheme of things and it didn't turn out to provide any significant benefit to your employer; in fact, since it didn't work out and was reverted, it was essentially wasted money for them. (Not to say they didn't learn from the experience, but it didn't improve their business case toward their customers.) If you learned additional technologies or something like that through it, you may want to mention those as "also worked with" or something similar. It might make a good conversation piece during an interview if the interviewer asks "what did you do that used Kibana?", but I wouldn't consider the failed, relatively small assignment to be something that actively sells you to an employer.
However, as I also mentioned in a comment to the question, this type of experience sounds like a good answer to the classic "please tell me about a particular failure in your work" type of question: you were asked to do something, did it, it worked, but in the end it didn't work out for reasons unrelated to your work performance. There is a lot of learning potential from an experience like that; show the prospective employer that you learned from it. But my suggestion would definitely be to not make the specific mention until you've got your foot in the prospective employer's door by being there for an interview.
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
edited Dec 18 '14 at 20:00
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
answered Dec 18 '14 at 15:15
Michael Kjörling
646717
646717
"European-style vacations" is pretty vague, with a minimum of 20 day in the Netherlands and Germany, up to 30 in France or Finland. Considerung public holidays, the range is even more interesting, with 41 in Lithuania, 40 in Russia, down to 28 in the Netherlands. With those public holidays, the US have it almost like the Netherlands, with 25 days in total. -- source: edition.cnn.com/2011/WORLD/asiapcf/07/29/…
– phresnel
Dec 18 '14 at 16:26
Also, weekends alone would bring the number of days down to 1280, with holidays still to be deducted. I concur with the rest of your answer though :)
– user29632
Dec 18 '14 at 17:21
Good points both. The point wasn't a mathematically exact calculation, though, but rather to show how small a fraction of the total worked time the OP's project amounted to. For all I know, OP has worked ten years for this employer. Or half a year.
– Michael Kjörling
Dec 18 '14 at 19:55
suggest improvements |Â
"European-style vacations" is pretty vague, with a minimum of 20 day in the Netherlands and Germany, up to 30 in France or Finland. Considerung public holidays, the range is even more interesting, with 41 in Lithuania, 40 in Russia, down to 28 in the Netherlands. With those public holidays, the US have it almost like the Netherlands, with 25 days in total. -- source: edition.cnn.com/2011/WORLD/asiapcf/07/29/…
– phresnel
Dec 18 '14 at 16:26
Also, weekends alone would bring the number of days down to 1280, with holidays still to be deducted. I concur with the rest of your answer though :)
– user29632
Dec 18 '14 at 17:21
Good points both. The point wasn't a mathematically exact calculation, though, but rather to show how small a fraction of the total worked time the OP's project amounted to. For all I know, OP has worked ten years for this employer. Or half a year.
– Michael Kjörling
Dec 18 '14 at 19:55
"European-style vacations" is pretty vague, with a minimum of 20 day in the Netherlands and Germany, up to 30 in France or Finland. Considerung public holidays, the range is even more interesting, with 41 in Lithuania, 40 in Russia, down to 28 in the Netherlands. With those public holidays, the US have it almost like the Netherlands, with 25 days in total. -- source: edition.cnn.com/2011/WORLD/asiapcf/07/29/…
– phresnel
Dec 18 '14 at 16:26
"European-style vacations" is pretty vague, with a minimum of 20 day in the Netherlands and Germany, up to 30 in France or Finland. Considerung public holidays, the range is even more interesting, with 41 in Lithuania, 40 in Russia, down to 28 in the Netherlands. With those public holidays, the US have it almost like the Netherlands, with 25 days in total. -- source: edition.cnn.com/2011/WORLD/asiapcf/07/29/…
– phresnel
Dec 18 '14 at 16:26
Also, weekends alone would bring the number of days down to 1280, with holidays still to be deducted. I concur with the rest of your answer though :)
– user29632
Dec 18 '14 at 17:21
Also, weekends alone would bring the number of days down to 1280, with holidays still to be deducted. I concur with the rest of your answer though :)
– user29632
Dec 18 '14 at 17:21
Good points both. The point wasn't a mathematically exact calculation, though, but rather to show how small a fraction of the total worked time the OP's project amounted to. For all I know, OP has worked ten years for this employer. Or half a year.
– Michael Kjörling
Dec 18 '14 at 19:55
Good points both. The point wasn't a mathematically exact calculation, though, but rather to show how small a fraction of the total worked time the OP's project amounted to. For all I know, OP has worked ten years for this employer. Or half a year.
– Michael Kjörling
Dec 18 '14 at 19:55
suggest improvements |Â
up vote
2
down vote
I would say 'yes', if you successfully built it. Even if the people reading your resume have access to the project and see that the logging system is not there, you can explain why is was withdrawn (if they ask).
The whole point of putting things on your resume is that future employers can see what (knowledge, experience) you bring to them, and this certainly is one.
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
suggest improvements |Â
up vote
2
down vote
I would say 'yes', if you successfully built it. Even if the people reading your resume have access to the project and see that the logging system is not there, you can explain why is was withdrawn (if they ask).
The whole point of putting things on your resume is that future employers can see what (knowledge, experience) you bring to them, and this certainly is one.
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
I would say 'yes', if you successfully built it. Even if the people reading your resume have access to the project and see that the logging system is not there, you can explain why is was withdrawn (if they ask).
The whole point of putting things on your resume is that future employers can see what (knowledge, experience) you bring to them, and this certainly is one.
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
I would say 'yes', if you successfully built it. Even if the people reading your resume have access to the project and see that the logging system is not there, you can explain why is was withdrawn (if they ask).
The whole point of putting things on your resume is that future employers can see what (knowledge, experience) you bring to them, and this certainly is one.
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
answered Dec 18 '14 at 10:48
Jan Doggen
11.5k145066
11.5k145066
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
You can mention the project, and the accomplishments you made during it, as part of your work experience and capabilities.
Don't feel obliged to mention that the project was scrapped unless they specifically ask, or if you know for certain that it will be brought up by someone else (if you used your previous employer as a contact, for example).
If they ask, or if you know they'll be calling your previous employer and might ask about the project, tactfully mention that you were successful in implementing your project, but that forces outside your control (you have no control over how much server space you get allocated) meant you had to revert the process.
You should also turn this into a positive in itself - being able to do a project and revert it when needed is a skill, not a flaw. And the fact that it had to be reverted because of factors outside your control means you can focus entirely on the tasks you accomplished, while tactfully mentioning that there were other circumstances that resulted in you having to revert it in the first place (don't throw anyone else under the bus - you may need them for a reference after all).
In short, not only is it perfectly fine to mention it, but the fact that you accomplished it AND knew how to revert it when tasked to is two accomplishments, not one accomplishment and a failure.
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
suggest improvements |Â
up vote
2
down vote
You can mention the project, and the accomplishments you made during it, as part of your work experience and capabilities.
Don't feel obliged to mention that the project was scrapped unless they specifically ask, or if you know for certain that it will be brought up by someone else (if you used your previous employer as a contact, for example).
If they ask, or if you know they'll be calling your previous employer and might ask about the project, tactfully mention that you were successful in implementing your project, but that forces outside your control (you have no control over how much server space you get allocated) meant you had to revert the process.
You should also turn this into a positive in itself - being able to do a project and revert it when needed is a skill, not a flaw. And the fact that it had to be reverted because of factors outside your control means you can focus entirely on the tasks you accomplished, while tactfully mentioning that there were other circumstances that resulted in you having to revert it in the first place (don't throw anyone else under the bus - you may need them for a reference after all).
In short, not only is it perfectly fine to mention it, but the fact that you accomplished it AND knew how to revert it when tasked to is two accomplishments, not one accomplishment and a failure.
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
You can mention the project, and the accomplishments you made during it, as part of your work experience and capabilities.
Don't feel obliged to mention that the project was scrapped unless they specifically ask, or if you know for certain that it will be brought up by someone else (if you used your previous employer as a contact, for example).
If they ask, or if you know they'll be calling your previous employer and might ask about the project, tactfully mention that you were successful in implementing your project, but that forces outside your control (you have no control over how much server space you get allocated) meant you had to revert the process.
You should also turn this into a positive in itself - being able to do a project and revert it when needed is a skill, not a flaw. And the fact that it had to be reverted because of factors outside your control means you can focus entirely on the tasks you accomplished, while tactfully mentioning that there were other circumstances that resulted in you having to revert it in the first place (don't throw anyone else under the bus - you may need them for a reference after all).
In short, not only is it perfectly fine to mention it, but the fact that you accomplished it AND knew how to revert it when tasked to is two accomplishments, not one accomplishment and a failure.
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
You can mention the project, and the accomplishments you made during it, as part of your work experience and capabilities.
Don't feel obliged to mention that the project was scrapped unless they specifically ask, or if you know for certain that it will be brought up by someone else (if you used your previous employer as a contact, for example).
If they ask, or if you know they'll be calling your previous employer and might ask about the project, tactfully mention that you were successful in implementing your project, but that forces outside your control (you have no control over how much server space you get allocated) meant you had to revert the process.
You should also turn this into a positive in itself - being able to do a project and revert it when needed is a skill, not a flaw. And the fact that it had to be reverted because of factors outside your control means you can focus entirely on the tasks you accomplished, while tactfully mentioning that there were other circumstances that resulted in you having to revert it in the first place (don't throw anyone else under the bus - you may need them for a reference after all).
In short, not only is it perfectly fine to mention it, but the fact that you accomplished it AND knew how to revert it when tasked to is two accomplishments, not one accomplishment and a failure.
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
answered Dec 18 '14 at 18:27
Zibbobz
6,68752453
6,68752453
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f38619%2fshould-i-mention-an-interesting-but-failed-task-in-my-resume-as-an-achievement%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
4
related: Is it worth to tell a “Samaritan†(company mentor) about my story of particular failure? "If you plan for a career in software development, you'd better drop that attitude and instead, learn how to present your past project failures in a mature way and how to show what you have learned from these. Thing is..."
– gnat
Dec 18 '14 at 11:02
2
This sounds like an interesting example for a "please tell me about a particular failure in your work" type of question.
– Michael Kjörling
Dec 18 '14 at 14:59
I had a pilot project to evaluate a piece of software and the conclusion was to not use the software. They read that as pilot failed and I would have to explain the software company later went out of business - it was the correct conclusion.
– paparazzo
Dec 18 '14 at 15:22
I mentioned several failed projects I undertook during my sabbatical, but I doubt they'd have wanted to know if I had 'wasted' my employers time.
– SBoss
Dec 18 '14 at 16:11
Do you really mention every project that took 3 days on your resume? Or any such? How much "experience" do you think that you can claim after 3 days? At best you have a warm fuzzy feeling - not much more understanding than can be gleaned by reading a Wikipedia overview. If you mention it & don't mention 3 days, then when I learn that it was only 3 days I will think that you cheated/exaggerated/misled me. If you do mention that it was only 3 days then I will feel that you are trying to pad your resume and have nothing better to offer. Keep it to real achievements.
– Mawg
Dec 19 '14 at 9:13