I had the chance to interview Ather Qureshi, a software engineer at Carta. He’s got some interesting thoughts on how navigating the professional world is very different to learning in college and how problems in the real world can't really be solved like an exam at school.
Currently, I work for the Finance Automation Team at Carta. As the name suggests, most of my team's work is aimed at building and maintaining software to automate financial operations but we also manage a bunch of internal tools at Carta. We work very closely with the core payments team at Carta, and we report directly to the finance team.
Some key areas we work on:
I like to think that we mainly build the glue that holds our financial software together and help automate manual operations. With this automation, we get cleaner data and allow us to take proactive actions.
The work is extremely rewarding and challenging as we directly interact with our stakeholders and we get full autonomy on how we solve their problems. As carta continues to scale up, our work becomes paramount and we are positioned to produce a ton of impact.
I heard about Carta through a friend who worked there. Carta was growing rapidly in 2019 / early 2020, and they were opening a Canadian office in Kitchener/Waterloo. It was a closer commute than my current job. I was already interviewing around, and I actually had an offer in hand before I reached out to Carta via a referral from that same friend. I decided to just go ahead with it since it’s always good to practice interview skills, and there is nothing to lose by potentially gaining another offer. I had not done a lot of research about Carta at this point.
The interview process was typical for SWE roles with some slight modifications. These were the steps I took in Jan of 2020:
Some key things that I noticed during the interview was that the interviewers were extremely helpful and the questions being asked were not esoteric. The technical rounds consisted of practical problems that required you to work together towards solutions. The focus was more on turning ambiguity into specific requirements, iterating and making sure you covered all reqs - not testing if you knew specific algorithms. It was the first interview also where design patterns came into play.
I loved that since how to organize your code is actually something that you face constantly in your job, and I feel it’s a better skill to assess versus if you can write iterative merge sort or whatever. The behaviour rounds assessed culture-fit and collaboration skills.
I received positive feedback, and since I had another offer in hand, they expedited the interview process for me. All steps were completed within 3 business days. After a short while, Carta extended an offer. The offer was great and after doing more research at the company, I accepted. Some key things that pushed me towards accepting the offer was that:
For me, I try my best to stick to a routine everyday and avoid overworking myself especially now that we have been working from home for almost a year. I usually get into around 3-4 hours of deep concentrated work per day, and then 3 hours of more light work where I am also in meetings.
My typical routine is:
A non-average day usually is a flip between full meeting days or full deep work days. For instance, every quarter we have hackathons at Carta. During the hackathons, I can put out maybe 6 hours of uninterrupted deep work. These are fun because you get to choose what you work on, and get depth in other areas in Carta. Often, we try to tackle technical debt that we didn’t have time to fix. You just have to build a demo - you can take your time and polish it up before it hits production.
We also have full day company days, in which we get to see what each business unit is putting out, how Carta is doing overall, and do some fun collaborative activities. The one we did at the end of last year, we had a virtual escape room and a magician presentation over zoom.
My favorite thing about being a software engineer is that we get to build amazing things directly. In today’s day and age, where technology is the main resource you need to utilize to bring value - a software engineer is the only profession that can take an idea to a tangible product. I like that I can deliver value quickly and not be dependent on things I don't understand or I’m not responsible for. My work is hands-on and I feel proud of what I can build.
My least favorite thing is probably that it is a lot of sitting in front of the computer. I have to make sure that I don’t over-work myself, get plenty of exercise, and socialize. The work is also pretty taxing, and sometimes I find myself pretty worn out mentally wise at the end of every work day. I have to make sure I take breaks, and remember that binging will lower my overall productivity.
You generally gain more confidence as you just solve more problems. I don’t think there’s another way to do it. But to add meat to this answer, I believe It depends on the type of problems. Depending on their scope or difficulty, I aim for solo or collaborative approaches. I also think it’s important to believe you can solve the problem even though you don’t have the details hashed out yet. I and also the rest of the engineers at Carta, value reasoning in plain english before we start touching code. Try your absolute best to have solved the problem on paper before you hit your editor.
Small problems you can usually tackle them yourself, and they are pretty much solved if they are scoped properly on the ticket itself. If it’s a bit unclear, then dive in for a bit and see if you can make sense of it.
Medium sized problems, with some ambiguity can still be covered by 1-2 engineers but we make sure we get feedback on our approach before we start coding something out. We reason these problems with our core team usually just via slack or if it’s getting too long, we do a meeting.
If it’s a large enough problem, we create full design documents and collaborate across multiple teams. Once we are confident that we have the best solution, we start breaking it down and building it.
My best advice is to not lose your appetite for learning new things and constantly try to improve that skill. The skill of learning to learn. It’s imperative in a professional environment where you have to learn things fast, and deliver value all while making sure you aren’t pushing bugs or spaghetti. Ather Qureshi
All code is reviewed by at least 2 engineers, and if it’s a multi-domain touching contribution, we reach out to engineers from the affected domains. This is not just for gatekeeping, but so we can get good feedback and improve our products.
In summary, I build confidence through good planning and collaboration with the team. Specific things too, I find TDD helps me alot when I’m tackling complicated behaviors. You write tests for what you want to implement, and then you can take an iterative approach to cover everything. Also, learning more about the tools I’m using helps a lot. Building a good mental model of it allows me to peek under the hood and find problems faster. A lot of the times you can use libraries which cover you from any complexity of the underlying tool, but I found understanding more than the API of said library, gave me insight why my behaviours weren’t working as expected. An example of this is if you learn how to query relational databases with SQL, it becomes a lot easier to understand what an ORM is doing or more importantly, why it’s not doing what you expect.
My best advice is to not lose your appetite for learning new things and constantly try to improve that skill. The skill of learning to learn. It’s imperative in a professional environment where you have to learn things fast, and deliver value all while making sure you aren’t pushing bugs or spaghetti. Take courses on challenging things you want to learn. Do your best to absorb the material and look deeper. You have nothing to lose from getting good marks, so I suggest trying to attain the highest marks you can get. This discipline will help you in the workplace.
I suggest that you take a course or build a small project and see if you enjoy it. If you don’t, choose a different career.
These are questions to ask yourself as well:
Do you like writing logic and optimizing it?
Do you like assembling the various pieces together and seeing it come together?
Do you like building UIs?
What I mean by that is to make sure you find something fun about SWE before diving into the field. You need to enjoy at least some part of it. Through pure randomness, you might have natural skills for this type of work but I argue that it’s not enough to take you through obstacles. I believe you need something intrinsic which will drive your relentlessness through these obstacles.
SWE is difficult, detail-oriented, and puzzling work but if you enjoy the process and what you’re building, you can hold onto it until it gets slightly easier. If you are just clinging to SWE because you dream of the lifestyle of high compensation and flexibility, your motivation will likely get crushed at the first couple obstacles. You need a lot of patience!
We are actively hiring, feel free to reach out for more information via this link.
Some people call it a newsletter - I call it a good time. I write about tech careers and how you can get ahead in yours. It’s my best content (like this case study) delivered to you once a week.
