Hey! I'm 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 daring 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. By the age of 10, I could write a bit of code. However, since I wasn't very good at math in middle and high school, I suffered from the bias that programming wasn't a career for me to excel in. 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 couldn't 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, a roaster, an entrepreneur.
When I felt that I had explored everything I could in my scope of the value chain, and when confronted with various issues produced by the coffee industry in general, from social to environmental impact, I felt I needed to start exploring other paths to pursue a bigger and more positive outcome from my work.
In September 2019, I joined École 42, after spending approximately 400 hours on campus the month before, during the Piscine, coding various challenges among 600 other aspiring candidates for the school selection.
It was one of the most intense and rewarding months of my life, with firsthand experience of collective intelligence at work. Getting into the school felt like entering some sort of cult, a cult of code quality. During selection, we were told every day that a program working 99% is a failing program. I found the same search for excellence I had experienced in my coffee career: aiming for the best only and finding no compromise.
The curriculum itself was very system-oriented: learning C language from scratch, understanding OS memory handling, and going down to the assembly code level. I found that it laid 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.
I left 42 very idealistic, 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-week intense deep dive into web development focused on actionable and pragmatic skills.
Once done, 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…
This part would deserve a full article. Searching for your first job after a career switch, in the post-COVID recovery context, where companies would go for cheap internship labor or safe senior software engineer investments, was not an easy task.
It's a numbers game: the funnel is quite narrow from the number of applications to the number of final interviews, and ultimately to some offers. So to maximize my chances, I decided to streamline my research process: applying to a position should not take more than 15 minutes for most cases; and a maximum of 30 minutes for more specific positions, or applications in companies I really wanted to get into for various reasons.
This extra time was dedicated to investigating the company’s values more deeply, crafting a much more specific cover letter or introductory email, finding key people’s names in the company, taking time to read what the company showcased on their website, blogs, etc.…
Spending more than 30 minutes on the initial approach is a waste of time because of a single key piece of information that is almost never clearly stated, and even sometimes not deeply thought about by some companies themselves: is the team actually ready to onboard a junior member right now, and what is the definition of a junior for the team/the HR at this company?
You would be surprised by the number of companies with open positions for junior developers, only to figure out along the process their definition of junior is actually mid-level, or junior with 2 years of experience, or exclusively with a first experience.
You need to be aware of this early on in your research process because it will cost you time and effort, not to mention some dents in your motivation after the first few rejections.
So automate every single thing you can: you are a (soon to be officially) software engineer, so use every skill it takes to be one. Automate email sending, scrape websites, generate beautiful PDFs for your application documents with a single click or a single CLI command, use Notion databases or other tools to keep track of applications and each stage they are in, automate notifications for when you need to get back to someone, etc.…
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.
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.
Being a junior means you come in with zero preconceptions about most technical things. 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.
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. A mostly senior team's quality can be measured by how accessible they make complex concepts to their junior counterparts. Discussing complex 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 build. But once the product is developed enough so the team can incorporate more diverse members in terms of training and experience, then it is on 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 naive look at things. When feeling overwhelmed by the technical complexity, I defaulted to considering the issue was me not being expert enough.
Talking about this to Bastien, our CTO, during a gamba session, he made it clear that when the complexity does not translate into readable code, I should instead default to considering it an implementation failure: the team was not able to make it so the code reads clearly enough for any team member to deduce the specs from reading the code or the tests.
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 (or customer, I would say in my previous career) oriented. 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, and Slack).
So by leveraging soft skills I had from before, I could improve my new technical skills, and made the company more efficient.
Use the power of learning from tasks you work on: 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 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, 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 it is specific for junior engineers: 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.
So after going through this, 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 couldn't 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 required.
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 couldn't 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 I have already built some strong soft skills foundation before Inato. Given the path Inato is on, I have no doubt plenty of opportunities will be available when I need to meet them, as the company is growing fast and has very strong ambitions in its market.
In the meantime, I keep sipping great coffees while writing the best lines of code I can.
[ASIDE] ## The Craftsmanship Bridge: From Coffee to Code
In my previous work in the coffee industry, I ensured that the coffee beans were of the highest quality, roasted to perfection, and brewed perfectly. As a software engineer, I am now responsible for ensuring that the code I write is of the highest quality, with clean and efficient code that runs smoothly. Although these two roles may seem vastly different, they both require a love for crafting quality products.
In both professions, creativity is a valuable asset. In the coffee industry, I might have created new blends or experimented with different brewing methods to come up with a unique and delicious cup of coffee. Similarly, as a software engineer, creativity is required when designing algorithms, solving problems, and developing new software applications.
Another key similarity between the two roles is the need for precision. In the coffee industry, even the slightest mistake in measuring the coffee beans or water could lead to a subpar cup of coffee. As a software engineer, even the slightest mistake in my code could lead to bugs or errors that could cause the software to malfunction. Therefore, a high level of precision is required in both professions.
Attention to detail is also crucial in both roles. In the coffee industry, I needed to pay attention to the roast level, grind size, water temperature, and brew time to ensure that the coffee tasted just right. Similarly, in software engineering, I need to pay attention to every line of code, ensuring that it is correct and optimized for performance.
Overall, while my roles in the coffee industry and as a software engineer may seem vastly different, there are many parallels between the two. Both require a love for crafting quality products, creativity, precision, and attention to detail.
In the coffee industry, I worked in a high-value chain: depending on producers and importers to work on amazing raw products, and as a roaster, I would add the most value I could to the product through craftsmanship so it could be used and served in coffee shops by other hands. Similarly, as a software engineer, I collaborate with other engineers, the product team, designers, and internal users to develop new features and improve existing ones. This interdependence is key in delivering a great product to end users.