End-to-end software application for mobile working machines: insights from Jürgen Webersinke (Bosch‑Gruppe Österreich)

Context and entry point into the session

In the session “Jürgen Webersinke, Gruppenleiter Softwareapplikation bei Bosch” (Speaker: Jürgen Webersinke, Company: Bosch‑Gruppe Österreich), the DevJobs.at editorial team got a concise yet rich look into a workplace where software engineering meets hydraulics, vehicle engineering, and industrial electronics. The focus: application software on ECUs for mobile working machines—from construction and agricultural equipment to track construction and fire-fighting vehicles.

The message from Webersinke’s team is clear: machine functions are becoming more complex, while operation should become simpler, safer, and more environmentally friendly. This is precisely where software application comes in—and it’s growing. From what was shared, we see a distinct engineering culture, a structured hiring process, and a hands-on learning environment where impact is visible from day one.

Why the team is growing: more functions, more ownership

The software application landscape in mobile machinery is scaling. More functionality shifts into software; the number and depth of features implemented on control units increase. For a team that specifies, implements, tests, and commissions these functions, that translates into steady growth.

• Software carries more and more of the machine’s behavior.
• Complexity is rising—along with expectations around usability, safety, and environmental performance.
• The application focus moves from isolated aspects to end-to-end responsibility.

From our vantage point, this mirrors a broader trend: software becomes the product’s core. This is exactly where Bosch‑Gruppe Österreich positions itself with Webersinke’s team.

A distributed DACH team with rituals that matter

The team operates across Germany, Austria, and Switzerland. Despite the distance, they rely on clear rhythms and shared moments to keep collaboration strong:

• Virtual check-ins every 14 days create cadence and transparency.
• In-person gatherings roughly every quarter—deliberately combined with activities like go‑karting, skiing in Switzerland, or visiting the Stuttgarter Wasen (Oktoberfest).

Practically, these are smart answers to distributed work: predictable virtual touchpoints; intentional offsites; and situations that bring people together outside project deliverables. The outcome is a group that trusts each other across borders and disciplines.

The power of mix: age diversity and cultural complementarity

The team is “very mixed in age,” with diverse origins and cultural backgrounds. The goal isn’t uniformity; it’s complementarity: different skills, perspectives, and experiences click together. In an environment that spans software, mechanics, E/E, and domain knowledge, that variety is an advantage.

The editorial takeaway: multidisciplinary work benefits from heterogeneous teams. Different profiles fill different gaps—from C programming to hydraulics intuition to on-machine commissioning.

A fair, structured, team-centered hiring process

Webersinke outlines a process that is rigorous and candidate-friendly:

1. Intake and evaluation

• Applications are reviewed jointly by recruiting and the specialist department.
• If the current opening is not a fit, they look for a better-matching role within the corporation.

1. First conversation

• Usually in person, otherwise virtual.
• Goal: mutual introduction and interest check.

1. Teamstuffing

• The next step is “Teamstuffing”: the candidate visits the department, meets potential colleagues, and gets a sense of the workplace.
• The team also explains their customer landscape: manufacturers of mobile working machines—from construction to agriculture to fire-fighting vehicles.

This puts role fit and team fit front and center. “Teamstuffing” specifically answers the crucial question: does the person match the team—and does the team match the person?

Customers and impact: machines that deliver in the field

Customers are manufacturers of mobile working machines. The use cases are tangible: construction machinery, agricultural equipment, track construction, and fire-fighting vehicles—things we see in everyday life. Software application contributes in a palpable way:

• Functions become more complex while staying intuitive to operate.
• Safety and environmental goals move to the foreground.
• ECU‑level implementation is a significant factor in making machines “work the way they work.”

For engineers, that’s a powerful driver: your work doesn’t remain abstract. You see it in the field—under load, doing real work.

Scope of work: broad, learning‑intensive, and grounded in practice

The job is “very extensive,” and the team benefits because you learn a lot—technically, methodologically, and in the domain. Many come in with a programming‑heavy background, then deepen domain knowledge on the job:

