When the inevitable question "What are you most proud of?" comes up, it's your turn to impress.
This is my biggest weakness. I haven't worked on anything where I made a substantial contribution that I'm proud of. I've been working as a programmer for nine years.
Three years in a consultancy implementing solutions based on a third-party framework. The framework was terrible, so the best we could do was to paper over its cracks. We made things much better, but it was still very poor compared to normal software.
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.
Two and a half years in an agile consultancy. Many short projects, mostly building technically rather simple things, but focusing on teaching the clients how to be better at software development. The one technically complex thing we built was mostly only complex because some plonker settled on a microservice architecture using a new messaging framework before I took over. I think we did a good job, but I can't justify the central design decision of the project!
Those companies were all agile, with pairing, collective code ownership, and self-organising teams. Even where we did something good, it wasn't my work alone.
One year so far in a hedge fund. I've built several small tools and features, most of which haven't ended up being very useful. The two bigger things I've done have mostly been about wrapping sophisticated third-party libraries in an application which integrates them into our environment - I'm a plumber.
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.
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).
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.
This is my biggest weakness. I haven't worked on anything where I made a substantial contribution that I'm proud of. I've been working as a programmer for nine years.
Three years in a consultancy implementing solutions based on a third-party framework. The framework was terrible, so the best we could do was to paper over its cracks. We made things much better, but it was still very poor compared to normal software.
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.
Two and a half years in an agile consultancy. Many short projects, mostly building technically rather simple things, but focusing on teaching the clients how to be better at software development. The one technically complex thing we built was mostly only complex because some plonker settled on a microservice architecture using a new messaging framework before I took over. I think we did a good job, but I can't justify the central design decision of the project!
Those companies were all agile, with pairing, collective code ownership, and self-organising teams. Even where we did something good, it wasn't my work alone.
One year so far in a hedge fund. I've built several small tools and features, most of which haven't ended up being very useful. The two bigger things I've done have mostly been about wrapping sophisticated third-party libraries in an application which integrates them into our environment - I'm a plumber.
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.