Building Quality Into the Product: Inside CADS GmbH’s Engineering Culture and Onboarding

What we learned from “Lukas Windner, Division Manager Quality Engineering bei CADS”

In the session “Lukas Windner, Division Manager Quality Engineering bei CADS” (Speaker: Lukas Windner, Company: CADS GmbH), we got a grounded, practical view into how a company that builds software for the medical device sector organizes quality, collaborates across teams, and welcomes new hires. The setting is Perg; the company belongs to a larger group and operates with development, research, prototyping, marketing, HR, and management closely aligned.

The spotlight was on Software Quality Engineering—how roles are defined, how they mesh with project leadership and development, and how onboarding actually works. Our takeaway: CADS turns quality into an engineering discipline, not an afterthought. The talk was rich with specifics that matter to tech talent evaluating where to apply.

Mission and context: Software for the medical device sector

CADS GmbH develops software in the medical device environment—an area where documentation, risk analysis, and systematic testing aren’t optional. It’s no surprise that quality is organizationally embedded; the interesting part is how CADS makes it work in practice:

• Quality is a dedicated function with leadership and hands-on roles.
• Development teams (junior and senior) primarily build web applications; there’s also AR and AI work housed in the research function.
• Prototyping, marketing, HR, and management are part of the operating model.

The combination of a regulated domain with a modern web/cloud stack creates a compelling setting for engineers: clear processes, tangible quality goals, and up-to-date tooling.

How Software Quality Engineering is structured

As Division Manager, Lukas Windner laid out a clean separation of roles that still work tightly together.

The core roles: Project Quality vs. Softwarequality

• Project Quality Software Engineer (PQE)
• Owns documentation and risk analysis.
• Coordinates the Softwarequality Engineers.
• Serves, as Lukas puts it, as the project manager’s “left and right hand.”
• Softwarequality Engineer (SQE)
• Executes testing: manual, automated, security, and load.
• Leans on individual experience—responsibilities align with the engineer’s background and strengths.

The two collaborate closely: PQE ties into project leadership and documentation; SQE drives depth and breadth across test types.

Cross-support over silos

Lukas emphasized that people support each other, even across projects. If someone has security testing experience, they help out elsewhere. Roles aren’t static; you might step into either SQE or PQE duties when needed. That reflects two cultural commitments:

• Knowledge sharing is expected and practiced.
• Accountability is clear but not rigid—competence trumps org chart when it benefits delivery.

Engineering-first quality

Quality at CADS is built into engineering. You can see it in the tooling and in the way the quality team maintains scripts and automation. Quality management is hands-on and integrated with development workflows.

Development, research, and more: The broader setup

Outside of Quality Engineering, CADS runs development rooms with junior and senior developers building “a lot of web applications.” AR and AI topics reside in the research function, which evaluates and applies “state of the art” methods. Marketing, prototyping, HR, and management complete the structure.

This arrangement signals that quality is an outcome of collaboration across development, research, product, and operations—supported by HR and leadership practices that make onboarding and everyday work run smoothly.

Hiring, selection, and onboarding: The concrete path

Few companies describe their process as plainly as Lukas did. Here’s the path candidates can expect at CADS:

Job descriptions: HR and the quality org co-author

• The Head of Quality, the division lead, and HR jointly define the job ad.
• After review, HR publishes the role.

Early involvement from the hiring team ensures realistic profiles and aligned expectations from the start.

First interview: virtual and led by the hiring manager

• After applications arrive, candidates typically have an initial virtual conversation.
• Lukas usually leads this call himself.
• The discussion covers a mutual introduction, an overview of CADS’ products, and the candidate’s past experience.

For candidates, it means direct access to the hiring manager from the first touchpoint.

On-site in Perg—with the COO in the room

• Next comes an on-site interview in Perg.
• The COO usually joins, building mutual context on both sides.

The team then aligns internally. If everything fits, contract and start date follow.

Buddy program: Three months of structured support

Once you start, the onboarding follows a documented process anchored by a buddy program:

• For the first three months, you have an assigned buddy.
• On Day 1, they welcome you, help you log in, install needed software, show you your workspace and, yes, the kitchen, and explain the day-to-day.
• You’re pulled into projects early: the buddy brings you along to meetings and introduces you to colleagues and stakeholders.
• Online meetings are common, since CADS works with customers in the U.S. and Germany.

The key is accessibility: “You can always ask.”

Open culture: All doors are open, including the CEO’s

Lukas repeatedly described CADS as “a very open company”:

• Questions are encouraged—“you can even go to the CEO” if you need an answer.
• People won’t just pass you along; they try to help directly.
• Even basic how-to questions (like submitting vacation requests) are fair game.

For new joiners, these norms reduce friction and uncertainty. For the organization, it reflects hands-on leadership that’s present in everyday work.

Growth and maturity: From a solo function to a six-person quality team

Lukas has been at CADS for about four and a half years. He started as the only person in quality; today the team counts six. That evolution tells us that:

