Forem: Kleinanzeigen & mobile.de

Conversations That Mattered: My Journey Mentoring a Senior into Leadership

Kleinanzeigen & mobile.de — Thu, 11 Sep 2025 19:42:12 +0000

Introduction

At mobile.de we run a mentoring program where people can sign up as mentors or mentees. In my role as Engineering Manager, which I’ve been doing for several years at different companies and where I focus on supporting teams and individual growth, I volunteered as a mentor and was paired with a Senior Backend Developer — and I was excited to see what would come next.

My current mentorship relationship began, as many do: we created a calendar invite and then we introduced ourselves. I learned she was a Senior Backend Developer and that she was looking for some professional development guidance. Her CV looked solid to me and she came with a lot of questions, which I was more than happy to answer based on my past experience. I felt really excited, while I was really nervous. Would I be enough to meet her expectations? What are her expectations? Would I be able to help her grow in the way she needed? . She wasn’t sure whether Tech Lead or Principal Engineer was the right next step, and that uncertainty shaped our work: both paths demand technical excellence, yes, but also excellent communication, organisational influence, and the confidence to make tough decisions.

I would like to share with you my experience on this short but enriching journey, as I feel it didn’t only help my mentee to grow professionally and personally, but also it helped me a lot reflecting on how a good mentoring relationship and program should look like, how to adapt when the context differs from my previous mentoring experiences, how cultural background affects the way we mentor and how to communicate for getting the best outcomes.

My aim in this post is quite simple: to offer no more than an inspirational, practical guide for any mentor who wants to be part of such a journey and to show that you don’t need a specific role in the company to be an effective mentor.

Initial steps

At the beginning we met to get to know each other and validate whether our mentoring relationship would potentially be a good match or not. During that first conversation we agreed on the goals we wanted to achieve and discussed what each of us could contribute to the process. Spoiler alert: We turned out to be a great match.

We also wanted to give this a proper structure and for this reason we defined weekly 1:1 sessions of 30 minutes.

Her aims were twofold: explore the Tech Lead and Principal Engineer paths, and improve communication so she could build trust and influence, so in the future she could potentially take one of these two roles and just because it is nice to build trust. Now it was time to start doing.

Learning style was also part of the conversation, as I needed to know whether she preferred reading or watching videos. Since she was more of a reading person, I defined a weekly cadence for sharing written resources which we would later discuss in our 1:1s. Always in a timely manner, as she was going to need enough time to read and reflect about the topic.

Growth Areas

Once we recognised what we wanted to talk about, we created a brief roadmap of the topics we wanted to discuss in our weekly meetings:

Building confidence in your own abilities

Confidence is the foundation of day-to-day work, and because I’ve seen impostor syndrome become a major issue — I suffer from it myself — we addressed it first, although we returned to the topic several times.

Building trust across the team

Trust isn’t only self-confidence — it’s confidence from others: peers, managers, and cross-functional partners. How can you feel confident if you do not have a proper relationship with others? And how can you build such a relationship and trust? This is tough, but we talked about strategies on how to overcome this situation. At the end of the day it is all about talking and setting up the right expectations, as we’re here to have a good relationship and act as a team and not only like individuals. If there is no trust, your impact will be limited.

Organisational influence and communication

Once you trust yourself and your team, the next step is influencing the broader organisation. I’m not talking about being the rock-star in the spotlight all the time; I mean being an example to other engineers and an inspirational contributor, whether you’re a leader or not. For example, a senior engineer might lead cross-team architecture reviews, build a reusable internal library, or run recurring tech talks — small, tangible actions that set an example, spread best practices, and align technical work with product impact. By doing that, we can develop the best approaches together and generate ideas that help us make the most of our product and how we work.

How to keep yourself motivated when things are not going well?

We all know that being 100% motivated all the time is kind of impossible, because life happens and because we’re just human beings, this is where keeping the motivation on a good level when things are not going well is tough and a few things tend to help: celebrate small victories, reset yourself, zoom out to see the bigger picture and please please, don’t blame yourself.

How to handle conflicts

I’m still developing my skills in this area, and this experience taught me the most: by listening to my mentee’s perspective on conflict, I discovered concrete ways to improve my communication and decision-making. What I confirmed here is that communication and decision making are crucial here, but at the same time please always give yourself the time to hear both parties, to understand where they’re coming from and try to apply techniques for addressing these situations. You don’t have any techniques for it? Then I think it is crucial for you to start building your own conflict management toolset, it will just make your life easier.

Self development and self knowledge

From beginning to end, it was a process of self‑discovery. How do we give feedback to ourselves and to others? How do we receive feedback from others, and what do we do with it? These were some of the questions we discussed in our sessions. Too often you take feedback and don’t turn it into action, which can cause you to miss opportunities. Feedback from others is a key piece of the puzzle — and I don’t mean just from upper management; I mean the people you work with every day.

Engineering Ladders

People talk about “engineering ladders” a lot, but they rarely explain what it actually takes to move up. The higher you go, the fuzzier the criteria become — which makes promotions feel mysterious and unfair. This is where the Engineering Ladders framework comes into play and what I really like about it, is that it will give a bit more of a concrete vision on which are the dimensions considered for developers, tech leads and engineering managers — even PMs are part of this framework. Once you read it, you will understand that the dimensions are pretty well defined. We liked the most that they don’t only talk about technical skills, which is also important, but that there are more dimensions which are also relevant. Use this as one of many tools for building your career path.

Technical skills

Skipping this wasn’t an option, right? Definitely not. We focused on the topics mentioned above because that was the path my mentee wanted to follow — she was already confident in her technical skills. That said, technical ability is not something to ignore, and we worked to enhance her skills further to support the influence work I described earlier.

First, we discussed how well she knew the product, the architecture, testing approaches, resiliency, and so on. With that context, we created a plan to review the application’s big picture and identify improvements to make it more resilient.

Technical decisions and decision making

Once the technical solution is clear, some implementations seem “easy enough.” But what happens when they aren’t? When you must choose between “quick and dirty” and “perfect,” that trade-off is a daily reality for Tech Leads and Principal Engineers. Much of this is learned on the job — theory only goes so far — but having solid strategies for difficult conversations makes those on-the-fly decisions far easier.

We discussed real-life scenarios where a decision had to be made and which communication strategies fit best. Questions we explored included: should you be the first to speak, or let others voice their views? When is it useful to wait and let silence work for you? A ten-second pause often elicits valuable input. The more tools you have for framing decisions and guiding discussion, the better your outcomes will be.

Self evaluation and next steps
As a closing act we ran a self evaluation from start to finish of the process and what we learned from it. With this in mind and her interest, we decided to follow these steps

Creation of a high-level architecture of the application she’s working on and share it with the team. Baby steps first!
She’s becoming a mentor now, she will use the same structure, in order to expand her level of influence and communication skills.
Given that she’s lacking in specific technical areas, she will dig deeper into certain topics and the knowledge will be shared with her team and also her area.

This mentoring relationship is not over, and I think it is far from over, but I wanted to give you a summary of what has happened so far. I have learned a lot and I realised how many things sounded great in theory but were harder in practice. Now I have run my own self reflection (as mentioned above for her) and this has been so fruitful!

I was really happy when I received positive feedback from my mentee — it meant the world to me, because something I was not sure I could do definitely paid off. So, if you are hesitating about mentoring somebody, I always recommend you go for it! Even in the worst case, mentoring produces learning for both parties. I speak from experience: some of my past mentorships failed, yet those failures taught me crucial lessons I still use today.

Special thanks to Philipp Mayer, Busayo Oyewole, Stefan Wilke for helping me review this document.

Resources I have used along the road and that might be useful for you

