Bewerbung Hays (Embedded/Hardware-naher Entwickler, Display & Videosysteme) finalisiert (versandreif)
Finale Fassung als bewerbung.md gesichert. Register aktualisiert. Prozessaenderung (Skill bewerbung-schreiben, Schritt 5): jeden Bewerbungstext- Entwurf sofort committen/pushen, dabei nur die Entwurfsdatei; alles andere erst am Ende der Bewerbung. Gedaechtnis (stil.md): Wiederholungs-Regel verschaerft (jede Formulierung nur einmal, ueber Absaetze hinweg pruefen), Trivialitaets-Regel (Fundort/Online-Datum bei Portal-Bewerbungen weglassen), Formatierungs-Regel um Rich-Text-faehige Portale (Hays) erweitert, Portal-Header-Beispiel. inhalte.md: SerDes-Erfahrung seit 2000 belegt, Display/Video nur ueber GMSL-Kameramodul, Stundensatz als -Vorstellung formulierbar. log.md: datierter Eintrag. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -37,6 +37,14 @@ Lege darin den Entwurf `entwurf.md` an.
|
||||
Schreibe gemäß Stil-Gedächtnis und Vorgaben. Iteriere mit dem Nutzer bis
|
||||
versandreif. Speichere die finale Fassung als `bewerbung.md` im Ordner.
|
||||
|
||||
**Entwurf sofort committen und pushen (verbindlich):** Jeden Entwurf des
|
||||
Bewerbungstextes (`entwurf.md`, später `bewerbung.md`) unmittelbar nach dem
|
||||
Schreiben/Überarbeiten committen und pushen, damit der Nutzer ihn am
|
||||
DesTEngS-Git-Server reviewen kann. Dabei **nur die Entwurfsdatei des
|
||||
Bewerbungstextes** einzeln stagen und committen. Alle übrigen Änderungen
|
||||
(Gedächtnis, Register, Skill-/Vorgaben-Anpassungen) werden **nicht** mit
|
||||
committet, sondern erst am Ende der Bewerbung (Schritt 6).
|
||||
|
||||
## 6. Gedächtnis aktualisieren (Session-Ende)
|
||||
- Stil-Erkenntnisse → `gedaechtnis/stil.md`
|
||||
- geprüfte Inhalte → `gedaechtnis/inhalte.md`
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
An: Hays (Referenz 873996/1) über das Hays-Bewerberportal
|
||||
Betreff: Bewerbung als Embedded Software / Hardware-naher Entwickler – Display & Videosysteme (Referenz 873996/1)
|
||||
Anhänge: Lebenslauf_Dr-Ing_Thomas_Langer.pdf
|
||||
|
||||
---
|
||||
|
||||
Sehr geehrte Damen und Herren,
|
||||
|
||||
auf Ihre Ausschreibung für einen Embedded Software / Hardware-nahen Entwickler im Bereich Display- und Videosysteme bewerbe ich mich sehr gern, weil sie ausgezeichnet zu meinem Profil passt. Ist das Projekt noch aktuell?
|
||||
|
||||
**Verfügbarkeit:** Ich stehe **ab sofort** zu **100 %** zur Verfügung.
|
||||
|
||||
**Stundensatz:** Meine All-in-Stundensatz-Vorstellung liegt bei **105 €** netto.
|
||||
|
||||
**Remote-Anteil:** Die Remote-Leistungen erbringe ich in meinem Ingenieurbüro in Unterhaching im Großraum München, das mit professionellem IT-Equipment ausgestattet ist.
|
||||
|
||||
Besonders reizt mich an diesem Projekt die hardware-nahe Arbeit an Datenübertragungs-Schnittstellen, also genau das Feld, in dem ich bereits sehr lange tätig bin.
|
||||
|
||||
Die im Projekt geforderten Tätigkeiten habe ich immer wieder erbracht: Inbetriebnahme und Bring-up von Hardware-Komponenten, Debugging und systematische Fehleranalyse sowie die enge Zusammenarbeit mit Hardware- und Software-Teams. Mit verschiedenen Serializer-/Deserializer-Systemen habe ich mich seit 2000 immer wieder beschäftigt.
|
||||
|
||||
Gern sende ich Ihnen anbei meinen aktuellen Lebenslauf. Über Ihr Interesse freue ich mich sehr; für Rückfragen oder ein Gespräch erreichen Sie mich jederzeit.
|
||||
|
||||
Mit besten Grüßen
|
||||
|
||||
Thomas Langer
|
||||
@@ -11,3 +11,4 @@ passender Einträge als Vorlage nutzen.
|
||||
| 2026-06-12 | Optimus Search (Agentur) | Senior System Engineer – Communication & Electronic Systems | Hybrid-München | Systems Engineering, System Integration, Requirements Engineering, Verifikation & Validierung, Embedded & Kommunikationstechnik | bewerbung.md | Versandreif (Nutzer versendet E-Mail) |
|
||||
| 2026-06-13 | YER Deutschland (Agentur) | Freiberuflicher Data Scientist – LLM / Vector Search / Unstrukturierte Daten | Remote | LLM, Vektordatenbanken, RAG, Python, Produktiver Einsatz | bewerbung.md | Versandreif (Nutzer versendet) |
|
||||
| 2026-06-13 | consultingheads (Agentur) | Business Analyst – Software Development Life Cycle | Remote | Requirements Engineering, Systems Engineering, System Integration | bewerbung.md | Versandreif (Nutzer versendet über Freelancermap-Portal) |
|
||||
| 2026-06-15 | Hays (Agentur) | Embedded Software / Hardware-naher Entwickler – Display & Videosysteme | Remote | Embedded & Kommunikationstechnik, System Integration, Verifikation & Validierung | bewerbung.md | Versandreif (Nutzer versendet über Hays-Portal) |
|
||||
|
||||
@@ -21,6 +21,14 @@ Was hier steht, ist verifiziert richtig. Wird am Ende jeder Session aktualisiert
|
||||
mit Berichtslinie an die Entwicklungsleitung (VP Engineering) — vom Nutzer bestätigt,
|
||||
als Beleg für „Management-Sprache verstehen" nutzbar.
|
||||
- **Industrieelektronik** belegt durch ASMPT SMT Solutions (industrielle Bestückungsmaschinen).
|
||||
- **Serializer-/Deserializer-Systeme (SerDes) seit 2000** belegt: Multilink Technology
|
||||
(Backplane-Entzerrer-ICs/Demultiplexer ab Dez. 2000), Toshiba (Transceiver-ICs bis 11 Gb/s,
|
||||
MIPI D-PHY), Magna (GMSL-Pfad eines Kameramoduls, Signalintegrität). Formulierung „seit 2000
|
||||
immer wieder mit Serializer-/Deserializer-Systemen beschäftigt" ist gedeckt.
|
||||
- **Display-/Video-Technologie:** konkreter Beleg nur der **GMSL-Pfad eines Kameramoduls** (Magna,
|
||||
EM-Feldsimulation/Signalintegrität). Es gibt **keine** Erfahrung in Integration/Konfiguration von
|
||||
Display-ICs (Deserializer, TDDI-Controller) → nicht behaupten, nur als „mit GMSL/Videoschnittstellen
|
||||
gearbeitet" auf Signalintegritäts-/Bring-up-Niveau benennen.
|
||||
- **Kein** Beleg für sicherheits-/missionskritische Systeme nach Safety-Prozessen
|
||||
(ISO 26262, DO-178) und **keine** INCOSE-/IREB-Zertifizierung → nicht behaupten.
|
||||
|
||||
|
||||
@@ -61,3 +61,27 @@ Datierte Einträge: was wurde am Gedächtnis geändert und **warum**.
|
||||
Doku-Variante erweitert; Ubidyne-Führungsfakt (Gruppenleiter, Berichtslinie an VP Engineering,
|
||||
nutzerbestätigt); Caveats ergänzt: Scrum/agil nur einmal (Alcatel-Lucent) → nicht breit anpreisen,
|
||||
SAFe nicht behaupten, BPMN/Use Cases/User Stories nicht wörtlich behaupten.
|
||||
|
||||
## 2026-06-15 — Bewerbung Hays (Embedded/Hardware-naher Entwickler, Display & Videosysteme, 100% Remote), versandreif
|
||||
- Agentur-Anschreiben (Hays) für hardware-nahes Embedded-Projekt (Bring-up, Debugging,
|
||||
Fehleranalyse, Display-/Videoschnittstellen, Serializer-/Deserializer-Systeme). CRM-Opportunity
|
||||
vorab angelegt (Hays als Reseller, kein namentlicher Kontakt; Must 100 % / Nice 100 %).
|
||||
**Versand über das Hays-Portal**, nicht per E-Mail.
|
||||
- **Prozessänderung** (Skill `bewerbung-schreiben`, Schritt 5): Jeden Entwurf des Bewerbungstextes
|
||||
sofort committen und pushen (Review am DesTEngS-Git-Server), dabei **nur die Entwurfsdatei**
|
||||
einzeln stagen; alle übrigen Änderungen (Gedächtnis, Register, Skill/Vorgaben) erst am Ende
|
||||
der Bewerbung committen.
|
||||
- **Stil** (`stil.md`), per Nutzer-Feedback:
|
||||
- Wiederholungs-Regel verschärft: jede markante Formulierung **nur einmal im gesamten Text**,
|
||||
Prüfung **über Absätze hinweg**; Negativbeispiele „erbringende … erbringe" und doppeltes
|
||||
„mehreren Positionen" (Absatz 6/7); Tätigkeitsbegriffe nicht in Reiz- **und** Tätigkeitsabsatz doppelt listen.
|
||||
- **Triviale Aussagen weglassen**: bei Portal-Bewerbungen nicht schreiben, **wo** die Ausschreibung
|
||||
gefunden wurde und **seit wann** sie online ist (Aktualitäts-Nachfrage bleibt erlaubt, ohne triviale Begründung).
|
||||
- **Formatierungs-Regel präzisiert**: Rich-Text auch bei Portalen erlaubt, die ihn übernehmen
|
||||
(z. B. **Hays-Portal** → Formatierung wie bei bekannter E-Mail); nur reiner Klartext-Kanal ohne Formatierung.
|
||||
- Header-Beispiel für Portal-Versand ergänzt.
|
||||
- **Inhalte** (`inhalte.md`): Serializer-/Deserializer-Erfahrung **seit 2000** belegt (Multilink
|
||||
Backplane-Entzerrer/Demux ab Dez. 2000, Toshiba-Transceiver-ICs, MIPI D-PHY, GMSL-Pfad eines
|
||||
Kameramoduls bei Magna). Display-/Video-Bezug konkret nur über GMSL-Kameramodul (Signalintegrität),
|
||||
keine Display-IC-Integration → nicht überzeichnen. Stundensatz als „**-Vorstellung**" formulierbar,
|
||||
wenn Verhandelbarkeit signalisiert werden soll.
|
||||
|
||||
@@ -20,13 +20,32 @@ aktualisiert. Nur **übertragbares** Wissen, keine projektspezifischen Einmaligk
|
||||
- **Lücken nicht erwähnen.** Schwächen/fehlende Abdeckung nicht offenlegen. Entdeckt
|
||||
der Empfänger sie, lässt sich das im Interview souverän klären; von selbst darauf
|
||||
hinweisen schadet nur.
|
||||
- **Triviale Aussagen weglassen.** Nichts schreiben, was für den Empfänger ohnehin
|
||||
offensichtlich ist. Insbesondere bei Portal-Bewerbungen **nicht** erwähnen, **wo** die
|
||||
Ausschreibung gefunden wurde (bei einer Hays-Bewerbung ist „auf der Hays-Projektbörse
|
||||
gesehen" trivial) und **seit wann** das Projekt online ist. Eine sachliche
|
||||
Aktualitäts-Nachfrage („Ist das Projekt noch aktuell?") bleibt erlaubt, aber ohne die
|
||||
triviale Begründung.
|
||||
|
||||
## Wortwiederholung vermeiden (verbindlich)
|
||||
- **Jede spezielle/markante Formulierung nur einmal im gesamten Text.** Vor dem
|
||||
Speichern den ganzen Text gegen Wiederholungen prüfen, **auch über Absätze hinweg**,
|
||||
nicht nur innerhalb eines Satzes.
|
||||
- Greift man **Schlüsselbegriffe der Ausschreibung** auf (Buzzword-Match für den
|
||||
Agentur-Empfänger), die markante Wendung **nur einmal** verwenden und eine zweite
|
||||
Erwähnung umformulieren (Beispiel: „umsetzungsnahe Spezifikationen" einmal lassen,
|
||||
an anderer Stelle „systematisch aufbereiten"). Auch dieselbe Verb-Wurzel nicht zweimal
|
||||
dicht hintereinander (z. B. „… remote zu **erbringende** Leistung **erbringe** ich …").
|
||||
an anderer Stelle „systematisch aufbereiten").
|
||||
- Dieselbe **Verb-Wurzel** nicht zweimal dicht hintereinander, auch nicht im selben Satz
|
||||
(schlecht: „… remote zu **erbringende** Leistung **erbringe** ich …" → besser
|
||||
„Die **Remote-Leistungen** erbringe ich in …").
|
||||
- Dieselbe **Wendung nicht in aufeinanderfolgenden Absätzen** wiederholen (schlecht:
|
||||
Absatz 6 „habe ich in **mehreren Positionen** bereits erbracht" und Absatz 7 „In
|
||||
**mehreren Positionen** habe ich …" → eine der beiden umformulieren, z. B. „bereits
|
||||
mehrfach erbracht").
|
||||
- **Tätigkeitsbegriffe nicht doppelt listen:** Der „Was-mich-reizt"-Absatz und der
|
||||
„Tätigkeiten"-Absatz dürfen nicht dieselben Stichworte (z. B. Bring-up, Debugging,
|
||||
Fehleranalyse) aufzählen. Den Reiz-Absatz höher ansetzen (das Themenfeld), die
|
||||
konkreten Tätigkeiten genau einmal nennen.
|
||||
|
||||
## Anschreiben an Agenturen
|
||||
Annahme: Der Agentur-Mitarbeiter hat fast keine Fachkenntnis und gleicht nur
|
||||
@@ -45,11 +64,12 @@ Buzzwords und Zahlen mit der Ausschreibung ab.
|
||||
bedanken; direkt mit der Begeisterung einsteigen.
|
||||
2. **Wichtigste Fakten** (jeweils als eigener Absatz mit Schlagwort am Anfang, da
|
||||
Bullet-Points im Mail-Editor oft nicht dargestellt werden). **Fett-Formatierung
|
||||
nur, wenn eine E-Mail-Adresse des Empfängers bekannt ist** (dann ist Rich-Text-Versand
|
||||
gesichert): dann **sparsam** fetten, nämlich die Themen-Schlagworte mit Doppelpunkt am
|
||||
Absatzanfang sowie die interessantesten Informationen (meist Starttermin, Verfügbarkeit,
|
||||
Stundensatz). **Ist keine E-Mail-Adresse bekannt** (z. B. Versand über Portal-Nachricht),
|
||||
**gar keine Textformatierungen verwenden** — Labels und Zahlen bleiben unformatiert.
|
||||
nur, wenn Rich-Text-Versand gesichert ist:** bei bekannter E-Mail-Adresse des Empfängers
|
||||
**oder** über ein Portal, das Rich-Text übernimmt (z. B. das **Hays-Portal**). Dann
|
||||
**sparsam** fetten, nämlich die Themen-Schlagworte mit Doppelpunkt am Absatzanfang sowie
|
||||
die interessantesten Informationen (meist Starttermin, Verfügbarkeit, Stundensatz).
|
||||
**Nur bei reinem Klartext-Kanal** (Portal-Nachricht ohne Rich-Text, E-Mail-Adresse
|
||||
unbekannt) **gar keine Textformatierungen verwenden** — Labels und Zahlen bleiben unformatiert.
|
||||
- **Verfügbarkeit:** ab wann, welcher Prozentsatz. **Interesse an langfristiger
|
||||
Zusammenarbeit nur erwähnen, wenn die Ausschreibung selbst eine Verlängerung nach der
|
||||
Erstbeauftragung in Aussicht stellt** (dann: „auch über die ersten <N> Monate hinaus
|
||||
@@ -79,12 +99,19 @@ Buzzwords und Zahlen mit der Ausschreibung ab.
|
||||
dass sie noch fehlt, statt sie zu erfinden.
|
||||
|
||||
## Header des Entwurfs
|
||||
Immer angeben: Zielperson, Nachrichtenkanal + Zieladresse, Betreff, Anhänge. Beispiel:
|
||||
Immer angeben: Zielperson, Nachrichtenkanal + Zieladresse, Betreff, Anhänge. Beispiele:
|
||||
```
|
||||
An: Frau Candy Williams per E-Mail an C.Williams@brink.de
|
||||
Betreff: …
|
||||
Anhänge: Lebenslauf_Dr-Ing_Thomas_Langer.pdf, Zertifikat TÜV AI Consultant
|
||||
```
|
||||
Bei Versand über ein Portal statt E-Mail den Kanal entsprechend benennen (Zielperson
|
||||
ggf. „Sehr geehrte Damen und Herren", falls keine namentliche Ansprechperson genannt):
|
||||
```
|
||||
An: Hays (Referenz 873996/1) über das Hays-Bewerberportal
|
||||
Betreff: …
|
||||
Anhänge: Lebenslauf_Dr-Ing_Thomas_Langer.pdf
|
||||
```
|
||||
|
||||
## Grußformel (immer identisch)
|
||||
Ohne Dr.-Titel, drei Leerzeichen vor dem Namen:
|
||||
|
||||
Reference in New Issue
Block a user