If you’re here, it means you’re probably curious about Elixir, that dynamic, functional language that’s great for building scalable and maintainable applications.

Whether you’re just getting started or looking to dive deeper, this learning path we’ve created at Welcome to the Jungle will hopefully help you along the way, especially if you’re interested in exploring awesome frameworks like Phoenix and Ecto.

Think of this as a roadmap to Elixir, not a strict course. It’s packed with tips and resources for key concepts that we think are important. Feel free to go at your own pace and explore what interests you most!

What you’ll learn

We start by getting you comfortable with Elixir’s syntax and the basics of functional programming. From there, we jump into Phoenix, which is perfect for building web applications, and Ecto, your go-to tool for managing databases. By the end, you’ll have the confidence to start building and deploying your own Elixir projects.

What to expect

This learning path is like a friendly tour through Elixir’s core ideas, with lots of resources and tips along the way. We’ve organized information into three levels, starting with the easiest and progressing to the hardest. We cover the key areas you should focus on, but remember, this is just one path — feel free to adapt it and follow the learning journey that resonates best with you.

Diagrams and resources

You’ll find some diagrams along the way to help you visualize the concepts at each stage. The resources we suggest are pretty flexible and can apply to multiple parts of your learning journey, so don’t worry if they don’t always line up exactly with the diagrams.

Concept levels

We’ve grouped concepts into different levels based on how tricky they are, but don’t let that stop you from exploring them earlier if you’re up for it. For example, abstract syntax trees (ASTs) are a big part of Elixir, but we’ve put them in level 3 because they’re a bit more complex. Just dive in whenever you’re ready!

How to contribute

We’d love your help to make this learning path even better! If you think we’ve missed something, have awesome resources to share, ideas to suggest, or updates to the diagrams, please go ahead and open a pull request on our repository. We’re all on this learning journey together!

What is Elixir?

Before we set out on our learning path, let’s take a look at the Elixir ecosystem as a whole.

The Elixir ecosystem

Elixir is a functional and concurrent programming language that runs on the Erlang virtual machine. It’s known for being super-reliable, which makes it perfect for building scalable applications. If you’re curious about what Elixir is all about, here are some great resources to get you started:

• Behind the Code: The one who created Elixir: An insightful video interview with José Valim, the brains behind Elixir.
• Elixir’s official website: Your go-to for everything Elixir.
• Introduction to Elixir by Gints Dreimanis: A great intro to Elixir that quickly covers the basics.
• Elixir in 100 seconds: A super-quick introduction to what Elixir is all about.
• Elixir: The Documentary by Honeypot: A behind-the-scenes look at how Elixir was created and how it evolved.

Functional programming

Elixir is a functional programming language that focuses on immutability and first-class functions. Getting a handle on these concepts is key — the below links will help:

• Functional Programming 101 by Cassidy Williams: A great starting point for understanding functional programming.
• What is functional programming | Easy way by Hitesh Choudhary: Check out this video for an easy-to-understand introduction to functional programming.
• Grokking Simplicity by Eric Normand: A book that breaks down functional programming into easy-to-grasp ideas, showing you how to simplify your code and make it more manageable in real-world projects.

Why choose Elixir?

So, why pick Elixir? Well, it has a lively community, a strong ecosystem, and loads of advantages. For a deeper look, check out The Soul of Erlang and Elixir by Saša Jurić.

Global learning and tech watch resources

• Official Elixir documentation: Your go-to resource for everything you need to know about Elixir’s features and functions.
• Programming Elixir 1.6 by Dave Thomas: A practical book that takes you through Elixir programming with clear examples and exercises.
• Elixir in Action by Saša Jurić: A hands-on guide that takes you through building real-world applications with Elixir.
• Elixir School: A fantastic free resource to help you learn Elixir.
• Exercism’s Elixir track: A site with puzzles and exercises to help you practice every Elixir concept. Its syllabus is great!
• Alchemist Camp: A structured, hands-on approach to learning Elixir, with engaging video tutorials and real-world projects.
• Joy of Elixir: A beginner-friendly online book that makes learning Elixir fun and approachable, using simple language, humor, and interactive examples.
• Elixir Newbie: Learn Elixir with a friendly and approachable tone. There is also a podcast available.
• 10 tips for new Elixir developers by Chris Gregori: Some valuable advice if you’re just starting out with Elixir.
• CodeCast’s Intro to Elixir: A hands-on, video-driven introduction to Elixir, focusing on practical coding exercises and real-time feedback.
• An Animated Introduction to Elixir by Mark Mahoney: A visually engaging and easy-to-follow introduction to Elixir.
• Thinking Elixir podcast: A podcast that dives deep into Elixir’s ecosystem, featuring expert interviews, real-world examples, and practical advice.
• Awesome Elixir: A curated list of useful Elixir resources and tools, including libraries, frameworks, tutorials, and best practices.
• ElixirConf’s YouTube channel: Videos from ElixirConf, featuring talks from the community.
• Welcome to the Jungle Tech Medium page: A range of in-depth articles that cover practical Elixir tutorials, case studies, and handy tips.
• AppSignal’s blog: Posts and tips on Elixir performance and best practices.
• ElixirWeekly: A curated newsletter that delivers the latest news, articles, and updates from the Elixir programming community.
• ElixirStatus: Post your new project, blog post, or version update there.

Elixir cheat sheet

Keep this Elixir cheat sheet handy for quick reference when you need it.

Our Elixir learning path

Level 1: Elixir core concepts

Objective: Get a strong grip on Elixir’s syntax and functional programming basics.

Installing Elixir and running the IEx console

The asdf version manager

• asdf: A versatile CLI tool that lets you manage multiple Elixir versions (along with other language runtimes) on a per-project basis.
• Installing Elixir and Erlang with ASDF: A simple guide to setting up Elixir and Erlang using asdf.

IEx and compilation

• Elixir interactive mode: The interactive mode allows you to execute code snippets, test functions, and experiment with expressions in real time.
• IEx Helpers by Elixir School: Handy tips and tricks for using IEx.- How does Elixir compile/execute code? by Xavier Noria: An explanation of how Elixir compiles and runs your code.

Elixir style guides

• Naming Conventions: The official guide to naming things in Elixir.
• The Elixir Style Guide: A great GitHub resource with tips on writing clean and idiomatic Elixir code.

Basics

Basic types and operators

• Basic types: An overview of the fundamental data types in Elixir.
• Basic operators: A rundown of the essential operators you’ll use in Elixir.
• Basic Data Types by Elixir School: A friendly guide to understanding Elixir’s core data types and how to use them.

Immutability

• Understanding Elixir’s Immutability and Data Structures by lago: An article about immutability and data structures, explaining how they work and why they’re essential for writing reliable and efficient code Elixir.

Strings and binaries

• Binaries, strings, and charlists: A quick dive into how Elixir handles different types of text and binary data.

Collections

Lists, tuples, maps, keywords

• Collections by Elixir School: An easy-to-follow guide to Elixir’s different collection types and how to use them effectively.

List comprehension

• Comprehensions: A friendly intro to using list comprehensions in Elixir for cleaner and more efficient data handling.

Enum modules

• Enum by Elixir School: A helpful guide to using the Enum module in Elixir for working with collections.
• Enumerables and Streams: A simple overview of Elixir’s tools for handling data with enumerables and streams.

Pattern matching

• Pattern matching: A guide to mastering pattern matching in Elixir.
• Pattern Matching by Elixir School: A great resource to get you up to speed with pattern matching basics and best practices.

Modules and functions

• Modules and functions: Explore how Elixir uses modules and functions to keep your code organized and reusable.
• Composition by Elixir School: A great guide to composing functions in Elixir, taking you through how to build up complex behavior from simpler pieces.

Functions (and anonymous functions)

• Functions by Elixir School: A friendly rundown on how to create and use functions in Elixir, including those handy anonymous functions.

> Default function argument

• Default arguments — Find out how to use default arguments in your functions to keep things tidy and flexible.
• Default Arguments by Elixir School: Helpful information about how default arguments work in Elixir.

> Functions and pattern matching

• Functions and Pattern Matching by Elixir School: How to blend functions with pattern matching for even more powerful Elixir code.

Structs

• Structs: Learn how to use structs to manage and organize complex data in Elixir.

Guard conditions

• Guards: Get the scoop on guard clauses and how they add extra conditions to your pattern matching.

Control structures

• Case, cond, and if: A guide to Elixir’s control structures for making decisions in your code.
• Control Structures by Elixir School: A simple overview of Elixir’s control structures.

IO and files

• IO and the file system: Learn how to handle input and output, including when working with files in Elixir.

Debugging

• Three Ways to Debug Code in Elixir by Pulkit Goyal: Check out these practical tips for debugging your Elixir code like a pro.

Level 2: Phoenix, Ecto, and OTP basics

Objective: Mix your Elixir skills with web development and database management for a complete setup.

The Mix build tool

• Mix by Elixir School: A guide to using Mix for managing projects and tasks.
• Introduction to Mix: A quick intro to Mix and how it helps you with Elixir projects.

Errors and exceptions

• try, catch, and rescue: Learn how to handle errors and exceptions in Elixir with these handy techniques.
• Error Handling by Elixir School: A guide to managing errors and exceptions to keep your Elixir code running smoothly.

Testing your code

• ExUnit: Get to know ExUnit, Elixir’s testing framework, for writing and running tests.
• Introduction to Testing Elixir Applications with ExUnit by Cody Boggs: A great introduction to testing your Elixir applications with ExUnit.
• Testing by Elixir School: A helpful guide to writing tests in Elixir to ensure your code is reliable.
• Testing Elixir by Andrea Leopardi and Jeffrey Matthias: A comprehensive look at testing techniques to ensure your Elixir code is reliable and bug-free.
• Property-Based Testing with PropEr, Erlang, and Elixir by Fred Hebert: An excellent book that helps you master property-based testing in Erlang and Elixir.

Configuration and releases

• Configuration and releases: Learn how to configure your Elixir applications and handle releases for deployment.

Erlang with Elixir

• Erlang Interoperability by Elixir School: Discover how Elixir and Erlang work together and how to use Erlang libraries in your Elixir projects.

OTP basics

• Intro to OTP with Elixir by Jesse J. Anderson: A video to understand OTP and its role in Elixir.
• A Brief Guide to OTP in Elixir by Gints Dreimanis: A quick overview of OTP and how it enhances your Elixir applications.
• Designing Elixir Systems with OTP by James Edward Gray, II and Bruce A. Tate: Explore advanced concepts and best practices for designing robust Elixir systems with OTP.

The Phoenix web framework

• Phoenix’s official repository: The go-to for all things Phoenix, including source code, issues, and updates.
• Phoenix documentation: Everything you need to know about Phoenix, straight from the official docs.
• Exploring Elixir and Phoenix: A Comprehensive Overview for Beginners by FullStack Labs: A friendly guide to understanding how a Phoenix app is structured and how everything fits together.
• Contexts: Learn about Phoenix contexts and how they help organize your application’s business logic.
• Creating a Chat App by ElixirBridge: A hands-on tutorial on building a chat application using Phoenix.
• Phoenix a Web Framework for the New Web by José Valim: A video overview of why Phoenix is a great choice for modern web development and what makes it special.
• Phoenix in Action by Geoffrey Lessel: Dive into Phoenix and learn how to build powerful web applications with this practical guide.
• Real-Time Phoenix: Build Highly Scalable Systems With Channels by Stephen Bussey: An introduction to building scalable, real-time web applications with the Phoenix framework, showing you how to leverage channels and other features for dynamic, interactive systems
• Programming Phoenix 1.4 by Chris McCord, Bruce Tate, and José Valim: A detailed resource for mastering Phoenix and creating high-performance web applications.
• Programming Phoenix LiveView by Bruce A. Tate and Sophie DeBenedetto: A practical book that shows you how to build interactive, real-time web applications with Phoenix LiveView, allowing you to create dynamic user interfaces with minimal JavaScript.

The Ecto database library

• Ecto’s official repository: The central hub for Ecto’s source code, issues, and updates.
• Ecto documentation: Everything you need to know about using Ecto for database interactions.
• Ecto: An Introduction to Elixir’s Database Toolkit by Gints Dreimanis: A guide to getting started with Ecto.
• Lessons: Ecto by Elixir School: A helpful set of lessons on how to use Ecto for database operations and queries.
• A brief guide to Ecto.Multi by Elixir School: A quick overview of how to use Ecto.Multi for running multiple database operations in a single transaction.
• Ecto.Multi: The official documentation for Ecto.Multi, showing how to manage complex database transactions.
• Dynamic queries: Learn how to build and manage dynamic queries with Ecto to make your data operations more flexible.
• Programming Ecto by Darin Wilson and Eric Meadows-Jönsson: A guide that dives into using Ecto for managing your database in Elixir.