Zhuo, J. (2019). The Making of a Manager.
Larson, W. (2021). Staff Engineer.
Meyer, E. (2014). The Culture Map.
LinkedIn. (n.d.). Building Confidence as an Engineering Manager.
Workfeed.ai. (n.d.). Building Trust in Cross-Cultural Teams.
Gambill, T. (2022, July 26). 5 Characteristics Of High-Trust Teams. Forbes.
LeadDev. (n.d.). Three strategies for building trust with your engineering teams.
emdiary.substack.com. (n.d.). Staying Motivated When Things Go Wrong.
LeadDev. (n.d.). Managing conflict in engineering teams.
Wen, J. (n.d.). Tech Lead Handbook — Manage Conflicts. Medium.
leadership.garden. (n.d.). The No-BS Guide to Engineering Team Conflicts.
Engineering Ladders. (n.d.). Engineering Ladders.
Highland Literacy. (n.d.). De Bono’s Six Hats.

Trust & Transparency: Why we updated our review system at mobile.de

Kleinanzeigen & mobile.de — Fri, 05 Sep 2025 09:09:29 +0000

an article by Busayo Oyewole

If you’ve ever found yourself scrolling through reviews, you know the feeling. One listing has a sparkling 5.0 star rating, but with only three reviews. The other has a slightly lower 4.6, but with thousands of ratings. Which one would you choose?

(meme from instagram.com)

If you’re anything like the person in the meme above, you’d probably pick the 4.6. Why? Because a perfect score with no history feels hollow. It lacks the social proof and depth that only a high volume of feedback can provide. It’s a UX problem we’ve been wanting to solve.

As the Trust & Safety team, our job is to anticipate these moments of hesitation and build a system that feels genuinely trustworthy. We realised our previous approach (i.e. only showing the total number of reviews from the past two years) was creating this exact paradox. Dealers, who had built a long history of excellent service, felt like their past accomplishments were being completely ignored, not giving them the corresponding credit for their relentless effort. And our users, the buyers, were missing the full story. They were making decisions with only a fraction of the available information, which undermined their confidence.

We knew we had to do better. So we made a simple but critical change.

We now display the total number of reviews a dealer has ever received, right next to their star rating. This one metric provides an immediate, powerful signal of a dealer’s credibility and experience. It gives dealers the credit they’ve earned over their entire history and gives buyers the complete picture they need to feel confident.

Of course, recency still matters. That’s why we still calculate the star rating based on reviews from the last two years. This dual approach gives users the best of both worlds: a comprehensive view of a dealer’s long-term reputation and a look at their recent performance.

(Screenshot sample of about the dealer section from mobile.de)

Since we launched this feature, the feedback from our dealers has been incredible. Many have noted that they are now receiving a significant increase in reviews and feel a renewed sense of pride in their complete history.

For us, the Trust & Safety team, this project is a reminder that user trust isn’t built on a single score; it’s built on a foundation of transparency, context, and a complete picture. It’s about empowering our users to make confident decisions, one review at a time.

Special thanks to Gonzalo, Bishal & Ana for reviewing the first draft of this article.

Rebranding on Android Apps — Behind the Scenes

Kleinanzeigen & mobile.de — Fri, 15 Aug 2025 08:24:35 +0000

an article by Hannah Olukoye

Rebranding an app is no small feat, especially when it involves overhauling the design, implementing a dark theme, and addressing years of technical debt. To understand the challenges, strategies, and lessons learned during our recent rebranding phase, I sat down with one of our Android architects, who shared the team’s experience navigating this transformative project.

Q: How did the rebranding affect the existing theming architecture, and did it require any major refactoring?
The rebranding wouldn’t have been possible without prior refactoring. Before this, there was no clear structure or guidance on styling components, which also prevented us from enabling dark mode in the Android app. We had too many redundant styles, along with legacy and custom UI components that were inconsistent.

One of the first steps was to dissolve these legacy components and adopt Material Components. This allowed us to consolidate patterns, such as applying consistent styles to contact form inputs. We also established a proper definition of styles and themes in the app, creating distinct files for specific components and aligning our terminology with the Design System. This made it easier for developers to translate Figma designs into Android layouts.

Each component was tackled individually — new styles were applied, and old, unused ones were removed. I also communicated with the team about which styles to use and how to implement them. Sometimes, this required layout changes to make the new styles work, which turned into a bigger effort than I initially expected. Interestingly, I ended up reducing technical debt from 8 years ago in the process. (Impressive!)

The rebranding itself was the final step and took only two weeks to implement once the base refactoring was done. While some adjustments and corrections were necessary, the effort was minimal compared to the groundwork we laid beforehand.

Q: What architectural decisions guided your theme implementation strategy, especially regarding modularization, reuse, and support for feature-based theming?
From a modularization perspective, not much changed. We already had our Android resources centralized in a single module accessible to all feature modules. While text and icon assets are often feature-specific, we decided to keep everything in one place.

A key decision was adopting a clear naming scheme to distinguish components, types, and themes while differentiating our style definitions from those inherited from the Material Components library. This naming scheme followed the Design System conventions, making it easier to maintain consistency.

By default, we apply base definitions to components and set specific attributes directly rather than creating additional styles, which had previously cluttered our style definitions. When custom changes are necessary, they’re extended within the feature module while adhering to the same naming scheme.

Consistency was key. Hardcoded values, especially colours, were avoided to ensure support for dark mode and dynamic themes. Developers used token-based definitions tied to system settings. I also reduced icon assets by consolidating them and applying consistent tinting, replacing previously duplicated, hardcoded versions. Special design requests were evaluated collaboratively to see if they could align with the Design System. Simplicity remained our core principle.

Q: How did you test theme behaviour across different devices, screen sizes, and Android versions? Were there any tricky bugs or edge cases?
For development, I primarily tested on one emulator with standard settings. Since we use Material Components, I assumed changes would work similarly across older Android versions for individual components. For larger changes, I tested on older versions and tablets as well. I also went through layouts multiple times, testing repeatedly since components were tackled one by one.

UI tests helped ensure functionality wasn’t broken, and I relied on the Android chapter to test changes in their respective feature areas. Before releases, I used BrowserStack to test on a variety of devices.

That said, there were challenges. Some widgets, like content cards, weren’t fully updated or cleaned up, which caused issues when testing dark mode. Problems with background colours and missing tint colours were common. Dialogs were particularly tricky — there were many types, each with different implementations and styles, which required significant effort to fix.

Custom implementations, such as spans or UI inflated in code instead of XML, were another pain point. Finding these usages and ensuring proper styling often required adding extra code. Despite these challenges, properly migrated components worked fine.

Q: What key lessons or best practices did you learn from this redesign, and what would you do differently if starting from scratch?
One of the biggest lessons is the importance of early involvement with UX. Understanding what’s coming and getting an initial sense of task complexity helps immensely. Close collaboration with UX throughout the project is also invaluable for resolving unexpected issues or missing assets.

Another key takeaway is to stick to defaults. Use what the platform and design library offer rather than working against them. This not only ensures backward compatibility but also improves accessibility.

Regularly updating to the latest versions of libraries is crucial. It fixes bugs and introduces new features that can enhance the app. Additionally, having a clear set of defined styles applied consistently across the app is a must. When changes are needed, they should be made in the base style, so all components are updated simultaneously.

If I were starting from scratch, I’d likely use Compose from the beginning. While it’s just a different approach to styling, the same principles around themes, styles, and components would still apply. Compose offers a more modern and flexible way to build UI, which could streamline the process further.

This rebranding effort — along with the introduction of dark theme — gave the app a fresh, modern look while laying the groundwork for a more maintainable and scalable design system. The lessons learned and best practices established during this phase will continue to influence and elevate Android development at our company.

