Interviewfragen für Embedded-Entwickler, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Lern die kurze Antwort und häng ein Gerät daran, an dem du gearbeitet hast: den Prozessor, den Fehler, das Werkzeug, mit dem du ihn gemessen hast, und was ihn behoben hat. Interviewer im Embedded-Bereich trauen einer Geschichte zur Fehlersuche mit einer Aufnahme vom Oszilloskop mehr als einer Liste von Features, die du kennst.

Was ein Embedded-Entwickler können muss

• Sprachen: C auf hohem Niveau, C++In 76 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Modernes C++ für kleine Geräte: kein überraschender Speicherverbrauch, Vorsicht mit Exceptions und Templates, klare Zuständigkeit für jeden Puffer. für größere Firmware, PythonIn 22 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Skripte für Tests, Flashen, das Auswerten von Logs und Prüfstände; selten auf dem Gerät selbst. für Tests und Werkzeuge und eine Vorstellung davon, wo RustIn 2 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Eine neuere Wahl für speichersichere Firmware; in manchen Anzeigen ein Plus, in sicherheitszertifizierten Produkten noch selten. passt.
• Echtzeit: Interrupts, Scheduling, Prioritäten und Timing, mit oder ohne Echtzeitbetriebssystem wie FreeRTOS oder Zephyr.
• Hardware: ein Datenblatt und einen Schaltplan lesen, BusseIn 20 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Bus- und Netzwerkprotokolle: CAN, SPI, I2C, UART, Ethernet und Funkverbindungen, und wie du sie am Oszilloskop liest. wie SPI, I2C, UART und CAN, und messen mit Oszilloskop, Logikanalysator und JTAG-Debugger.
• Qualität: Tests außerhalb des ZielsystemsIn 8 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Tests der Logik auf dem Build-Rechner, mit Platzhaltern statt der Hardware, bei jeder Änderung ausgeführt., Tests auf einem HIL-Prüfstand (das echte Gerät in einer simulierten Umgebung), statische Analyse und Programmierrichtlinien und eine PipelineIn 16 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Jede Änderung für das Zielsystem gebaut, durch statische Analyse und Tests geschickt, am besten auch auf echter Hardware., die für das Zielsystem baut.
• Produkte: Low Power, sichere Updates im Feld, Sicherheit der GeräteIn 9 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Secure Boot, signierte Updates, keine Standardpasswörter und ein Plan, Schwachstellen nach der Auslieferung zu beheben. und, wo nötig, Funktionale Sicherheit.

Echtzeit, Interrupts und Nebenläufigkeit

Was macht Software echtzeitfähig, und wann brauchst du ein Echtzeitbetriebssystem?

Worauf sie achten: dass du weißt, dass Echtzeit rechtzeitig heißt, jedes Mal, nicht schnell.

Kurze Antwort: „Echtzeitsoftware muss innerhalb einer festen Frist reagieren; eine späte Antwort ist eine falsche Antwort. Ein einfaches Gerät kann in einer Hauptschleife mit Interrupts laufen. Wenn sich mehrere Aufgaben mit verschiedenen Fristen den Prozessor teilen müssen, plant ein Echtzeitbetriebssystem, ein RTOS, sie nach Priorität ein, sodass die dringende Aufgabe immer zuerst läuft.“

Die ausführliche Antwort: Harte Echtzeit heißt, eine verpasste Frist ist ein Ausfall, etwa beim Airbag oder in der Motorsteuerung; weiche Echtzeit heißt, eine verpasste Frist senkt nur die Qualität, etwa beim Audio. Ein RTOS wie FreeRTOS oder Zephyr bietet Tasks, Prioritäten, Queues und Timer mit bekanntem Timing; der Preis sind Speicher und neue Arten von Fehlern zwischen den Tasks. Miss den schlechtesten Fall, nicht den Durchschnitt: Schalte einen Pin am Anfang und am Ende einer Task um und beobachte ihn am Oszilloskop.

Schwache Antwort: „Echtzeit heißt, der Code ist sehr schnell.“ Nachfrage: „Dein Regelkreis muss jede Millisekunde laufen, und eine Logging-Task verzögert ihn manchmal.“ Gib der Schleife eine höhere Priorität, nimm das langsame Logging aus ihrem Weg und miss danach den Jitter.

Was soll ein Interrupt-Handler tun, und was darf er nie tun?

Worauf sie achten: kurze Handler und eine sichere Übergabe der Daten an den Rest des Programms.

