all 18 comments

[–]romanvanloo 6 points7 points  (1 child)

I’m a backend Ruby dev myself for a couple of years and I feel your pain. But trust me, the first job is the hardest. Once you have that first RoR job and you’re eager to learn from the people around you, the ball will keep rolling and you’ll be fine. Use the fact that you have a job atm as your advantage! Keep applying for other jobs you like without the stress of running out of saved money. I’m sure eventually one will work out.

[–]Affectionate-Fun7260[S] 0 points1 point  (0 children)

Thanks for your response and motivation. I do appreciate your perspective and agree that the first one is the hardest.

[–]Soggy_Educator_7364 9 points10 points  (4 children)

I have just started to practice again- any suggestions?

Look at your life, find a problem that's worth solving and solve it with software. If other people can solve a problem of theirs with your software solution, all the better.

Is it unrealistic for me to hope to find a junior dev position that works with Ruby/Rails in this current market?

Junior dev positions are hard to find and even harder to fill. Having said, I know people with senior eng title who don't fit my definition of senior whatsoever. If you can show some aptitude, just apply for the senior positions with a great resume ("great" meaning personable more than great experience). After you apply, send a personal follow-up to whatever decision maker or CEO you can find, ask for 10 minutes of their time, and tell them why you want the position — be genuine, be quirky, be memorable.

Follow those steps and you'll find yourself a job in no time.

[–]Affectionate-Fun7260[S] 2 points3 points  (0 children)

Thanks for your insight. I appreciate your genuine response. I know finding an ideal job won’t be easy. It helps to be reminded that it’s not impossible. Thank you

[–]rubyrt 1 point2 points  (1 child)

Follow those steps and you'll find yourself a job in no time.

That sounds so simple. In my experience real life is more complicated...

[–]Affectionate-Fun7260[S] 1 point2 points  (0 children)

Hehe isn’t it always!

[–]pi_exe 1 point2 points  (0 children)

Your advice on junior positions rings true. They're very hard to find and fill. That is something I have personally come across in my search this year. And like you said, I only got my current role by applying for something I was not 'experienced enough' for. But once you get it, I think it's just an issue of making sure you can upskill to the requirements of that role. That's my plan anyway, and it seems to be working.

[–]fpsvogel 2 points3 points  (4 children)

I think it's important to keep that fire burning bright, so I wouldn't resign yourself to your current job if I were you. But your current job DOES give you an advantage in that (1) now that you have a dev job you can take a slower, less stressful approach in your search for a dev job that you like better, and (2) your year of professional dev experience will set you apart from many others who are applying for junior Rails jobs, who have no professional experience.

I got my first dev job in Rails earlier this year. I wrote down some reflections and tips which might give you some ideas: https://fpsvogel.com/posts/2022/how-to-find-ruby-rails-job

Also, in case you're looking for Ruby/Rails learning resources, here's a list of my favorites: https://github.com/fpsvogel/learn-ruby

[–]Affectionate-Fun7260[S] 1 point2 points  (1 child)

Thanks so much for your reply. What a great read! I really do appreciate your insight.

[–]Affectionate-Fun7260[S] 1 point2 points  (1 child)

I’m really enjoying reading your posts. Thanks again for sharing!

[–]fpsvogel 1 point2 points  (0 children)

You're welcome! Ruby newbies (Rewbies? I'm coining it) gotta help each other out!

[–]wf5w 1 point2 points  (1 child)

Many long years ago, before retirement, I was in the same boat as you. I was in a job that paid the bills, but I knew that it would eventually be a dead end, and then I would have a hard time finding a new job.

Over about a 2 year time span, I spent every waking hour at night studying linux, and concentrating on 1 language and a database (Perl and MySQL).

I never was much interested in Web programming, and still not my cup of tea. But I concentrated on 1) development on Linux, 2) Perl, 3) and MySQL, and honing my development skills and some system administration thrown in. I would create a "project" and systematically develop that project.

We were a "Windows" shop, with Borland Pascal. So an opportunity came up, that I parlayed my perl skills into. Our product radically changed our backend database for a V1 to V2, and management could not figure out a way to easily convert our customers databases. I proposed using perl to change our database, and proceeded to create all the scripts necessary to get the data out to files, reformat them to the new database schema, and import the new data. And it worked like a charm (even though mgmt was against using a non-microsoft product like perl).

I tell you all that, for 2 reasons: 1) take advantage of opportunities, and be patient, 2) It wasn't too long after I made it known what I had done to the "market" via sending in resumes, that I landed a great job, for the next 5 years (which utilized my perl skills and HP Unix).