You can experience the new design by downloading the mobile.de app on Android and iOS

Many thanks to Thomas Rebouillon for sharing his insights and contributions throughout the rebranding process.

Building Bridges: How a Team Charter Transformed Our Communication

Kleinanzeigen & mobile.de — Tue, 10 Jun 2025 09:43:30 +0000

an article by Hannah Olukoye

As an Engineering Manager, I recently led a communication training session for my team in collaboration with an agile coach. Our aim was to examine our interactions more closely, identify areas for improvement, and co-create a team communication charter.

The session proved to be an incredibly valuable experience, helping us foster stronger alignment, mutual understanding, and a clearer framework for our work together.

In this article:

I will share key learnings and helpful tips through our team experience
I will share links to a template we used in our team to guide the discussions

If you’re considering a similar initiative with your team, I hope our journey offers both inspiration and a practical starting point to help foster more intentional, effective communication.

Setting the Mood

When I planned this communication training session for our team — with the support of an agile coach, I wasn’t entirely sure what to expect. We knew we wanted to improve how we interacted, especially in moments of tension, but what emerged from the session far exceeded those intentions. The room quickly shifted into a space of openness, curiosity, and reflection as we dove into what truly drives — and derails — effective communication.

Unpacking the Discoveries

One of the most eye-opening exercises was exploring how we each tend to communicate in conflict. Guided by our agile coach, we examined four core styles: Aggressive, Passive, Assertive, and Passive-Aggressive.

AGGRESSIVE

Dominates
Interrupts
Ignores opinions

ASSERTIVE

Speaks clearly
Advocates for self & others

PASSIVE-AGGRESSIVE

Mixed signals
Indirect
Confusing

PASSIVE

Avoids conflict
Doesn't speak up
Prioritizes others

We saw how aggressive communicators can appear confident but often override others’ voices. Passive communicators avoid confrontation, sometimes to the detriment of clarity. Passive-aggressive behaviour sits in the murky middle — indirect, and often confusing.

But the real breakthrough came with assertiveness: direct, clear, and respectful communication that makes space for both expression and listening. It became our shared ideal.

In another exercise, we mapped out our individual communication profiles: Analytical, Amiable, Expressive, and Driver. Each style brought its strengths and challenges:

Analyticals value logic and precision, but may be slow to act or overly critical.
Amiables foster harmony and empathy, yet can shy away from necessary conflict.
Expressives infuse energy and creativity, though they may lack follow-through.
Drivers are focused and decisive, but risk being perceived as overly forceful.

[ ANALYTICAL ]
🧩 Logic-driven
⚠️ Critical

[ AMIABLE ]
💙 People-first
⚠️ Over-accommodating

[ EXPRESSIVE ]
🌟 Creative buzz
⚠️ Lacks detail

[ DRIVER ]
⚡ Results focus
⚠️ Too pushy

As we explored these styles, we realised much of our past communication friction wasn’t due to misalignment, but rather a clash of unspoken styles. It wasn’t dysfunction — it was difference.

Putting Everything Together

By the end of the session, the fog had lifted. We understood more about how each of us communicates — especially under stress, and how to adjust our approach with others in mind. These insights became the bedrock for our Team Canvas: a set of shared, written agreements that define how we want to show up in conversations, give feedback, and navigate conflict.

It’s not a perfect science, but it’s a huge step forward. Now, when tension arises, we don’t just react — we pause, remember what we’ve agreed on, and approach each other with more empathy and intention.

Template from TheTeamCanvas Website

. . .

Understanding and Resolving Infinite Consumer Lag Growth on Compacted Kafka Topics

Kleinanzeigen & mobile.de — Tue, 25 Jun 2024 08:55:42 +0000

an article by André Charton

Kleinanzeigen has been using Kafka since 2016 as a distributed streaming platform of choice. We have many real-time data pipelines and streaming applications running on top. Some of our topics are compacted...

What is a compacted topic?
A compacted topic in Apache Kafka is a special type of topic where Kafka’s log compaction feature is enabled. It helps retain the latest records for each key in the topic while removing older records for the same key. This pattern we apply for topics in front of our ElasticSearch indices, so we can use it as a scalable source of truth to index and also full index.

What is consumer lag?
Consumer lag is a metric that measures how far behind a consumer is from the latest message in a Kafka topic/partition. It holds the number of messages that the consumer needs to process. Sometimes we see a lag increase, while an application bottlenecks, on network issues, etc.

Per default monitoring consumer lag ensures that consumers are keeping up with the producers. We expose this metric for our clusters and have it in Prometheus, visualised in Grafana.

What is an offset reset?
In Apache Kafka, an offset reset refers to the operation of changing the current offset position for a consumer group. The offset determines the position from which the consumer will start reading records from a partition. This strategy we can perfectly use to execute a full index on our indices, described above.

Why infinitive growth?
Since we using Kafka 8+ years, some topics getting older and older. A compacted topic for instance containing user posted ads (used by full index our major search index). With the years we see on full index operation the lag is getting bigger and bigger. Recently we saw numbers above 400M. We wondered, getting nervous and invested. But it happens by the nature of combing a compacted topic and offset reset.

Over time the distance between “now” and the oldest record will growth until the oldest record is gone. We have some user ads from even before 2016, because user can extend ad lifetime again and again. So when we perform an offset reset, a consumer will start at the beginning: [0], in the sample below at [2]. Our log metric would show a lag of [8] still it just needs to produce 3 records. So this explains the spike we saw in Grafana metric which measures “just” the offset.

Conclusion
Be careful on the interpretation of lag metrics on compacted topics in case of offset reset. In our example of a full index and lag of 400M, we count just less than 60M records get processed.

Another option could be to rewrite the topic using MirrorMaker and a new topic name. But we are fine with understanding here.

Special thanks to my colleague Daniil Roman who inspired me to this article.

“Data has a Dream” — A Short comic about data mesh and how it can transform your company

Kleinanzeigen & mobile.de — Mon, 18 Mar 2024 19:42:49 +0000

a little data story by Markus Schüler (Director of Data Strategy Adevinta) with drawings by Gitanjali Venkatraman (Technology Writer and Illustrator at ThoughtWorks)

The profound impact of Data Mesh and its associated principles

domain data ownership
data as a product
self-serve data platform
federalised data governance processes

are currently reshaping our industry landscape. Amidst this revolution, the most important realisation at mobile.de was that the key to a successful Data Mesh implementation was bringing our people along on that journey — no matter if that is the C-level leadership team or members of our product and tech teams. And for that we need to convey the benefits of data mesh in simple terms, avoiding the pitfalls of cryptic data terminology.

Out of this realisation, a whimsical idea was born — a comic that breaks down these fundamental principles and illustrates their transformative power but in a unique and accessible way. Teaming up with the passionate Data Mesh enthusiasts at Thoughtworks, where the concept of Data Mesh first came to life, we are thrilled to present “Data has a Dream” our very own Data Mesh comic:

A heartfelt thank you goes out to the individuals who made this possible: Special appreciation to Gitanjali Venkatraman for infusing life into little data’s journey with her incredible drawings and amazing skill to simplify complex terms. Also to Chris Ford and Magno Mathias for believing in my seemingly crazy idea and tuning it into a tangible reality. And finally to my amazing teams at mobile.de and Adevinta, who made me embark on the journey of learning more about data mesh through them.

Better Search Relevance using Learning To Rank at mobile.de

Kleinanzeigen & mobile.de — Thu, 29 Feb 2024 11:16:54 +0000

Written by Manish Saraswat

At mobile.de, we continuously strive to provide our users with a better, faster and a unique search experience.

showing mobile.de search engine