Kurze Antwort: „Ein Interrupt-Handler soll kurz sein: die Hardware lesen, die Daten ablegen, das Flag löschen und einer Task oder der Hauptschleife signalisieren, den Rest zu erledigen. Er darf nie warten, an einem Lock blockieren, Speicher anfordern oder auf einen langsamen Port schreiben, denn alles andere wartet, solange er läuft.“

Die ausführliche Antwort: Daten, die sich ein Handler und der Hauptcode teilen, brauchen Sorgfalt: Der Compiler muss wissen, dass sich der Wert jederzeit ändern kann, und ein Wert, der breiter ist, als der Prozessor auf einmal lesen kann, muss mit kurz gesperrten Interrupts oder über einen sicheren Puffer gelesen werden. Die Prioritäten der Interrupts entscheiden, welcher Handler einen anderen unterbrechen darf. Lange Handler zeigen sich als verlorene Nachrichten auf einem Bus oder als Jitter in einem Regelkreis, also miss, wie lange jeder einzelne dauert.

Schwache Antwort: „Ich mache die ganze Verarbeitung im Interrupt, damit nichts verloren geht.“ Nachfrage: „Bei hoher Geschwindigkeit gehen UART-Bytes verloren.“ Nutze den DMA oder einen Ringpuffer, halte den Handler kurz und prüfe die Prioritäten.

Zwei Tasks teilen sich Daten, und das Gerät hängt sich etwa einmal pro Woche auf. Wie findest du den Fehler in der Nebenläufigkeit?

Worauf sie achten: eine Methode für seltene Fehler und Wissen über Race Conditions, Deadlocks und Prioritätsinversion.

Kurze Antwort: „Ich sorge dafür, dass es öfter passiert: mehr Last, kürzere Timeouts, viele Geräte auf einem Testgestell. Ich füge günstiges Tracing hinzu, etwa Zeitstempel in einem Ringpuffer, und lasse den Watchdog die Aufzeichnung vor dem Reset sichern. Dann suche ich nach geteilten Daten ohne Schutz, nach Locks, die in verschiedener Reihenfolge genommen werden, oder nach einer Task mit niedriger Priorität, die einen Lock hält, den eine Task mit hoher Priorität braucht.“

Die ausführliche Antwort: Klassische Fehler sind eine Race Condition auf geteilten Daten, ein Deadlock zwischen zwei Locks und die Prioritätsinversion, die ein Mutex des RTOS mit Prioritätsvererbung vermeidet. Trace-Werkzeuge für das RTOS zeigen, welche Task wann lief. Behebe das Design, nicht das Symptom: ein Besitzer für jedes Stück Daten und Nachrichten über Queues machen viele Locks überflüssig. Lass die Korrektur länger auf dem Gestell laufen als der alte Abstand zwischen zwei Ausfällen, bevor du sie für erledigt erklärst.

Schwache Antwort: „Ich baue eine Verzögerung ein, und es geht weg.“ Nachfrage: „Es passiert nur im Feld, nie am Labortisch.“ Sammle Absturzdaten von den Geräten, vergleiche die Bedingungen im Feld wie Temperatur und Netz und stelle sie nach.

Speicher, Hardware und Busse

Wie verwaltest du den Speicher auf einem kleinen Mikrocontroller, der keinen Platz für Fehler lässt?

Worauf sie achten: dass du den Speicher vorab planst und weißt, wo er ausgehen kann.

Kurze Antwort: „Ich vermeide es, nach dem Start zur Laufzeit Speicher anzufordern, damit er später weder fragmentieren noch ausgehen kann. Puffer sind fest und für den schlechtesten Fall bemessen. Ich prüfe im Map-File, wie viel Flash und RAM belegt sind, gebe jeder Task einen Stack mit Reserve und messe den echten Stack-Verbrauch mit einem Füllmuster.“

Die ausführliche Antwort: Ein Stack Overflow ist der klassische stille Fehler: Er überschreibt andere Daten und zeigt sich an ganz anderer Stelle. Eine Memory Protection Unit kann ihn sofort abfangen. In C++In 76 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Modernes C++ für kleine Geräte: kein überraschender Speicherverbrauch, Vorsicht mit Exceptions und Templates, klare Zuständigkeit für jeden Puffer. werden Features, die Speicher anfordern oder Exceptions werfen, oft abgeschaltet oder mit Vorsicht genutzt. Leg Konstanten in den Flash, achte darauf, was Bibliotheken mitbringen, und verfolge den Speicherverbrauch in der Pipeline, damit eine Änderung, die das letzte freie RAM frisst, vor dem Release auffällt.