• Quality is genuinely prioritized and scales with project and product work.
• Knowledge building and responsibility transfer are real: a one-person function became a team with defined roles and shared expertise.

For candidates, it’s a sign of a learning organization that adjusts structure to match demand.

Tooling and stack: Pragmatic, cloud-forward

The tech picture is familiar to modern engineering teams and shows how quality is embedded into delivery:

• Planning and collaboration: Jira and the broader Atlassian Suite.
• Code, builds, and automation: “Asha DevOps” is used by development and quality—especially important for automated testing that relies on source code and scripts.
• Hosting and infrastructure: No on-prem infrastructure for applications; web apps run on AWS.
• AWS services in use: S3, EC2 instances, SNS, and SQS. Overall, CADS leans on managed services to support build and runtime needs.

Test automation and test types

• Automated tests: C#/.NET paired with Selenium.
• Mobile testing: Java and a Selenium-like framework referred to as “Abium” in the talk, used for mobile applications.
• Load testing: Teams use tools for load and performance testing.
• Security testing: Work follows the OWASP Testing Guide, with Burp Suite as a primary tool.

The quality team writes scripts, integrates with build pipelines, and uses the same platforms as development. In short, Quality Engineers are, by design, software engineers.

AI and AR: Targeted use over hype

AI is on the radar—anchored in the research team and considered for future quality workflows, for example to detect errors earlier. But the stance is intentionally measured:

Instead, CADS evaluates where AI is actually “goal-oriented.” For quality, that means applying it where it makes sense, not for show. The approach fits a broader theme: pragmatic technology choices, integrated into existing processes.

Day-to-day collaboration: Internationally connected, internally accessible

Two patterns define the everyday experience:

• Frequent online meetings—customers are in the U.S. and in Germany.
• Open internal lines—questions go straight to the people who can help, without ceremony.

Add flexible cross-role support, and you get a culture that values collective problem solving. For engineers who like to take ownership and share expertise, this environment resonates.

What CADS looks for in new teammates (inferred from the talk)

Even without a bullet-point job ad, Lukas’ descriptions make the expectations clear:

• Ownership—whether as a PQE close to project leadership or as an SQE deep in testing and automation.
• Collaboration and knowledge sharing—helping across projects is normal.
• Technical curiosity and pragmatism—use modern toolchains, but aim for outcomes over buzzwords.
• Communication—ask openly internally; engage clearly in online meetings with customers.

For Quality Engineering, this pairs with solid test and automation skills (Selenium, scripting in C#/.NET, Java for mobile contexts), security grounding (OWASP, Burp Suite), and a feel for documentation and risk analysis.

Why CADS is compelling for tech talent

• Mission with impact: software for medical devices calls for rigor and responsibility.
• Clear roles, real product proximity: PQE and SQE work hand in hand and close to project management.
• Engineering-first quality: automation, build integration, and AWS services make quality part of delivery.
• Strong onboarding: a three-month buddy program with structured support from Day 1.
• Open culture: leadership access, short paths, and no “ping-pong” when you ask for help.
• Modern cloud stack: AWS (S3, EC2, SNS, SQS), Atlassian, “Asha DevOps,” Selenium, Burp Suite.
• Breadth of topics: web applications plus AR and AI in research—plenty of room to learn.
• International context: regular collaboration with customers in the U.S. and Germany.

Lines that stick

These quotes capture a culture that is ownership-driven, collaborative, and pragmatic.

Closing thoughts: Quality that scales, supported by structure

The session “Lukas Windner, Division Manager Quality Engineering bei CADS” shows how CADS embeds quality into product development: clear roles, cross-project support, grounded tech choices, and onboarding that truly supports new joiners. The quality function grew from a solo role to a six-person team in a few years—evidence that quality scales with the work, rather than being bolted on at the end.

For developers, test automation engineers, and quality specialists who like responsibility and cross-functional collaboration, this setup is a strong fit. From the first virtual touchpoint with the hiring manager to a documented three-month buddy program—and doors open all the way to the CEO—the practical details add up to an engineering culture that helps people do their best work.

If you’re looking for a place in Perg where quality isn’t a slogan but a way of building software, the insights from Lukas Windner offer a clear picture of how CADS GmbH makes that a reality.

• 

  

  Dominic Koch, Product Manager bei CADS

  Product Manager bei CADS Dominic Koch erzählt im Interview über die Abläufe im Unternehmen, was Neueinsteiger erwartet und mit welchen Technologien gearbeitet wird.

  Watch now

• 

  

  Claudia Wittner, Researcher bei CADS

  Claudia Wittner von CADS redet in ihrem Interview über die ersten Berührungspunkte mit dem Programmieren bis hin zur aktuellen Arbeit, wie ihr Alltag als Researcher aussieht und gibt Tipps für Anfänger.

  Watch now
• 

  

  Katharina Freinschlag, 3D Software Entwicklerin bei CADS

  Katharina Freinschlag von CADS spricht im Interview über ihren Weg zur Software Entwicklung, welche Challenges im 3D Development gibt und was ihrer Meinung nach Wichtig für Beginner ist.

  Watch now