Mentoring at GetYourGuide: How our engineers build confidence, skills, and dream-reading apps

Mentorship programs quietly do something powerful: they turn curiosity into capability. At its core, it’s a structured way for a mentee to build valuable skills in a new technology of their choice. The mentor can learn valuable lessons, too, as they support learning a new skill, working toward a technical goal, and navigating the challenges of building something unfamiliar.

But it’s not just about “teaching.” At its best, it’s about creating the conditions for someone else to grow: clarifying goals, giving practical feedback, sharing patterns and pitfalls, and encouraging a mindset of ownership and iteration.

In this post, we’ll walk through how mentoring works at GetYourGuide, share the real journey of two engineers: Valentin Derksen (mentor) and Fabian Bücheler (mentee), and offer a set of recommendations for anyone thinking of embarking on a similar project.

{{divider}}

What mentoring looks like for GetYourGuide tech teams

It all started when one of our engineers saw an opportunity to create a lightweight, scalable way for employees to learn from each other across teams, backgrounds, and skill sets.

Valentin Derksen was there from the beginning:

“The mentorship program at GetYourGuide started as an initiative by an amazing engineer a few years ago. I joined the program from the start. It gained popularity quickly, and many engineers from different backgrounds joined. I love programming across the stack, and it feels great to understand a project from all sides deeply. I wanted to share that passion and help others become more of a generalist.”

That last line is an important theme. Mentoring doesn’t just help people deepen expertise in a narrow area. It can also help them broaden their range and learn how systems connect across backend, frontend, infrastructure, and product decisions.

To make the program work across a fast-paced environment, we use a process that balances structure with independence:

1) Find a mentor

There’s an internal list where mentors can sign up and describe their skill set (languages, systems, domains, areas of interest). Mentees browse, identify someone they’d like to learn from, and reach out to ask whether that person is available and interested in mentoring.

2) Agree on a roadmap

Once mentor and mentee match, they establish a roadmap for the coming months: expectations, objectives, and how they’ll collaborate. This helps avoid the most common mentoring failure mode: good intentions without a clear plan.

3) Meet regularly and keep momentum

Mentorship meetups become a working rhythm: progress updates, discussion of challenges, and agreed next steps.

A core principle of GetYourGuide mentoring is mentee ownership. This isn’t a “mentor sets the homework” setup; mentees shape the direction and bring the goals and questions. The mentor’s role is to coach, helping them clarify priorities, make decisions, learn faster, and build with confidence.

This expectation matters because it mirrors real engineering work: autonomy, initiative, and the ability to make progress even when frameworks aren’t neatly defined.

Mentoring benefits both sides

The benefits to mentees are more obvious: skill building, confidence, perspective, and momentum. But the process also helps mentors in ways that are harder to come by in their day-to-day work.

A few examples:

• Explaining complex concepts clearly
• Guiding without taking over
• Reviewing pull requests with a teaching mindset
• Sharing technical decision-making frameworks
• Coaching through ambiguity, trade-offs, and scope cuts

Mentoring can be both challenging and rewarding, especially when both parties are exploring new ground together.

The project: “Dreamcatcher”

To make Valentin and Fabian’s mentorship concrete, they chose a personal project with a clear end goal: build a full-stack mobile app called Dreamcatcher.

Dreamcatcher lets users:

1. Describe a dream they had
2. Save it like a diary entry
3. Receive an AI-generated analysis of the dream’s meaning using a language model

The idea had a strong mentoring shape. It was fun, well-scoped in concept (even if ambitious in execution), and included enough complexity to touch multiple disciplines: frontend, backend, storage, infrastructure, and AI.

Architecture overview

Dreamcatcher spanned a full stack:

• Frontend: React Native (so it could run on iOS and Android)
• Backend: Java service exposing APIs for dream management
• LLM: a small Mistral model for dream analysis
• Database: MySQL for storing dream entries
• Hosting: Hetzner Cloud for the database, backend service, and LLM service
• Privacy choices: European providers were selected for Hetzner and for the LLM hosting approach to support stronger data protection considerations

Fabian described why the project worked well as a mentorship vehicle:

“While the app was a project that was not work-related, it seemed to be an exciting project with a clear goal that we could work on collaboratively. To this end, we met up virtually twice a month, where we would discuss progress, current status, challenges, and next action items.”

What they shipped (and what they chose not to)

By the end of the project, Dreamcatcher was working on Android. Users could submit a dream, have it analyzed by the model, and archive it. Like most real projects, it shipped with strengths and rough edges.

Known weaknesses (the “if we had another sprint…” list)

They called out several areas that would be natural follow-ups in a production setting:

• The user flow wasn’t intuitive in places (for example, after submitting a dream, you had to leave the submission page manually)
• Missing UI feedback, like success pop-ups
• Manual typing required (voice recording wasn’t implemented)

In a normal product cycle, these features are prioritized, sequenced, and shipped over time. But in a mentorship project with limited time, each enhancement comes at a cost.

Clear strengths (smart design choices with real impact)