Level 3: Advanced topics (OTP, Metaprogramming, security)

Objective: Get the hang of advanced features and tools to build super-fast and efficient applications.

Processes (spawning, links, tasks, etc.)

• Processes: A deep dive into how Elixir’s processes work, offering insights and practical tips for using them effectively.
• Understanding Processes for Elixir Developers by Carlo Gilmar: A guide to grasping how Elixir handles processes, making your concurrency tasks easier.
• Elixir, A Little Beyond the Basics — Part 6: processes by Karl Seguin: Explore Elixir processes with this article that goes a bit deeper into how they work and why they’re important.
• Elixir processes, or Biology-inspired software development by Pedro Assunção: Watch how Elixir’s approach to processes is inspired by biological systems and what that means for your code.

Supervisors

• Supervision trees and applications: An overview of how supervisors and applications work together to manage processes in Elixir.
• OTP Supervisors by Elixir School: A friendly guide to using OTP supervisors for building resilient and fault-tolerant Elixir applications.
• Using Supervisors to Organize Your Elixir Application by Ilya Averyanov: Discover how to use supervisors to keep your Elixir app organized and running smoothly.
• Elixir, A Little Beyond the Basics — Part 7: supervisors by Karl Seguin: Dive deeper into Elixir supervisors with this detailed guide.

The abstract syntax tree (AST)

• A deep dive into the Elixir AST by Lucas San Román: A thorough look at the AST and how it works under the hood.
• The Elixir AST explained using the AST Ninja by Arjan Scherpenisse: A fun and detailed explanation of Elixir’s AST to help you understand how code is structured and processed.

Advanced testing

• Mocks and explicit contracts by José Valim: Learn about advanced testing techniques in Elixir, including how to use mocks and how to define explicit contracts for your functions.

Security

• Elixir Secure Coding Training (ESCT): Handy tools and tips to keep your Elixir code secure and protected from vulnerabilities.

Other resources

For deeper learning about related topics, consider these reads:

• Metaprogramming Elixir by Chris McCord: Unlock the power of metaprogramming in Elixir and learn how to write more flexible and dynamic code.
• Craft GraphQL APIs in Elixir with Absinthe by Bruce Williams and Ben Wilson: An easy-to-follow book that shows you how to build awesome GraphQL APIs in Elixir using Absinthe, packed with hands-on examples and tips.
• Concurrent Data Processing in Elixir: Fast, Resilient Applications with Otp, Genstage, Flow, and Broadway by Svilen Gospodinov: Master concurrent data processing in Elixir with this book, which shows you how to efficiently handle and process data in a scalable way using practical examples.

Communities

Join Elixir forums and communities to stay connected and learn from others:

• Elixir Forum
• Elixir Community Slack
• Elixir Community Discord
• Elixir Programming LinkedIn group

Engage with the community to grow your Elixir skills!

Apply without fear!

At Welcome to the Jungle, we’re hiring backend developers who are passionate and curious, regardless of their current tech stack or degree. If you are hired, we will train you on Elixir! We want to ensure that our employees are well-equipped with the skills and knowledge necessary to succeed. That’s why we offer a comprehensive training program to all new backend engineers hires, so they can hit the ground running.

Ready to jump in? Apply now!

Written by Anne-Laure Civeyrac, Tech editor, based on the learning path developed by backend developers.

Illustration by WTTJ

Join our team!

Getting started with Elixir: A comprehensive learning path was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Full-stack developers are sometimes looked down upon in the tech industry. Other developers will tell you that by attempting to be experts in everything, they become experts in nothing. But like a general practitioner in medicine, full-stack developers are useful to a tech team in more ways than you realize.

At Welcome to the Jungle (WTTJ) and Otta — the job-search platform acquired by WTTJ in January 2024 — we couldn’t conceive of working without full-stack developers. Currently, we have six of them on our teams, along with back-end and front-end developers.

“Full-stack developer” is a title that is constantly changing and evolving. At WTTJ it describes someone that is fluent in both Elixir and React. They work on all parts of a given project, including the back-end, the front-end, and the integration between the two. At Otta, the flavor of full-stack is particularly rich as the scope of responsibility includes regular programming tasks as well as DevOps and data. A dedicated team handles these two aspects at WTTJ.

Because we believe full-stack developers are key to a tech team’s performance, we wanted to share the reasons we can’t live without them.

Your delivery process will be more efficient

With full-stack developers, there is no more having to wait for someone to release something to be able to deliver a feature or a bug fix. Which means you don’t end up in this waterfall-like process where you are dependent on someone else to finish what you started.

And if someone is out sick or has had to take some holiday at short notice, any full-stack developer can pick up where they left off. There’s no more, “Oh God, there isn’t anyone in today who knows how to do this,” because the full-stack developers can oversee all of the code when issues arise.

It also means you can more easily change the scope of the thing that you are building on the fly without having to communicate with other people. Which is particularly useful with a fast-paced product like we have at WTTJ and Otta. And if you have any issues, it’s very easy to discuss them with any of the full-stack developers.

Your experts will be able to focus on what they do best

The value of full-stack developers is particularly felt in feature development or bug fixes that require handling at the back and front-ends at the same time. Having them on the team frees up a bit of scope for back-end and front-end developers to work on an area where particular expertise is needed, removing some of the pressure and mental drain for them.

Sometimes tasks involving back and front-end skills can be difficult to assess for developers as they aren’t familiar with the full scope. Instead of it ending up a pass-the-buck kind of situation, full-stack developers can fulfill a need here by taking care of those tasks, which allows the team a certain flexibility and avoids blockages occurring. This is especially true with regard to bugs, where they will be able to explore both ends to understand where the bug is coming from.

At WTTJ, we decided to use API contracts to manage communication between back-end and front-end developers and it’s the responsibility of full-stack developers to handle them so that back-end and front-end developers can focus on their tasks.

You will build a culture of end-to-end responsibility

At Otta, where full-stack developers are not limited to programming alone, there is full accountability and responsibility from top to bottom. It’s part of their job as engineers to take ownership during all the different stages of development: Build, run, and monitoring. And there’s no “Oh, I thought this person was going to do this! It’s not my problem, not my fault” kind of attitude.

Having one person responsible for the end-to-end process also makes it simpler to provide solutions that can benefit other projects because of the global vision acquired. Full-stack developers can impact back-end/front-end communication that’s part of other projects as well.

You will rely on people rather than technologies

As you all know, a big thing with software engineering is that technologies are changing all the time and you do need to be able to pick up things to learn and move. Since full-stack developers don’t have a single focus, they will be more eager to keep you up to date with the latest trends and technologies.

For example, at Otta, having full-stack developers on board meant we didn’t have to hire anyone to work on GPT prompt engineering, which was great as we had a queue of people wanting to try this technology because it’s exciting and innovative. So when changes in the market happen, you can be confident you’ve already got a team together that’s ready to go out and give things a go.

And that can be particularly useful if you use niche technologies like we do at WTTJ and Otta with our back-end language: Elixir. Hiring full-stack developers who have the mindset of continuous learning rather than wanting to focus on a specific technology has made a real difference with how we’ve expanded. As we couldn’t easily hire full-stack developers who had already mastered Elixir, we took on people who weren’t particularly opinionated about a particular language, and instead just saw a language as a tool to get a job done, which has had a positive impact. In the future, we plan to offer training to our back-end and front-end developers who are interested in moving towards full-stack development.

Your front-end and back-end developers will understand each other better

The presence of full-stack developers can greatly benefit both back-end and front-end teams by fostering a deeper understanding of each other’s work. Many full-stack developers possess a genuine curiosity about the entire development process which can enhance collaboration and problem-solving. Their interest lies not only in performing every task themselves but also in comprehending the underlying reasons behind various decisions and implementations.

Sometimes back-end and front-end developers can get frustrated about pushing things that aren’t immediately useful. As a back-end developer, for instance, you don’t get that involved in the design of a page and thus don’t get to feel what the end user will experience.

Keep in mind that, historically, a lot of back-end developers were full-stack (or simply web developers, as we called them back then) at a time when applications were often monoliths. But the excessive increase in front-end languages and frameworks in the past few years has discouraged some of them from keeping up, leading to them returning to the familiar environment of the back-end. Rather than learning more about jQuery successors, for example, they preferred to focus on what they knew best.

You will challenge product managers in new ways

Because they have a broader vision of a project, full-stack developers can better understand a feature, challenge product decisions, and provide product managers with food for thought. It’s not really the full-stack aspect that forces them to develop soft skills like communication, empathy, and persuasion, but because they find themselves having to interact with more people, they end up developing them.

They’re also able to easily produce a proof of concept (POC) to help people to make a quick decision and can more readily see where effort still needs to be made, both on a particular task and a whole feature. In addition to their programming skills, they often acquire knowledge about deployment itself.

OK, I get it! But how to get and keep the greatest full-stack developers now?

Now that we’ve explored the excellent reasons to hire a full-stack developer, it’s time to see how you can make sure you get the most out of them.

Adapt your hiring process

At WTTJ, our entire business logic is back-end oriented. Consequently, it’s important to test our full-stack candidates on the back-end. But it can be the opposite for you if the logic of your application is in the browser, for instance. Anyway, keep in mind that fundamentals on the back-end are often the most difficult to get to grips with. Our belief is that data architecture or building data tables and understanding how to work with SQL, for instance, are fundamentally important and take quite a while to learn.

When recruiting full-stack developers, we focus more on the candidates’ excitement and passion about learning things. From a hiring manager’s perspective we’re always looking for the answer to these questions: “Do you ask good questions and are you willing to try things, be wrong, and learn and keep your ego reined in?” You can always learn things, but you can’t force that excitement and passion about full-stack software engineering.

It can also be interesting to focus the interview on the explanation full-stack developers give for the technical choices they make during their test — they are going to have to make lots of decisions in their role, so understanding how they arrive at them is important. As full-stack developers, they usually have to come up with twice as many solutions as experts.

Make them feel included

Some back-end or front-end developers tend to overlook the input of full-stack developers unintentionally. This can happen because of perceived expertise levels, particularly when developers feel fully in control of their specialized domain and can swiftly address tasks. Consequently, they may not always seek the insights of full-stack developers when making decisions and might more readily question technical choices made by them compared to their peers.

It’s important to recognize that full-stack, back-end, and front-end developers all share the title of software engineer, albeit with differing day-to-day paradigms. Full-stack developers possess a broader range of knowledge, while back-end and front-end developers typically have deeper expertise in their respective domains. However, these differences in expertise shouldn’t exclude any developer from contributing or participating fully in collaborative processes.

Therefore, it’s crucial that all developers, regardless of their specialization, are afforded the same privileges, legitimacy, and opportunities within the team. This includes participation in workshops, chapters, and other collaborative settings where diverse perspectives can enrich discussions and solutions.

Additionally, full-stack developers have to ensure they are explicit about what they can take on and the contribution they can make to the team in general, as well as pinpoint the experts they need to contact if they have any queries. Legitimacy for full-stack developers is not always assumed — they often find themselves needing to explain and justify their actions more frequently compared to some of their colleagues.

That’s all folks!

We hope this article has helped you understand how full-stack developers contribute to tech teams’ efficiency and adaptability. Their ability to navigate both front and back-ends fosters collaboration, innovation, and a deeper understanding within the team. Embracing full-stack development also empowers teams to leverage diverse technologies and methodologies for continued growth. To attract and retain top talent, it’s essential to tailor hiring practices and create an inclusive culture that recognizes the invaluable contributions of full-stack developers.

Written by Anne-Laure Civeyrac, Tech editor, based on interviews with Billy Williams, Emma Ritcey, Irene Gonzalez, Sylvain Colignon and Sébastien Azimi

Illustration by WTTJ

Join our team!

Why every tech team would benefit from hiring a full-stack developer was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the first semester of 2022, the Product team started to experience difficulties integrating new features in our Welcome to the Jungle Solutions B2B product. Indeed, our product architecture no longer met our needs. Several issues were observed: The product architecture was no longer aligned with the brand architecture and the business offering, and new features, like job boost (for increasing the visibility of some jobs), company featured posts (for publishing company-related content), and the profile editor (for updating a company’s profile), did not fit rationally into the navigation menu, affecting their discoverability by users.

