How do I explain to future employers why my past work looks like crap?

September 15, 2019 10:36 AM

My publicly-visible past work doesn't look great for reasons largely outside of my control. What should I do?

I've been doing full stack development for about 4 years now (and other development for ~15 years before that). I'm more or less up to speed on modern tooling and practices.

I've been deeply involved with two major projects. Most of the projects are internal facing: internal tools, database tomfoolery, API development, fixing the many, many issues left behind by early project decisions, etc. As such, there have been a lot of mostly-invisible successes.

At the start of each project, each company told me that they wanted a best-in-class web experience. And this is fantastic: user experience is what I really care deeply about, with the back-end work being the necessary evil to support that.

I built alpha versions of the user interfaces with the intent to enter a user feedback cycle, and both times, the project manager has said "Good enough! Never work on this again!" (Just imagine several months worth of arguments and politics and broken promises right about here...) So, there are now two alpha-quality websites, the only publicly visible artifacts of my four years of work, that will exist in the world with my name on them.

In a few months, I would like to start looking for another job with more focus on front end design and build. And since I have greying hair, I expect a bit more difficulty.

What can I do to present the best face on this to prospective employers? Should I be spending my evenings building a set of portfolio sites? Code boot camp? MOOC certificates?

Any ideas or experiences are appreciated.

posted by cowcowgrasstree to Work & Money (3 answers total)

Take the ugly stuff out of your portfolio, and emphasize your backend work. Curation!
posted by oceanjesse at 10:38 AM on September 15, 2019 [1 favorite]

In my experience in hiring software engineers, even having a visible portfolio is the exception. Not having something to demo from the past 4 years wouldn't raise any flags with me. The catch in your situation is that the way you describe what you were working on will probably imply that there should be something public, and that is something i would follow up on as an interviewer. Would you feel comfortable calling your outputs "prototypes" or "MVP" or "version 0.1"? We all understand that business decisions sometimes impact the quality of a project, and it's fine to explain that in a way that doesn't throw the PM under the bus. When discussing them, be sure to mention the improvements that you had been planning. Since you won't want the hiring manager to find the project before you can provide your context, maybe be a little vague on your resume, as long as it doesn't sound evasive.
posted by Horselover Fat at 11:52 AM on September 15, 2019 [3 favorites]

It's more common than not for development work to be unavailable for public view, either because it's backend code, or front-end code for an internal or proprietary site or app. Everybody who's reached senior level has been forced to ship code they didn't believe was ready, and has work they're proud of that they'll never be able to show anybody.

Don't show work that doesn't make you look good. If you believe it's worth mentioning your experience with a flawed product, save it for the interview where you will be able to use it as an illustration when answering questions about your past experiences, what you learned from them and what you would do differently if you could do them over again.
posted by at by at 12:16 PM on September 21, 2019