Related: In a job interview, how do I explain why I was fired?

Have you had jobs before these three? If so, what is different about these versus prior jobs?

@JoeStrazzere they were internships and then temporary jobs for fixed periods. They were bigger companies and I got good references from them.

@Johannesberg - assuming your performance wasn't poor in those jobs - why not? What is different now? As I wrote in my Answer, maybe temp jobs are just your "thing"?

@JoeStrazzere I think one of the reasons was that in those jobs I generally had to build things from scratch so didn't have to deal with technical debt - and thus refactoring and cleanup (on my own code) was always fast and unnoticeable to management.

@Johannesberg - if that's a big factor, you should seriously consider it in your search for you next job.

My hearty sympathies are with you. I have a family but still feel like an orphan.

Consider contracting. The barrier of entry is lower, meaning that there will be fewer awkward question. No one will ask for references, so you might imply that you quit, rather than were fired, because you are still trying to find the right niche, so a series of contracts might help you find it.

...also you might be able to stick to contracts where you're writing greenfield code.

Were you explicitly asked to refactor the code?

What country are you in?

You say you work in a software company? Can you code? Asking because many people really can not code barely at all. Sorry to be blunt, but if implementing fizzbuzz takes more than (say) 10 mins, you should change field.

@TeroLahtinen yes, I'm actually above average in terms of coding. The problem seems to be that I have a tendency to refactor and cleanup code while working and not communicating this. I tried to stop this but was too late..

@SteveSmith no. I tried to solve related technical debt while working on a piece of code that I was assigned to. I also tried to add tooling to the testsuite to test better the thing I was working on. So all this took much more time than the estimation in the ticket.

@Johannesberg I can get obsessive with code quality. The thing is, refactoring is a business decision. The time you put in is an investment. That has to pay back in the future somehow. It has to at least have a good chance of being worthwhile (change multiplied by time saved or something). Often, at least basic refactoring of horrible code is worth it. But don't go overboard. A lesson I'm still working on :)

There is a market for cleanup and refactoring work. I used to write and automate tests, create/review quality guidelines and analyze/update legacy code for various clients, usually in 3-6 month projects. Judging by your comments, I suspect that sort of work might be right up your alley, and it would be easy to sell it as "I really care about code quality, so I want so make this my professional focus." Be warned, though, that you'd most likely have to work on some really messy specimens.

VOTED TO REOPEN - this is not a duplicate of the linked question

You do refactoring without explicit instruction if you are good and fast enough to do the task at hand and refactoring in the time alloted. And then you make sure you don't get carried away.

Many programmers fail to realise that, beyond a reasonable level of quality, companies are far more interested in having code delivered on time in a usable state than code that is well written, well tested etc. The best programmers from a business perspective are those who know how to balance best practices with delivering timely results. If you can't do the latter very well, consider freelancing or something where you have control over the deadline and can choose clients who rather well-written code than less well-written code delivered in a timely manner (though I doubt many exist).