So we set up a dedicated team to design a new navigation menu component, using tools like Maze to consult panels of users along the way. Between the first workshops and the component going into production for all users, it took us a whole year. Rather than working on the design immediately, we spent time during this unique exercise validating the navigation architecture first, which was quite a new approach for us.

In this article, we will detail every step we took in designing this new navigation menu component, describing each phase’s validation with users, and share our main takeaways about the whole experience.

Our starting point

If you aren’t familiar with what Welcome to the Jungle (WTTJ) does, we actually make work exciting. We achieve this by building innovative employer branding solutions that make companies attractive to workers and by creating inspiring experiences and content that empower workers and companies to build new rules for more sustainable working practice. Using our WTTJ Solutions product, companies can publish job postings, follow up applications (if they use our internal applicant tracking system, or ATS), and promote their brands.

The old information architecture isolated features in independent environments, presenting them either via top navigation or sidebar navigation. “Switch app”-type dropdown navigation made it possible to navigate from one environment to another, but its main weak point was that it hid these first-level navigation items of the solution by making them only visible when you clicked on the dropdown menu. In addition, the navigation context differed depending on the macro-feature you were viewing.

Applicant tracking system (ATS) — #Top navigation

• Jobs
• Candidates
• Statistics
• Settings
• Career website

Employer brand — #Sidebar navigation

• Analytics
• Featured articles
• Job boost

Homepage and management of organizational settings — #Top navigation

Personal settings — #Top navigation

Step n°1: Organizing open card sorting within the company

Our first step was to set up an open card sorting exercise with the Product team, but we didn’t stop there. We also included Product Marketing and representatives from diverse teams (account managers, sales, tech, customer care, and human resources) to minimize bias as much as possible. We formed small teams to categorize the existing and potential future key features of WTTJ Solutions into groups. The categories were defined by the participants themselves since it was an open card sorting session. A similarity matrix was then used to analyze the results and define which categories should be kept on the menu. Alongside this, competitors’ navigation menus were benchmarked. With the organization of a 6to1 workshop, we also began discussing what the design should look like.

At this stage, the following first-level categories were considered for the new navigation menu:

• My account
• Admin
• Employer brand
• ATS (our internal one)
• Jobs
• Integrations (with external applications)

Step n°2: Conducting open and closed card sorting sessions with users

Using the categories defined in the internal card sorting exercise, a panel of 16 users conducted a closed card sorting exercise using Maze. Features had to be sorted into categories.

The categories we defined internally were also challenged in another open card sorting session with a different panel of 11 users, where they were asked to group features into categories and to name those categories. To make sure each type of user was represented, these participants were selected based on a personas study conducted a few months earlier. Segments were chosen based on business usage (CEO, recruiter, employer branding role, etc.) and various company sizes. By doing this, we made sure that WTTJ ATS users were represented as well as those using an external ATS.

Following both card sorting events, similarity matrices were generated.

This two sessions of card sorting with users resulted in three interesting results:

• Having “ATS” and “Jobs” categories was confusing for users: They didn’t know where to position features during the closed card sorting sessions.
• Users intuitively grouped the features related to job management, applications, job boosts, the candidate pool, and associated parameters in a category called “Recruitment.”
• The analytics were instinctively sorted by users into one global section rather than distributed among different categories.

The first result illustrates how internal company organization can impact on product architectures and cause confusion for users. WTTJ has two dedicated teams — one for ATS and one for jobs — and it had clearly been a mistake to maintain this distinction when working on the navigation menu.

At this point, the following first-level and second-level categories were chosen for the new navigation menu:

Home

Employer brand:

• Showcase editor
• Featured
• Career website

Recruiting:

• Application tracking
• Jobs

Analytics

Integrations

Help

My account/Organization:

• Account settings
• Organizations (switch)
• Organization settings
• Members
• Recruiting settings [shortlink to recruiting section]

Step n°3: Running tree tests on the new architecture

To determine the new architectural information model, we designed a new tree structure. A technical constraint quickly arose: Since the WTTJ ATS architecture and interface could not be changed, its structure needed to be incorporated into our new architecture as it was. In the “Recruiting” category, we ended up with the two second-level categories we had wanted to avoid (because they’re confusing for users): “Jobs” and “ATS.” While this wasn’t the ideal solution, it was a compromise considering the legacy we had to live with.

Afterward, tree tests were conducted with three panels of users: 289 individuals using the WTTJ ATS, 5 individuals using an external ATS, and 6 employer brand managers. Using Maze, we were able to create a simulated navigation from our MVP to test different scenarios. Various actions were presented to users, including publishing a new job posting, boosting a job posting, and reviewing the analytics. To perform these actions, testers had to guess the path in the navigation menu.

Using tree tests, we were able to assess the understanding of the architecture in terms of path and wording. Overall, our architecture scored 6.7 out of 10 in terms of comprehensiveness, which was a pretty good result. We were able to validate our choices, even if some details needed to be adjusted.

Step n°4: User testing on prototypes

We tested our prototypes with users by providing them with main task scenarios on Maze to carry out, such as “consult the latest application for the data analyst position” or “edit the profile editor.” We evaluated the path’s effectiveness based on the success/fail criteria defined previously. This mainly allowed us to remove risk from the handling of this new navigation from a user experience point of view and the implementation of a new job page in parallel with the ATS section.

A score of 72 out of 100 was achieved for the global system usability (SUS score). Overall, it’s a good score for usability performance in terms of effectiveness, efficiency, and ease of use.

The UMUX-LITE (usability metric for user experience) rates were as following:

Rating 5.3/7 (The functionalities of this navigation system meet my requirements)

Rating 5.3/7 (This navigation system is easy to use)

The development began, with some back and forth on QA while simultaneously defining the animations, to transition between the reduced navigation menu and expanded one, and vice versa.

Step n°5: Deploying progressively

To test the new navigation menu component in real life, we chose to deploy it to 5% of our users, which represented approximately 400 individuals. A Typeform survey was proposed so that users could provide feedback. To be completely honest, we didn’t receive a lot of feedback at this stage, but we didn’t receive any big warnings or complaints either.

The component has now been in production since the end of September 2023.

Here is the latest version of our new navigation menu component:

Taking a step back

So what were the main takeaways from our journey?

Our good moves to replicate

Validating the architecture with card sorting and tree tests before designing the experience was definitely a good decision. Information architecture can be overlooked because it does not produce immediately visible results. Our time spent validating it allowed us to proceed with the confidence that we were heading in the right direction and gave us legitimacy when discussing the topic with management.

The process of checking every step with our users is also something we intend to follow in the future. The experience helped us to transcend our biases in a very positive way. Obviously this requires having user panels readily available, which is not always easy to achieve. To be fully transparent, it was hard to convince people to participate without gift certificates.

Communication with other squads was also crucial to the creation of this new component. Providing assistance with the design interface and documentation was required to help other teams integrate the component.

Things to do differently next time

It’s true that the change management for users could have been handled better. The new navigation information was included in a global email (along with other news) that was sent out on the same day the new navigation was put into production. Several users complained that this didn’t provide enough time.

Looking back, the beta (progressive rollout) didn’t have enough users. We know now that we weren’t able to catch enough bugs by involving only 5% of our users. Next time we will definitely engage more people.

During the process, we also lost track of who was using WTTJ Solutions. Recruiters (which make up most of our users) complained that we overemphasized employer branding in the new navigation menu component.

Finally, there was also some frustration about the lack of improvements to the ATS (which we couldn’t make better). This resulted in duplicate views for users of our ATS, which we were not happy about.

Stepping up

Having worked on the navigation menu component, we now intend to redesign the homepage, which is the first-level page users see. Our goal is to make our users’ experience better on this page by providing them with more value. And we definitely want to replicate the user-centric approach in this new task!

Co-written by Pauline Arnaud, Senior product designer @ WTTJ, Emmanuel Rafitosoa, Senior product manager @ WTTJ & Anne-Laure Civeyrac, Tech editor

Illustration by WTTJ

Join our team!

Redesigning navigation with a user-centric approach was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to the Jungle (WTTJ) is an online platform that allows companies to post job offers, showcase their corporate culture through multimedia content, and streamline job searches for candidates by showcasing the human side of companies.

My name is Clément Folliet, and I am the Business Technology Manager at WTTJ (and a former Developer and Engineering Manager). As part of my role, I am responsible for building a team dedicated to automations and internal tools.

Automation involves creating automated workflows that connect different applications and services to perform specific actions in response to predefined triggers to simplify processes and eliminate the need for repetitive manual tasks. The goal is to save time, eliminate human errors, improve process efficiency, and enable users to connect heterogeneous applications.

In this article, I’m going to share the fascinating story of how we created our dedicated automation team at WTTJ in 2023. I will explore the missions assigned to this team, its composition, its mode of operation, the successes and failures encountered during its first year of existence, and the expected development prospects for the year 2024.

You will discover how a small team of automation engineers helped three of our internal teams to avoid having to spend dozens of hours on laborious tasks each month, working with significantly less disruption thanks to nearly 150 automations.

[January 2023] A struggling team with limited technical expertise

At the beginning of 2023, a new team dedicated to customer onboarding had recently been formed. Comprising about 10 members, it was immediately tasked with the challenging mission of onboarding hundreds of customers each month onto our product. This complex and time-consuming process required collaboration from several internal and external teams within the company, as well as the sharing of data across 15 tools.

Faced with this challenge, the team quickly sought inspiration by consulting other business teams using automation tools such as Zapier. The goal was to automate repetitive tasks such as data synchronization between two tools, creating reminders, or sending automated emails.

However, the team soon realized that they neither had the time, given their workload, nor the necessary skills to build an effective automated system. The few automations in place did not always function correctly, resulted in errors, and did not instill sufficient confidence. At times, the team preferred to perform certain tasks manually rather than rely on automations.

In light of this, and convinced that proper tooling could enable our teams to work more efficiently and under optimal conditions, the company decided to create a dedicated team for the automation of internal processes.

[May 2023] Creation of the automation team: Its vision and ambitions

A team consisting of two automation engineers and one manager was formed. We deliberately chose members with in-depth technical expertise, extending beyond the “no-code” domain and benefiting from a strong background in software engineering. Recruiting profiles inclined towards no-code posed a significant challenge, as developers transitioning to this approach are rare. On the other hand, there is an abundance of candidates who can quickly undergo training on a no-code tool, but unfortunately many lack a deep understanding of the underlying technical concepts or the experience needed to ensure the longevity of a technical solution well beyond its production deployment.

We are convinced that creating a scalable automated system requires skills and knowledge beyond mere task automation. We frequently encounter error management issues, handle significant volumes of data, and must adhere to security best practices to prevent exposure to malicious activities.

Beyond the technical aspect, our goal was to build a team of curious individuals capable of engaging with business experts, understanding their challenges, and describing technical possibilities to them. We believe that the best solutions emerge when technical and functional experts collaborate and challenge each other.

Our ambition was to establish a center of expertise aimed at increasing efficiency and improving the working experience of business teams. This center is tasked with advising and overseeing teams in the selection of tools and implementation of automations, with the goal of optimizing existing processes, reducing repetitive tasks, and providing quality technical support. It thus contributes to enhancing team efficiency and creating the best possible working experience.

We decided to rely on “business ambassadors” with whom we exchange information on a weekly basis to establish a link between our technical team and the “internal client” business teams. These ambassadors play a crucial role in understanding business challenges, identifying and prioritizing specific needs, and determining edge cases and exceptional procedures that could compromise automations. Their expertise allows us to tailor solutions to the unique requirements of each business team.

[August 2023] Process implementation and initial projects

During the implementation of our initial projects, we had to select our technology stack and define our initial processes.

Optimizing consistency and quality

We chose to use Make to host our new automations because this platform allows us to create complex automations with advanced features to effectively manage them. These features include branch creation, manipulation and processing of data tables, error management, cost control, security, and maintenance.

We retained Zapier as a historical player in the company to preserve all existing automations and allow anyone in the company to conduct automation tests if desired.

It soon became essential to standardize our approach to automation construction to ensure high consistency and maintainability of systems, regardless of the automation author or end user. This standardization was achieved through naming conventions, documentation templates, and the application of best practices. For example, we standardized the names of automations and the way to document their triggers and API calls. Another example was the creation of “user” service accounts to build connectors to third-party tools, thus avoiding dependence on the accounts of employees who might leave the company, disrupting automations when their accounts are closed.

Enhancing efficiency and management

With the creation of our dedicated automation team and the success of the initial projects, numerous requests have poured in for the implementation of new projects or the maintenance of existing ones.

Therefore, we have implemented two new processes to enable teams to submit new automation requests and report issues.

