Inside SMATRICS Engineering: Cloud-first, pragmatic QA, and speedy hiring – Insights from “Dominik Treber, Team Lead Software Process & Quality Assurance bei SMATRICS” (SMATRICS GmbH & Co Kg)

Why these insights matter to engineers

What does it take to be “the top technology provider behind every charging experience”? In our session with “Dominik Treber, Team Lead Software Process & Quality Assurance bei SMATRICS” (SMATRICS GmbH & Co Kg), that ambition becomes concrete. SMATRICS runs cross-functional teams, has migrated almost entirely to AWS, and tunes its stack—from Java/Angular to a move from Selenium to Playwright—based on real product needs. Add to that a hiring and onboarding experience designed for speed, clarity, and cultural fit.

For developers, QA professionals, product owners, and platform engineers, this translates into product responsibility within clearly shaped teams, meaningful quality practices, and a culture that selects technologies because they work for the business—not because they are fashionable.

Mission and vision: e-mobility as a technology mandate

“SMATRICS is a 360-degree e-mobility provider,” Dominik states. The vision is just as explicit:

From an engineering perspective, this is more than a tagline. It sets expectations for architecture, reliability, security, quality, and the ability to release software predictably. It also explains why IT at SMATRICS deliberately designs and evolves its processes: technology is not just an enabler—it is the brand, experienced at the charging point.

How IT is organized: cross-functional, product-centric, and supported by Platform Engineering

Dominik outlines a cross-functional department where multiple disciplines collaborate:

• Platform Engineering
• QA (Quality Assurance)
• Scrum Masters
• Product Owners
• A large Development team

Products are owned by several teams. A typical team includes:

• one Product Owner
• two to five developers (depending on product size)
• one QA engineer

This setup shows that releasability—repeatability, automation, standardization—is not left to chance. Platform Engineering provides the foundations, standards, and tooling that product teams rely on. For engineers, that means fewer ad-hoc workarounds and more focus on building the product.

Collaboration in the team: clear roles, shared outcomes

• Product Owners prioritize and carry the product vision for the team.
• Developers deliver end to end and collaborate closely with QA.
• QA is embedded in the team—not a late-stage gate.
• Platform Engineering ensures consistent release processes and shared technical fundamentals.

This structure is compelling for talent seeking product-centric work where quality, delivery, and collaboration are treated as a cohesive whole.

Technology choices: purpose-built over hype-driven

“We always try to adapt to what’s happening in the market and what fits our situation.” That line captures SMATRICS’ stance well. Technology is not an end in itself. Fit matters: what serves the business requirements? What works in practice for each product context?

AWS Cloud: a near-complete migration

The strong cloud focus signals a commitment to scalability, flexible infrastructure, and modern delivery pipelines. For engineering teams, it means access to a rich toolbox of managed services and a platform for enforcing clear standards. It also underpins the organization-wide push for consistent releases—a core contribution from Platform Engineering.

Java backend and Angular frontend

The Java–Angular pairing is a proven foundation for building scalable business applications. It brings enterprise-grade robustness and a mature ecosystem—appealing to engineers who value clean architecture, type safety, and well-understood patterns.

Databases: MariaDB and MongoDB—selected per product

There’s no one-size-fits-all database. Selection follows the product’s functional needs. For engineering teams, that yields both freedom and responsibility: make informed trade-offs and build maintainable solutions.

Test automation: from Selenium to Playwright

Dominik openly explains the rationale behind SMATRICS’ testing shift:

That’s a pragmatic, context-driven choice. Angular’s asynchronous nature can challenge E2E stability; Playwright helps address that. For QA and frontend teams, the result is more robust tests and fewer flaky runs—tools that better represent real user flows. It also showcases a learning mindset: evaluate, adapt, and improve quality practices.

A quality culture by design: QA is a team function with a dedicated role

Having a QA role embedded in each team signals that quality is part of the development process, not an afterthought. Combined with Platform Engineering and fit-for-purpose tooling (Playwright for Angular), the result is a quality culture that prioritizes stability, speed, and reproducibility.

• QA is part of the team, not external.
• Tooling is chosen for the product context, not trendiness.
• Releasability is supported across the organization.