Every day, millions of people visit mobile.de to find their dream car. The user journey typically starts by entering a search query and later refining it based on their requirements. If the user finds a relevant listing, they contact the seller to purchase the vehicle. Our search engine is responsible for matching users with the right sellers.

With over 1 million listings to display, finding the top 100 relevant results within a few milliseconds is an immense challenge. Not only do we need to ensure the listings match the user’s search intent, but we also must honour the exposure guarantees made to our premium dealers in their sales packages.

Identifying the ideal search results from over 1 million listings quickly while optimising for user relevance and business commitments requires an intricate balancing act.

In this post, I would like to share how we are building learning to rank models and deploying them in our infrastructure using a python microservice.

What motivated us?

Our current Learning to Rank (LTR) system is integrated into our ElasticSearch cluster using the native ranking plugin. This plugin offers a scalable solution to deploy learning to rank models out-of-the-box.

While it has provided a solid foundation over several years, we have encountered some limitations:

Our DevOps team faced plugin integration issues when upgrading ElasticSearch versions
There is no automated model deployment, requiring manual pre-deployment checks by our data scientists. This introduces risks of human error.
Overall system maintenance has become difficult
The infrastructure bottlenecks limit our data scientists from testing newer ML models that could improve relevance

Clearly, while the native ElasticSearch ranking plugin gave us an initial working solution, it has become an obstacle for iterating and improving our LTR capabilities. We realised the need to evolve to a more scalable, automated and flexible LTR architecture.

This would empower our data scientists to rapidly experiment with more advanced ranking algorithms while enabling easier system maintenance.

How did we start?

Realising our outdated search architecture was the primary obstacle to improving relevance, we knew a pioneering solution was needed to overcome this roadblock.

We initiated technical discussions with Site Reliability Engineers, Principal Backend Engineers and Product Managers to assess how revamping search could impact website experience.

Our solution had to balance speed with business metrics. We needed to keep search fast while improving key conversions like unique user conversion rate.

Based on the feedback, we decided to decouple the relevance algorithm into a separate microservice. To empower data scientists and engineers, we chose Python to align development and production environments closely while ensuring scalability.

Implementing Learning to Rank

There are several techniques to implement learning to rank (LTR) models in python. Up until a few years ago, we were using a pointwise ranking approach, which worked well for us.

showing pointwise loss

Last year, we decided to test a pairwise ranking model (trained using XGBoost) against the pointwise model and it outperformed in the A/B test.

showing pairwise loss

This gave us good confidence to continue using the pairwise ranking approach. Also, the latest XGBoost version (>=2.0) provides lots of cool features such as handling position bias options while training the model. Also, since XGBoost supports using custom loss function, we trained the model using a multi objective loss function.

In our case, our objectives are set to listing relevance and dealer exposure. As mentioned above, we try to optimise the balance between showing relevant results and showing our premium/sponsored dealers at top positions.

Training the models in the jupyter notebook is the easy part. We can use all the features we need and build a model. However, as a data scientist, we should always ask ourselves, will these features be available in production? Approaching a machine learning (ML) model from a product perspective helps to tackle lots of problems in advance.

Keeping the features feasibility in mind, we decided to test the model with following raw and derived features:

Historical performance of the listing
Historical performance of the seller
Listing attributes (make, model, price, rating, location etc)
Freshness of the listing
Age of the listing (based on registration date)

When tested offline using NDCG@k metric, we found that these features gave us a good uplift as compared to the existing model. We always aim for uplift in offline metrics before testing the model online in an A/B test, this helps us to iterate faster.

How did we serve the models?

We learnt that serving a machine learning model has multiple aspects:

Ensuring the model has access to features array to predict
Ensuring the model is trained periodically to learn the latest trends in the business

To tackle the above aspects, we used airflow to schedule our ETL jobs to calculate features. Due to the choice of our features, we were able to precompute the feature vector and store it in a feature store. To summarise, we had to setup following jobs:

To fetch latest information, every new update of a listing is pushed to a kafka stream, we consume this stream using a python service to update our feature array
Another task reads these updated feature arrays, generates prediction and store them into our feature store
Training job retrains the model once a week based on optimised set of parameters, adds versioning to the model and stores it in gcp bucket.

showing data pipelines for model training and feature generation

We created a microservice (API) using FastAPI to serve the models. You might ask why not Flask? We have been using FastAPI for quite some time now and haven’t found any bottleneck yet to think about other frameworks. Also, FastAPI framework has quite solid documentation where they also share the best practices to build an API.

Our service workflow looks like the following:

The development work for FastAPI happened in Python.
The code gets pushed to github. Using CI pipelines integrated with linting test, unit testing, integration testing we make sure every new line of code pushed is tested. Also, the code gets packaged into a docker image and gets pushed to a registry.
Deploy the docker image on kubernetes (although this part is mainly handled by our site ops team).
Track the service health metrics using grafana dashboards.

showing ranking service latency over 24 hours

Show me the results

We were also waiting to see if our months of hard work was going to make an impact. We decided to launch an A/B test for two weeks. At mobile.de, the best part of being a data scientist is that you are involved in the end to end process.

After putting all the pieces together, we launched an A/B test for two weeks and recorded positive significant improvements in the business metrics. For example, while not affecting the SRP (search result page) performance — microservice responding under 30 milliseconds at p99, the new search relevance algorithm generated:

showing change in metrics post A/B test

showing user replies and parking buttons on car listings

This uplift is special for the team because the baseline we were competing against was already providing solid results. Given the significant uplifts in our metrics we strongly believe that the team has done a tremendous job in improving the search relevance for our users. That is, making it easier for our users to find the right vehicle and contact the seller.

End Notes

In this post, I shared our experience building learning to rank models and serving them using a microservice in python. The idea here was to give you a high level overview of the different aspects we touched during this project.

All of this would have not been possible without an incredible team. Special thanks to Alex Thurm, Melanya Bidzyan, Stefan Elmlinger for contributing to this project at different stages.

In case you have questions/suggestions, feel free to write them below in the comments section. Stay tuned for more stories :)

Embracing Growth and Learning: My Journey as a Software Developer Trainee

Kleinanzeigen & mobile.de — Mon, 07 Aug 2023 14:56:55 +0000

Hello, I’m Simona, and I’m thrilled to share my journey as a Software Developer Trainee at mobile.de (part of Adevinta). As a passionate learner and adventurer, I’ve ventured on an incredible path of growth and transformation. With a background in hospitality management and a newfound passion for web development, I’ve discovered a world of possibilities at the Trainee programme. Join me as I reflect on my experiences, both past and present, and the invaluable learning opportunities I’ve encountered along the way.

That’s me, Simona.

Nurturing Curiosity through Coding

Born and raised in Lithuania, my adventurous spirit led me on a journey far from home. I studied Archaeology in university, always driven by a curious nature and a thirst for new experiences. Over the past decade, I’ve lived in six different countries, immersing myself in different cultures and working in hospitality management. These experiences taught me resilience, adaptability, and the art of building a home from scratch in unfamiliar places.

A Turning Point

However, there came a point when I realised that the places I lived no longer challenged me enough. I was craving something more, something that could ignite my passion and drive. Little did I know that the answer would lie in the world of technology. Despite not having a background in IT, I’ve always had a fascination with the field. In my youth, I was drawn to mathematics and dreamed of the possibilities of coding, but societal norms at the time discouraged me from pursuing it.

An Unexpected Passion Unveiled

During the COVID-19 pandemic, I stumbled upon an online marketing and web development course. Intrigued by the potential connections with my hospitality background, I enrolled. It turned out that this accidental discovery would reveal a long-suppressed passion. As I delved into coding, I became captivated by its intricacies and limitless possibilities.

Embracing Change