The first process has allowed us to standardize requests, ensuring that we gather the right information to prioritize and handle them effectively.

We now ask each team wishing to automate a process to document the project context and its point of contact, explain the existing process and the issues they’ve encountered with it, and describe their expectations and anticipated impacts (in terms of time, cost, and customer or user experience). This allows us to quickly determine which internal expert is best suited to address the request and prioritize based on benefits to the company. Documenting a request often helps to gain perspective, identify the root cause of problems more easily, and consider more impactful solutions than simple fixes to processes requiring an update.

Upon receiving an automation request, our team will meet with the project’s business owner to delve into different use cases, describe the solution in more detail, and estimate risks and technical feasibility.

The phases of automation construction by automation engineers will follow, with tests conducted with the business expert to validate the system’s proper functioning in accordance with the expectations expressed in the initial specification stages.

Once the automation is deployed in production, our team will handle documentation and technical maintenance, while the business expert will be responsible for functional documentation and change management with users.

The second bug reporting process aims to ensure that problems are reported with sufficient detail for investigation. Unlike previous practices based on exchanges through Slack messages, emails, or coffee machine discussions, the use of a technical support tool like Jira allows us to centralize and share information and progress status with multiple people, prioritize issues based on their urgency and severity, and track the team’s workload.

[November 2023] Tool consolidation and scaling

Getting rid of bugs

It quickly became evident that our “functional’ scope was significantly expanding while the size of the team responsible for automations remained unchanged. We needed to ensure the scalability of our operations.

Over time, with the rapid growth in the number of our automations, we faced an increase in errors. To address this promptly, we implemented several systems. Firstly, an alert system with a small automation created in Make was set up, notifying our team via Slack whenever an automation stopped due to an error, and thus ensuring optimal responsiveness to issues.

Simultaneously, a dashboard in Datadog was created to track the evolution of these errors over time. This allows us to analyze the least stable automations and the most common types of errors, facilitating the planning of improvements to avoid the recurrence of these errors in the future.

A dashboard tracking the number of executions for each automation also helped us identify those that were running too frequently, taking up a significant portion of our platform budget. The identified costly automations were improved, for example, by modifying their structure or adjusting their frequency and time range of execution, such as reducing the execution interval from 5 to 10 minutes and suspending automation at night and on weekends. Additionally, this dashboard also helped to detect malfunctioning automations requiring corrections or simply identifying those that were not being used and could be removed.

We were frustrated by the difficulty of debugging certain automations because it was not always easy to determine if data in a tool was being used in an automation. It was also impossible to easily know if modifying the configuration of a tool would have an impact on automation. For example, would a change or deletion of a field in a Monday board have an impact on automation? To address this issue, we implemented a full-text search engine that allows us to more easily identify keywords present in automations and thus the dependencies between tools and the automations themselves. More specifically, this operation is technically translated into an automation that collects all the blueprints of Make scenarios. These are then slightly restructured using a Node.js script before being indexed in Algolia. It is then sufficient to perform keyword searches in this index to find scenarios containing the name of a specific module or a mapping identifier in another tool.

We also encountered difficulties when data manipulated by multiple automations was incorrect. To remedy this, we developed a tool that allows us, based on an identifier, to find all automation executions that manipulated this data. In this situation, we simultaneously launch a Javascript script on several pre-selected scenarios, which performs full-text searches in the execution histories of Make.

Recognizing that we are not infallible, despite our best intentions, good practices, and established conventions, we also decided to subject our automations to a peer “review.” Additionally, we created automations that automatically check compliance with best practices and conventions as far as possible.

Implementing on-demand coaching and training sessions

Our modest team dedicated to automations has now achieved a satisfactory initial level of expertise. However, it was imperative to recognize and value the automation creators who were present in the company before the formation of our team. Being aware of the need to maintain a small team size, it was out of the question to deprive these individuals of their achievements or force them to migrate their existing automations to Make.

Therefore, we opted for a coaching approach, providing assistance by advising and guiding them in their daily tasks of maintenance and automation creation. These individuals thus retain responsibility for the systems they have implemented and we are present to support them and answer their questions.

To enhance their technical expertise, we organized several training sessions. Additionally, we introduced office hours slots in our schedules, offering anyone the opportunity to discuss automations with us. These discussions can cover clarification of the automation concept, exploration of possibilities offered by no-code tools, analysis of functional needs, or the resolution of technical challenges.

Conclusion

Dozens of hours saved across several teams

After nine months and numerous projects, our dedicated customer onboarding team has significantly improved its efficiency. By skillfully integrating project management tools with those dedicated to appointment scheduling, client portals, information retrieval, email communication, and satisfaction surveys, the team members have been able to work more efficiently, saving dozens of hours of manual tasks each month.

Our Care team, responsible for addressing customer and user inquiries about our products, has optimized its members’ time by saving four hours per month through automation that synchronizes data between our CRM and Support Desk, eliminating manual cross-referencing searches.

Billing management by our Finance team has been greatly streamlined with daily updated data, saving approximately two hours of monthly work. This increased efficiency will ensure greater peace of mind, especially in the face of the expected increase in the number of signed contracts each month.

What we’ve learned

The implementation of these projects highlighted the importance of proper communication channels with other teams, allowing us to gather their needs, collaborate on building and testing new technical solutions, and intervene quickly in case of any issues.

Unfortunately, our attempt to assist our Video Production team faced difficulties. This team produces and publishes hundreds of videos on our platform every week, allowing our clients to promote their corporate culture, and the candidates to envision themselves in their future company during the application process. Our attempt to automate the weekly upload of hundreds of videos online failed. We learned that automation requires appropriate tools with connectors or APIs for effective integration into a complex system. Today, we are more vigilant and provide guidance to business teams on how to choose tools with integration capabilities, ensuring our ability to achieve future integrations.

Currently we are overseeing nearly 150 automations, but we know this is just the beginning. The Marketing and Business teams, once autonomous for simple automations, are increasingly turning to us with growing ambitions. And we are aiming to bring our expertise to other teams often overlooked by IT teams, such as human resources, legal, and office management.

The outlook for 2024

The year 2024 will bring its own share of innovations. Currently, our focus is on automating tasks related to specific business processes. However, we have observed that by developing internal solutions, teams can significantly improve their efficiency and working day. Rather than using multiple off-the-shelf tools that do not perfectly meet their needs, they could benefit from custom products. To achieve this, we are considering evolving our team towards “low-code” technical expertise and adopting work methods more akin to a product team.

We also intend to contribute more to the entire company by creating more generic tools, allowing all employees to quickly accomplish various tasks such as searching through our business tools, translating documents, booking meeting rooms, etc. Furthermore, we have not yet explored the possible applications of generative AIs and the benefits they could offer.

Regarding our relationships with other teams, we acknowledge that there is still progress to be made, whether in our emerging and fragile relationships with ambassadors within the business teams or in our communication with teams that have not yet sought our services. We need to better showcase what we are capable of and help teams visualize the benefits we could bring them.

Finally, we are excited to welcome the Otta team to WTTJ this year. This collaboration provides an opportunity to broaden our perspectives and explore other issues and interesting best practices.

Written by Clément Folliet, Business technology manager @ WTTJ

Edited by Anne-Laure Civeyrac

Illustration by WTTJ

Join our team!

The story behind the creation of our dedicated automation team was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

On reading the title, you might have expected yet another article highlighting the importance of writing in order to boost the productivity of a team of engineers. However, this piece offers a fresh perspective by exploring the personal advantages to be gained from taking notes, based on my own experience — experience achieved from a career trajectory that started in a chemistry technician role and most recently landed in a Site Reliability Engineer (SRE) position.

The field of chemistry demands meticulousness in writing protocols and consigning result reports. Every detail must be carefully documented to ensure reproducibility of the procedures under identical conditions. Although this aspect of the job may not be the most exciting, it played a crucial role in shaping the person I am today.

Meticulous note-taking helped me transition from the controlled environment of a laboratory to the dynamic realm of site reliability engineering. Initially serving as a trail of breadcrumbs, these notes have assisted me in navigating unfamiliar coding languages and system architectures. Over time this practice has evolved into composing various cheat sheets for troubleshooting methodologies, providing me with a reliable resource to do my job as efficiently as possible.

Keeping this perspective in mind, let me break down why writing notes can be beneficial for your personal growth. The explanations I will be outlining are based on real-life situations that show just how important note-taking can be. They are all examples, but they give you a good idea of why the notes you take can turn into really handy technical documents, such as how-tos, meeting reports, tickets, or Architecture Decision Records (ADRs).

While this article primarily targets associates and those thinking of changing career, it’s worth highlighting that taking notes is a crucial skill no matter what your role is, so I hope everyone will find it useful!

Because you don’t have an eidetic memory

Unless you have an eidetic memory, you can’t remember everything — that’s a fact. During a call, simply open a text editor on the side and write down the most relevant details. No need for long sentences — just take notes, retrieve instructions for a task, outline architecture ideas for future discussions… It might seem a bit tedious initially, but doing this allows you to quickly see if you are missing any information for the next steps.

So why is this habit worth embracing?

Speaking from experience, I can’t count the number of times I’ve made a cheat sheet during a call, just writing down the steps needed to tackle a ticket. And every now and then, I have to get one out because I’m not sure which command to run. Some of my cheat sheets have even been used to complete some of our how-tos, helping others with their own tasks. There’s something really rewarding about watching your old personal notes becoming common tools for everyone to use.

Writing down all this information minimizes errors and makes you more confident, especially when moving to a new role.

Because it will help you understand things

You can take all the notes you want, but if you don’t understand what you’re writing down, they won’t be useful to you. You need to comprehend what you’re writing in order to properly convey the information to others. Chances are, if you don’t understand what you’re doing, others won’t either. Taking notes is also a great opportunity to ask for feedback and additional information. By writing down details and asking questions, you can make sense of it!

So, how can this actually be good for you?

When I first joined my team, I started taking notes during our meetings, especially when they involved decisions aimed at improving our architecture. In those early days, I received a lot of information in dribs and drabs. Taking notes during our calls allowed me to connect all the previous information and understand our infrastructure as a whole. Those notes later came in handy when I was working on the documentation related to our infrastructure. Making them not only helped me but also meant newcomers could be provided with a clearer understanding of our setup — another way to add a trophy to your collection!

Writing down all this information helps to cement your understanding of the situation and facilitates more confident exchanges with your colleagues.

Because you’ll delve deeper into topics

In addition to improving your understanding, writing notes allows you to delve deeper into the subjects you’re dealing with. While reviewing your notes, you may find yourself considering gray areas. Why is this step designated for the beginning? What would the consequences be if it were performed at the end? What does this term mean? To clarify these areas, you’ll need to do some additional research, thus deepening your knowledge of the subject. Your research will therefore span both the global technical scope and your company or team context.

So, how can this help you improve?

After transitioning into my new role, I familiarized myself with the majority of technical terms through various online searches. However, discussions about the infrastructure remained somewhat nebulous as sometimes the information I got related to another company’s specific infrastructure. Consequently, it could often be challenging to find information that aligned with our particular situation. Once my team received a request from the Data team about a static website they wanted to deploy. I bounced back and forth between asking questions and reviewing my notes, and ultimately we realized it wasn’t so simple. As my SRE coworkers couldn’t find a proper solution, we had to conduct some research, which evolved into writing an ADR based on my notes. Getting involved in this exercise turned out to be a really important learning experience. Beyond writing the document itself, we had to make sure that other technical teams could understand what the different options were and ask for their insight.

Writing down all this information encourages your curiosity and leads you to become more precise with your work.

Because you feel like an impostor

For many, starting a new job can lead to experiencing what is known as impostor syndrome. My technique for minimizing its impact is to not feel useless: I need to feel that my work is useful to my peers. A simple solution is to share reliable documentation. A meeting report outlining progress on a subject, a how-to distributed internally, an incident follow-up leading to actions, etc… It may seem like a modest contribution but feeling useful is a real reward. It’s also a way to share your knowledge and get recognition.

So, how does it help you avoid impostor syndrome?

After a few months in my position, the SRE team decided to migrate the first application from our legacy servers to a completely new infrastructure stack. Everything was prepared: First one member of the team had the keyboard, another kept an eye on monitoring, and the engineering was ready for testing. Feeling like I couldn’t find my place at the time, I decided to write down all the different steps taken that morning, the events encountered, and the future modifications needed. We now use this as a template to prepare the rest of our production migrations and minimize any oversights.

Sharing all this information allows you to feel more legitimate and useful in your position.

Because you’re gaining experience