Schwache Antwort: „Der Chip hat genug RAM.“ Nachfrage: „Nach einem neuen Feature setzt sich das Gerät zufällig zurück.“ Prüfe zuerst die Höchststände der Stacks und das Map-File.

Du bekommst eine neue Platine vom Hardwareteam. Wie nimmst du sie in Betrieb, angefangen beim Datenblatt?

Worauf sie achten: ein schrittweises Vorgehen mit Hardware und Teamarbeit mit Hardwareentwicklern.

Kurze Antwort: „Ich fange klein an: Versorgung und Takte, dann ein blinkender Pin und eine serielle Schnittstelle für Meldungen, dann ein Peripheriegerät nach dem anderen, jeweils geprüft gegen Datenblatt und Schaltplan. Jeden Schritt messe ich mit dem Oszilloskop oder dem Logikanalysator, bevor ich ihm traue, und ich notiere jeden Fehler der Platine für das Hardwareteam.“

Die ausführliche Antwort: Das Datenblatt und das Referenzhandbuch nennen die Register, Timings und Errata; lies die Errata zuerst, denn bekannte Fehler des Chips sparen Tage. Prüfe die Verbindung zum Debugger, JTAG oder SWD, dann den Taktbaum, dann den Speicher, dann jeden Bus. Schreib kleine Testprogramme, die der Produktionstest später wiederverwenden kann. Wenn etwas fehlschlägt, entscheide mit dem Hardwareentwickler durch Messen, nicht durch Streiten, ob es an der Platine oder am Code liegt.

Schwache Antwort: „Ich spiele die komplette Firmware auf und schaue, was funktioniert.“ Nachfrage: „Der Prozessor startet überhaupt nicht.“ Prüfe Versorgung, Reset und Takt mit dem Oszilloskop, dann die Verbindung zum Debugger.

Ein Sensor am SPI-Bus liefert Unsinn. Wie suchst du den Fehler?

Worauf sie achten: dass du einen Bus am Labortisch lesen und mit dem Datenblatt abgleichen kannst.

Kurze Antwort: „Ich hänge einen Logikanalysator an den Bus und dekodiere ihn: Ist der Takt da, ist Chip Select aktiv, welcher Modus und welche Geschwindigkeit werden genutzt, welche Bytes gehen raus und kommen zurück? Dann vergleiche ich jedes Detail mit dem Datenblatt des Sensors: Taktpolarität und Phase, Bitreihenfolge, Timing, das Format der Befehle.“

Die ausführliche Antwort: Ein falscher Modus, ein zu schneller Takt, eine fehlende Pause nach Chip Select oder ein geteilter Bus, auf dem ein anderes Gerät antwortet, sind die üblichen Ursachen. I2C hat seine eigenen: Pull-up-Widerstände, Adressen und ein Gerät, das die Leitung auf low hält. UART braucht dieselbe Geschwindigkeit und dieselben Einstellungen; der CAN-Bus braucht Abschlusswiderstände und das richtige Bit-Timing. Frag immer, ob der Bus ein Problem der Software, der Verkabelung oder der Signalqualität ist, und sieh dir das Signal am Oszilloskop an, wenn die dekodierten Bytes zufällig aussehen.

Schwache Antwort: „Ich probiere verschiedene Einstellungen, bis es funktioniert.“ Nachfrage: „Am Labortisch funktioniert es, im Gehäuse nicht.“ Sieh dir am Oszilloskop Signalqualität, Kabellänge und Störungen an.

Strom, Updates und Fehler

Wie entwirfst du Firmware für niedrigen Stromverbrauch auf einem Gerät, das jahrelang mit einer Batterie laufen muss?

Worauf sie achten: dass du den Strom misst und das Gerät so auslegst, dass es schläft.

Kurze Antwort: „Das Gerät schläft im tiefsten Modus, den es kann, und wacht nur für Arbeit auf, per Timer oder per Interrupt. Ich schalte ungenutzte Peripherie und Takte ab, bündle den Funkverkehr und messe den Strom über einen ganzen Tageszyklus mit einem Leistungsanalysator, denn ein vergessener Pull-up oder ein Funkmodul, das zu oft aufwacht, ruiniert die Laufzeit der Batterie.“