Driven by a newfound fascination, I made the bold decision to transition into a career in web development. Despite the doubts that crept in about my late entry into the field and societal biases, I chose to embrace the challenge. I enrolled in a one-year web development coding bootcamp and dedicated myself wholeheartedly to learning this exciting new craft. The journey was not without its difficulties, but the satisfaction of conquering challenges and the joy of finding creative solutions to complex problems fuelled my determination.

Joining mobile.de, part of Adevinta

Today, I am proud to be a part of mobile.de and so Adevinta. As a Software Developer Trainee, I have found a supportive and inclusive community that values diversity and fosters personal growth. Adevinta’s commitment to include everyone, especially empowering women in tech, resonates deeply with me. I want to inspire other women to break barriers, challenge societal norms, and pursue their passions fearlessly.

Our trainee cohort 2022 during their onboarding.

Contributing to a Trusty Digital Space

In my role as a frontend engineer with mobile.de’s Trust & Safety team, I have the privilege of working alongside experienced professionals on meaningful projects. During my first rotation, I have been actively involved in developing and enhancing features that promote trust within our platform. It’s truly fulfilling to know that our team work contributes to establishing a secure and reliable digital space for our users.

Our Trust & Safety team at a team building event.

Inclusive Collaboration, Agile Practices, and Mentorship

In my experience at mobile.de, collaboration, agile practices, and mentorship are highly valued. The company promotes a culture of continuous learning and collaboration, where agile methodologies are embraced in our development processes. We have quarterly innovation days that allow employees from all departments to pitch ideas and collaborate, fostering creativity and cross-team cooperation for innovative solutions. Weekly Frontend Guild meetings ensure alignment, share best practices, and keep our code base up to date, creating an efficient and cohesive development environment.
One aspect that has greatly contributed to my personal and professional growth is the regular one-on-one meetings with my assignment lead and mentorship in pair programming sessions. These interactions have not only enhanced my problem-solving skills but also provided valuable guidance and support whenever I’ve felt overwhelmed or stuck. Additionally, the regular retrospectives provide an inclusive platform for every colleague to voice their opinions, enabling us to identify areas of improvement and make necessary adjustments to enhance our work-life balance and productivity.

Community Building and Talent Development

Adevinta prioritises community building and talent development, exemplified through events like the Early Careers conference where I had a pleasure to attend. This conference brought together trainees and early-career professionals from various locations, providing workshops focused on talent development and opportunities to share personal and professional experiences. It not only expanded networks but also enriched perspectives on the broader level of the company, fostering connections and growth within the community.

Snapshot from the Adevinta Early Careers conference.

Embracing the Journey

As I continue my journey as a Software Developer Trainee, I am constantly reminded of the importance of embracing growth and learning. Every day brings new challenges and opportunities to expand my knowledge and skill set. I am grateful for the supportive mentor, manager and a whole network of colleagues who are always willing to share their expertise, encourage to explore and help me overcome obstacles.

My experience as a Trainee has been transformative. From my diverse background in hospitality to my newfound passion for web development, I have grown both personally and professionally. Adevinta and mobile.de has provided me with a platform to pursue my goals, embrace change, and inspire others to join the dynamic field of technology. I encourage everyone, regardless of their gender, background, or age, to never shy away from pursuing their passions in tech. With Adevinta’s great example and unwavering commitment to diversity, inclusivity, and personal growth, the possibilities are limitless.

I will never shy away!

Hadoop Migration: How we pulled this off together

Kleinanzeigen & mobile.de — Sun, 16 Apr 2023 11:00:15 +0000

A short guide to help understand the process of migrating old analytical data pipelines to AWS by following the Data Mesh strategy.
by Aydan Rende, Senior Data Engineer at eBay Kleinanzeigen

Hadoop was used as a data warehouse in a few marketplaces in the former eBay Classifieds Group (now part of Adevinta) including eBay Kleinanzeigen for a long time. While it served analytical purposes well, the central teams wanted to say goodbye to this old friend. The reason was simple: it was old and costly.

Before diving into the solution, let’s take a look at eBay Kleinanzeigen’s Hadoop data pipeline:

Deprecated Hadoop data pipeline

The monolith is the main backend service of eBay Kleinanzeigen. It has several Kafka topics and produces analytical events in JSON format to the Kafka Cluster.
These topics are consumed and ingested to Hadoop by the Flume Ingestor.
The monolith runs scheduled jobs every midnight to fetch and aggregate the analytical data.
Finally these aggregates are stored in KTableau which is a MySQL database.

I have marked the problematic components of this pipeline in dark magenta:

Hadoop is not maintained by Cloudera and runs as an old version, which means that the maintenance costs extra.
Kafka cluster is on-prem and again in the old version (v1). We had a strict deadline from the DevOps team to shut down the cluster because the hardware reached its end of life.
KTableau is not a Tableau instance, it's a non-maintained on-prem MySQL. I have marked this in pink because this is the next one to get rid of. (K-Tableau: K comes from Kleinanzeigen)
On-prem monolithic service is the main serving point of the eBay Kleinanzeigen platform. It's a bottleneck, however. The service also runs analytical jobs, but mostly fails silently.

The problems I have outlined give good reasons to change the data setup, as the entire company is, as a matter of fact, in the process of cleaning up and moving away from on-prem to AWS, from monolith to microservices etc. So why not clean up the old analytical data pipeline as well? Yet, we had a teeny tiny issue to deal with; our Data Team was relatively small, so the question was „How do we pull this off together in a short time?"

Data Mesh to the Rescue

Data Mesh is a decentralised data management paradigm that allows teams to create their own data products suited to the company policies by using a central data infrastructure platform. This paradigm aligns with Domain Driven Design which eBay Kleinanzeigen successfully implements for the teams. The teams own a domain and they can also own domain data products as well.

Data Mesh is not new to Adevinta (our parent company). Adevinta's central teams already provide a self-serve data platform called DataHub and the marketplaces use this platform autonomously. It has several managed data solutions from data ingestion to data governance. Our task was to learn and create a new data pipeline with these services. However, we also wanted to use dbt for the transformation layer of the ETL process in addition to the services provided because we wanted to keep the transformation layer neat and versioned.

This migration seems to be more important because it's the beginning of the Data Mesh strategy at eBay Kleinanzeigen. It's great that our teams already own domains, but owning data products is new to them. Therefore, we decided to create a proof of concept, migrate the existing datasets from Hadoop to the new design and explain to teams the ownership of data.

The New Design

Data pipeline of a domain

The new design looks more complicated, but, in fact, it's easier to adopt by the teams, as they can reach out to the central services and integrate with the entire data ecosystem that exists in Adevinta. Hence, it provides data ownership out of the box.

In the new design:

The backend services already use Kafka to emit events, however, the new Kafka cluster is on AWS and is „managed" which means that maintenance of the cluster is taken care of by the central teams.
Scheduled jobs are run in Airflow in a more resilient way. It's better to trace the logs and get notified of errors on Airflow. We no longer need to dive into logs of the big monolith backend service where it is polluted by the other service logs.
Data transformation is performed in dbt instead of the backend services. Data analysts can go to the dbt repository and check the SQL queries instead of reading through the backend service code to understand the reporting query.
We leverage the central services as much as possible to reduce the DevOps effort and costs.

With these changes, we not only deprecate the old Hadoop instance, but also take the analytics load away from the backend services, which are supposed to be busy with the business transactions anyway, not the analytical transactions.

Managed Kafka

Managed Kafka is a data streaming solution that is an AWS Kafka Cluster and is owned by the Adevinta Storage Team. The central team offers maintained secure Kafka Clusters, provides metrics and on-call services. All we need to do is create new Kafka topics to replace the old Kafka topics running on-prem. We have also changed the record type: it was JSON in the old setup, but we decided to use AVRO to have schemas available in the repositories with the version control system (Github in our case).