• Hydraulics
• Vehicle technology
• Combustion engines
• Electric drives

The mix defines the day-to-day: continuous learning, always varied. The breadth isn’t a goal in itself; it follows from end-to-end accountability across projects.

Tech stack and tools: C, less CoDeSys, trend toward MATLAB/Simulink

A key section of the session covered the concrete stack. The ECUs are manufactured on Bosch production lines—where engine ECUs are also built. They follow automotive requirements and specs and are adapted to the team’s needs.

• Programming and modeling
• Predominantly C
• CoDeSys “less and less”
• Trend toward MATLAB/Simulink
• Debugging and interfaces
• Tools from the automotive environment
• ECU connection mostly via CAN
• Plus automotive Ethernet
• Operating systems
• Some devices run Linux
• Specialization
• The field is “very extensive and varied”—those with specific interests can focus.

These details matter to engineers: they show the current reality and the direction of travel. C remains core, model‑based development is gaining, communication runs over CAN and automotive Ethernet, and Linux is part of the portfolio.

The applikateur role: your “own baby”—but never alone

The applikateur (application engineer) role is central. It spans the entire project lifecycle and comes with entrepreneurial ownership:

• Requirements specification with the customer
• Implementation/programming
• Project management
• Testing
• Commissioning on the prototype machine

At the same time, you’re not alone:

• Review partners and colleagues accompany the work.
• A software development process helps deliver the project “in the necessary quality.”

From our editorial lens, this setup binds ownership and teamwork productively: clear responsibility at the application level, coupled with review routines and process support.

Onboarding and continuous learning: buddy system and corporate training

On what candidates need to bring, Webersinke is pragmatic:

• No one is expected to know everything; solid fundamentals should be in place.
• Team fit matters.
• “The rest you basically learn with us.”

Execution:

• A buddy system acts as mentoring: an experienced colleague introduces the domain and helps you become project‑ready step by step.
• There’s extensive training available within the corporation, enabling ongoing upskilling across many topics.

It’s a convincing learning path—and a strong signal to talent who want to grow: hands‑on learning in projects, supported by structured training.

Collaboration tactics: connected, review‑driven, quality‑minded

Beyond biweekly virtual meetings and quarterly offsites, the team emphasizes reviews and process quality:

• Regular reviews ensure quality and knowledge transfer.
• The software development process provides structure and traceability.
• Direct customer contact in requirements and commissioning keeps the team grounded in real‑world constraints.

This combination builds trust—internally, because people learn from each other and de‑risk together; and externally, because results hold up in the field.

What stands out for tech talent

Several themes from the session translate into clear reasons to join if you’re an engineer or systems‑minded developer:

• End‑to‑end ownership: from specification to commissioning—with a strong review net.
• Visible impact: machines in the field that work “because of us”—highly motivating.
• Broad field, real specialization: C, MATLAB/Simulink, CAN, automotive Ethernet, Linux—with room to go deep.
• On‑the‑job learning: hydraulics, vehicle tech, combustion, electric drives—continuously and in context.
• Buddy system and trainings: learning by doing, backed by structured programs.
• DACH team culture: reliable virtual rhythm and deliberate in‑person moments.
• Productive diversity: age and cultural mix that truly complement each other.
• Candidate‑centric journey: careful evaluation, “Teamstuffing,” and internal alternatives if a specific role isn’t the right fit.

Practical engineering: from customer requirement to prototype machine

To understand the applikateur’s work, follow the path from initial requirements to commissioning:

1. Specification

• Requirements are clarified with the customer.
• Focus includes functionality, usability, safety, and environmental considerations.

1. Implementation

• Predominantly in C, complemented by model‑based development in MATLAB/Simulink.
• CoDeSys plays a diminishing role.

1. Integration and debugging

• Use of automotive debugging tools.
• Communication with ECUs via CAN and automotive Ethernet.
• Linux‑based devices add OS‑level considerations when present.

1. Test and validation

• Quality is ensured along the software development process.
• Peer reviews form part of the safety net.

