From Coffee to Code: a year in life of a junior software engineer at Inato
Bonjour š I am Brian, and Iāve been working as a Product Engineer at Inato since July 2022 when I landed my first job ever in the tech industry! This followed a bold career switch that began in the summer of 2019, after 12 years in the specialty coffee industry.
The switch to software engineering came naturally to me: growing up in the 90s, my father worked as a programmer for an aerospace engine manufacturer. This meant that I started interacting with computers from a very young age, which was not so common for my generation. (yes, I am a pre-internet human š« )
By the age of 10, I could write a bit of code. However, I suffered from the typical bias view on programming: since I wasnāt very good at math in middle and high school, I was convinced it was not meant for me. Instead, it became a great interest that I pursued on the side.
Fast forward to 2007, when I landed in Toronto, Canada. I stepped into the first decent coffee shop of my life. Coming from Paris and its culture of CafƩs, the place, but not much the product, I could not imagine that the culture of Coffee was radically different in other parts of the world. People spoke of varietals, processes, ratios, recipes, brewing methods, and so on, just like French people would talk about wine, cƩpages, or vintages. I felt like I had fallen into a rabbit hole and spent the following years learning about coffee.
It took me around the world, from Taipei, Taiwan š¹š¼ to San Miguel, El Salvador šøš»
It connected me with so many people and provided me with a career. I became a barista, then a trainer, consultant, coffee roaster, an entrepreneur.
When I felt that I had explored everything I could in my scope of the value chain, I felt I needed to start exploring other paths to pursue a bigger and more positive outcome from my work.
The Journey kickoff: The Upskilling and Challenges
September 2019, I joined Ćcole 42, after spending approximately 400 hours on campus the month before, during the Piscine, a hard-core selecting process consisting of coding various challenges among 600 other aspiring candidates.
The curriculum itself at 42 is very system-oriented: learning C language from scratch, understanding OS memory handling, and all the way to the CPU doing some assembly. I found that it lays the foundation for my understanding of how computers work, even after playing around with them for many years.
Six months later, COVID hit. It allowed me to start experiencing remote life and focus deeply on my projects for the school, complete as many projects as I could while staying pragmatic when picking each subject.
I left 42 very idealistic, probably a bit naive too, with big knowledge and skill disparities. To level up on something that could get me a job, I took an opportunity to join the Ironhack bootcamp: a 12-weeks intense deep dive into web development focused on actionable and pragmatic skills. (Which is quite an investment for someone without financial support from government or pension system, to whom I would recommend the free alternative that is The Odin Project)
The Journey: Finding the First Position
After Ironhack, I was finally ready to start sending out CVs, feeling more legitimate to do so, even if I was still sweating thinking about technical assessments and interviewsā¦
In the challenging post-COVID job market, where companies prefer interns or experienced software engineers, finding my first job after a career switch was tough. The application process is highly competitive, with many applications leading to few interviews and even fewer job offers.
To increase my chances, I optimised my job search. I limited application time to 15 minutes for most positions and 30 minutes for select companies I was particularly interested in. The extra time was spent researching the company, its key peopleās names, a bit of extra personalising of the cover letters, and understanding their values and team dynamics.
I learned it is inefficient to spend over 30 minutes on initial applications, especially since many companies have vague definitions of ājuniorā positions which end up not fitting an actual first position seeker.
It is good to be aware of this early on, because not taking this into account cost time and effort, not to mention some dents in oneās motivation after the first few rejections.
To streamline this process, I automated as much as possible: sending emails, scraping websites, generating PDFs for application documents, and tracking applications and follow-ups with tools like Notion. In a sense, it takes a bit of software engineering to become one!
This section would deserve its own article, given all of its challenges and learnings, but after exactly 2 months of searching and about 3 cycles of applications reaching āalmostā the last stage with a few companies, I met with Inato ās team.
Inato is on a mission to create a world where all patients can access the right clinical trial for them in their community, making medical research more accessible, inclusive and efficient. Its current solution takes the form of a marketplace to link hospitals to trials.
The Transition: First Year in Tech
Now, having been in tech for over a year at Inato, going from complete junior to hopefully soon the first step of mid-level, I can look back at this time and share a few things that one might consider when going through the same crucial first year.
Use the power of starting fresh
Being a junior means you come in with zero preconceptions about most technical questions. You might have heard along the way that X stack sucks and Y is the way to go, that no one should do Z (rarely why though), and so onā¦ But mostly, you work on a shiny new canvas, and you should leverage this. Transparent companies will also tell you they see hiring juniors as a great opportunity for this very reason: you are trainable to a way of doing things that have already been decided internally before you joined.
If you have picked a company you trust, based on the successful business position it is in, or on its tech branding that makes you feel you are in good hands, then it means they know what they are doing, and you are about to benefit from this as much as the company does by growing good professional foundations. You might not learn the theory of the best practices: instead, you will learn things that are currently working in the real world, making this company and/or team successful.
Use the power of being the most uninformed about a subject
When in my first daily meeting on day 2, I felt like I had just landed in Taiwan and was addressed in Mandarin Chinese. Of course, this was expected, but I quickly learned not to accept this all the time.
The quality of a team made of mostly senior members can be measured by how accessible they make complex concepts to their junior counterparts. Discussing some abstractions among senior engineers when starting off a new product from the ground up is necessary to quickly build a strong architecture upon which juniors will be able to contribute. But once the product is developed enough for the team to incorporate more diverse members in terms of training and experience, then it is up to the most expert members to make it accessible to others.
So when you are a junior member in a new epic kickoff meeting, and you canāt make sense of something, you have the power to direct the discussion to a more understandable level. Doing this will force other team members to clarify things, and often discover some contradictions in the technical design, some unclear specs, or other issues that would not arise until later, or at all until they are an issue in 2 or 3 epics from now.
As a junior, you bring this balance to the team, with an outsider and fresh look at things. When feeling overwhelmed by the technical complexity, I defaulted to considering the issue was that I was not expert enough.
Talking about this to our CTO Bastien, during a gemba walk, he made it clear that when the complexity does not translate into readable code, I should instead default to considering it as an implementation failure: the team was not able to translate the specifications into code that reads clearly enough for any team member to understand it.
Use the power of being senior in your previous field
When going through retraining, you are not exactly a junior in every aspect of it: chances are you already had a first professional life, and many soft skills are transferable. In my case, I feel like the biggest skill I leveraged was being comfortable interacting with diverse teams and being very user oriented (or customer oriented, as I would have say in my previous career). Be it internal or external users. So I could easily take some responsibilities around operational questions which involved our engineering, product, and customer success teams. I created a role for myself to coordinate and reduce friction around setting up new clinical trials on our marketplace.
This was the perfect project for me to deepen my understanding of the key feature of our product, a part of the codebase with a lot of complexity (and legacy), and the most business-critical.
Inato encouraged my venture into that role because the value was clear, we could reduce the time spent by engineers on operational tasks by: rethinking parts of some processes, leveraging clean code, using automations in some internal tools (GitHub, Notion, Slackā¦).
So by leveraging soft skills I had from before, I could explore new technical skills, and made the company more efficient.
Use the power of learning from your job: optimize for learning (from The Effective Engineer by Edmond Lau)
It is true for all levels of software engineering, but probably even more for juniors in their first job.
It means that from picking the company you want to work for, until deciding to leave it for another step in your career, and every decision in between as simple as your daily to-do, should be affected by this strong bias: you need to learn something out of it. When faced with the decision to work on two different tasks, and as time is a finite resource it means this decision will be a daily occurrence: pick the task on which you have the higher learning potential, and only after, factor in the impact of this task in terms of value it brings to you, your team, your product, your company. I believe this specific rule goes for junior engineers who just started contributing to their team: a task with high learning potential and average impact will still be more valuable than a task with an average learning potential and a higher impact.
Happy to Have Made the Switch: the Values I Met
So after going through this journey, I can proudly say I made the right decision. It took me a bit of time to find this position, but I genuinely feel like I could simply not have hoped for a better alignment with a company and a team.
Inato was ready to onboard juniors, and we have since then onboarded a couple more, with all the trade-offs it requires.
I feel like I work on a product that makes sense to society by helping clinical trials become more accessible to diverse populations and various hospitals across the world.
In my day-to-day, I feel free to improve anything, to provide feedback to anyone so the company succeeds.
I work in a team that is caring and helps me and others become successful engineers. My working conditions could not fit me better: I get to be remote full time if I wish to ( I am writing these lines sitting at Kiosk, my favorite coffee shop in Taipei, Taiwan, where I am staying for a few weeks), yet I have a welcoming and great-looking office to go to when I want to in Paris.
My next steps are around continuing to improve technically as I intend to stay an individual contributor for a while to build up expertise. Given my career switch, I can already foresee possibilities to turn into management roles in a few years given some strong soft skills foundation I built before Inato. Given the path Inato is on, I have no doubt plenty of opportunities will be available when I will need to meet them, as the company is growing fast and has some very strong ambitions in its market.
In the meantime, I keep sipping great coffees while writing the best lines of code I can. ā
