Generelle persönliche Fragen

• Durch meine fast 8 Jährige Arbeit als Embedded Software Entwickler u. Architekt verstehe ich nicht nur die Theorie sondern habe eine Menge in der Praxis miterlebt - sowohl in erfolgreichen Projekten als auch in weniger erfolgreichen Projekten  - sei es interne oder Kundenprojekte.
• Des weiteren besitze ich nicht nur fundierte Kennntnisse in der Softwareentwicklung sondern kann auch Erfahrung im Design und der Softwarearchitektur vorweisen und damit die Qualität eines Softwareproduktes entschieden verbessern, indem ich Eigenschaften, wie Skalierbarkeit, Portierbarkeit, Performance, Security, etc. durch geeignete Maßnahmen beim Entwurf mitberücksichtigen kann. Mein Ansatz bei der Entwicklung ist es nicht lediglich die Funktionalität der Anforderung zu erfüllen, sondern Qualitätsattribute direkt mitzuberücksichtigen - quasi ein Attributsgetriebener Ansatz - Die Funktionalität kommt implizit mit. 
• Für die Stelle als Softwareentwickler für Industrial Security, braucht Rexroth jemanden, der nicht nur in der SW-Entwicklung Erfahrung gesammelt hat, sondern v.a. auch bereits Implementierung von SEcurity Komponenten durchgeführt hat.
  • Mehr als nur SW-Entwicklung (Beachtung Seitenkanäle, etc.)
  • Das habe ich bei Hilscher gemacht
• Tiefergehdende Auseinadersetzung mit IEC 62443-4-er Reihe durch Einfürung von SSDLC bei Hilscher (4-1) und Entwicklung von Komponenten nach 4-2. Ich finde es ist nicht üblich Kandidaten zu finden, die mit dieser Norm vertraut sind, aber Hilscher und Bosch Rexroth in der industriellen Automatisierung tätig sind, passt das super für beide seiten.
• Den Vortiel den ich bringen werde, ist dass Bosch Rexroth jemanden gewinnt, der neugierig und motiviiert ist und Erfahrungen sowohl in der Softwareentwicklung, -architektur aber vor allem auch in diversen Gebieten der Embedded SW Security mitbringt.

Kurz gesagt, herausfordernde Technik und Innovation, weswegen ich auch den Studiengang und letzendlich auch dieses Berufsfeld gewählt habe.

• Neue Technische Herausforderungen, bei denen man erstmal recherchieren und dazulernen muss um die Aufgabe lösen zu können. Ich bin hier neugierig und finde gerade die Konfrontation mit neuen techn. Herausforderungen sehr spannend.
• Ein Problem nicht nur zu lösen, indem die geforderte Funktionalität erreicht wird, sondern technisch raffinierte Lösungen zu finden, welche ich auch gerne mit Kollegen oder im Team diskutiere.
• Mir ist es wichtig, dass ich selber zufrieden bin mit der Arbeit, die ich leiste - dafür gehe ich auch gerne die Extrameile, um das zu erreichen. 
• Zu guter letzt die Tatsache, aber auch ein für mich sehr wichtiger Punkt, dass der Job beide Tätigkeitsfelder abdeckt an denen ich starkes Interesse mitbringe, nämlich Softwareentwicklung und Embedded Security - und ich finde dass gerade bei dieser Kombination keine Herausforderung ist, wie die andere und ich bin der Meinung dass diese Rolle genau das mitbringt.

• Kollegen wissen nach einiger Zeit, dass ich zuverlässig und kreativ bin und disktuieren konstruktiv auch gerne über technische Probleme mit mir um diesbezüglich vllt. eine andere Ansicht  zu gewinnen.
• Ich bin hilfsbereit - und versuche bei Fragen von Kollegen soweit es geht zu helfen.
• Sie wissen, dass sie auch unter Druck auf mich und meine Ergebnisse zählen können.
• In der Gruppe bringe ich das Fünkchen Spaß mit - was die Atmosphäre auch auflockert.
• Und ich nörgle nicht sondern versuche selbst in schierigen Situationen das positive zu sehen - ich bin also motiviert und schaffe es auch oft diese Motivation auf andere Teamkollegen zu übertragen.