Die ausführliche Antwort: Stell ein Energiebudget auf: der Strom in jedem Zustand mal die Zeit, die das Gerät darin verbringt. Funk und Sensoren dominieren meist, also sende seltener und weniger Daten. Ein Echtzeitbetriebssystem kann in den Schlaf gehen, wenn keine Task bereit ist. Prüfe den Ruhestrom auf der fertigen Platine, nicht auf dem Evaluation Kit, und wiederhole das nach jeder Änderung der Firmware.

Schwache Antwort: „Wir nehmen eine größere Batterie.“ Nachfrage: „Die Batterie hält nur ein Drittel der geplanten Zeit.“ Miss das Profil, finde, was nie schläft, und prüfe die Einstellungen des Funkmoduls.

Wie aktualisierst du Firmware im Feld per Funk, als OTA-Update, ohne Geräte unbrauchbar zu machen?

Worauf sie achten: ein sicheres Update-Design mit einem Weg zurück.

Kurze Antwort: „Ein kleiner Bootloader, der sich im Feld nie ändert, prüft und startet die Anwendung. Ein neues Image wird in einen zweiten Slot geladen, seine Signatur geprüft, und erst dann schaltet der Bootloader darauf um. Wenn die neue Version nicht bestätigt, dass sie gut läuft, rollt der Bootloader zurück. Updates gehen in Wellen hinaus, und wir achten dabei auf Ausfälle.“

Die ausführliche Antwort: OTA-Updates brauchen ein signiertes Image, damit nur deine Firmware läuft; eine Prüfung der Version, damit alte, fehlerhafte Versionen nicht wieder geladen werden können; und genug Flash für zwei Images oder ein sorgfältiges Verfahren mit weniger. Ein Stromausfall während eines Updates muss ein funktionierendes Gerät hinterlassen. Viele Teams nutzen einen bestehenden sicheren Bootloader, statt einen eigenen zu schreiben. Halte den Update-Pfad in der Pipeline getestet, denn ein kaputter Updater lässt sich nicht per Update reparieren.

Schwache Antwort: „Wir überschreiben den Flash mit der neuen Version.“ Nachfrage: „Mitten im Update fällt der Strom aus.“ Zeig, wie die zwei Slots und der Rollback das Gerät am Leben halten.

Was macht ein Watchdog, und wie erholst du dich im Feld von einem Fehler?

Worauf sie achten: dass du für Fehler entwirfst und aus ihnen lernst.

Kurze Antwort: „Ein Watchdog ist ein Hardware-Timer, der das Gerät zurücksetzt, wenn die Software ihn nicht rechtzeitig bedient. Ich bediene ihn erst, wenn jede wichtige Task gezeigt hat, dass sie lebt, nicht aus einem Timer-Interrupt, damit eine hängende Task einen Reset auslöst. Vor dem Reset sichert das Gerät die Ursache, etwa die Task und den letzten Zustand, um sie später zu melden.“

Die ausführliche Antwort: Ein Reset ist das letzte Mittel, keine Lösung: Das Gerät muss in einen sicheren Zustand zurückkehren, und das Team muss herausfinden, warum. Speichere Reset-Gründe und Fehleraufzeichnungen in Speicher, der den Reset übersteht, und schick sie bei der nächsten Verbindung nach Hause. Zähl die Resets pro Version; ein Anstieg nach einem Release ist ein Grund, den Rollout zu stoppen. In sicherheitsrelevanten Produkten ist der Watchdog Teil des Sicherheitskonzepts und wird wie jede andere Funktion getestet.

Schwache Antwort: „Ich bediene den Watchdog im Timer-Interrupt, damit er nie zurücksetzt.“ Nachfrage: „Geräte im Feld setzen sich einmal am Tag zurück.“ Sammle die gespeicherten Gründe und such die Task, die aufhört, den Watchdog zu bedienen.

Tests, Safety und Security

Wie testest du Embedded-Software, wenn die Hardware spät kommt oder knapp ist?

Worauf sie achten: Testebenen, die anfangen, bevor es die Platine gibt.

Kurze Antwort: „Ich halte die Logik vom Zugriff auf die Hardware getrennt, damit das meiste davon als Unit-TestsIn 8 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Tests der Logik auf dem Build-Rechner, mit Platzhaltern statt der Hardware, bei jeder Änderung ausgeführt. auf dem Build-Rechner läuft, mit Platzhaltern für die Hardware. Statische Analyse läuft bei jeder Änderung. Auf echter Hardware speist ein HIL-Prüfstand simulierte Signale in das Gerät ein und prüft seine Ausgänge automatisch, und ein paar Platinen laufen über Nacht in Langzeittests.“