Let’s take 2 minutes to pause and assess your progress. If you have understood all the points mentioned above, it’s obvious that you have already gained experience. You will become more skilled and therefore better equipped to participate actively in decision-making. You will also know where the important information is to move forward. It may feel like baby steps but when you look back at it, you’ll see it was one big step that starts out as a simple habit and becomes continuous progression contributing toward your professional life.

So, how can you see results?

For the moment, I’m the only associate in my team but not the most recent arrival. We hired a senior shortly after me and I was proud to participate in his onboarding. He had more technical experience but I had more knowledge of our infrastructure. Having participated in documenting our infrastructure, I knew where to find the information. Using my personal notes, I could actively take part in his orientation and induction and it also demonstrated how I had progressed in my position. Sharing your knowledge with others is good practice and a perfect way to demonstrate your progression.

Gathering all this information allows you to monitor your growth and progression.

A few tips to get you started

I understand that taking notes regularly is perceived as an obligation rather than a good habit. But as you can see from this article, those notes can often be turned into documentation. Taking notes is often assumed to be a waste of time, so I hope what I’ve shared here offers a fresh perspective, helping you to recognize that it is a good habit that will help not just you in your daily work, but your colleagues too.

If you’re unsure where to begin, practice on a 15-minute call and draft all the information. While reviewing your notes, sift out the unnecessary information and choose a title that summarizes the remaining information. Gradually you will be able to retrieve the correct information on the first try and start enjoying the time saving. Step by step, you will find yourself updating existing documentation as well as feeling more confident about what you’ve learned.

One important thing when starting: Don’t worry about who’s going to be reading, just write first and foremost for yourself. Fretting about finding the right tone or wording can add too many constraints to your technique at the start.

These tips are only meant to help you get in the habit of taking notes and creating documentation. The definition of technical documentation and best practices for writing it are a whole other topic… So stay tuned!

I hope this article has inspired you — and don’t hesitate to share your personal experiences!

Written by Clémence Fauchet, Associate Site Reliability Engineer @ WTTJ

Edited by Anne-Laure Civeyrac

Illustration by David Adrien

Join our team!

Why taking notes can be beneficial for you and others was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

The purpose of this series of interviews is to present unusual job roles at Welcome to the Jungle (WTTJ). Our first installment features Amélie Bresson, a Product writer and Localization specialist who joined the Design team in August 2022.

Hi, Amélie! Can you tell us what you studied before coming to WTTJ and about your previous experience?

Sure! I studied English and film-making at the same time because originally I wanted to be a screenwriter. During my studies a teacher told me I was meant to be a translator, so I went and did a Master’s degree in Technical translation!

During my second year, I interned as a technical translator at Sage in the Product team for the X3 accounting software, and I stayed there for 10 years [which included two years of freelancing]. I was doing French and English translations both ways for the software user interfaces and the online help center.

What does your position at WTTJ involve?

My current position actually covers two roles — Product writer and Localization specialist.

The Product writer part is also called UX writing in other companies. It consists in reviewing both English and French software interfaces, what we call microcopy, so any text within an application or software, like buttons, error messages, dropdowns, anything written on your screen… My goal is to make the product easy to use and consistent. I also write hint texts or helpers so people have help on screen as they navigate.

The second part of my job is to ensure the localization process runs as efficiently as possible, so basically the translation process for all the languages that we support within the Tech and Product teams. It means finding the best tools, translation agencies, and workflows to deliver high-quality translations on time.

Who are the people you interact with most within the company?

Basically anyone in squads — designers, product managers, and developers. I am also in contact with other teams such as Brand, Marketing, or Customer care to align on terminology, tone and voice, or advise on translation processes when needed.

What does a typical day look like for you?

My morning routine includes coffee, emails, Slack, and prioritizing the requests I receive from all the squads. I currently use a Jira dashboard to track my progress and assess which requests need to come first based on the roadmap or the urgency of the request.

Then I open Figma and start diving into the mockup of the feature. Sometimes, product managers also set up quick meetings with me to give me more explanation. And I start drafting ideas. Usually I just open a notepad and start writing or try it out in Figma in a draft. When I’m done, I put my suggestion on Figma for designers and on the Jira ticket to make sure developers have the right wording from the start. Usually the product manager and designer let me know whether it’s OK or not and we iterate a bit so that user experience, technical, and language standards are met.

When do you intervene in the development workflow?

I like to be part of the workflow right from the discovery stage, because it gives me a lot of time to understand the feature — who it’s for, what we do with it. And as soon as mockups have been delivered I can start working with designers to try things out. For instance, if I want to name a button “Let’s go”, I have to know the space I have on screen to see if it is too long. So it’s very important for me to have the actual design so I can make the best decision. But sometimes it’s not possible.

Why should a company hire a UX writer? What are the benefits?

The position of UX writer has existed in France for 10 years tops I think, but all tech companies should have one! Usually when they don’t, someone will be working on copy anyways, but you really ought to have a specialist. You need someone who is involved early on in the development process to avoid issues related to language down the road, someone who knows linguistics and UX and has a global view of your products overall. The role of a UX writer is transverse, so it’s a great opportunity to actually ensure overall consistency.

What do you like most about your job?

I used to translate 300 words an hour. After a while I realized I was losing sense of why I was doing this. As a technical translator, I felt like I was at the very end of the development chain and my input was always coming in too late. So it’s easy to lose purpose.

Becoming a product writer has put meaning back into everything I’ve studied and learned so far. Even when there’s pressure to deliver quickly, you’re not working on 300 words an hour but maybe 3! I have the luxury of thinking it through, doing research, and asking questions to make sure I’ve come up with the best possible solution. It’s really about quality and user experience. It feels like you’re making a difference!

I am also very happy to be working at a startup. This is something really new for me. It felt like diving into the unknown at first because I came from a 40 years-old and 12,000-person company with quite heavy processes. But I’ve actually reconnected with the flexible and autonomous way of working that I was looking for, and passionate colleagues!

What are the most important skills to have as a product writer?

Apart from English and writing, I would say that the most important one is knowing how to collaborate. You cannot do this job alone. You have to rely on what the product managers, designers, and experts know, and be able to collaborate with them in a respectful way to understand what they do. Then you have to take all that knowledge and turn it into something that users will understand in a very short sentence!

What pitfalls do you need to avoid?

It’s all about finding the right rhythm and balance. You need to take the right amount of time to write your texts. But it can quickly turn into a never-ending story because there’s always room for improvement — you could iterate for a thousand years if you wanted to. Sometimes I dream about it at night, and [when I wake up] I’m like, “That’s the word I was looking for!” But then you also need to think about whether that change is really worth it, because changes will create some workload and disruption.

What has been your biggest challenge so far at WTTJ?

Without a doubt reviewing all the copy that was created before I was actually hired. “Should I do it all at once? Should I do it progressively? Should I only do some parts?”

Knowing which parts to prioritize over others is also not always simple. For instance, one thing that makes me cringe on a website is when upper cases and lower cases are mixed. That’s the type of thing a language geek like me would prioritize, but it might be seen as a very minor issue by others. Still, I’m pretty sure that users will quickly feel uneasy using a website because of this type of thing, even if they don’t actually spot what’s wrong.

Another challenge is the frequent confusion between a copywriter and a UX writer, but that is a very different job! Copywriters manage marketing copy, focusing on making people want to subscribe or buy services. I focus on making sure that they use our solutions with ease and confidence.

Is there anything you wish you had known when you started?

When I started at WTTJ, I spent 3 or 4 months just trying to figure out how I should work and I think I spent too much time drafting processes. “I should work before the designer, no, after the designer…” I’m actually still doing it a year later, because you can’t really figure it out beforehands, you need to get your hands dirty first.

What are your strong convictions about UX writing?

You have to always put yourself in the position of somebody who doesn’t know anything about anything. Of course, UX writers are knowledgeable people, but cultivating reasonable doubt is probably the best way to make sure you always have perspective. Stay curious and open, and absorb all the information that people give you. Always doubt, not yourself, but the words, the information… Keep doubting and admit that you will never stop learning. If you feel like you have nothing to learn, you’re probably not doing your job right.

Any advice for someone who wants to become a UX writer?

Don’t be afraid to apply for this position if you feel you have the skills and motivation! You probably don’t have a degree in UX writing, but there is no proper degree in UX writing in France yet, as far as I know.

Any resources you recommend for training?

You can follow the UX Writers FR groups on LinkedIn or Meetup. They do webinars, meetups, training… Some of them are giving lectures at universities. And I am pretty sure there are resources online to train yourselves too. There are a lot of books you can read as well. I know translators, technical writers, designers, and even people from the legal field, who’ve all successfully made the switch to UX writing.

Any book suggestions?

There is one called UX Writing by a Frenchwoman called Gladys Diandoki, who I’ve actually met. She is a freelance Content designer and Conversation designer. She’s really next level and inspiring if you want to start somewhere.

Who is your biggest inspiration?

I use Shopify a lot for inspiration. They have a fantastic style guide. Once you see that, you’ll never try to create your own style guide again. It’s just the best style guide I have ever seen. They have really set the trend for many UX writers out there.

What was your latest hack?

I finally figured out how to translate Figma mockups back and forth, which is a pain point many UX writers working with multiple languages face. All it took was this simple CopyDoc plugin (paired up with a translation tool).

What’s next at WTTJ for you?

I’ve been working on inclusivity as far as content goes. It’s a big topic in French — in English as well, but the grammar makes it a bit easier. Inclusivity is about gender but not just that. It’s also about the words that we use that discriminate against people, making them feel like they are different — anything that makes people feel bad about themselves or not “normal” will definitely lessen the user experience. I’m hopeful that more and more people are now inclined to make progress on this topic.

Interview by Anne-Laure Civeyrac, Tech editor @ WTTJ

Illustration by WTTJ

Join our team!

Debug my job #1 — Amélie, Product writer and Localization specialist was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

As Data Analysts at Welcome to the Jungle (WTTJ), we often face straightforward data questions like “What is the click-through rate on this button?”, “How many people visited that page?”, or “What are the main landing pages for a specific cohort of users?” Before we could find the answers, we often found ourselves going through a series of time-consuming tasks: Setting up tracking plans, ingesting and modeling new data, or crafting SQL queries of varying complexities. Hours, sometimes even days, could pass before we were able to provide what seemed to be simple numbers to outsiders.

As our company grew from 150 to 350 employees over the past 3 years, the demand for data-driven decision-making grew significantly. With more individuals seeking insights, we encountered constraints in our capacity as Data Analysts to quickly and efficiently answer those needs, resulting in team frustration. Acknowledging this challenge, we recognized the necessity to empower team members across the company to be able to independently access data. This strategic shift not only alleviated decision-making bottlenecks but also paved the way for promoting data autonomy throughout WTTJ.

That’s why we embarked on a quest for a complementary analytics tool. A tool that could improve the way we handled data inquiries. A tool to streamline the processes, boost efficiency, and ultimately unlock the full potential of our data-driven efforts.

It’s worth mentioning that, before joining WTTJ, I worked at Contentsquare, a UX analytics tool, where I held various data positions, including educating customers on technical data aspects of the tool, and later working on developing new features for the product. This multifaceted experience provided me with valuable insights that contributed to a nuanced understanding of our requirements and possible solutions to fit our needs. At WTTJ, we finally chose to work with Contentsquare, but it’s important to note that our choice was not influenced by my previous job, rather it stemmed from a comprehensive evaluation of the tool’s alignment with our needs.

In this article we will share our 2-year journey of selecting, implementing, and utilizing Contentsquare at WTTJ.

1. The limitations of Snowplow analytics: Why we needed more

In 2020 we started using Snowplow, an open-source tracking tool to capture data effectively. It quickly became the backbone of our data strategy, enabling us to uncover super-important insights and provide our organization with data-driven decisions.

Thanks to Snowplow, we had the ability to dig into granular and customizable tracking. This helped us get a clear picture of how users were doing things with our product. Plus, the cool thing was that we had full control over everything. It gave us tons of freedom, granting us access to raw data, preventing the black box effect, and ensured that we handled privacy and security concerns the right way.

However, as our company continued to grow and our interest in data increased, relying solely on Snowplow was no longer enough.

The example mentioned earlier in the introduction was merely a glimpse of the numerous challenges we encountered. The continuous updates to our tracking plan resulted in a long development cycle, which became burdensome. This cycle involved identifying new events or user interactions requiring tracking, devising detailed tracking plans to capture these elements, implementing the necessary code changes, testing for accuracy, and then finally deploying the updated tracking. The complexity and time required for each step sometimes hindered our ability to respond promptly to evolving data needs. Moreover, following UX changes with a standard tracking plan was complicated, as we needed to specify every possible scenario (if the user clicks here, send origin = A; if he clicks here, send origin = B, and so on), which led to endless tracking specifications. Additionally, the absence of a user-friendly interface left our non-technical teams without access to data insights. Even simple metrics like click rates or user segmentations required convoluted SQL queries, adding complexity to our path toward data autonomy.