• Ich finde, das lässt sich so pauschal nicht beantworten, sondern es kommt auf das Projekt bzw. auf das Thema an. Ich finde es hier einfach wichtig, dass alle Beteiligten bei der Teamarbeit ihr Potential und ihre Kenntnisse ausnutzen. 
• Nehmen wir an, es is ein Thema, bei dem ich mich sehr gut auskenne, kann ich die Teamarbeit auch leiten - wie z.B. wenn es um bestimmte Themen Rund um den Bereich Security geht.
• Ansonsten bin ich immer für konstruktive technische Diskussionen zu haben über Vorschläge der Teamkollengen.
• Also zusammengefassst eine Kombination aus Voranbringen von den postiven Vorschlägen von Kollegen, aber auch das Einbringen eigener Kenntnisse und der Vertretung der eigenen Meinung. 

Zwar versuche ich, Fehler zu vermeiden - mmN. sind Fehler in der Softwarebranche unvermeidlich (statistisch 1 Bug pro 10 Zeilen Code) doch sollte ich trotzdem einmal damit konfrontiert werden, löse ich die Situation in zwei Schritten:

1. Zunächst konzentriere ich mich auf eine passende Lösung, um den Fehler zu beheben. Dabei gehört meiner Meinung nach auch das Informieren der relevanten Stakeholder (PJM, etc.) dazu, falls erforderlich.
2. Anschließend lasse ich noch einmal Revue passieren, wie es dazu kommen konnte, um in Zukunft bei einer ähnlichen Situation besser reagieren zu können.

Ich finde das Wort Rückschläge etwas negativ geprägt. Letzendlich für mich sind es Erfahrungn die man gemacht hat und letzendlich sind Erfahrungen dazu da um aus ihnen zu lernen. 

• Neugierig
• Zuverlässig
• Kreativ

• Zeitorganisation bei mehreren parallen Projekten
  • Lösung mit todo lists und vereinfachte Form von Kanban
• Zurückhaltend in größeren Meeting runden
  • Ich glaube v.a. wg. des Jungen Alters im Vgl. zu anderen Kollegen
  • Dadurch vergebe ich die Chance gute Ideen und Ansätze einzubringen
  • Gerade als junges Teammitglied kann ich frischen Wind in die Sache bringen und das sehe ich z.B. als einen Lösungsansatz für dieses Problem … mit steigendem Alter wird das meiner Meinung nach dann auch besser
• Small-Talk und Networking
  • Nicht gut in Smalltalk bzw. sehe wenig Sinn dahinter à dadurch Netowrking schwer
  • Das sehe ich aber als einen Punkt den man sich abeignen kann, z.B. durch Seminare, Artikel etc. à Verbesserung hier sollte auf jeden Fall möglcih sein

• Sehr gute Präsentationstalent
  • interne und externe Schulungen bzw. Präsentationen vor Kunden bei Themen wie Security
• Wissbegierig und hohe Auffassungsgabe
  • Projekte / Kundenprojekte mit neuen ASICs werden u.a. oft mir zugeteilt, da ich mich schnell einarbeiten kann und auch das Projekt auch den qualitativen Anforderungen entspricht
• Arbeiten unter Druck – ohne dass die Qualität darunter arbeitet
  • das motiviert mich ehrlich gesagt, statt mich abzuschrecken bzw. "bewegungsunfähig" zu machen
• Techn. Sachverhalte bis ins letzte Detail verstehen – dann verinnerliche ich sie auch

• Portierung der TLS-Bibliothek auf unsere ASICs, Treiberentwicklung für unsere KryptoHardwarebeschleuniger und INtegration in die TLS-Bibliothek 
• Damit habe ich den Grundstein für Softwarekomponenten und Protocol Stacks gelegt, welche auf TLS angewiesen sind
  •  Profinet Security, CIP (EtherNET / IP), Secure Webserver, etc.
• Definition einer Hilscher eigenen PKI (public-key-infrastructure)
• Implementierung von Secure Boot bzw. der erforderlichen kryptographischen Algorithmen im ROM Code unseres neusten ASICs
• Entwicklung von Komponenten für embedded Authentifizierung und Authorisierung
• Anforderungsanalyse für gewünschte Security Funktionalitäten für unseren nächsten ASIC  