Die ausführliche Antwort: Ein HIL-Prüfstand setzt das echte Steuergerät in einen Kreis mit einer simulierten Welt: Ein Modell des Motors, des Autos oder des Patienten sendet Signale und liest die Antworten. Testgetriebene EntwicklungIn 2 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Den Test vor dem Code schreiben; das klappt gut für Treiber und Protokolllogik, die von der Hardware getrennt sind. passt zu Treibern und Protokollcode. Werkzeuge für statische Analyse und Programmierregeln wie MISRA C finden ganze Klassen von Fehlern, bevor ein einziger Test läuft. Die PipelineIn 16 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Jede Änderung für das Zielsystem gebaut, durch statische Analyse und Tests geschickt, am besten auch auf echter Hardware. baut für das Zielsystem, lässt die Tests laufen und flasht eine Platine auf dem Gestell.

Schwache Antwort: „Wir testen, wenn der Prototyp kommt.“ Nachfrage: „Der Prüfstand ist jede Nacht belegt.“ Verlege mehr Tests weg vom Zielsystem und nutze den Prüfstand nur für das, was echte Hardware braucht.

Was ändert sich, wenn deine Software eine internationale Norm für Funktionale Sicherheit wie IEC 61508 oder ISO 26262 erfüllen muss?

Worauf sie achten: dass du Sicherheit als Prozess mit Nachweisen verstehst, nicht nur als sorgfältigen Code.

Kurze Antwort: „Die internationale Norm IEC 61508 und ISO 26262, ihre internationale Fassung für Straßenfahrzeuge, beginnen mit einer Gefährdungsanalyse, die festlegt, wie viel Risikominderung jede Funktion braucht, eine Sicherheitsintegritätsstufe, im Auto ASIL. Die Stufe entscheidet, wie streng der Prozess ist: verfolgte Anforderungen, Reviews, Programmierregeln, Testabdeckung und unabhängige Prüfungen. Jeder Schritt hinterlässt Nachweise für die Sicherheitsargumentation, den Safety Case.“

Die ausführliche Antwort: Eine Sicherheitsintegritätsstufe, SIL in IEC 61508 und ASIL in ISO 26262, beides internationale Normen, legt die Methoden fest: Höhere Stufen verlangen ein formaleres Design, mehr Testtiefe und mehr Unabhängigkeit. Software für Medizinprodukte folgt der internationalen Norm IEC 62304, mit Klassen nach Risiko. Die Arbeit wird für das Produkt von einem unabhängigen Assessor bewertet; Entwickler müssen die Methode kennen, und manche machen einen Kurs mit Prüfung, um sie zu lernen. Die Qualifizierung der Werkzeuge, das Änderungsmanagement und die Rückverfolgbarkeit zählen so viel wie der Code selbst.

Schwache Antwort: „Wir testen einfach mehr.“ Nachfrage: „Eine Anforderung ändert sich spät im Projekt.“ Zeig die Auswirkungsanalyse, die aktualisierte Rückverfolgung und welche Tests und Reviews wiederholt werden müssen.

Wie baust du Sicherheit in ein vernetztes Gerät ein?

Worauf sie achten: Security, die in das Gerät und sein ganzes Leben eingeplant ist.

Kurze Antwort: „Secure Boot, damit nur signierte Firmware läuft, signierte Updates, keine Standardpasswörter, gesperrte Debug-Ports in der Produktion, Schlüssel in geschützter Hardware, verschlüsselte Kommunikation und ein Weg, Korrekturen für Schwachstellen auszuliefern, die nach dem Release gefunden werden.“

Die ausführliche Antwort: Fang mit einem Bedrohungsmodell an: wer das Gerät angreifen könnte, wie und was er davon hätte. IEC 62443 ist die internationale Normenreihe für Sicherheit in der Industrie. In der EU bringt der Cyber Resilience Act Pflichten für Produkte mit digitalen Elementen, die in der EU verkauft werden, etwa den Umgang mit Schwachstellen und Sicherheitsupdates über einen Unterstützungszeitraum. Andere Länder haben eigene Regeln, also prüf, wo das Produkt verkauft wird.

