3 ms·

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 actual

by l_t 9y ago

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?"

sngz 9y ago
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.
- l_t 9y ago
  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).
  - sngz 9y ago
    #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.

by l_t 9y ago

sngz 9y ago

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.

l_t 9y ago
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).
- sngz 9y ago
  #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.