1. Commissioning

• On the prototype machine, functions are exercised under real conditions and released.

This chain makes clear why domain depth matters—and why the team leans into project‑based learning.

Culture of responsibility: quality as a shared commitment

Amid all the diversity, there’s a shared commitment to quality. The blend of automotive standards, review culture, and process discipline ensures projects hold up. This isn’t a box‑ticking exercise—these machines have to perform in demanding environments, safely and reliably. Responsibility here means shipping results that work—in the field, not just in the lab.

The profile that fits—and how to get started

A strong foundation and the drive to grow into the domain are key:

• Solid software foundations, especially in C, are a strong start.
• Openness to model‑based approaches (MATLAB/Simulink) helps.
• Curiosity for vehicle technology, hydraulics, and drive systems is an advantage—the specifics come on the job.
• Team fit and communication matter: clarify requirements, sustain reviews, launch together.

The path in is structured—from the first conversation to “Teamstuffing” and buddy‑based onboarding.

What we’re taking away: strong reasons to apply

From DevJobs.at’s editorial perspective, the reasons to apply to the Bosch‑Gruppe Österreich software application team condense into a few strong points:

• You work on machines that matter—and that you can see in everyday life.
• You own complete projects—with a team that has your back.
• You keep learning—deep in the domain and broad in technology.
• You benefit from clear processes, solid tooling, and automotive standards.
• You join a DACH culture that creates closeness across distance.
• You find real specialization paths—without losing sight of the whole system.

Closing image: “It stays exciting—and hugely motivating”

The essence of Webersinke’s session: software application work is varied, responsible, and remarkably tangible. You see what you build. You never stop learning. You’re never alone. And the team provides the framework to grow—personally, technically, and as a group.

For engineers who like end‑to‑end ownership, visible impact, and team play in a distributed, diverse setting, this is a compelling place to be—backed by a stack and a culture that make building great machines possible.

• 

  

  Why you shouldn't build a microservice architecture

  Michael Eisenbart von Bosch stellt in seinem devjobs.at TechTalk die Vor- und Nachteile einer Microservice Architektur gegenüber – mit dem Hintergedanken, stets die Dinge etwas kritisch zu beleuchten.

  Watch now

• 

  

  Michael Eisenbart, Senior Manager bei Bosch

  Der Senior Manager bei Bosch Michael Eisenbart fasst im Interview die wesentlichen Eckpunkte der Teamorgansiation, des Recruitings und der Dev-Technologien zusammen – und warum Gitlab Profile wichtig sind.

  Watch now
• 

  

  Florian Berg, Digital Leader bei Bosch

  Digital Leader bei Bosch Florian Berg gibt im Interview einen Überblick über die Teamorganisation, den Ablauf des Recruitings und die eingesetzten Technologien.

  Watch now

• 

  

  Jasmin Grabenschweiger, Data Scientist bei Bosch

  Data Scientist bei Bosch Jasmin Grabenschweiger spricht im Interview über ihren Werdegang und gibt Tipps für Neueinsteiger und Einblicke in den Data Science Alltag mit Beispielen.

  Watch now
• 

  

  Liam Rafael, Data Engineer bei Bosch

  Liam Rafael von Bosch spricht im Interview von seinen ersten Berührungspunkten mit dem Programmieren bis hin zur aktuellen Arbeit als Data Engineer und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Dominik Steininger, DevOps Engineer bei Bosch

  DevOps Engineer bei Bosch Dominik Steininger spricht in seinem Interview über seinen Werdegang – angefangen von den ersten Gehversuchen, bis hin zur aktuellen Arbeit – und gibt Ratschläge für Einsteiger.

  Watch now
• 

  

  Melika Parpinchi, Data Scientist bei Bosch

  Melika Parpinchi von Bosch erzählt im Interview über ihren ursprünglichen Zugang zum Programmieren, das Besondere an ihrer aktuellen Arbeit bei Bosch und was ihrer Meinung nach wichtig für Anfänger ist.

  Watch now