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

Thermondo GmbH is a Berlin-based energy-tech company building the digital infrastructure that powers Germany's home heating transition, chiefly through heat pump installations and connected energy platforms. Their engineering teams handle everything from installer scheduling and IoT device management to customer-facing apps and billing services. As of mid-2026, Thermondo has 199 open roles, with software engineering positions covering backend services, platform infrastructure, and data engineering.

Candidates report a process that typically runs three to four stages: an initial recruiter or HR screen, a coding exercise (take-home or live), one or two technical interviews focused on system design and coding, and a final round covering values and ways of working. Interviews are conducted in English. Because Thermondo works in a regulated, hardware-adjacent sector, interviewers pay close attention to how you reason about reliability and real-world constraints, not just how fast you solve algorithm puzzles.

Knok job-radar data shows Indian-market software engineer salary bands across experience levels:

For Germany-based or EU-contract roles, Glassdoor and levels.fyi carry publicly reported figures that will differ from the above.

Technical and system design

1. Walk me through a backend service you built that had to handle real-time or event-driven data.
2. How would you design an API layer connecting a mobile app used by field technicians to a central operations platform?
3. Describe your experience with microservices or distributed systems. What broke in production and what did you do about it?
4. How do you write and test code that integrates with physical devices or third-party IoT platforms?
5. What strategies do you use to make a service resilient when an upstream API (say, a utility provider) goes down?
6. How would you approach migrating a monolith to a more modular architecture without halting ongoing feature work?

Domain, ownership, and collaboration

1. Thermondo operates in a regulated energy sector. How have you handled compliance or data-integrity requirements in a past role?
2. Tell me about a time you worked closely with operations, product, or sales teams to ship a feature end to end.
3. How do you handle a situation where a business request conflicts with what is technically safe or feasible?
4. What does a good code review look like to you? Give me a concrete example of feedback you gave or received.
5. How do you keep yourself and your team accountable to quality when delivery pressure is high?
6. Tell me about a time you improved observability or reduced incident frequency in a production service.

Q: Walk me through a backend service you built that had to handle real-time or event-driven data.

*Situation:* At my previous company we ran a logistics platform that ingested GPS pings from delivery vehicles every few seconds. During peak hours the volume caused processing lags that delayed customer notifications.

*Task:* I was asked to redesign the ingestion layer to handle traffic spikes without dropping events or delaying downstream consumers.

*Action:* I introduced a message queue between the GPS receivers and the processing workers, batched writes to the database, and added a dead-letter queue so failed events could be replayed without manual intervention. I also set up latency alerts so the team could catch degradation before customers noticed.

*Result:* End-to-end processing time dropped noticeably, alert noise reduced, and the system handled a major traffic spike without any production incident. The design pattern I documented became the team's standard template for new event-driven features.

---

Q: Tell me about a time you worked closely with a non-engineering team to ship a feature.

*Situation:* Our operations team needed a scheduling tool so they could assign installation jobs to technicians based on location and skill set. They had been managing this in spreadsheets, which caused regular double-bookings.

*Task:* I was the backend engineer responsible for the scheduling API and had to understand business rules well enough to model them in code, which meant working directly with ops leads rather than waiting for a finished product brief.

*Action:* I ran three working sessions with the ops team, mapped out their edge cases on a whiteboard, and built a phased API: a simple assignment endpoint first, then conflict detection, then skill-based matching. I kept a shared changelog so they could track progress without reading pull requests.

*Result:* The tool replaced spreadsheets within a month of launch. Double-booking incidents dropped to zero in the first quarter, and the ops team flagged two additional edge cases early because they felt comfortable raising them directly with me.

---

Q: Tell me about a time you improved observability or reduced incident frequency in a production service.

*Situation:* A payment integration service at my team was firing generic alerts at odd hours. On-call engineers were spending a long time in runbooks trying to diagnose root causes before they could act.

*Task:* I volunteered to lead a reliability sprint focused on making incidents faster to understand and resolve.

*Action:* I added structured logging with correlation IDs so a single request could be traced across all downstream calls. I rewrote the alerting rules to distinguish between 'payment provider timeout' and 'internal processing error' so on-call engineers could take the right action immediately. I also wrote a short runbook for each alert type.

*Result:* Mean time to diagnose dropped significantly on our internally tracked metrics. Night-time pages fell noticeably in the following month, and two other teams adopted the structured logging pattern across their own services.

