First - welcome to my blog! Why did I choose this name?
It's a Power Rangers/coding pun.
I've been meaning to write about my experience as a software engineer and Hashnode seems like a neat tool to use. I've looked at some other articles here and found them informative, and want to throw my hat in the ring and maybe help somebody in my shoes.
I plan to write about some projects I work on and what I learned, and then present them in a way that's easy to digest and reproduce if you're following along. I've found that while there are a lot of tutorials out there, they focus on how to do something and not why you do it a certain way. I think my ability to explain complex concepts in a way anyone can understand will go a long way toward this effort and I look forward to sharing some of my expertise.
How I got started
It is tough out there for a newly minted software engineer trying to get their first full-time role. Before coding, I was a tax accountant. I decided to change careers because being a tax accountant is as fun as it sounds. That I was a tax accountant is not important - what is important are the transferrable skills I learned.
Project and deadline management - funny enough, Kanban-style organization (think Jira or Trello) is exactly what I used to keep track of different clients and work products. Instead of a ticket, I had a client, and instead of sub-tickets, I had 'pending lists', which is just a bullet-pointed note containing all the documents and work products still needed for a client. As enough pending items roll in, you can start to work on the client and move them through your board while keeping an eye on clients with missing items.
Communication and problem-solving skills - chances are you have a tax horror story where some complex tax rule is preventing you from filing your taxes. Whether it's a lack of clarity on Schedule C (a sole proprietorship) or Schedule E (rental property income), it can be hard to digest what it is you need for your return. Part of my job was looking at the body of information about an individual or company's finances and translating what I saw into actionable requests for data from the client. I was paid to digest a complex topic and spit out, in simple terms, what the client needs to provide for me so that I can help them.
Working under pressure - if you're familiar with the public accounting industry, you know that it thrives by taking on more work than it has the capacity for. This is best embodied by 'busy seasons', aka everything but November and December. It's more accurate to say there's a 'light season' during the Thanksgiving and Christmas holidays. Anyways, during busy seasons there is always more work to do even if you finish all your assigned tasks early. This is where the firms make their money, and that means working for these firms is like working in a pressure cooker for ten months of the year.
Automation and Scripting
While I learned a lot, and I will likely be able to do my taxes for the rest of my life, I was unfulfilled by the work I was doing. I've always enjoyed working with computers and the extent of complex technical work I did was either using unintuitive tax forecasting software or making complex spreadsheets in Excel. I'm not going to lie, I did enjoy writing macros that reduced the manual work I needed to do, but I rarely had time and ended up doing a lot of VBA coding in my spare time. This led me to change careers to software engineering, something I've always had a knack for.
I got my start coding by writing VBA macros as I said above. The most useful macro I wrote contained a list of different financial statement accounts, and parse messy or hand-made financials into a trial balance that I could load into the software. From here, I started using Python as a scripting language and explored integrating it with Google Sheets to automate spreadsheets even further. I quickly discovered Google Apps Script, which is 1) the Google Sheets version of VBA, and 2) essentially JavaScript with built-in support for Google objects (like the spreadsheet or the document or your Google account).
I had some fun with Google Apps Script and built a fairly complex spreadsheet that I used for financial analysis. It looks a LOT like this. It does the job, but eventually I gained the skillset for full-stack web development and transitioned this project into a web-app, which I plan to deploy and link to eventually (I think this will be my first real technical article - deploying a project that uses Auth0, the pitfalls you run into when doing this for the first time, and how to achieve success).
I still played around with Python - I eventually built some web-scrapers to locate GPUs from various retailers in my area, back when there was a shortage (is there still a shortage? My 2070S does the job and will likely last me another 5 years at minimum).
I also made a command line game with ASCII graphics where the user is represented by an @ and navigates a dungeon consisting of underscores and hashtags, fighting monsters represented by various letters. The fighting is just dice roll rng, but one day I want to expand it and add items, gear, a persistent campaign, etc. But this was the first real 'app' I ever built.
Hack Reactor
I went to and graduated from the Hack Reactor 12-week Software Engineering Immersive. Did I need to do this? Not really - I am somewhat of an autodidact, which you need to be to survive work in public accounting. Am I a better coder for having done so? Absolutely. Do I feel like it prepared me to get a job? Yes - I made real projects with real teams of engineers and learned how to do the job, something that is exceedingly difficult to do on your own with no guidance. I already knew how to learn, but Hack Reactor taught me how to identify what to learn to be a software engineer.
I have experience doing full-stack work with several self-employed projects under my belt, and ~1.5 years of cumulative professional experience, but I'm looking for a full-time position with stability and an opportunity to learn from an internal knowledge base.
Some projects include:
A language- and culture-based social media web app
An e-commerce redesign
Front-end modernization
Back-end refactor from monolith to microservices
A financial analysis web app
These projects cover general requirements for most full-time roles I'm looking for:
PERN/MERN stack
Back-end language (Go)
Version control and working with a team via Git
Deployment via AWS
Working to a client's spec
You'd think this would be enough, right?
Well it might be. I am actively interviewing, and am currently in the final round of interviews for a company with millions of daily users that I can guarantee you use. I did over a month of preparation for the technical interview, and have high hopes. Even if this role doesn't work out, I have interviews with multiple other companies scheduled throughout the next two months (I am not used to the months-long hiring process many tech companies have - I got my first accounting offer during my first interview with the firm, maybe my third interview ever. I got my next job after one interview and received the offer the week after the interview).
The flip-side of this is that I've sent out hundreds of applications and I know I'm not alone. My current response rate is 33.79% (meaning I either moved to the next phase of the process, or was rejected). This means that just over 66%, nearly two-third of my applications, have been ghosted.
Of these ~34% of responses, 5.41% have been succesful. Of all applications, only 1.83% have been successful. I'm defining success as moving past the application phase of the interview process.
Strategy
My strategy is to send ten good applications a day using various aggregators and job boards and then spam easy-apply on LinkedIn.
For my good applications, I take the time to write a cover letter that matches things I've done with the requirements in the job posting. I've collected a bunch of different technical challenges I worked on in a Google Doc and just copy/paste what's needed. This has taken a lot of the tedium out of cover letters, and even still I've noticed I get the best responses when I carefully craft the cover letter to the job.
For my easy-applies, I just make sure I match the language requirements and am close to the years of experience. Could this strategy be better, could I vet these postings more thoroughly? Possibly, but if I devoted as much time to these applications as I do to my 'good' applications I would have sent a fraction of the applications I have.
And some advice I've received includes 'just spam those out', so that's what I'm doing.
Conclusion
If you've gotten this far, thank you for reading. If you skipped down here, I don't really have anything to provide - this post was just meant to introduce me to you and the Hashnode platform.
Check back soon for an article discussing the numerous ways you can mess up when deploying a React app that incorporates Auth0, why these mistakes happen, and how to fix them.