Hacker News Reader

Whether or not you feel proud about them, I would suggest trying to look at some of your accomplishments from a different perspective to see how they can actually be impressive. Things like cleaning up terrible legacy codebases are valuable and reflect two positive traits, to me: Willingness to get your hands dirty, and the sense to distinguish between "good" and "bad" code.

On the other hand, if you really just want to build more "pride-worthy" things, I think you really just need to prioritize that desire more. Making something you're proud of often means going beyond what's mandated by "useful and sensible". This might sound a bit inane, but I would seriously consider asking yourself, before you start your next project(s), "How can I make this project something I'm proud of?"

I'm in a similar boat as OP, every thing you say is true and I've tried selling myself that way, but in the end when you're trying to break out of that industry and work for a startup or different kind of company not all of them can appreciate that type of work. I've gotten rejected many times with the feedback that I was great but other people interviewing for the same position has more relevant experience.

Good point. I imagine most smaller companies are specifically looking for people who can build things in a self-directed environment using the latest tech. Maybe it's only the larger, older orgs that care about legacy code wrangling.

In my limited (n=1) experience with startups, I'd say they take a very different approach to recruiting and should be "courted" by the applicant in a slightly different way. Relevant experience becomes more important. IMO, startups particularly care about:

1. Can the applicant hit the ground running? Startups don't want to hire people that need training, because they want them to be productive ASAP. Startup teams have very little slack, so individual productivity is more important. For example, I started working at a large company and had 3 months training before I touched any code. Then I went to a startup and pushed a bugfix to production my first day. The expectation is quite different. My recommendation would be to work on some side projects that use common startup tech stacks (Ruby, Node, Python, etc.) so they know you're familiar with more than just Java or whatever, and emphasize how you're a quick learner that adapts easily to different situations.

2. Does the applicant offer a specialization we need? Startups are always looking to increase the quality and range of their technical skillset. If you have a relevant specialization that their engineering team is lacking, like DB admin, security, hiring, management, distributed systems, AWS, etc., the startup will be much more inclined to hire you. Recommendation here would be to try to dig into some topics and gain expertise in your current company that can carry over. Alternatively, something like getting an AWS certification, publishing blog posts about relevant topics, etc.

3. Is the applicant a culture fit? For example, usually startup employees should be internally motivated, autonomous, good communicators that enjoy programming and think of development as a vocation instead of a chore. You shouldn't have to be exactly the same as everyone else, just show that you're likeable, flexible, and can do good work without a manager.

(edited: Added some additional clarifying points).

#1 and #2 is basically why me and many others have been stuck in the same industry working on big enterprise apps and legacy technology/code.

You need to either take pride in your work or just pick the most complicated task you have done and explain it well and use that as the answer.

Or you could do a side project that would fit the bill.

It's not about the actual project but about storytelling. First you need to write a compelling story, read some blogs about writing or even books on the subject. Side projects won't help you unless you build something massively popular

> Everything I've done has been what seemed like the most useful and sensible thing to do for the client or company at the time. None of it helps in interviews.

Maybe focus on the non-technical results of those "useful and sensible" things?

Yeah, if one of the projects stands out as having the most benefit to your users or clients then I would focus on talking about that as it would help the listener realize that you care about the _business_outcomes_ of your work.

> Two and a half years at a small company, working on their legacy codebase. We did innumerable small cleanups, bodged in new features, and did one bigger architectural change. Even the big change was the sort of thing that would only take a week in a sane codebase.

Can't you take some pride in that? Any idiot can do green fields work, they'll likely be gone before any of their mistakes get a chance to become apparent, but taking an existing lump of spaghetti and moulding it without breaking anything is a whole different ball game.