Consequently, we began considering the integration of an analytics tool featuring automatic tracking alongside Snowplow, to enhance our data analytics ecosystem.

Snowplow always remains our source of truth, as it grants us access to the complete data journey, from its raw, unprocessed form to the meticulously modeled data, empowering us to diagnose and resolve any discrepancies or issues. Snowplow is the sole tracking data we ingest into our data warehouse, which we combine with other data through modeling and share internally and externally.

This approach sought to strike a balance, capitalizing on the advantages of both solutions to empower our data teams to analyze and utilize data effectively.

2. The journey to Contentsquare: The selection process

Over the course of a quarter, we embarked on a careful journey to find the perfect analytics solution to complement Snowplow. Here’s how we made our decision:

Identifying challenges

We began by listing all the existing difficulties we encountered with Snowplow, as well as new challenges we wanted to address, like UX improvement.

Extensive benchmarking

To ensure we explored all available options, we conducted a rigorous benchmarking analysis, evaluating more than 20 competitors in the market.

Prioritizing features

We categorized analytics tools’ features according to three levels of priority — critical needs, essential needs, and bonus features — aligning them with our specific requirements.

Comparative analysis

To gain a holistic understanding, we constructed a comprehensive comparison table, assessing how each of the 20 competitors would address our needs.

Interactive demos

We took the next step by booking demos with four promising contenders, digging into their capabilities and functionalities.

Thorough testing

Further narrowing down the options, we put two of the shortlisted tools through rigorous testing over several weeks, while also actively seeking feedback from clients who had experience with these solutions.

Finally, after careful consideration, we arrived at our decision to collaborate with Contentsquare because it not only provided all the functionalities we required in a more advanced way compared with its competitors, but also we had the advantage of having a power user already within our company (me, as a former employee), which greatly facilitated the adoption process and gave us huge confidence in choosing it as the solution.

3. How Contentsquare meets our needs

Certain functionalities of Contentsquare distinctly align with our requirements, and in this section we will expose some of them in detail, shedding light on why we ended up choosing Contentsquare after this long selection process.

• Optimizing data implementation: In our quest to simplify the laborious process of manually implementing data tracking for every new feature, Contentsquare emerged as a solution. Its JavaScript tag promises to automatically track all page views and events across our website. This eliminates the need for extensive manual tracking plans, which would be time-consuming and resource-intensive for our data, development, and QA teams to implement. What adds significant value for us is the retrospective accessibility of all this data. With Contentsquare, we no longer have to anticipate data needs in advance.
• In response to our need for greater autonomy among non-data teams and improved data accessibility, the Contentsquare platform made the data available through a user-friendly interface accompanied by intuitive visualizations. This accessibility extends beyond data experts, allowing individuals across various disciplines within our organization to analyze user behaviors effectively.
• Recalling an example from our introduction — “What is the click-through rate on this button?”, which previously required complex SQL queries from Data Analysts — the Contentsquare Zoning feature offers a promising solution. With its detailed and customizable heatmaps, distinct from conventional static ones, it provides a quick and simple avenue for accessing zone-specific data, including click patterns, hovers, and conversions. This accessibility greatly aids conducting thorough analyses and ensures that non-data teams like Product Managers and Designers can easily access vital insights, all without the need for Data Analysts.

• Customer journey analysis: Understanding how visitors navigate our website, from their initial interaction to their final destination, is critical for uncovering user needs and areas of frustration. This valuable analysis can shed light on opportunities for site optimization. Without Contentsquare, this is a complex task. Analyzing user journeys involves creating intricate SQL queries to trace actions from page to page, often leading to hard-to-interpret tabular results. Even when utilizing tools like Looker, visualizing user paths beyond the second page and across multiple entry points remained challenging.

Contentsquare’s sunburst visualization allows us to quickly and intuitively map user journeys. We can effortlessly filter and analyze specific user segments, start journeys from the landing page or from designated pages, and even create inverted sunbursts to identify paths leading to specific pages of interest.

Furthermore, Contentsquare’s capabilities enable us to delve deeper into identified journeys, with automatic segment creation from the sunburst streamlining our optimization efforts. This powerful tool has simplified our ability to decode user behavior and optimize our website effectively.

• Advanced segmentation: In our analysis, the need often arises for intricate and precise segmentation that goes beyond the capabilities offered by competitors’ simpler tools, typically limited to 1 or 2 conditions. Contentsquare comes to our aid by providing highly sophisticated segmentation options. This enables us to construct chains of conditions, such as identifying users who viewed specific pages then navigated to other pages and eventually clicked on specific zones. This advanced segmentation is invaluable as it allows us to conduct incredibly precise analyses of user behaviors, an essential aspect of optimizing our platform and providing the best possible user experience.

• Session recording: This feature serves as a valuable asset within our data-analysis toolkit, enabling us to directly witness how users engage with our products. This qualitative data is pivotal in informing our user experience enhancements and aids in the illustration and comprehension of specific user behaviors. While quantitative data from other features might flag issues on certain pages or zones, session recording goes a step further by allowing us to pinpoint precisely what is problematic. By observing users’ interactions in real time, we gain valuable insights into their struggles and challenges.

In addition to listing all those functionalities, it’s essential to emphasize that Contentsquare was chosen to complement our current solution, Snowplow. Unlike some of the other options we considered, which were too similar to Snowplow in terms of analytics and tracking, Contentsquare aligns better with our complementarity objectives.

4. The implementation journey

When it comes to implementing Contentsquare, the commercial pitch might promise a simple copy-paste of the JavaScript tag, but it can end up a more complex story, depending on your site’s tracking maturity. In our case, we embarked on two distinct waves of implementation that explored vastly different paradigms: One on a highly mature product with lots of existing data, and the other from scratch.

Firstly, in early 2022, right after signing up with Contentsquare, we implemented the tool on our well-established B2C site, which was already data-mature. Leveraging our existing setup with Google Tag Manager (GTM), where we implemented advanced event tracking and utilized variables within the data layer, proved advantageous. With a robust data layer in place, filled with most events and pageviews already sent through GTM, incorporating Contentsquare was as straightforward as adding the Contentsquare tag within GTM, with a few necessary adjustments, particularly concerning pop-in handling. After just a week of implementation and regular pairings with the Implementation Manager from Contentsquare, the mission was accomplished.

Encouraged by the successful adoption of Contentsquare on the B2C side by the end of 2022, we made the decision to implement it on B2B products. In contrast, these products were in an earlier stage of development concerning data infrastructure. Consequently, we were faced with a more time-consuming implementation process, given that we essentially had to create the data layer from scratch. This endeavor required weeks of dedicated work, involving the collaboration of our developers to establish and populate the data layer and address product-specific intricacies and other related tasks. While this implementation phase demanded additional time and resources, we received lots of support from Contentsquare’s Implementation Manager. Once the data layer was comprehensively populated, the integration with Contentsquare progressed swiftly, taking only a few days across four products. The primary complexities stemmed from Content Security Policies (CSPs) and the GTM script. However, once these hurdles were overcome, setting up the Contentsquare tag, variables, and mapping within Contentsquare itself proved to be a relatively straightforward process.

Although the implementation might seem challenging, it’s much less so compared with what other tools like Snowplow might need. For instance, with Snowplow, introducing a new page or feature involves a laborious process: Data analytics teams create tracking plans, sometimes requiring complex modeling when data doesn’t fit existing models. Then the development team implements the tracking, followed by QA.

However, with Contentsquare, once the tag is placed, releasing a new page or element automatically collects data without the need for data or development team intervention. The information is instantly available within the tool, eliminating the requirement to anticipate data needs and enabling retroactive analysis from the tag-implementation day, diminishing the stress of future planning.

After implementing Contentsquare, it was time to embark on the process of onboarding our teams to this new product. Our onboarding strategy had two key phases. Initially, Contentsquare guided our Data Analysts to become experts, preparing them to lead internal onboarding. This laid the foundation for independent team onboarding. We had access to rich learning resources, such as online documentation and masterclasses, enabling efficient training. Our organizational structure, with a dedicated Data Analyst per cross-functional team, allowed us to establish Contentsquare experts within each team. These champions were instrumental in disseminating knowledge and seamlessly integrating Contentsquare within our workflows.

5. One year later: Reflecting on Contentsquare and our usage

The standout feature of Contentsquare is its ability to collect data automatically, eliminating the need for detailed tracking plans and code implementation, and without requiring anticipatory tracking plans. We are no longer restricted by predefined tracking plans, which took hours to set up and test, making us more agile in responding to user trends and needs. We are now able to focus more on analysis and less on tracking implementation.

The visual interface provided by Contentsquare has revolutionized our analysis processes. Previously, complex SQL queries were required to understand user journeys and conduct advanced segmentation. With Contentsquare, we can easily visualize user paths, analyze engagement levels, and create custom heatmaps for specific zones on our website. This not only provides us with valuable insights into user behaviors but also serves as an initial guide, pointing us toward areas that might require more in-depth analysis to enhance the user experience and address potential conversion bottlenecks.

Contentsquare allows us to conduct in-depth analyses of page usage and evaluate the impact of new features or product releases. The ability to segment data based on various conditions provides profound insights into user behaviors, leading to better UX optimization and decision-making.

Consequently, since implementing Contentsquare, our data-driven decision-making culture has seen positive growth. Teams across the organization now utilize Contentsquare’s insights and functionalities. Product Managers and Designers have become more self-sufficient in analyzing user behaviors and tracking key performance indicators. This autonomy accelerates development and reduces the workload for Data Analysts, resulting in agile feature tracking, quicker iterations, and faster time-to-market results for new releases.

More specifically, on our day-to-day, we mostly use Contentsquare as follows:

• To quickly get simple usage data, like click rates on call-to-action buttons and scroll rates on new pages.
• For comparisons before/after implementations of new features or making changes in positioning or naming, to assess the impact of changes on user behaviors and experience.
• For session replays for analyzing “suspicious” user behaviors, leading to valuable insights regarding UX improvements. For instance, we observed users attempting to perform drag and drop actions, unaware that the feature was not available. This insight prompted us to consider developing the drag and drop functionality to enhance user experience and minimize confusion.

We’ve adopted a flexible approach to our analytics toolkit, utilizing both Contentsquare and Snowplow depending on the specific use case. For closely monitoring critical features or metrics over time, integrating user behavior data within our database, and sharing data with our customers, manual Snowplow tracking is still invaluable. This allows us to seamlessly incorporate this data into our visualization tool, Looker, and perform complex data analysis. However, for tracking the adoption of new features or understanding user interactions with elements like buttons, Contentsquare has proven to be highly efficient. Its automated data collection streamlines the process, saving us significant time and effort. What’s interesting is that we now have more control over where we want extremely granular data. In cases where we need that level of detail, we opt for manual tracking with Snowplow. However, Contentsquare handles the job seamlessly when we require less granularity, saving us considerable time and effort. This adaptive approach ensures that we have the right tool for the right job, optimizing our data analytics workflow.

6. Important considerations before using Contentsquare

Despite its advantages, as with any tool, there are some crucial challenges to keep in mind if you are considering adopting Contentsquare:

• Dynamic HTML IDs: To work effectively, Contentsquare requires HTML div IDs to be static and unique. Unfortunately, Contentsquare cannot accurately gather data from dynamic IDs, which exist in various parts of our products. This limitation hinders our ability to fully leverage Contentsquare’s capabilities. Addressing this issue required our developers to invest significant time and effort into finding a sustainable, non-manual solution.
• Zoning limitation: After implementing changes on our website, there is a 30-day window during which we need to remember to capture zoning data for the previous site state. If we forget to do so within this timeframe or fail to take a screenshot, we are unable to access zoning data for the older version of the site, even if we have access to a year’s worth of historical data. In fact, it’s not uncommon for us to experience moments of panic, wondering, “Oops, did we remember to capture the zoning data in time?”!
• With the implementation of Contentsquare, a challenge that arose was the determination of data ownership once it became accessible to other departments. As Contentsquare provides easy access and user-friendly features for data analysis across various teams, the question arises: Who should be responsible for conducting analysis using Contentsquare? Should it be the Designer, the Product Manager, or the Data Analyst? Although we recognize that this issue can be perceived as a “rich man’s issue,” it is essential to address potential frustrations and ensure a streamlined and effective data-utilization process. As we continue to reflect on this challenge, we are actively contemplating the necessary organizational adjustments that come with adopting a new tool — who will be responsible for its use, how it will be integrated into our workflows, and how it can best serve our collective objectives.