• x ist ein Top Arbeitgeber mit super Arbeitsbedigungen super Kollegen und auch die Beziehung zum Vorgesetzten ist gut und von Offenheit geprägt
• Folglich ist die Entscheidung die Firma zu verlassen zu wollen ist mir relativ schwer gefallen.
• Jedoch haben hier zwei Punkte eine entscheidende Rolle gespielt
  • Ich bin als Junior Software Architekt eingestellt worden . Aktuelll arbeitern wir seit mir als vier Jahren an einer neuen Platform für E- und V-Stapler, ohne SW-Architektur überhaupt mit berücksichtigt zu haben. Jetzt wird langsam klar, dass das Ignorieren dieses Themas, was ja eigentlich im Entwicklungsprozess eine der frühsten Stadien der Entwurfsphase sein sollte, nicht mehr weitergehen kann, da kontinuierlich Probleme hochkommen, die genau von dieser Natur sind - nämlich einer fehlenden SW-Architekturdefinition. Uns wird langsam klar dass das Thema SW-Architektur uns langsam einholt. 
    • Ich habe mehrmals Lösungsvorschläge ausgedrückt und vorgestellt, wie wir, das Problem über die nächsten Monate in den Griff bekommen könnten, und meinen Vorgesetzten ist es auch klar, dass das aktuell keine Rolle für einen SW-Architekten ist, leider sehe ich weder jetzt noch in naher Zukunft weder konrekte Handlungen noch die Bereitschaft die Situation zu ändern und die Vorschläge in die Tat umsetzen zu wollen. 
• Im Vorstellungsgespräch habe ich es so verstanden, dass ich als SW-Architekt im Team die Architektur für Komponenten definiere aber auch die Implementierung von Komponenten übernehmen kann. Da ich aber aktuell der einzige wohlgemerkt Junior Softwarearchitekt bin, ist die Komponente Implementierung leider weggefallen und gerade dieses Thema Softwareentwidcklung fehlt mir.  

Projektmanagement Techniken haben allle die selbe Aufgabe - nämlich ein Projekt zu Ende zu bringen. Aber es gibt verschiedene Möglichkeiten und Projektmanagement und einzelne haben sich heutzutage durchgesetzt.

1. Wasserfallmodell
2. V-Modell
3. Scrum
4. Kanban
5. ...

Das Wasserfallmodell erfreut sich heute immer noch großer Beliebtheit. Dabei werden große Projekte in mehrere Stufen / Phasen unterteilt:

• Aufteilung großer Projekte in mehrere Stufen / Phasen (5-6), die aufeinander aufbauen und in einer bestimmten Reihenfolge durchgeführt werden
• Gut planbar da klare feste Ziele für jede Phase (Meilensteine) 
• Bei stabilen Anforderungen, ist das Budget meistens gut abschätzbar

Folgende Phasen:

• Anforderungsanalyse
• Systemdesign
• Implementierung und Modultests
• System- und Integrationstests
• Auslieferung und Wartung

Nachteile:

• großer Aufwand wenn Fehler erst später gefunden werden z.B. während des System- und Integrationstests
  • Wiederholung der einzelnen Phasen
• Rückschritte und Iterationen können hier als Veränderung / Verbesserung das Problem beheben (Stichwort kaskadiertes Wasserfallmodell)
  • allerdings sinkt dadurch der Vorteil der Planbarkeit, wofür das Wasserfallmodell eigentlich steht

Das ISO/OSI (Open Systems Interconnect Model) ist ein Referenzmodell für Netzwerkprotokolle als Schichtenarchitektur. Seit 1984 ist es ISO standardisiert.

Zweck des OSI-Modells ist, Kommunikation über unterschiedlichste technische Systeme hinweg zu beschreiben und die Weiterentwicklung zu begünstigen. Dazu definiert dieses Modell sieben aufeinanderfolgende Schichten (engl. layers) mit jeweils eng begrenzten Aufgaben.

Kurzzusammenfassung

7. Schicht / Anwendung: Funktionen für Anwendungen sowie die Dateneingabe und -ausgabe.

6. Schicht / Darstellung (Presentation): Umwandlung der systemabhängigen Daten in ein unabhängiges Format.

5. Schicht / Sitzung: Steuerung der Verbindungen und des Datenaustauschs.

4. Schicht / Transport: Zuordnung der Datenpakete zu einer Anwendung.

3. Schicht / Vermittlung (Network Layer): Routing der Datenpakete zum nächsten Knoten.

2. Schicht / Sicherung (Data Link Layer): Segmentierung der Pakete in Frames und Hinzufügen von Prüfsummen.

1. Schicht / Bitübertragung (Physical Layer): Umwandlung der Bits in ein zum Medium passendes Signal und physikalische Übertragung.[9]

Ähnlich dem Wasserfallmodell wird das Projekt auch hier in Phasen aufgeteilt.

• es gibt verschiedene Phasen und jeder Phase besitzt eine "komplementäre" Phase, welche diese Phase testen soll
• linke Seite (Spezifikationsphase) - rechte Seite (Testphasen)
  • Systemanforderungsanalyse < > Abnahme und Nutzung
  • Funktionaler Systementwurf < > Systemtest
  • techn. Systementwurf < > Integrationsttests
  • Softwarearchitektur < > Komponentets
  • Software-Entwurf < > Unit/Modultests