Schwache Antwort: „Niemand greift unser kleines Gerät an.“ Nachfrage: „Ein Forscher meldet eine Schwachstelle.“ Bestätige sie, behebe sie, liefere ein signiertes Update aus und sag den Kunden, was sie tun sollen.

Wann wählst du Embedded Linux statt eines Mikrocontrollers mit RTOS?

Worauf sie achten: dass du die Plattform zu den Anforderungen des Produkts passend wählst.

Kurze Antwort: „Embedded LinuxIn 41 % der Anzeigen für Embedded-Entwickler gefragt (Stand 05.11.2026).Embedded Linux: ein Image bauen, einen Treiber schreiben oder anpassen, Kernel-Logs lesen und die Bootzeit kurz halten. passt, wenn das Gerät einen reichen Netzwerkstack, ein Display mit voller Oberfläche, viel Speicher oder viele bestehende Bibliotheken braucht und mit längerem Booten und höherem Stromverbrauch leben kann. Ein Mikrocontroller mit RTOS passt zu hartem Timing, niedrigem Stromverbrauch, niedrigen Kosten und sofortigem Start. Viele Produkte nutzen beides: Linux für die Oberfläche und einen Mikrocontroller für das Timing.“

Die ausführliche Antwort: Linux braucht ein Build-System für das Image, etwa Yocto oder Buildroot, Treiber im Kernel, Updates für viele Pakete und einen Plan für Sicherheitskorrekturen über die Lebensdauer des Produkts. Ein Mikrocontroller braucht mehr eigenen Code, aber weniger bewegliche Teile. Schreib die Entscheidung mit ihren Gründen auf: Timing, Strom, Kosten, Können des Teams und Unterstützungszeitraum.

Schwache Antwort: „Linux, weil es alles hat.“ Nachfrage: „Das Produkt muss in unter einer Sekunde starten.“ Erkläre die Grenzen der Bootzeit und wo ein Mikrocontroller übernehmen würde.

Lead-Embedded-Entwickler, Embedded-Systemarchitekt und Head of Embedded Software

Diese Fragen kommen für Rollen als Senior-Embedded-Entwickler, Lead-Embedded-Entwickler, Embedded-Systemarchitekt und Head of Embedded Software, in denen die Arbeit das ganze Produkt und die Teams dahinter umfasst.

Wie teilst du als Lead oder Architekt ein Produkt zwischen Hardware, Firmware und Cloud auf?

Worauf sie achten: Denken im System und Abwägungen, die du jedem Team erklären kannst.

Kurze Antwort: „Ich gehe von den Anforderungen des Produkts aus: Timing, Strom, Kosten, Sicherheit und wie es aktualisiert und unterstützt wird. Hartes Timing und Sicherheit gehören nah an die Hardware; aufwendige Berechnungen und Daten, die sich oft ändern, auf einen stärkeren Prozessor oder in die Cloud. Ich schreibe die Schnittstellen zwischen den Teilen früh auf, stimme sie mit jedem Team ab und führe eine Liste der Entscheidungen und ihrer Gründe.“

Die ausführliche Antwort: Jede Entscheidung verschiebt Kosten und Risiko: Ein günstigerer Chip spart Geld bei jedem Gerät, kostet aber Entwicklungszeit; Logik in der Cloud lässt sich leicht ändern, fällt aber ohne Verbindung aus. Der Architekt hält das System als Ganzes sicher und testbar, plant den Update-Pfad und den Unterstützungszeitraum und spricht mit dem Einkauf über Bauteile, die schwer zu bekommen sein könnten. Ein Head of Embedded Software plant außerdem Menschen, Werkzeuge und Budgets über die Produkte hinweg.

Schwache Antwort: „Die Hardware entscheidet, dann schreiben wir die Software.“ Nachfrage: „Der gewählte Chip ist ein Jahr lang nicht lieferbar.“ Zeig, wie eine Schicht zwischen Hardware und Logik einen Wechsel des Chips möglich macht.

Dein Lebenslauf für diese Fragen

Interviewer suchen sich ein Gerät aus deinem Lebenslauf aus und fragen, wie es funktionierte und was schiefging. Schreib Zeilen, die eine solche Geschichte eröffnen, jeweils unter der Stelle, an der sie passiert ist:

Bewerte deinen Lebenslauf vor dem Vorstellungsgespräch an einem echten Embedded-Job; jede Lücke, die dabei auftaucht, ist eine Frage, für die du eine Antwort vorbereiten solltest.