Thermondo GmbH Mobile Engineer Interview: Questions, Experience & Prep (2026)

Thermondo GmbH is a Berlin-based energy-tech company that installs heat pumps and heating systems at scale across Germany. Their mobile app serves both end customers and field technicians who work in areas with variable network connectivity. As of July 2026, knok jobradar shows Thermondo has 199 open roles, signalling active growth across teams.

The Mobile Engineer interview process typically spans 3-4 stages. Candidates report an initial HR call to check communication and motivation, followed by a technical round covering coding and mobile-specific topics, then a system design or architecture session, and finally a culture and values conversation. All rounds are typically conducted in English.

Thermondo values engineers who think about the product user (a field technician or homeowner) and not just the code, so expect product-thinking questions alongside technical ones.

1. Walk us through the architecture of the last mobile app you shipped. What trade-offs did you make?
2. How do you approach offline-first design? Describe your sync strategy and conflict resolution approach.
3. Thermondo field engineers use the app in low-connectivity areas. How would you design a feature for that scenario?
4. What is your approach to state management in a complex mobile app?
5. How do you detect and fix a memory leak or UI jank on a real device?
6. Describe your experience with push notifications. How do you handle delivery failures?
7. How do you structure a CI/CD pipeline for a mobile app targeting both iOS and Android?
8. How do you manage breaking API changes from the backend without shipping a broken release?
9. Tell me about a time you disagreed with a product or engineering decision. What did you do?
10. How do you write and maintain meaningful tests for a mobile codebase?
11. How do you balance shipping new features against paying down technical debt?
12. Thermondo is scaling fast. If you had to migrate a live app to a new framework, how would you plan it?

Q: How do you approach offline-first design?

*Situation:* At my previous company we built a field-service app for technicians who visited client sites. Network coverage was unreliable.

*Task:* I needed to make sure technicians could log job updates even with no signal, without losing any data.

*Action:* I introduced a local SQLite store as the source of truth on device. Every write went to local storage first, then a background sync worker pushed changes to the server when connectivity returned. I used a 'last-write-wins' strategy for non-conflicting fields and flagged conflicting records for manual review in an admin panel.

*Result:* Field teams reported near-zero data loss during connectivity gaps. The sync queue added minimal overhead and the pattern became the standard for all offline-capable features in the app.

---

Q: How do you detect and fix a memory leak on a real device?

*Situation:* Our iOS app had a screen showing live sensor readings. QA noticed the app would crash after several minutes on that screen.

*Task:* I had to reproduce, isolate, and fix the leak without disrupting the release schedule.

*Action:* I ran the app through Instruments with the Leaks and Allocations instruments. I found a retain cycle between a view controller and a closure in our sensor data publisher. I used 'weak self' captures inside the closures and verified the deallocation with a 'deinit' print statement. I also added a unit test that checked for the deallocation pattern to prevent regressions.

*Result:* Memory growth on that screen dropped to a flat line. The fix went out in the next patch and QA closed the crash ticket.

---

Q: Tell me about a time you disagreed with a product decision.

*Situation:* My product manager wanted to add a mandatory onboarding carousel with several screens before users could access the app. I felt it would hurt activation.

*Task:* I needed to raise my concern constructively without blocking the sprint.

*Action:* I pulled publicly reported activation benchmarks for similar apps and presented a case for a shorter, skippable version. I proposed a quick A/B test to measure drop-off before committing to either approach. I framed it as a risk reduction exercise rather than a disagreement.

*Result:* The team agreed to the test. The skippable version showed better activation in the test cohort, and that became the shipped version.

STAR is the most reliable structure for behavioural questions. Lead with *Situation* (one or two sentences of context), then *Task* (what you specifically needed to do), then *Action* (the steps you took, using 'I' not 'we'), then *Result* (a concrete outcome, even if qualitative).

For technical questions, try the Clarify, Design, Trade-off pattern. First clarify the constraints (network, device, user type), then describe your design, then name at least one trade-off you accepted. Thermondo interviewers typically value engineers who acknowledge trade-offs rather than presenting one-size-fits-all solutions.

For system design, open with the user journey before jumping into components. 'A field technician opens the app to log a job, so the critical path is...' anchors your answer in the product context and signals product empathy immediately.

Based on publicly known information about Thermondo's product and candidate reports, interviewers look for four things.

Product empathy. Thermondo's mobile users include tradespeople on job sites. Candidates who talk about users (not just APIs) tend to stand out.

Depth over breadth. Interviewers typically probe one topic deeply rather than covering everything. Expect follow-up questions when you give a high-level answer, so be ready to go into implementation detail.

Ownership. They want engineers who have shipped things, hit problems, and fixed them. 'We' answers get probed with 'What specifically did you do?'

Communication. Because the team works in English and is cross-functional, clear thinking under pressure matters as much as technical knowledge.

Week 1: Core mobile fundamentals. Review the lifecycle of your primary platform (activity/fragment lifecycle on Android, UIViewController on iOS, or widget tree on Flutter). Revise state management patterns you have used and be ready to compare them. Read through Thermondo's app reviews on the Play Store or App Store to understand what real users say.

Week 2, part 1: System design practice. Pick a couple of mobile system design topics such as offline sync, push notification architecture, or a real-time data feed, and sketch out a design for each. Focus on constraints before components.

Week 2, part 2: Behavioural prep. Write down a few stories covering a technical challenge, a disagreement, and a time you improved a process. Practice delivering each story concisely.

Week 3: Company and process. Spend time reading about Thermondo's product before each interview round. Look at their open roles page to understand which teams are hiring. If you receive a take-home task, test it on a real device, not just a simulator.

If you are still searching for the right role, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you.

1. Talking in 'we' throughout. Interviewers need to know your individual contribution. Say 'I designed...' and save 'we' for team context.
2. Skipping trade-offs. Every architecture decision has a cost. Naming the cost shows senior thinking.
3. Ignoring the Thermondo context. Field technicians, poor connectivity, and energy-tech are clues about what the team cares about. Answers that ignore the domain feel generic.
4. Over-engineering the system design. Start with the simplest thing that works, then add complexity only when a constraint requires it.
5. Not asking clarifying questions. Jumping into an answer without confirming constraints is a red flag in design rounds.
6. Under-preparing for behavioural rounds. Many candidates prep only for coding, but candidates report that the culture round at Thermondo carries significant weight.