Challenges to come

Over the past year, Contentsquare has played an important role in enhancing our approach to data-driven decision-making. It has offered teams an intuitive interface, automated tracking, and extensive analysis features. Despite some challenges, the tool’s impact has been significant, offering valuable insights and simplifying data utilization. As we progress, Contentsquare remains an essential ally in our ongoing quest for data-centric improvement. Looking forward, we anticipate a series of new challenges on our data-driven journey. We are committed to deploying the tool across new products and onboarding new users effectively, ensuring that its benefits are felt company-wide. Moreover, as we continue to become more data-centric, defining clear ownership of data and its analysis will be crucial to avoid fragmentation and ensure consistency. We also recognize the importance of not falling into the trap of vanity metrics, prioritizing impactful data and meaningful data analysis that drives actionable insights. These challenges are the next frontier in our data-driven evolution, and we are dedicated to meeting them head-on.

Written by Aurélia Kain, Senior data analyst @ WTTJ

Edited by Anne-Laure Civeyrac

Illustration by WTTJ

Join our team!

Choosing the right analytics tool: Insights from our Contentsquare journey was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I started out as a backend developer I didn’t know what portions of code to test and how to test it properly. Despite recognising the importance of testing code, setting up the necessary boilerplate seemed complex.

The difficulties I encountered often came from the code complexity rather than the testing process itself. Now I have come to realize that writing tests can actually be an enjoyable experience when the code is neatly organized, bringing me an unparalleled sense of peace of mind, so much so that I can no longer do without it.

Of course, it’s essential to focus testing efforts strategically on critical features rather than attempting to cover every nook and cranny of the codebase. While it’s (relatively) straightforward to write tests for CRUD (create, read, update, delete) models, writing extensive tests with code sections that you don’t fully understand can be intimidating, for example when dealing with external services such as APIs. But ensuring that your application will respond accurately to any given scenario is where testing becomes relevant.

The Elixir ecosystem offers a multitude of possibilities to streamline the testing of external services. At Welcome to the Jungle, we had the opportunity to compare several of these techniques to efficiently test our numerous external services (emailing, queues, payment systems, etc.), most of which lack a dedicated test environment.

In this article, we will summarize what we discovered and provide an overview (albeit not an exhaustive one) of various Elixir methods for testing payment API calls, ranging from the simplest to the most intricate. The focus will be solely on unit testing, through input/output examples, and not extend to discussions either on alternative unit-testing approaches like mutation or property-based testing, or end-to-end or integration testing.

Although the testing methods we will explore use different technical approaches, they all share a common inherent logic: A focus on the internal code and business logic over the final implementation, ensuring independence from the underlying service (which may change over time). While our article only features examples in Elixir, it is very likely that these concepts can be adapted for other programming languages.

Presentation of the use case

In this article, we will simulate a simple call to a fictional payment API called Stipe. Our comparison will focus on the following use case: A user initiates a payment using a credit card stored in the model (note, this should never be done in a real application). The user’s status will then be updated, regardless of the payment outcome — whether it succeeds or fails.

In our simulation, we will treat this as an external library, for which we will have no control over the code in charge of executing the external HTTP call. Our tests will therefore have to focus on examining the payment logic rather than the library itself.

TLDR: Summary table

It is worth noting that some libraries, such as Exq or Oban, offer built-in mock modules for testing function calls. This avoids having to reimplement this logic on the application side.

You can clone our public Git repository to run the code on your end. The master branch contains the initial project without any testing, and each experienced solution is available on a separate branch.

The initial architecture of the project is built as follows:

Lib

| my_app

| misc => ignore this folder, it contains the fictitious implementations of the Stipe library and the Stipe backend

| my_app.ex => the file where our business logic is located (the user’s payment)

| user.ex => the user structure

test => the test folder, empty at the moment

Naive tests

Mock

https://github.com/maximemenager/elixir-testing/tree/with-mock

During this initial testing phase, we will look at an approach often used in many programming languages: monkey patching. This technique involves replacing one function with another in the program memory on the fly.

Your code will no longer call the code of the external library. Instead, it will call a function defined by the developer in “test” mode.

For example, this code snippet shows that we can “overload” the external make_payment function:

This concept is interesting for achieving quick results. However, the main concern here is that it changes the behaviour exclusively in test mode and not in production. To put it simply, it is as if you had two distinct logics between your testing and production phases.

This can lead to significant problems, as any modifications to the business logic in production would go unnoticed in testing. The simplest example would be a change in the response from the library during an update. If the library’s initial response is a tuple ({:ok, response} or {:error, response}) and that a version bump now returns just “response” or “nil”, this modification would remain invisible during testing, resulting in code breakage when deployed to production.

While this test mode can be useful for temporary development, it does not guarantee long-term robustness of the code.

More advanced testing

Fake HTTP server

https://github.com/maximemenager/elixir-testing/tree/with-http-server

This approach involves redirecting your calls to the external API — not to the actual API, but to a custom-built one. The principle is simple: Replicate the responses of the real API by reverse engineering.

The main weakness of the previous approach has been removed. Here, the production and test code are identical, they follow the same path. The distinction lies in the final endpoint that will vary based on the context.

However, we still encounter the same issues as before: A change in the API (which is not supposed to happen) will unfortunately lead to a breakage in the production environment. Once the bug is discovered, resolving it requires duplicating the fix previously mentioned. We will therefore be behind on production. While this type of test is convenient for end-to-end scenarios, it still overlooks the most important aspect: Testing your business logic, not HTTP calls (because, yes, this case is almost like testing the HTTP protocol).

Mock with behaviour

https://github.com/maximemenager/elixir-testing/tree/with-behaviour

Similar to the previous concept, this approach involves eliminating the entire HTTP component to focus on a behaviour. A behaviour consists of generalizing a logic through a contract and deporting the final implementation of the logic to a module that adheres to this contract.

There’s a major subtlety here in comparison to testing with a fake HTTP server or a mock. In this case, you will call the same logic (defined by the behaviour), regardless of whether you are in test or production mode. However, the actual implementation at the end will differ, providing that it is consistent with the contract.

This way, we can very easily create functions that produce the same response as those present in the library. Compared to using mock, we are likely to detect an error before production. If an external function changes signature, it will no longer respect the contract and a warning will be raised during compilation, allowing for easier anticipation and resolution of the problem.

Nevertheless, there is a limitation to this approach: It does not allow for checking the parameters/headers sent or modifying the response on the fly (to differentiate between an HTTP 401 code and an HTTP 200 code, for example).

Mock with a GenServer

https://github.com/maximemenager/elixir-testing/tree/with-genserver

This solution is quite similar and repeats the previous way of doing things. Instead of locking the returned response, we will store the received parameters in a global state (using an Agent/GenServer, for example) to validate the parameters later.

One of the advantages of this solution is that we will be able to check the parameters sent since they are stored in a global state. Furthermore, it is possible to modify the response returned based on the received content.

However, the solution does have limitations in terms of flexibility, since it is impossible to validate that it was our specific function call that saved the parameter in the global state. It is also impossible to guarantee that the function has only been called once and that no other equivalent parameters have been saved.

Mox/Hammox

https://github.com/maximemenager/elixir-testing/tree/with-hammox

Mox is a library inherited from José Valim’s excellent article Mocks and explicit contracts, which presents a clean approach to testing an external service. Based on Mox, Hammox takes the concept further by incorporating the defined typespecs. To keep things simple, we will only refer to Mox for the rest of this article.

Despite being a very small library (fewer than 1,000 lines of code), Mox combines the benefits of the two previous methods (with-genserver and with-behaviour). It provides a shared-state mechanism to ensure that a function is called and tracks how many times it has been called.

The core principle is to generate functions at runtime based solely on the callbacks defined in a behaviour. By default, the functions will exist but will lack underlying implementation. Therefore, in each test that calls a function, it becomes necessary to specify the desired return value. To avoid the boring task of implementing a function during every test, even when the result is irrelevant to the current test case, it’s possible to simplify things by using a stub, a default implementation in case the user implementation is not defined.

Mox also provides the functionality to track the number of calls to a function. If the most common occurrence is a single call, we have discovered intricate ways to validate, with Mox being very helpful. For example, for a production bug that made an unwanted external call, we were able to write a unit test that ensured no external calls were made. Similarly, we have already encountered the reverse situation, validating that two consecutive external calls had been made.

Exploring more

In this article, we explored a subset of the many testing possibilities offered by the Elixir ecosystem. Using different examples, we have tried to transcribe the evolution of our testing approach over the years at Welcome to the Jungle. The progression of our testing methodology has been an ongoing process over several months, and it is worth noting that there may be alternative approaches to testing your applications.

While Mox was presented in this specific use case, keep in mind that this library is useful in any situation where edge effects are involved within a function, such as writing to a file or even performing read/write operations in a database (even if the latter is subject to debate).

In addition to the mock tests, it is worth exploring other types of tests that have not been presented here (such as mutation or property-based testing). These concepts can be more complex by their very nature, but they remain an interesting place to start not only in the Elixir ecosystem, but also in terms of professional growth and development.

Some resources to help you investigate further:

• blog.appsignal.com/2023/02/28/an-introduction-to-test-factories-and-fixtures-for-elixir.html
• pragprog.com/titles/lmelixir/testing-elixir/

And libraries:

• github.com/dnlserrano/exavier
• github.com/whatyouhide/stream_data

Written by Maxime Ménager, Senior backend developer @ WTTJ

Edited by Anne-Laure Civeyrac,

Illustration by David Adrien

Join our team!

Exploring various approaches for testing external calls in Elixir was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Observability refers to the ability to monitor and analyze the health of an application’s system. Instead of focusing on individual services, it provides insight into how a system performs as a whole. Three types of data are aggregated to achieve observability: logs, metrics, and traces — the so-called “three pillars.” Logs are time-stamped events that happen to a particular system. Metrics are quantifiable or countable software characteristics that help us understand a system’s performance. And traces follow requests sent to an application, consisting of multiple spans that depict their paths across a distributed system and the time taken to process them.

To gain a deeper understanding of the concept of observability, we recommend you read Anita Ihuman’s article “An Introduction to Observability and Its Pillars”.

At Welcome to the Jungle, we used service-oriented monitoring for years, mainly because most of our codebase was located in our monolith. So when we switched to a distributed system architecture, we had to consider observability instead of just monitoring services.

This article is aimed at experienced Elixir developers looking to improve their observability practices and build stronger experience of handling logs and exceptions.

Scalability challenges at Welcome to the Jungle

Our company has been operating web services since we launched in 2015 and has seen its traffic increase steadily over the years. A growing number of companies are using our website to showcase themselves and more job hunters are coming to our platform to find their dream company to work for.

To support this growth, we have been hiring more engineers and creating new teams. The transition from one team working on the historical monolith to 5 teams building their own set of features in dedicated microservices has brought new challenges regarding observability.

Earlier this year (2023), we were experiencing, on a daily basis, 100,000 error logs, with Sentry reporting 1,000 exceptions. This resulted in poor observability, unhappy customers, and engineers spending a huge amount of time fixing production instead of building new features.

One of our senior back-end engineers decided to take matters into his own hands: He gathered developers from other teams to discuss our scalability issue and the “observability initiative” was born. Its goal was to gradually increase experience of this topic and implement increments for scalability.

This article details what we learned about decreasing the amount of errors and exceptions in an Elixir application.

Reducing noise as a prerequisite

If you’re experiencing an increase in unhappy customers while the engineers who work on your products are claiming that they’re not having to deal with many incidents, your monitoring stack is likely to be suffering from too much noise.

Engineers are only human, so they tend to overlook monitoring data if there is too much information. This means, of course, that the chances of missing a major error or a regression are going to be higher.

What is noise?

Let’s define noise.

In signal processing, “noise” is a general term for unwanted (and, in general, unknown) modifications that a signal may suffer during capture, storage, transmission, processing, or conversion (Vyacheslav Tuzlukov, Signal Processing Noise, the Electrical Engineering and Applied Signal Processing Series, 2010).

For observability, noise is unwanted and unnecessary information that makes monitoring services harder to deal with and painful.

It can be:

• Logs with error levels when events should be labeled as informative or with a warning.
• Caught exceptions that have already been dealt with or are unactionable.
• An overload of notifications due to irrelevant alerting thresholds.

