Becoming a software engineer after a career change

Every week, we publish an internal newsletter for engineers: the gazette. It contains various news, and also a portrait of an engineer. It’s a great way to get to know each other, as our team is growing.

Earlier, we’ve published the portraits of three other engineers on fire! Today we are interviewing Anne-Claire.

Where are you coming from Anne-Claire? Could you briefly explain what was your role in your previous position?

Back in business school I knew I wanted to acquire more technical skills. I taught myself how to code during lockdown — it was all very rudimentary. It wasn’t until I started a personal project that I really got into it.

At that time, I needed to pass a certification, but was struggling to find an available exam date. To solve this problem, I crafted a bot that could log in to the platform, scan every minute for an open spot, and book it for me. When I came up with a stable version, I commercialized it for about a year.

In parallel, I got into Data analytics (a fancy term for “playing with spreadsheets”), and got a first position as a Consultant at Ernst and Young. I would juggle the 2 projects, which was both exhausting and exhilarating! At Ernst and Young, we would work with banks and insurers. We had various projects, such as helping them design their data model, or build reporting solutions.

Most of these tasks were quite repetitive, but I was given a lot of freedom in how to execute them. So I started crafting basic Python scripts to automate them. Soon, it became an added value –in a field where no one is really expected to code. I realized that I would love it as a full-time job. Hence, I engaged in a reconversion into software engineering and joined Alan.

What were you worried about when you applied?

Many things! As someone with no formal training on Computer Science, I was concerned that it would take me too long to ramp up before actually becoming productive.

Since I had never coded in Javascript, yet at Alan we’re all full stack, I was also wondering how challenging it would be to learn a new language. But on this part, I was mostly excited to get a chance to do full stack development.

On another note, I was intrigued by Alan’s culture. I’ve had echoes of a company with a strong work ethic. Having myself been used to similar work environments in more traditional companies, I was wary of the potential side effects of such a culture. I know that I have a tendency myself to take pride in working long hours, in order to complete a task.

I shared this concern with one of my interviewers. Their impression was that at Alan, we do value work, but there is no pressure coming from peers. It’s up to anyone to decide how much time they want to invest in their tasks. However, being surrounded by so many brilliant people can make you want to run faster in order to keep up.

How did you address those?

Despite a lack of experience, I gained confidence through the recruitment process. The architecture interviews in particular, gave me a good idea of what the day-to-day tasks would look like at Alan –with some level of support. It was motivating to see that, even without proper full-stack experience, you can still have some instinct on how to design a user-facing feature, and work out a solution.

During my first months at Alan, I required some close pairing to ramp up on the basics. At first, it could feel overwhelming to start from scratch on so many topics! Git basics, OOP… But eventually, it all started to come together into a routine. Choosing my battles also helped –for instance, front-end is still not my strong point. But focusing on a scope and building an expertise on it, allowed me to feel more at ease.

This is one benefit from the distributive ownership at Alan: you naturally end up owning a scope (ex: a product segment like onboarding a company), and becoming a referent for it.

What did you expect during your onboarding?

Given my context of reconversion, I knew I would spend a lot of time catching up on basics, reading documentations and practicing. But I was hoping for some kind of mentoring structure: well defined tasks, alongside pair sessions with more senior Alaners.

When you onboard at Alan, you get paired with:

• a Coach, a more senior Alaner who mentors you,
• a Role Buddy, another engineer who helps you get on track and introduces you to Alan's culture.

I was very lucky with my setup: my coach and role buddy naturally offered pair sessions, and shared their knowledge when I needed it.
Joining my current crew was also a great enabler: before I arrived, our crew lead did a great job at scoping my tasks, with a backup ownership system that allowed me to quickly grow autonomous. Until today, where it has been over 1 year now that I’m part of the crew.

Conclusion

There are several ways to shift your career into software engineering.

To acquire the fundamentals, the most important is to find a way to practice regularly.
On my side, developing a side project played a key role. I also tried to incorporate programming into my previous job –which is, of course, easier in some jobs than others.
Some of my colleagues have also attended bootcamps, which have the significant advantage of providing a structured training program, and sometimes even an apprenticeship.
Then of course, it comes down to finding a company that is willing to hire based on potential.

When we’re undertaking a career change, we tend to think that getting the job is the hardest part.
Still, it is equally important to ensure that the work environment offers the right setting for you to ramp up.
This means finding a team with the appetite and resources to support your development, and for you to grow autonomous. I have felt lucky to find it here at Alan.