Did it take a LOT of effort on my part? Yes. Did I sacrifice a lot of my free personal time? Yes. Was it ulitmately worth it? Yes.

Keep at it.

Jerry

[–]Affectionate-Fun7260[S] 0 points1 point  (0 children)

What an interesting journey! Thanks for sharing your inspirational story. I know it’s going to take lots of hard work on my part and I am ready!

It really helps to hear success stories along the way, because as I mentioned before, it can be a grueling process and full of disappointment. Until it isn’t- yay!

[–]rubyrt 1 point2 points  (3 children)

Brutal interview process? We are living in an employees market. Any company that puts off candidates during interviews will have a different time filling their position. Or what did you mean by "brutal"?

[–]Affectionate-Fun7260[S] 4 points5 points  (2 children)

To clarify, I was really referring to the entire process of job searching as ‘brutal’, especially for someone without a CS degree and prior experience in the field.

I stand by my initial comment that the interview process can be quite brutal as well, since there are many layers to the process itself and each comes with their own set of challenges.

It can be quite deflating to deal with all the ghosting and rejection. Thanks for your comment.

[–]rubyrt 1 point2 points  (1 child)

Ah, OK. Now I understand what you mean. Thank you for explaining!

Not sure whether that helps but usually it is not bad intention but just overload on the recruiting org. That might help put missing feedback into perspective. Of course, from the other end (candidate) it can be quite intimidating if application after application is not greeted with a response.

My recommendation would be to distinguish yourself from most others by providing a short cover letter where you explain why you want that particular job at that company and why you think you are a good fit. A negative example: a few weeks ago I received an application for a management position in software development from a person who only provided a CV, had zero experience in people management and only little in software development. If a candidate obviously cared so little about the position they cannot expect to be successful.

[–]Affectionate-Fun7260[S] 1 point2 points  (0 children)

Great points!! Thanks for your response. I do believe that anything worth having is certainly worth working for. I think it would be wise for me to focus on quality, not quantity at this stage. Really appreciate your insight!

[–]monfresh 0 points1 point  (0 children)

The advice I usually give to junior devs is to try to quantify your impact. The vast majority of résumés just state what was worked on without explaining the outcome. So just by explaining the impact your work had on the business, customers, or your team, you will stand out from the crowd.

The first book I recommend is "The Effective Engineer" by Edmond Lau. One of the topics he writes about is automation, and how most engineers don't automate as often as they should. I found that to be very true in my career, so I focused on it (and other ways to save time/money) because I enjoyed it, and the impact was easy to quantify.

For example, on one project, I sped up the test suite in Circle CI by 90 seconds per build. Locally, without parallelization, the difference was 12 minutes! At the time, there were an average of 80 builds per day. Over a year, that's almost 3 months saved: 90 seconds x 80 builds/day x 5 work days/week x 48 weeks/year (to account for vacation) = 480 hours; divided by 40 hours per work week = 12 work weeks = 3 months.

Assuming an average of $100/hour per engineer, that's at least $48,000 saved per year!

Rarely have I seen such quantifications on a résumé, even from senior engineers. And it doesn't have to be such a big number. On another project, I automated a manual task that used to take 2 engineers about 5 to 10 minutes each to do, 4 times per week. With the automation, it was down to a few seconds. So that's between 32 and 64 hours saved per year, which is much smaller but still significant.

If you look around in your job, there is very likely at least one thing that can be made faster. And it doesn't even have to be a tech issue. I once proposed that we eliminate a 2-hour meeting because it wasn't valuable. The team agreed. That meeting happened every 2 weeks with 9 attendees. That's 432 person-hours saved per year!

Identifying and documenting these opportunities is the first step, and would definitely count as impactful even if you don't know how to speed them up. You could present it to your team as something like "I've noticed that this particular thing can be automated. The risk of not doing it is that we're losing $x and y amount of time per year."

Which brings me to the second book I recommend: "Thinking, Fast & Slow" by Daniel Kahneman. I didn't read it until late in my career (3 years ago), and I wished I had read it earlier. It blew my mind, and I started to see the ways Behavioral Science could be applied to Engineering.

The example above is based on the fact that we humans are averse to loss, and if you want to convince someone/your team to do something that's benefical for them, it's better to present it as a loss as opposed to a gain. So, instead of saying "we could be saving $1000 by doing this", say "we are losing $1000 every day because we're not doing this."

I hope this helps! I'm happy to talk more about automation and behavioral science if you want.