Why is it necessary to reduce noise?

Having too much noise can lead to the following problems for engineering teams:

• A lack of confidence when it comes to any action, from deploying to production.
• It takes too long to detect and resolve an incident.
• A poor experience for developers, with increased mental load.

Having thousands of errors a day gives the impression that the service is hitting issues every time something occurs. It is therefore very difficult to read the monitoring data to determine whether something serious has happened when stakeholders (e.g. customers, support teams) complain about an incident or bug.

Actionable steps to reduce noise in Elixir applications

At Welcome to the Jungle, we write and deploy Elixir services. To monitor these in production, we use Sentry and Datadog.

The following recommendations mostly relate to these tools, but the general principles can be used with any other logging framework or monitoring platform.

Pick the right log level

Noise mostly comes from unnecessary error logs in monitoring applications.

Here at Welcome to the Jungle, we follow these rules of thumb:

• An error level is set whenever the application hits an issue that has an impact and is actionable.
• A warning is set to indicate that something unexpected has occurred but does not prevent the application from running correctly.
• An info is set for pure information data that we don’t need to look at on a daily basis.

Interested in mastering log-level hierarchy? Please have a look at Rafal Kuć’s article “Understanding Logging Levels: What They Are & How to Use Them”.

Meet multi-line log aggregation

As seen in our tech blog article “A brief history of Erlang and Elixir”, Elixir operates on the Erlang virtual machine with an OTP framework.

At startup, multiple processes are spawned and, as errors can happen, processes can crash along the way. When a crash occurs, a multi-line report is printed, as per the below example:

By default, loggers do not play nicely with multi-line aggregation and will append one log entry for each line, resulting in poor log collection, as per the below example:

We need to instruct loggers or log collection tools to aggregate all lines relating to a crash report.

If you’re using Datadog to aggregate your service logs, we recommend looking at its documentation for automatically aggregating multi-line logs.

Filter out exceptions sent to Sentry

The purpose of Sentry is to report any uncaught exceptions in your application. As Elixir is crash-first oriented, we tend to get a lot of exceptions.

Although the Phoenix framework handles a lot of them (thanks to the Plug.Exception protocol), exceptions are still reported to Sentry because these are, ultimately, uncaught by the application service.

The good news is Sentry can be configured to filter out any exceptions we consider safe. Tuning this in your application service helps to reduce overall noise, especially in situations where your service receives a lot of garbage requests during bug bounty sessions, security audits, and, simply, attackers trying to breach your system.

The official Sentry client for Elixir already supports a list of well-known exceptions to filter out. In June (2023), we submitted a contribution via a pull request that was merged to expand this list based on our experience with noise. You can find it here if you are curious.

To use a Sentry event filter module, you must configure it in your configuration file, as below:

The module MyAppWeb.SentryEventFilter must implement the behaviour Sentry.EventFilter.

We recommend having a look at the Sentry Elixir client documentation if you’re interested in crafting your own event filter.

Define a process for Sentry exceptions

To prevent engineers from getting tired of the overload of Sentry exceptions, we drafted a process to handle new Sentry issues.

Once an exception is raised, the engineers responsible for monitoring create a task on our issue tracking tool. This process is semi-automated thanks to Jira integration in Sentry.

The issue can either be fixed right away (bugfix), in which case the ticket is closed, or not, in which case developers are encouraged to catch the exception and log an error. Once the exception is caught, the Sentry issue can be marked as resolved. This allows engineering teams to tackle incoming Sentry issues continuously while maintaining a manageable and healthy backlog.

The most important thing is to make sure that the Sentry issue is marked as resolved as soon as possible so the team can be informed and specific steps are taken for its resolution.

Wrap-up

We hope you enjoyed reading about our initial experience of observability at Welcome to the Jungle. Sanitizing our logs helped us better understand how our production systems work and enables us to go beyond.

In the teams where we have implemented noise reduction, we have seen:

• An increase in deployment quality.
• A greater sense of ownership of errors and alerts.
• Better visibility of services’ health.
• A faster response time to incidents.

One unexpected outcome is we have been able to reduce our overall costs relating to log ingestion, because every bit of noise we killed reduced our usage of monitoring tools, including Sentry and Datadog.

And all this preliminary work makes it simpler to address other challenges present in our observability roadmap, like proactive monitoring, incident management, and quality of service.

We assess the progress of this initiative once a month within a dedicated task force, with one of our senior engineers leading and sharing the incremental results.

Resources

• An Introduction to Observability and Its Pillars
• Understanding Logging Levels: What They Are & How to Use Them
• PromEx Design Philosophy
• Sentry.EventFilter technical documentation
• Datadog documentation on multi-line log aggregation
• Quality of service for microservices

Written by Guillaume Pouilloux, Backend developer @ WTTJ

Edited by Anne-Laure Civeyrac

Illustration by WTTJ

Join our team!

Observability: Reducing noise in Elixir applications was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

White-collar workers will have worked five jobs (including two internships) before they reach the age of 35, as they stay on average 2.8 years in one position according to a 2015 study by Deloitte and Nomination. Therefore finding a job needs to be a simple and easy process!

At Welcome to the Jungle (WTTJ) we are committed to making work an exciting experience for everyone. This involves offering emotional support for work life through our media, making sure we provide high-quality job postings on our platform, and continually improving the accuracy of job search results. With 43% of users’ behaviors revolving around the job search feature on our website, improving the accuracy of results quickly became a priority for our tech team.

Here we will explain how we improved our job search results for both job seekers and hiring companies by exploring functionalities on the Algolia search engine and releasing a new feature to boost the visibility of job postings.

Spotting the issues

We run regular NPS campaigns at WTTJ to measure the global satisfaction of our users. And the results are good: Our NPS score is currently about 50. However, we felt that there was something wrong with the job search experience.

A specific campaign that focused solely on the job search process quickly confirmed this, giving a lower score. A series of user interviews was then conducted and three types of issues emerged regarding the job search feature on our website:

• The results were not always relevant.
• Several filters were missing.
• Job seekers, especially students, were struggling to find the right job titles.

Additionally, we quickly implemented a new KPI to measure the search satisfaction by displaying like and dislike buttons on search results pages. By using them, people can tell us directly what they think of their search experience, allowing us to measure the impact of changes in the experience more frequently.

A new pop-up appears if they click the dislike button:

If they click the like button, they still have the option to share their thoughts:

Now let’s look at how we addressed the issues.

Deep diving into the Algolia search engine

During the last quarter of 2022, the Algolia search engine indexed 5 million searches on the WTTJ website, with 40% of them using filters.

Search engine optimization

To begin with, we conducted 14 AB tests on the Algolia search configuration in order to improve search results, which included removing stop words, optimizing searchable attributes, and adding synonyms. The experience made us question our decisions, such as regarding whether the search should be based on job titles only or on the entire content, and whether linking words should be removed. We also enriched our synonym suggestions for job titles in response to feedback from users as well as data science.

Optimizing the Algolia search engine for our needs required going through a lot of trial and error. We tested a wide variety of configurations before releasing them and discovered that those that work well individually could be inefficient when combined. Having a large number of searches helped us iterate quickly and it usually took us two days of testing to decide whether an optimization was worth it.

Significant results were achieved! By working on synonyms, we were able to increase the click-through rate by 1.2 points and the conversion rate by 1 point.

After optimizing the search engine, we worked on enhancing the user experience, taking advantage of Algolia’s features.

User experience rework

Historically, the search feature on our website had offered users a real-time search experience: Typing keywords into the search bar would update results immediately. But we quickly realized it wasn’t ideal, especially for students who don’t always know what to type.

To inspire and guide users, we switched to Algolia’s auto-complete feature to show similar job titles as well as the number of open roles.

By making just this one change, the click-through rate increased by 2 points.

This wasn’t enough, though. While improving the search experience, we also wanted to address recruiters’ stakes. So last year the tech team decided to work on a new feature to make job postings more visible.

Promoting job postings

In 2022, we decided to introduce a new feature that allows hiring companies to boost their job posts. Nothing new there: Similar features had already been proposed by some of our competitors. After confirming that our customers would be willing to pay for that feature, we conducted several interviews with users and companies to understand what they expected from such a feature.

Identifying expectations

Based on our conversations with recruiters, we concluded that there were two situations where boosting was needed:

• Urgent hirings, such as when someone in a key position leaves the company, or when the person in charge of a crucial event is due to leave the company in the near future.
• Difficult hirings, such as for profiles where there is a shortage of talent.

To make this feature successful, it also had to meet the expectations of job seekers. Job boards are like marketplaces: Demand and supply must be balanced. To target the right audience, we decided to use the Google model rather than some sociodemographic data to reach people based on their intentions.

Taking into consideration both client and job seeker expectations, we decided to market this new feature as an easy-to-use and efficient solution for our clients that gives job seekers visibility of the promoted job postings in search results.

Implementing the solution

A new index containing only boosted job postings was created in Algolia. Whenever a search is performed on the WTTJ website, a multi-query is used to request this index and organic search results. Job seekers will only see boosted jobs that correspond to their searches.

A UX analysis then helped us optimize the positioning of boosted job postings. We used Contentsquare to have a deeper understanding of candidates’ behaviors, not only on our website as a whole, but also on individual pages. Thanks to heat zones, clicking-recurrence areas, and more, we were able to identify potential UX issues and understand how our visitors interact with the content. It turned out that the top of the page had the best visibility. As a result, we display up to 3 boosted job postings at the top of each page, when available. The job postings that follow these are organic.

Last but not least, we wanted to ensure that job seekers understand why boosted jobs appear before more recent ones in our system. Transparency is important to us beyond legal requirements. As a result, we created a “promoted” tag to be fully transparent in our engagement with users.

Using this tag also allows us to get some feedback as users are encouraged to share their thoughts after clicking it.

A 3-step launch to confirm the impact

Our team tested this feature in 3 steps in real life before releasing it. The users’ reactions were hard to predict and we wanted to be careful not to misread them or create a negative experience.

We began by promoting some of our own job postings as phase 1, as well as adding specific tracking actions through our tracking solution Snowplow to have a deeper insight into the impact. The results were impressive: Page views increased by 8 and applications increased by 4. By this point, we knew promoting jobs worked, but we weren’t sure how people would react to other companies’ openings. Because we were using our own job board for our posts, we didn’t want the results to be biased.

So we moved on to phase 2. Some of our customers were invited to take part in the experimentation and try this new feature. These results were conclusive as well.

However, we were still not confident enough to proceed with the release. So, for phase 3, additional tests were carried out on a job vacancy with a lot of competition to see how well the boost works under those circumstances. Once more, a strong impact was confirmed: Page views increased by 4 and applications by 1.6.

Improving the experience for hiring companies

From the hiring companies’ perspective, the process was quite manual at the beginning. To promote a job posting, they would need to manually set a Boolean. This wasn’t ideal, since we wanted companies to be able to manage their boosts themselves. So we worked on creating a product out of the experience.

How does it work? Think of a boost as a parking spot. Once you activate it, you can only place one job in it at a time, and you can change jobs whenever you want (and even leave the spot empty for a while if you want to). We wanted to give recruiters as much latitude as possible to experiment.

We also provide hiring companies with some data to assist them. For example, they can see how many page views were generated during boosted and non-boosted periods. As a result, they have control and can make informed decisions about which jobs they want to boost.

A never-ending job

Because the search for improvements is a never-ending job, every week we track the reasons some job seekers click dislike about their search on WTTJ.

We are currently testing a new feature that allows people to search only in the titles of job postings to restrict the search results and only show very precise matches. In addition to improving the results, this feature has taught us the importance of clarity in wording and design, as we realized this new feature was not being seen or understood correctly when we first released it.

A rework of the mobile and desktop UX was also prioritized to address filtering slowness and mobile UX issues. These were among our top pieces of feedback, as well as a design and tech prerequisite that would enable us to address other important issues, such as missing filters (salary, start date, contract duration, etc.).

After all this work, our dislike/like ratio improved with +4 likes on desktop and +7 likes on mobile. With the most recent improvements, we reduced the dislike reasons “filtering slowness” and “mobile UX issues” by 2.5.

On top of that, we made sure to not lose sight of our strengths along the way! Having a great design sets us apart from the competition and makes our users satisfied. This was something we were not going to compromise on.

Written by Jean-Nicolas Fine, Team Lead Data Analysis and Aurèle Duterme, Product Lead @ WTTJ

Edited by Anne-Laure Civeyrac

Illustration by Myriam Wares

Join our team!

Improving job search accuracy through test and learn was originally published in Welcome Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.