Metrics of the Managed Kafka Cluster

DataHub Sink

Sink is an in-house event router that consumes Kafka topics, transforms, filters events and stores them inside the S3 bucket or another Managed Kafka topic. In this phase, we collect the raw data, convert it to Delta format and store it to our AWS S3 bucket with a sink. Delta format gives us ACID (Atomicity, Consistency, Isolation, and Durability) properties that guarantee a consistent version of the tables at any read time, even in case of concurrent writes. It thus avoids inconsistent or incomplete reads.

Databricks

Databricks is an analytical data service that provides data lake & data warehouse capabilities together in one platform. This was not an ideal choice for our setup, if you consider that we already have an AWS Data Lake. Databricks is not offered by Datahub, but by another central team. It has already been used by our data analysts, so we tried to stick with that and mounted Databricks to our S3 bucket instead. Once the delta files are collected under the S3 path, we create a table in Databricks. You can read more about the mounting in this document.

Data Build Tool (dbt)

dbt is a data transformation tool that enables data analysts and scientists to run transformation workflows while benefiting from the software engineering practices such as collaboration on data models, versioning them, testing and documentation. dbt also provides a lineage graph between fact and dimension tables so that dependencies can be visualised in the document generated.

We created a dbt repository that has several SQL models and is integrated with Databricks. We implemented the CI/CD pipeline with Github actions so that every time we release a new model in dbt, a docker image is created together with the entire dbt repository, secrets and dbt profile and then this image is pushed to Artifactory. The image is later fetched by the Airflow operator and is run in a schedule. Another great feature of dbt is that we can easily switch the warehouse setup from Databricks to Redshift in the future by making only a few changes.

Airflow

Airflow is a great job orchestration tool and a managed version of Airflow is offered by Adevinta central teams. Managed Airflow is a managed Kubernetes cluster that comes with the Airflow service and a few operators configured out of the box. In the managed cluster, it is difficult for us to install packages on our own. We need to request this from the owning team. We are also not the only tenants in the cluster, which means that, even if the central team agrees to install the required packages, a package conflict can affect the other tenants. That's why we decided to run dbt within a docker container with the KubernetesPodOperator. It's also a best practice to containerise as much as possible due to Airlflow's instabilities, which are described in this blog post in more detail. KubernetesPodOperator instantiates a pod to run your image within the Kubernetes cluster. This gives us the ability to create an isolated environment so that we can install whatever dependency we want to in order to execute the dbt command.

Here is an example of a DAG in Airflow that we executed to produce a data mart sent by email:

namespace = Variable.get("UNICRON_NAMESPACE", default_var="NO_NAMESPACE")
environment = Variable.get("UNICRON_USER_ENV", default_var="NO_ENV")
docker_image = Variable.get("DBT_DOCKER_IMAGE", default_var="NO_IMAGE")

default_args = {
   'owner': 'det',
   'depends_on_past': False,
   'email': ['some.email@adevinta.com'],
   'email_on_failure': True,
   'email_on_retry': False,
   'retries': 3,
   'retry_delay': timedelta(minutes=5),
}
with DAG(
       dag_id=os.path.basename(__file__).replace(".py", ""),
       default_args=default_args,
       description='Generates Kleinanzeigen email send-out analytics report for the last day',
       schedule_interval="0 3 * * *",
       is_paused_upon_creation=False,
       start_date=datetime(2023, 1, 3),
       on_failure_callback=send_dag_failure_notification,
       catchup=False,
       tags=['belen', 'analytics', 'email_sent', 'dbt_image'],
) as dag:

   test_email_sent = KubernetesPodOperator(
       image=docker_image,
       cmds=["dbt", "test", "--select", "source:ext_ka.email_sent", "-t", environment ],
       namespace=namespace,
       name="test_email_sent",
       task_id="test_email_sent",
       get_logs=True,
          image_pull_secrets=[k8s.V1LocalObjectReference("artifactory-secrets")],
       dag=dag,
       startup_timeout_seconds=1000,
       )

   execution_mart = KubernetesPodOperator(
       image=docker_image,
       cmds=["dbt", "run", "--select", "mart_email_sent", "-t", environment ],
       namespace=namespace,
       name="execution_mart",
       task_id="execution_mart",
       get_logs=True,
      image_pull_secrets=[k8s.V1LocalObjectReference("artifactory-secrets")],
       dag=dag
       )

   test_mart = KubernetesPodOperator(
       image=docker_image,
       cmds=["dbt", "test", "--select", "mart_email_sent", "-t", environment ],
       namespace=namespace,
       name="test_mart",
       task_id="test_mart",
       get_logs=True,
       image_pull_secrets=[k8s.V1LocalObjectReference("artifactory-secrets")],
       dag=dag
       )

   test_email_sent >> execution_mart >> test_mart

The only disadvantage of running dbt in a Kubernetes pod is that you are not able to see the fancy lineage graph of dbt while the steps are executed, as in dbt Cloud. However, the dbt models are generated separately in the Airflow DAG, so you can still see the failing steps and integrate Slack Webhook to receive notifications. Besides, a Github action can be configured to generate dbt docs every time a change is made in the main branch.

Summary

In this blog post, we provide a short guide to help you understand the process of migrating eBay Kleinanzeigen's old analytical data pipeline to AWS by leveraging Adevinta's Data Platform.

Basically, in our new data pipeline, we:

collect events with Kafka topics,
convert to Delta and store in S3 buckets with a Data Sink,
create Databricks tables of the stored S3 locations,
create data models with dbt and store in Databricks (again in an S3 bucket)
run the dbt models in a schedule with Airflow

The data marts produced are available in Databricks where analysts can easily access and create a Tableau dashboard. While Databricks is an interface to the analysts, it lacks visibility to the other teams. In the future, we plan to integrate a Glue crawler into our S3 bucket so that we can register the datasets in the data catalogue and achieve integration with the access management services of Adevinta.

So, what's next?

Please, keep in mind that Data Mesh is an approach. As such, it may differ based on the company setup. Thanks to the self-service data infrastructure of Adevinta, however, we were able to migrate from Hadoop to AWS in a quite a short period of time with a very small team.

The next step for our team is that we need to:

make the pipeline easy to integrate with all domain teams
give the teams the necessary technical support
explain the Data Mesh strategy and the importance of data products
and make sure the domain teams own the data products by testing, documenting and cataloguing properly.

Changes are difficult to make, especially the conceptual ones, but if we want to quickly scale and work with the high volume, diverse and frequently changing data, we will need to do this together.

Celebrating a Decade of Creativity

Kleinanzeigen & mobile.de — Tue, 14 Feb 2023 10:33:46 +0000

Over 100 days of collaboration, development & fun

Recently, we marked a significant milestone in our company’s history: the 10th celebration of our Innovation Days. With over 100 days of teamwork, growth, and enjoyment behind us, we felt it was the perfect moment to share our story with others. Nina Maaß, a talented software engineer and member of the organising team, was kind enough to share insights on how our internal hackathon started and why it continues to be successful.

Nina, could you tell us about the origin and motivation behind the founding of the Innovation Days at mobile.de?
“Everything started in December 2012. At that time — inspired by a blog post about slack-time* — and under the name of ‘Consumer Slack-Day’ all Product and Tech Teams had the chance once a month to work on the topic they normally don’t have time for. Over the years the format and name changed. With big support from management and organised by highly engaged colleagues, ‘Innovation Days’ became an important part of our Product and Tech culture.”

How does the format of the Innovation Days look like today?
“Currently, the Innovation Days take place on three consecutive days once per quarter. The days are mostly joined by our Product and Tech teams, but also by colleagues from other business units. Over the years not only has the company grown but also the number of participants. Last time around 50 people contributed and over 170 people joined the presentations.”