For talent with a modern QA mindset—SDET, Test Engineer, or developers with a strong quality focus—this setup offers a genuine opportunity to influence quality in the product.

Hiring at SMATRICS: multiple perspectives, fast feedback

Dominik describes a hiring process that delivers early, concrete answers to candidates.

Dominik acknowledges this might feel “overwhelming” at first glance—but the benefit is clear:

Two rounds, clear fit

• After a successful first round, a second round often follows.
• Additional team members join—e.g., someone from QA or the product team the person would join.
• Cultural fit is checked explicitly.

The outcome is a process that unites technical and cultural perspectives—without dragging on for weeks.

“Get Hired in 1D”: same-day decisions

A standout example of speed is the “Get Hired in 1D” initiative:

For tech talent that values clarity, this is a strong signal. The organization aims to decide quickly—and has built processes to make that possible.

Onboarding: Buddy system, checklists, and regular feedback loops

A well-structured start is the best foundation for long-term performance. SMATRICS relies on a clear setup:

• A buddy accompanies each new hire.
• A checklist guides them through internal processes and practical orientation (“where to find what”).
• Regular feedback conversations help adapt if needed: after one week, after two weeks, and at the end of each of the first three months.

In parallel, there is targeted technical onboarding:

The goal is autonomy—not through pressure, but through support. For new team members, that means guidance and responsibility in equal measure.

What engineers can expect at SMATRICS—key takeaways

From Dominik’s insights, we can outline the following core elements:

• 360-degree e-mobility with a clear technology mandate: software defines the charging experience.
• Cross-functional teams with embedded QA and dedicated Product Owners; 2–5 developers per team.
• Strong support from Platform Engineering for standardized, repeatable releases.
• AWS-first: a near-complete migration to the AWS Cloud.
• Java backend with Angular frontend across many products.
• Database choices per product: MariaDB or MongoDB, depending on business requirements.
• QA modernization: switching from Selenium to Playwright for more stable E2E in asynchronous Angular apps.
• Hiring for speed and clarity: multi-interviewer first rounds, rapid feedback, explicit cultural fit checks.
• “Get Hired in 1D” as a proof point: same-day offers possible when the fit is right.
• Structured onboarding with a buddy, checklists, and frequent feedback; aim for substantial autonomy after about three months.

These are not mere process notes—they reflect underlying principles: pragmatism, quality, accountability, and speed.

Why this is attractive to developers, QA professionals, and product leaders

• Impact, not overhead: work on products that directly shape the charging experience.
• Solid foundations: cross-functional teams, embedded QA, and a Platform Engineering backbone that supports delivery.
• Modern, fit-for-purpose tools: AWS, Java/Angular, Playwright—with the freedom to choose the right database per product.
• Transparent paths into the role: a hiring process that provides fast feedback and includes peers from the target team.
• Structured starts: buddies, checklists, and tight feedback loops foster orientation without stifling autonomy.

If you want to take ownership quickly and work in an environment that decides, learns, and iterates, this setup will resonate.

Quotes and lines that stand out

• “SMATRICS is a 360-degree e-mobility provider.”
• “The vision is that behind every charging experience, SMATRICS stands as a top technology provider.”
• “We migrated almost completely to the AWS Cloud.”
• “We use Java with an Angular frontend.”
• “MariaDB in some projects, MongoDB in others—according to business requirements.”
• “We switched from Selenium to Playwright… better for our asynchronous Angular frontend.”
• “Several people in the first rounds… so we can give feedback as quickly as possible.”
• “Get Hired in 1D”—offers possible by the end of the day.
• “Buddy,” “checklist,” and feedback after 1 week, 2 weeks, and monthly in the first three months—aiming for autonomy after roughly three months.

Our takeaway from the session with “Dominik Treber, Team Lead Software Process & Quality Assurance bei SMATRICS”

SMATRICS’ engineering organization is tuned for effectiveness: product teams with clear roles, backed by Platform Engineering; a cloud environment that enables modern delivery; and a quality culture that selects tools deliberately and adapts when needed. Hiring is straightforward and fast; onboarding is structured and people-centric.

Put together, it’s an appealing picture for tech talent: if you see e-mobility as a technology mandate and want to help shape the experience “behind every charging moment,” you’ll find a place where quality, speed, and ownership meaningfully converge.