STAR for behavioral questions

Start with the *Situation* in one or two sentences: set the scene, the product, and the stakes. Move to your *Task*: be specific about what you personally owned, not what 'we' did as a team. Use *Action* for the substance: name the technologies, the trade-offs you weighed, and the decisions you made. Close with a *Result* that is concrete, something measurable or visible to stakeholders.

For system design questions

Thermondo's domain involves connecting physical hardware, field technicians, and customers. Candidates report that interviewers appreciate when you:

• Clarify scope before drawing architecture boxes ('Is this read-heavy or write-heavy? What is the acceptable failure rate?')
• Surface real-world failure modes early, such as network partitions, third-party API timeouts, and data consistency across services
• Show awareness of operational cost and on-call burden, not just technical elegance
• Propose a simple version first, then layer in complexity only as the conversation calls for it

For coding rounds

Think out loud throughout the session. Candidates consistently report that interviewers at product-engineering companies care more about how you reason through a problem than whether you land on the optimal solution immediately. Write clean, readable code first and optimise only if time allows.

Thermondo builds infrastructure for a real-world, regulated sector where unreliable software has direct consequences for homeowners and field technicians. Based on what candidates typically report, interviewers look for four things.

Production mindset. They want to see that you think about failure modes, monitoring, and maintainability from the start, not as an afterthought. Mention logging, alerting, and rollback strategies naturally in your answers rather than waiting to be prompted.

Cross-functional collaboration. Thermondo's engineering teams work closely with operations and product. Candidates who can show they have navigated ambiguous requirements and explained technical constraints clearly to non-engineers consistently stand out.

Ownership and follow-through. Stories that stop at 'I shipped the feature' are weaker than stories that continue with 'I tracked the rollout, caught an edge case, and fixed it.' Show that you see work through to measurable impact.

Clarity in communication. Because the company is German-headquartered and engineering conversations happen in English, interviewers pay attention to how clearly you explain your reasoning. Structured, concise answers leave a stronger impression than verbose ones.

Week 1: Understand the domain

Read up on how energy-tech companies typically structure their platforms: installer management, IoT device onboarding, customer portals, and billing integrations. This gives you vocabulary to make system design answers feel specific rather than generic.

Week 2: Practise system design

Pick two or three design problems close to Thermondo's domain, for example 'Design a job scheduling system for field technicians' or 'Design a real-time device telemetry pipeline.' Practise narrating your design out loud, starting simple and adding complexity only when prompted.

Week 3: Sharpen your STAR stories

Write out five or six stories covering: a reliability improvement you led, a cross-team collaboration, a technical trade-off decision, a code review situation, and a moment where you pushed back on a requirement. Trim each to under two minutes when spoken aloud.

Week 4: Mock interviews and coding practice

Focus coding practice on data structures used in scheduling and graph problems (for routing or dependency resolution), which appear commonly cited in product-engineering interview feedback. Do at least two mock technical interviews with a peer so you get used to thinking out loud under time pressure.

Before each round

Review Thermondo's publicly available product information. Prepare two or three questions that show you have thought about the technical challenges specific to energy-tech, not just generic software engineering questions.

1. Treating it like a pure algorithms interview.

Thermondo is a product-engineering company. Candidates report that over-indexing on competitive programming tricks while ignoring system design and production considerations is a common misstep.

2. Using vague 'we' language in behavioral answers.

Saying 'we built a microservices platform' tells the interviewer nothing about your individual contribution. Always specify what you personally owned, decided, or changed.

3. Ignoring the energy-tech context.

Candidates who research Thermondo's product and ask informed questions about reliability in IoT or installer workflows consistently make a stronger impression than those who treat it as a generic software role.

4. Not asking clarifying questions in system design.

Jumping straight into a design without scoping the problem is a red flag. Interviewers want to see that you think like an engineer who has shipped real products, not just solved textbook exercises.

5. Skipping the result in STAR answers.

Many candidates walk through situation and action in detail, then trail off with 'it went well.' Finish every story with a concrete outcome, even if qualitative (for example, 'the ops team stopped using spreadsheets and the process became self-serve').

6. Arriving with no questions for the interviewer.

A candidate who has nothing to ask signals low engagement. Prepare thoughtful questions about the team's engineering challenges, on-call culture, or how they handle technical debt.