The numbers are impressive — why do you think it’s so successful?
“One of the golden rules and basis for its long-term success has always been: ‘When you’re at Innovation Days, you’re at Innovation Days. No daily business except P1 bugs!’ The three days shouldn’t be interrupted by meetings or any other activities.”

Three days sound like a lot of time — how are the days structured?
“Innovation Days actually start long before that. We send out invitations up to three weeks in advance. From that moment on, people can add topics with short descriptions into a list of potential projects and can already set up teams.
Then, on the first day in the morning we start with the idea pitches. Every single person or team presents their topic with the request to join. It’s important to know that the pitches are not an ‘automatic’ registration for the final presentation, because ideas can also change or be discarded. The decision whether something will be presented can be decided up to the end of Innovation Days.
For newcomers we offer a brief summary beforehand: ‘Innovation Days in a Nutshell’ explains what all the fuss is about. After the idea pitches, the assembled teams or single contributors start working. What follows is, what we call: Happy Development! Two days of fun bringing your idea to life. In the Pre-Covid time everyone was meeting in the office and worked as long as there was pizza and drinks.
On the third and last day up into the afternoon everyone has still time to work on the projects until the final presentation. The topics needed to be handed in a second time up to 30 minutes before. Every team or single contributor gets the chance to present their results.”

How would you describe the presentation?
“The final presentation is about knowledge sharing and learning. Not only successful projects, but also failures or detours are given room and attention. But of course, Innovation Days are also a challenge. At the end of the final presentation the winners are selected by voting. We’ve determined two categories for outstanding achievements taking into account different team sizes: ‘Winning Team’ for teams with more than three members and ‘Honourable Mention’ for smaller teams or single contributors. With this we want to encourage and reward ideas from everyone.”

If others would like to adopt this concept, could you share some best practices organising an event like this?
“Through the years the setup was adapted to the requirements. Currently, we are two people — me and my colleague Daniel Korger. I have been in the orga team since the end of 2019 and Daniel since the beginning of 2020.
We coordinate Innovation Days with management at an early stage in order to avoid conflicts with other company events and of course, daily business. We communicate the event through Slack and — not to underestimate — word of mouth. We send out calendar invitations. We are the moderators for the idea pitches and the final presentation. We accompany the event in all aspects. Our ambition is to constantly improve the event in order to provide the community with the space to work on their projects in an undisturbed and focused way.”

You mentioned earlier that Innovation Days used to take place in the office. How is it currently being carried out?
“Pre-Covid, Innovation Days were held alternately in one of our offices in Berlin or Dreilinden. However, even then we saw a trend towards remote contribution, so we were well prepared for the ‘home office’ time.
Now Post-Covid, Innovation Days are a remote event, but we start to create more and more of a hybrid experience. That means, who wants to work from the office, is free to do so and many colleagues use this opportunity.”

Ten years of innovation — there must be a bunch of great ideas. What happened to all those results?
“What happens to the projects after Innovation Days is always different and based on the context. The spectrum ranges from exploration of technology or concepts through prototypes or proof of concepts of single features up to tools to improve our daily work. If a project result is promising, the potential is discussed with stakeholders and business owners and prioritised accordingly. And then there are also teams that use the next Innovation Days to continue working on their project in order to improve it or gain new insights.”

Do you remember a project, which made it into the mobile.de platform or the company’s strategy?
“Yes, the project ‘Green Mobility’ is now part of our roadmap.”

What is the best thing about Innovation Days?
“For me personally, the best thing about the Innovation Days is the community and the support from management. Without this, the event would not be possible and could not have become part of our mobile.de culture. Furthermore, I am always impressed by the results as well as by some colleagues, who jump over their shadows and overcome their fear of talking in front of bigger groups.
And, I will not forget the year, when the tech leadership team tried to participate despite a full calendar, but ended up in front of the whole group to announce: ‘We have failed! We did not stick to our golden rule that when you’re at Innovation Days, you’re at Innovation Days.’ I always remember this, because our Innovation Days are also about sharing learnings and that includes failures.”

Thank you Nina, for sharing these insights. Would you like to add something for our readers?
“I hope we can inspire other companies with our experiences to try out something new. It takes time, patience and iterations to let something like Innovation Days become a permanent part of the culture. Because what works for us doesn’t have to work for others.”

The next Innovations Days are taking place now, mid February. We are starting in our 11th year and there are many more to come.

mobile.de Innovation Days Q1/2023

Do you have a hackathon or a comparable format like our innovation days in our company or team? Let us know in the comments.

*Link to blog post about slack-time https://agiletrail.com/2012/01/09/slack-to-the-rescue-what-you-want-to-do/

Who's Jenkins or how to experiment bravely

Kleinanzeigen & mobile.de — Tue, 08 Nov 2022 08:40:41 +0000

Taking risks can be uncomfortable, but when we choose to experiment bravely, we have the chance to find the best solutions. Doing something in a new way and learning from it was also something Fabian did.
This article is about how do we work at eBay Kleinanzeigen: We are open to experiments.
by Fabian Schwarz, Agile Coach

I am Fabian, an Agile Coach at eBay Kleinanzeigen. I still remember starting my job back in June 2021. In one of my first sessions, my people manager Noel asked me "What is the essence of your job? The most important thing?" Such questions can make one nervous, it surely made me. Because in the first weeks of my new position I wanted to prove myself worthy of such a great opportunity - working and learning in a company like eBay Kleinanzeigen.

At that time, I was intensively studying Lyssa Adkins and her bible of the agile profession called "Coaching Agile Teams". According to her, agile coaches fulfil various purposes. So, I answered Noel's question with "coaches mentor, facilitate, teach, solve problems, navigate through conflicts, and conduct collaboration." Noel smiled but repeated "And if you had to sum it up in your own words?" I thought about it. What is my role? When everyone fulfils their tasks and responsibilities, how can I be of any value to a team full of experts? For a long minute I was silent. What was the summary of what I have read in this incredible book on agile coaching?

"To help the team improve step by step?" I answered, almost questioning myself. Noel looked a bit surprised, as if he needed to think about how to translate my answer into what he himself would silently answer on the question. Another long minute. Then, he smiled. "Yes. That's true. If you support the team in getting better every week a little bit, you're doing a great job. That is the essence!"

Today, over a year later - how is it going? How did we improve over the last months? I'd like to give you one of many little examples of improvements our team came up with by experimenting bravely.

Situation: We are a huge cross-functional team (about 20 people: Developers, UX Designers, Product Managers, and additionally colleagues from Business Development, Marketing, Customer Service, someone from Legal etc.), we meet on a weekly basis, while the development people have their daily standup.

Complication: In a retrospective session, we asked all team members to show their 1-5 fingers on the questions "How well am I informed to perform the best work I could." 1 finger = not sufficient. 5 fingers = I know everything - I must deliver excellence.
The outcome spoke for itself. All Dev team members gave 4 or 5 fingers. All non-Dev team members gave 1 or 2 fingers. We started to discuss it. It became emotional and really stormy for some of us. It came out that most of our non-Dev team members felt excluded from the team. There was no mutual understanding on "What is currently going on?", "What is important to know?", and "How long do some things take?"

Question: How can we ensure non-Dev team members gain a better understanding of what happens within our team without creating an extra meeting or without documenting that would force anyone to invest a lot of extra time?
Answer: We run an experiment for three weeks and invite all non-Dev team members to the daily to improve information flow.

Hypothesis: By being present in the daily for three weeks (4 dailys a week with 15 minutes each = 1h time invest per week) we aim to create a mutual understanding of the questions "What is currently going on?", "What is important to know?" and "How long do some things take?"