• Es wird also die Spezifikation ggn. die Testphasen getestet
• Unterschied Wasserfall: Die Spezifikation von Testes wird bereits frühzeitig gefordert, und nicht, erst wenn die entsprechende Phase errreicht worden ist
  • z.B. Unit-Tests müssen bei der Spezifikation der Softwarearchitektur definiert werden

Vorteile:

• erweiterbar und anpassbar
• integriert viele Aspekte eines Projektentwicklungsprozesses

Nachteile:

• nicht für kleine Projekte geeignet
• man sagt, dass es zu allg. und zu generisch ist

Scrum ist eine agile Projektmanagementmethode mit den Hauptansätzen "empirisch", "inkrementell" und "iterativ". Es hat das folgende agile Manifest:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Bei Scrum gibt es 3 Rollen:

1. Product Owner
   • verantwortlich für die Eigenschaften und den wirtschaftlichen Erfolg des Projektes
2. Entwicklungsteam
   • verantwortlich für die Lieferung der Produktfunktionalitäten, die in einer bestimmten Reihenfolge vom Product Owner vorgegeben werden
3. Scrum Master
   • als Coach verantwortlich, dass das "Scrum" Rahmenwerk gelingt
   • Zusammenarbeit mit dem Entwicklungsteam - gibt aber keine Arbeitsanweisungen
   • kümmert sich um Störungen und Konflikte

• Sprints
  • Sprints umfassen ein Zeitfenster von ca. 1 - 4 Wochen (Festlegung am Anfang und sollte nicht verändert werden). Er wird nicht verlängert. Sprints sind zu Ende wenn dasZeitfenster für den Sprint zu Ende ist.
  • Ein Sprint ist ein Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird
    • er beginnt mit dem Sprint Planning und und endet mit dem Sprint Review -und -Retrospektive
• Sprint Planning
  • Was kann im kommenden Sprint entwickelt werden
    • gemeinsames Verständnis soll geschaffen werden, für die i Sprint zu erledigende Arbeit
  • Wie wird die Arbeit im kommenden Sprint entwickelt
    • Planung des Entwicklungsteams, welche Aufgaben zum Errreichen des Sprintziels notwendig sind
• Sprint Review
  • Die Sprint-Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen.
  • Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können

"Kanban - jap. Signalkarte"

• Kanban ist eine agile Projektmanagementmethode, mit der man den Workfllow in Projekten optimaler planen, überwachen und steuern kannn
• dabei gibt es eine adaptierte To-Do-Liste nämlich das Kanban Board
• das Kanban Board stellt dabei Aufgaben, Verantwortlichkeiten und Abläufe innerhalb eines Projekts übersichtlich dar
• Die Aufteilung gliedert sich in Spalten mit Einträgen zu Aufgaben, die man mit seinen Projektkollegen der Reihe nach arbarbeiten kann und bei Abarbeitung in die nächste Spalte verschieben kann
• mit dem Kanban Board lässt sich schnell ein Überblick verschaffen, welche Aufgabe sich gerade in welchem Stadium befindet - dabei wird das ganze im Kanban Board visualisiert
  • Bsp: To-Do, Doing, Done (natürlich erweiterbar oder modifizierbar nach eigenen Anforderungen)

• Ziel ist es eine Firma zu finden, an das ich mich langfristig binden will, und mich sowohl fachlich als auch persönlich weiterentwickeln kann. Gerade in den ersten Jahren ist es mir wichtig eine steile Lernkurve zu haben und meine fachliche Expertise weiter auszubauen. Gerade das Thema IEC 62443 z.B. wäre ein Thema, bei welchem ich meine bereits gewonnenen Kenntnisse noch weiter vertiefen wollen würde.
• Technische Herausforderungen und abwechslungsreiche Aufgaben. Die Idealkombination wäre Themen rund um  Softwaredesign- und entwicklung als auch Cybersecurity Themen zu vereinen. So würde ich sehr viel an bereits aufgebauter Expertise und Kenntnissen ausschöpfen und einsetzen können.
• Weiterhin ist mir vor alllem in der Anfangszeit wichtig, einen Mentor vorzugsweise auch in Kombination mit einer entsprechenden Einarbeitung zu haben. Das sehe ich als ausschlaggebend, um nach einer gewissen Zeit effizient und vor allem eigenständig arbeiten zu können.
• Weiterhin ist mir wichtig, bei den Themengebieten Sparringpartner (Kollegen) auf Augenhöhe zu haben, mit denen man verschiedene Lösungswege diskutieren kann, um letzendlich die beste Lösung für eine Aufgabenstellung zu finden. V.a. beim Thema Security finde ich das sehr wichtig, um auch sicherzustellen, dass an die wichtigsten Punkte bzgl. der sicheren Produktentwicklung gedacht wurde.
• Respektvoller Umgang zwischen den Kollegen und offener Austausch zwischen Vorgesetzten und Mitarbeitern.

