Over the last few months I have been pursuing a Software Engineering role as an early career engineer in a rough market. This blog outlines the steps and assumptions guiding my search.

Assumptions
I have avoided the 'shotgun' approach of mass-applying to jobs. Despite its potential, it often leads to disappointment and being ghosted after interviews I assumed went well.

I instead chose a strategy tailored to my individual strengths;

• I am generally a very persistent person. I believe this is a valuable trait in general. If you encounter an issue, you will need some level of persistence to figure out a solution

• Though valued in theory, being entrepreneurial is not valued in practice by employers. I have repurposed this as taking initiative, showing ownership and not being afraid to stand up to defend my product and assumptions made in the build phase

• My writing skills can be a proxy for good communication skills. Blogging about tech startups very early in my career helped me land an internship in a venture capital firm in South Africa, which, with other factors helped me get a contractor role in Google as an Analyst. Beyond this, writing about a startup I was building helped me secure my first few paying users and helped me raise funding.

For me this means focusing on startups. I have spent most of my career either working in startups, analyzing startups or pitching to highly active investors and raising money for a startup I was building. Additionally, this is a space that would most likely value more proactive/unconventional approaches. If I tried what I was doing with a bigger company, I would be ignored and my actions would likely be seen as being too pushy.

My approach involves using the a company's product either to build projects or find bugs, alternatively contributing to their open source where applicable. Through this I get a better understanding of their documentation, in some cases codebase and study GitHub issues raised around similar errors to understand how similar issues were solved, developing a more intuitive understanding of the product, issues someone using the product is likely to face and how to resolve them quickly.

I tend to focus on developer tools, companies building tools I could use regularly or were in a space I had some understanding of. I choose developer tools because I always have some product to build and test, so this not only helps me find a job I want but I also have to mentally justify why I should use this new product as opposed some other well established alternative.

Liblab - offer (rescinded)

There are many tools that can help you create SDKs in an instance, but I found Liblab to be one of the easiest to use, they had a very active blog and when I read threads about them on Hackernews I got the sense they were one of the leaders in the cohort of startups emerging to solve the problem around how laborious it can be to build SDKs in any language quickly.

In 2019, I build a data pipeline extracting data from BoxRec and CompuBox to build what was then going to be a machine learning model to predict the outcome of boxing matches. More recently, I realized the lowest hanging fruit was a much simpler problem, there is no consolidated site with boxing data. You can find boxer rankings in BoxRec and boxer status (weight, height, wins, losses etc). While you will find punch stats for each fight in CompuBox. You never quite know what the BoxRec rankings are based on. I leveraged FastAPI to create an endpoint exposing my data to the public and used Liblab to create SDKs for my API enabling users to access my API using whatever language they are more comfortable with. This blog was published on their site. I knew this was a very community driven product, targeting developers and this was a possible outcome. This amongst with updates on sent for weeks on what I was building helped me secure an offer even though they weren't hiring at that time. While the offer was eventually rescinded this is still a data point and validates my assumption.

VimCal

VimCal is an aesthetically pleasing calendar, 'the superhuman of calendars' that leverages NLP to help you create calendar invites quickly. I have to schedule interviews, intro calls, calls with developers and calls with users to test whatever product I am building, this gave me a real world use case.

For this I chose to schedule a demo call to get a better understanding of the tool, I installed the desktop version of their calendar, noticed a bug and created a very simple MVP and recorded a video with a possible solution. Was this an optimal solution? Probably not, but without access to their code it was a quick fix and I believed this would sufficiently show a willingness to take initiative, discover problems and suggest solutions even without access to much information. While I got the interview, I didn't go further as the founder expressed a concern about the risk of me leaving after 6 or so months. I followed this up with an email detailing other bugs I found (a few weeks later). I did this because despite his concerns, this is a product I actually use and view positively.

Dagger

Dagger is a programmable CI/CD engine to help you build pipelines that run as containers using any programming language. I read A LOT of HackerNews threads about Dagger and comparisons with other CI/CD tools. After my initial research, I decided to implement a CI/CD process in one of the products I built; a platform leveraging AI to help users practice for coding interviews. I wanted to run more tests to reduce the amount of bugs in my code and to set up infrastructure to more easily take on collaborators in the near future, while maintaining consistency in my code. I justified using Dagger because it enabled me to build a pipeline using any programming language. This would enable me to write conditional logic which YAML would not have allowed me to do.

I triggered Dagger through a GitHub Action Workflow so I could manually review changes before moving my build to staging and production environments. This helped me both build a better understanding of the tool while also helping me with a real issue I had. I blogged about this, was invited to a presentation and presented my work to the Dagger team and community. I didn't get the exact outcome I wanted, but I learnt a lot, and generally had a positive interaction with the team, including someone staying on a Discord call with me for close to an hour giving me valuable feedback, sharing about development methods I had never heard of and providing valuable resources to help me figure out what path to take with my product next (with regards to the CI/CD process).

Other

At another company, despite a hiring pause, the CTO still scheduled an intro call taking time to learn more about my experiences and tell me more about their product. C-Level execs of companies that have raised amounts north of $10 million are typically very busy, a willingness to talk to a candidate you aren't even interviewing objectively shows some level of interest. In another case a company gave me demo access to their closed beta tool, allowing me to test their product. While in other cases, I notice the email open and the user viewing my MVP a few times (I track everything).

This process can feel more exhausting and rejections feel rougher because of the time and effort invested. However, I enjoy building things and this approach aligns with what got me into programming and I believe will have a positive long term impact on my skills.

Stay tuned for more. Check out my portfolio to learn more about me.

Here's my LinkedIn if you would like to connect. and Twitter