How to measure the success of the experiment: We met at the beginning to determine our success criteria. At the end of each week, I sent out a short google form to determine each person's ROTI (return on time invested). That helped to reflect on information flow and information transparency. We also included the question: Would my rating improve if I had to rate again (finger rating)?

Set-Up / Constraints: Non-Dev team members take part in the daily as silent observers. As soon as the daily is over (5–8 minutes), the remaining time to the end of the full meeting (up to 15 min) is reserved for questions.

Outcome: After some silence in the first dailys together, the questions started. I guess no one wanted to be the "one stupid person asking this". But with the bravery of a few, some of our dailys became very valuable for all non-Dev team members. "What does it mean when you say you work on google analytics?", "What is a PR?", "Who is Jenkins and what is an API?" It turned out it was really helpful to show empathy with the non-Devs to create a shared understanding of how things work within our team and at eBay Kleinanzeigen. We had a great time together, and believe me: there is nothing more heartwarming than a Senior Developer using a metaphor explaining what "peer reviews" are. That made us feel close again in a parted Corona set-up. Even if not every question could be answered or sometimes we shy away from being the "stupid person to ask," curiosity and bravery to ask always pay back. Sometimes I even observed these magical moments when a developer learned something new thanks to a powerful question.

How we handle it today: The daily is still open for all non-Dev team members. They don't show up all the time but in most dailys they are present. We learned that for new team members it is essential to join at least for the first three months to get into our work. There is still time for questions, and our non-Devs enjoy having a mutual meeting to check in with the team. Sometimes, we use the questions slot to share another important thing, sometimes someone asks questions, and sometimes the time is not used, and we have a shorter daily. All in all, all non-Devs taking part in the experiment see a huge value in our newborn artefact:

The daily with silent observers and a short Q&A.

A day in the life of a Tech Trainee

Kleinanzeigen & mobile.de — Wed, 20 Jul 2022 15:37:13 +0000

Kamila’s Diary

A couple of months ago, I started the Tech Trainee Programme at mobile.de, and I still need to pinch myself from time to time to believe that I’ve had this amazing opportunity.

Before starting, I had no experience as a developer. I graduated in Marketing and Advertising in Brazil before moving to Germany where I worked in Digital Marketing. I was one of the tool testers in an international tech company in Dusseldorf, where I had the pleasure of working with people from all around the world. As part of my role, I worked closely with the tech team and became intrigued by what they did and how it helped us optimise our own work.

The beginning of my tech journey

Coronavirus had a huge impact on my former company and resulted in me leaving. At first, I worried about what I would do next, but I used the time off to think properly about what I wanted to do. I experimented in lots of different areas including interior design, gold-smithery, carpentry and UI design. All of those experiences were in a creative field, but I felt like something more analytical was missing. A good friend of mine introduced me to the coding world and I became excited by all the things I could do if I learnt it properly. It was mind blowing!

Through his recommendation, I did a Coding Bootcamp and this was my entry ticket into the extraordinary world of coding. The programme was very intensive and I learnt a lot in a short space of time. Although I felt like my brain was about to explode with all this new information, I was very excited thinking about all the possibilities that coding could bring. One of the key takeaways from the course was how united the tech world is and how there is an unspoken rule to help anyone who needs it. I love this sense of community.

I was just finishing my course when I saw the trainee post opportunity on the Bootcamp’s slack channel. I hadn’t really thought about jobs but the programme opportunity seemed so well structured and in eBay Kleinanzeigen, a company that I have always admired and used often, so I didn’t want to lose this chance!

The Tech Trainee Programme

The whole hiring process was super-well organised and every single person I came across was extremely kind and supportive. I still remember how I was shaking when I received the message that I was accepted-OMG, I was so happy and grateful!

There were six of us starting as trainees together, and I had never felt so welcome during the onboarding process. Within the two year programme, we will rotate across the three companies that are part of Adevinta in Germany: eBay Kleinanzeigen, mobile.de and the Global Tech Hub.

All the trainees are part of a different team and have an assignment lead, a people manager and a mentor. This is great as it means we have lots of people around us for support and I feel so lucky to have two mentors!

What my working day looks like

No two days are the same, but I will describe a typical Wednesday in the Friedrichshain office.

6:00 AM — I wake up early so it means I can enjoy a few more minutes just lying in bed before the day begins. After this, the first thing I do is make my bed — I can’t be at peace if my bed isn’t tidy and I like to do that whilst listening to some music or podcasts, depending on the mood I’m in.

6:30 AM — I get ready in the bathroom and if I have time, I meditate for 10 mins.

7:00 AM — I prepare my breakfast. I like a simple breakfast and don’t mind eating the same thing every day. Normally, I’ll have scrambled eggs with toast, a cappuccino and some vitamins.

7:30 AM — I get ready for work.

8:00 AM — I head to the train station. On the way, I listen to music and look at the beautiful city of Berlin.

8:50 AM — At the office, I’ll pour myself some water and a cup of coffee. The coffee always sets the day up for me. The office is usually quiet due to the pandemic but some colleagues come once a week just to change their routine and see people. Although it can be tiring commuting for an hour, I really enjoy seeing and talking to people so I prefer to be in the office. In order to keep everyone safe at the office, we have to follow some rules and have a wellness station at the office entrance with e disposable masks and fast tests for people to use.

9:30 AM — I attend the daily meeting, a call where each team member says what they have worked on the day before and what their plan is for that day.

10:00 AM — My team mentor, Juan, normally assigns a task for me and I start it by reading and understanding what I have to do. If needed, we have a quick call for him to explain in more detail.

As I am still learning, it still takes some time to understand the code — it’s huge! Researching is an important skill for a developer and I often need to research what it is that I have to implement.

At the moment, I am working on a loading effect for the user’s ‘manage ads’ page.

12:00 PM — Mahlzeit! The group goes for lunch together, normally at an Asian restaurant — our favourite one! From living in Germany, I’ve learnt how fresh air, especially in the winter, is good, so I really enjoy this small walk to the restaurant.

1:00 PM — Like a good Brazilian, I need to have a coffee after lunch, it helps me to get in the work mood again.

2:00 PM — By this time, I am working through the task, and whenever I get stuck, which happens quite a lot at this stage, I have my mentor there to rescue me. I call him Mirko-San. He is super knowledgeable and always teaches me useful tricks that make the work easier.

CoffeeBreak — Pietro is also part of the trainee programme, and, like me, he is assigned to the Global Tech Hub as the first part of the rotation. We have decided to go to the office every Wednesday so we can chat about our process and what we have learned so far. Although we have chosen different paths, Pietro is learning Swift (programming language for iOS devices) and I am learning Frontend development. It’s really useful to exchange experiences and share the challenges we are facing.

4:00 PM — The biggest challenge for me so far is to understand the huge files I have to work with — they look different from the ones from my Bootcamp. But luckily, there are many smart tricks you can learn that make everything work smoothly. I think it is very beneficial for me when I can do pair programming with my mentors and sometimes other team members as it’s interesting to see the different ways of coding, and which ways work — it helps me to develop my own style and find out what works better for me.

6:00 PM — After long hours looking at the code, it is time to pack. Today I am going to meet with a friend and visit an art gallery. Berlin has so many nice cultural options.

Normally when I work from home I start my work day earlier as I don’t have to commute. This means I can finish earlier so then I can cook something light before going to the gym. If I’m not too tired, I watch some YouTube videos — tutorials, interviews, or I read the book I got as a gift from my team called ‘The Culture Map’.

10:30 PM — Time to go to bed. Tomorrow is another day.

Infos about the Trainee Programme: mobile.de/careers or ebay-kleinanzeigen.de/careers