Die gab es in den 8 Jahren auf jeden Fall. Wie ich solchen Situationen umgehe, ist es einen lösungenorientierten Ansatz zu verfolgen, bestehend aus Problemanalyse und Erarbeitung einer Lösung, um das Problem lösen zu können. Ich kann Ihnen da gerne Beispiele dazu liefern.

• Einführung der IEC 62443 4-1 und 4-2 
• Abblockung der Themen aus Management Ebene - keien Notwendigkeit gesehen (Kosten, Projektlaufzeit)
• Lösungsorientierter Ansatz:
  • Dem Managementteam bewusst machen, dass wir als Zulieferer industrieller Kommunikationslösungen verpflichtet sind
  • Datensammlung (Support-Tickets, bereits gelaufene Kundengespräche), aus denen klar werden sollte dass die Nachfragen bei der Firma Hilscher bzgl. dieser Norm kontiniuierlich gestiegen sind (Hardcorekunden)
  • Die Lösung, die ich erarbeitet habe, war es diese Daten in Form einer Präsentation zu verpacken und dem Managementteam vorzustellen (es fehlte das Bwusstsein, aber auch das Wissen)
    • Vorteile Kundenvertrauen, Benutzung von Marketing, Neukundengewinnung, Verlust von Bestandskunden
  • In dem Rahmen war as Thema dem Management überhaupt nicht bewusst und nach ein paar weiteren Meetings wo Details und ein möglicher Zeitplan vorgestellt wurden, haben wir letzendlich eine Budgetfreigabe für das kommende Jahr bekommen

Hier verfolge ich einen lösungsorientierten Ansatz bestehend aus Problemanalyse und Ausarbeiten von potentiellen Lösungen für die problematische Situation.

Letzte Züge eines Kundenprojektes bei dem ich verantwortlich für die Entwicklung war.

• Kommunikation lief größtenteils über Tickets, wobei noch einige Tickets gab bei denen die Anforderung noch nicht klar genug war und ich Rückfragen gestellt habe, auf deren Antwort ich vergeblich gewartet habe
• Versuch, die Fragen in den Tickets nochmal zu stellen - kann ja untergegangen sein - trotzdem vergeblich gewartet und die Deadline näher rückte
• Lösung des Problems:
  • keine non-verbale Kommunikation durch Tickets, sondern direkte Kommunikation mit dem Verantwortlichen für die Tickets gesucht
  • In wenigen Meetingrunden die Anforderungen klar definiert und in den entsprechenden Tickets festgehalten
  • Damit konnte ich die letzten fehlenden Produktfeatures klären und implementieren und testen und das Projekt konnte in die nächste Phase übergehen (Interne Tests der Testabteilung)

Ich glaube, dass es in nahezu allen Teams mal zu Spannungen kommen kann. „In solchen Situationen haben wir die Probleme offen in einer Teamsitzung angesprochen. Im Gespräch stellte sich heraus, dass einige Kollegen überlastet waren. Daraufhin haben wir die Aufgaben neu verteilt und konnten die Kollegen so gemeinsam entlasten und die Spannungen lösen.“

• Was ist Ihrer Meinung nach die größte Herausforderung bei dieser Rolle als SW-Entwickler für Security?
• Mein Eindruck aus den bisherigen gesprächen ist sehr positiv und ich denke, dass ich viele der Anforderungen gut erfülle. Ich bin an dieser Position auch interessiert. Daher, gibt es noch irgendwelche Fragen ihrerseits, die noch offen sind und die wir besprechen müssten?
• Wie sieht das Onboarding aus bzw. meine ersten drei - sechs Monate?
• Was ist Ihrer Meinung nach die wichtigste Eigenschaft, welche man für diese Position mitbringen sollte?

Meine Gehaltsvorstellung liegt bei 85000 im Jahr. 

• Aktuell 84000 (sehe keinen Grund mich mit meinem Werdegang under Praxiserfahrung im Gehalt zu verschlechtern)
• Ich kombiniere verschiedene technische Kenntnisse die aktuell am Markt stark gefragt sind
• Darüber hinaus habe ich bereits zwei konkrete Angebote, welche vom Gesamtpaket her auch sehr attraktiv sind