At the same time, the project made several strong calls that mattered:

• Auth0 login for authentication
• Hashed/anonymized dream data
• A self-hosted LLM to reduce the risk of leaking PII to third-party providers

Even in a personal project, those choices reflect good habits: build with privacy in mind, think about where data goes, and avoid unnecessary exposure.

The real outcome: their learning journey

Sure, shipping the actual app was important, but the real achievement here was what Fabian learned by building something end-to-end. He often stepped outside his comfort zone to acquire the necessary skills and, thanks to Valentin’s mentorship, gained practical, usable knowledge.

Fabian reflected on the experience:

“Not having any previous experience with JavaScript, I coded the frontend with minimal help from AI. Having at least beginner-level knowledge of Java made coding the backend a bit easier. Moreover, learning about container networking between the backend services, as well as hosting an LLM ourselves, also made for great learning opportunities along the way.”

Valentin also emphasized that it wasn’t a one-way street:

“Funny enough, the scope of the project was also a challenge for me, and I learned along the way with Fabian. Just one example: I used the same project starter for React Native and tried it out myself, never having used it before, but having always been curious.”

This also touches on another important point: a good mentor doesn’t have to know everything. Ideally, you just need to stay open to new ideas, know how to structure progress, and have the patience and willingness to help your mentee move through a problem.

Challenges: scope, networking, and when to use AI

Fabian and Valentin ran into three major challenges, each of which will feel familiar to anyone who has built outside their usual stack.

1) Project scope (ambition vs. reality)

Building a complete app from backend to frontend takes time, even when you know the tools. Doing it while learning pieces of the stack creates a steep curve.

They felt that tension throughout: every new feature expanded the surface area, and every new technology required both understanding and implementation.

2) Networking and troubleshooting

Fabian called out networking as a particularly sharp learning edge:

“Another challenge certainly was the networking, which required a lot of reading, logging, and troubleshooting to understand why, e.g., a container could not communicate outbound or inbound. As a result, I now have decent troubleshooting knowledge when networks don’t work properly.”

3) Integrating the LLM (the ‘final boss’)

As the project progressed, the LLM integration became the crucial last step. Without it, Dreamcatcher would be a dream diary, not the dream analysis app it set out to be.

Integrating the model required:

• Reading up on the architecture
• Figuring out how to expose or connect to the model via APIs
• Wiring LLM requests into backend flows
• Ensuring services could communicate reliably

It was a lot of work, and also the most defining part of the app’s purpose.

4) The AI assistance dilemma (speed vs. learning)

Lastly, they encountered a common challenge engineers face: deciding how much AI to use while building.

With tools like ChatGPT, Claude, and Gemini, it’s easy to generate large portions of code instantly. But that can undermine the learning process, especially when the goal of mentoring is skill development rather than just output.

Fabian described how he tried to stay intentional:

“This is why I tried to stay away from AI as much as possible to go through the (sometimes painful) learning process myself. At the same time, a trade-off needs to be made at times… This trade-off is not always easy and often just falls prey to simply asking AI to support, even if I want to learn how things work.”

AI can accelerate progress, but it can also smooth over the exact friction needed for true understanding. Mentoring projects make that tension visible and give the space needed to practice making intentional choices.

Recommendations for future mentors and mentees

Considering a mentorship journey yourself? Here are some insider recommendations from both sides to get you off to a strong start.

Fabian’s recommendations (mentee perspective)

1. Choose a smaller-scope project.
   Dreamcatcher involved many technologies and took more than half a year to develop. Smaller projects are easier to complete and easier to learn from.
2. Pick something you’re genuinely excited about.
   When motivation dips (and it will), it’s your excitement that carries you through.
3. Don’t pick a stack where everything is unfamiliar.
   Learning one or two new technologies is great. Learning all of them at once increases the risk and can dramatically slow your progress.

Valentin’s recommendations (mentor perspective)

1. Consider personal projects over in-team projects.
   Personal projects can be more fun, more independent, and better aligned with learning goals without waiting on team roadmaps or cross-team coordination. Hybrid options can also work.
2. Be intentional about what you want to learn.
   Full-stack “do everything” builds are rewarding, but it may help to plan for deeper practice in the most important technologies.
3. Meet frequently by default, then adjust as needed.
   If you meet monthly and one session slips, suddenly it’s been 2–3 months. More frequent meetings protect momentum.
4. Document the learning journey.
   Keeping a record of my mentees’ questions and answers was a major accelerator. Over time, that documentation became a reusable reference and a story of progress!

Why this matters

If you’re considering finding a mentor or becoming one, take this as your sign to start! Work together to choose your goasl, keep the scope manageable, and build something you both care about. It’s easy for the process to feel abstract, but we hope that the case study and framework ideas featured in the post make it less daunting and more tangible. 

In the end, mentoring is less about the perfect plan and more about showing up consistently, learning out loud, and shipping something that didn’t exist before.

Interested in building with the latest tools alongside leading talent? Check out our open roles and learn more about our tech team.

‍