5 compelling reasons to work for Simply Wall St Tech
--
Why work for Simply Wall St tech? Here are some crucial technical reasons in addition to the culture and work flexibility.
It has been just over a month since I joined Simply Wall St, having worked in e-commerce for 10 years across 2 continents, it is surely the change in the work domain I was thirsty for. In this post, I will describe 5 compelling technical reasons to work for Simply Wall St (SWS), let’s get rolling.
SAAS, not physical goods
Before diving deeper, I would like to detail why Simply Wall St was enticing for me to apply for a new job. As mentioned, spending a decade in e-commerce specifically fashion e-commerce the daily vocabulary was orders, shipments, sizing, put away, picking, etc. I wanted to work for a Software As A Service (SAAS) company be it B2B or B2C as the product is not physical. Be it B2B or B2C, a SAAS company sells data/information to its customers.
The challenge, when oversimplified is getting more customers and keeping them, meaning having a lesser churn rate.
In regards to the physical infrastructure, it is simpler than running a warehouse that is the size of two football fields. Anyways, let’s get started with the technology-related reasons to work for Simply Wall St.
And the reasons are
Below are the reasons that will help you to seriously think about applying for the open roles at Simply Wall St. It is a profitable SAAS company with 4+ million users so most roles are tech roles :D.
Discussing the why and who, not just the how
This is not a strict tech reason but it is a very important one in my opinion. There are many ways to build new features, HiPPO (highest paid person’s opinion) being one that you don’t want your team or org to follow. On the contrary, at SWS we have data to back our assumption.
User research sessions are run to validate what feature should be built next.
Having domain knowledge is very important for software engineers, you can come up with the best solution to a non-existent issue that becomes a feature debt as soon as it is released. So understanding the user and doing things with who are we solving the problem for and why is critical. On top of it, we discuss things with the Jobs To Be Done (JTBD) and how to build customers’ habits lens. This makes the discussions much more valuable than discussing the technical details which we can and will put in place once the why and who are understood well.
Tech OKRs to improve technical things
I was introduced to Objectives and Key Results (OKRs) almost 4 years back when I first landed in Sydney, Australia. My experience with OKRs has been mainly achieving business objectives and key results. For example, get the add to bag rate up by X%, and decrease the return rate by Y%.
To my surprise, at SWS, we are setting OKRs about technical things. For instance, one of the tech OKRs we have this quarter is to add more applications to DataDog Application Performance Monitoring (APM).
So other teams could have tech OKRs like decreasing the error rate of an API or increasing the test code coverage for an application.
This is very useful and important to keep the tech debt to a manageable level and speed up the delivery of new features.
No waiting for the staging environment, 1 new branch = 1 URL — Bliss
Have you ever waited for your turn to test something on staging? Especially if it is a big and old (I don’t like to use the word legacy) application that has multiple teams/engineers working on it. Or after a week-long code freeze. It is a big waste of software engineers’ time possibly even more than waiting for the CI/CD builds ;).
The above scenario never happens at SWS, as soon as the build and tests pass the code is deployed to the “dev” environment for the git branch. It is possible by using the magical sauce of Gitlab pipelines, Docker, Kubernetes, and Helm.
This gives you a sense of using Netlify’s deploy preview or Vercel’s automatic branch URL every day, each branch on any project.
This is by far one of the best things, especially working with microservices and not having to wait for your turn to test, simply blissful.
Feature flags with a difference
Feature flags are the backbone of differentiating between deployment and release, where deployment is the technical part and release is the product and business aspect. A feature’s code can be deployed to production but it can be released only to 2 software engineers, internal users, a subset of users, or just 2% of the users, that's a feature flag in a nutshell.
My experience with feature flags was with a feature management SAAS. Here at SWS, we are using an open-source tool as our feature flag management service. It is hosted in-house which has its own pros and cons. One other interesting non-technical aspect was the ability to target new users only.
The main difference is that there is no external dependency and as the feature flag service is inside the same Kubernetes cluster it is much faster to access.
As mentioned this is a tradeoff and depends on the team and its capacity to manage this.
GraphQL in action, not just paper
In full honesty, I have worked only with REST-based APIs in the past 15 years. I had read about GraphQL in the past but I have not implemented or consumed a GraphQL API even for a side project except for some mild dabbling around. Like any other spec/standard GraphQL also has its own advantages and disadvantages, I am learning some of it first hand now.
If you are interested to see GraphQL in action in real-life money earning API with the federation, subgraph, mutation, and all that jazz Simply Wall St tech is the team you should be in.
As mentioned, I am new to GraphQL and I will take it as a new learning opportunity. I hope to make the best out of this chance. This also speaks volumes about the learning supportive culture at SWS. This leads us to other points to work for SWS tech.
Other important motivations to join SWS tech
In addition to the above-mentioned mildly and highly technical reasons, there are many other motivations to join the SWS tech team. For instance, the quarterly hackathons resulted in many great ideas deployed to production as seen below:
Simply Wall St is known for its unparalleled work flexibility. From flexible work hours (with core hours 10 AM to 2 PM) and remote-friendly to trust with work from overseas for 3 months. I was working from 6:30 AM to 2:30 PM and there are other team members working non-regular hours. SWS also has no meeting Mondays to keep your “flow state” intact.
Did I mention we also have Simply Stop Friday afternoons? This means all SWS employees work only 4.5 days a week with half-day each Friday.
On top of the ESOP and learning budget, there is also a “Share Club” to learn to invest in shares. You can read it all on our Careers page. SWS has recently added 4 more days of leave per year, one each quarter. To know more, ask about this in your chat with our Talent acquisition team :). You can discuss it in the tech stack too in that initial chat, but don’t get into the weeds.
Conclusion
Working at SWS for just over a month has been great. The team has been very supportive. Being a ~65 people startup there is no red tape and baggage of multiple levels. Communication is also easy as there is little chance of loss in translation.
We are currently looking for Fullstack engineers, Data engineers, and an Engineering manager in Engineering.
You can read in detail about us in our open confluence space. So, head to the openings page and hit that apply button now. Cheers!
