Files
claude-resume-kit/resume_builder/bundles/bundle_data_platform.md
T
dennisthiessenandClaude Opus 5 f515a1e522 fix(kb): close all six Zeugnis discrepancies on the user's rulings
D1/D2 - Bosch title and promotion: CONFIRMED by the user. The promotion and its
timing are correct and came from a re-grading (Neueinstufung). The Zeugnis does
not contradict it - it names DEPARTMENTS ("Ingenieur" in Fertigungstechnologie
1/2/3) rather than job titles. Separately corrected a false provenance note that
claimed official_title was "the formal combined string on the Zeugnis"; it never
came from that document, it comes from the user and LinkedIn.

D3 - part-time from 2021-09: NOT recorded, by the user's decision. Noted for
completeness that tenure wording such as "over ten years" measures elapsed time
and is unaffected; it would only matter if a document claimed FTE years, and
none does.

D4 - French and Italian: the Swisscom Zwischenzeugnis says he uses both
professionally on a regular basis. The user reviewed the sentence and confirmed
it is an ERROR IN THE DOCUMENT. DE/EN only stands. Recorded in
identity.language_note so nobody rediscovers the line and acts on it, with the
practical warning that a reader of that Zeugnis may take it at face value.

D5 - the RUAG MSSQL rule-out: the DECISION stands (user does not want it
revisited), the REASONING is corrected. Two of its four premises were wrong:
MSSQL is not 0 (Fraunhofer SCEDAS ran on Microsoft SQL Server), and "his stack
is AWS cloud-native" was too narrow - the Swisscom Zeugnis documents component
ownership for ETL into the Teradata DWH. Talend and SAP S/4HANA remain genuinely
0, and the required line reads "Aufbau UND Betrieb" while he has documented
Betrieb only - so the skip is still defensible, it was just better than its
written justification. Both RUAG decision rows now carry the correction and a
standing rule for future DWH postings.

D6 - Vizrt end date: 2018-05 stands by the user's decision.

And the follow-through that matters: the data-warehouse, MSSQL and mentoring
evidence is now IN THE BUNDLES, not only in claims.json. BS-6 showed last week
that evidence which reaches no bundle cannot be selected - this is the same
failure mode, caught the same week. The DWH entry carries its scope limit
explicitly: documented Betrieb, not Aufbau.

Validator PASS, 37/37 tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM
2026-09-11 21:46:05 +02:00

163 lines
12 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Bundle: Data Platform / Infra
> Target employers: Cloud-first companies, AWS-heavy orgs
> Tier: 3 — viable with careful framing
> Config key: bundle_data_platform.md
---
## S1: Role Profile & Priority Matrix
**Positioning:** Dennis's platform evidence sits inside data-engineering roles rather than a dedicated Platform/SRE title: Kubernetes delivery at Swisscom and Bosch, scoped AWS migration work with CloudFormation, GitLab CI/CD, Dockerized ML inference and an observability proof of concept. Position as a data engineer with production-platform depth, not as a dedicated SRE, developer-platform or Terraform engineer.
**Note on Tier 3:** This bundle is viable but slightly less natural than Tier 1/2. The gap is: Dennis doesn't have a dedicated platform engineering title, and his infrastructure work is in service of data pipelines rather than standalone infrastructure. Frame accordingly — emphasize that his platform skills are production-proven, not academic.
### Priority Matrix
| Priority | Achievement IDs | Rationale |
|----------|----------------|-----------|
| HIGH | SW-3, SW-1, SW-2, BS-1, BS-2, BS-3, BS-4, SW-5 | K8s/GitLab, AWS/IaC, pipeline ownership, ML containerization, data services, ELK observability, DevSecOps |
| MED | SW-4, SW-6, FC-1, FC-3, VZ-2, BS-5 | Automation, PySpark, CI/CD initiative, microservices, quality gates |
| LOW | FC-2, VZ-1, GN-1, GN-2, CA-1 | Non-platform signals |
**2-page resume bullet allocation (typical):**
- Swisscom: 3–4 bullets (SW-3, SW-1, SW-2, SW-5)
- Bosch: 3 bullets (BS-1, BS-2 or BS-3, BS-4)
- Fraunhofer: 1 bullet (FC-1 — CI/CD initiative)
- Vizrt: 1 bullet (VZ-2 — quality gates in CI/CD)
- Generali: 1 bullet (GN-1 or omit)
---
## S2: Summary Guide
**Headline pattern:**
> "Data Platform Engineer | Kubernetes · AWS · Kafka | Cloud-Native Data Infrastructure, IaC & DevSecOps"
**Building blocks:**
- "cloud-native data infrastructure" or "data platform ownership"
- "Kubernetes-based containerized pipeline deployment"
- "AWS IaC (CloudFormation)" — infrastructure-as-code signal
- "AWS migration" — hands-on cloud platform experience
- Security Champion is not a default positioning theme; use the 2025/2026 team role only when the JD explicitly requires security exposure
- "ELK + Grafana + Prometheus monitoring" — **never** "delivered/built the observability stack" or
"full monitoring suite": `claims.json` BS-4 is a **proof of concept** and forbids "built the
observability platform" / "enterprise observability platform". Carry the PoC scope into any wording.
> **Scope warning (corrected 2026-09-04).** The S3 row for BS-4 previously read "*Designed and
> delivered observability stack … full monitoring suite for manufacturing infrastructure*" and was
> labelled "Full observability stack implementation" — a delivered-capability claim over a PoC, and the
> same defect the 2026-08-21 log entry found in `bundle_data_engineer.md` §S5. That entry said to check
> the other four bundles; this is the one that had it. See CLAUDE.md → Scope Discipline.
**Tone:** Infrastructure-minded engineer who thinks about reliability, observability, and security — not just data throughput. Platform thinking embedded in data work.
**Avoid:**
- Leading with analytics or BI framing
- Overemphasizing test automation background
- Positioning as SRE or pure DevOps (the role was data engineering with platform ownership)
---
## S3: Achievement Reframing Map
| ID | Default Framing | This Role's Framing | Key Metric / Signal |
|----|----------------|--------------------|--------------------|
| SW-3 | K8s + GitLab | **Lead bullet** — "Deployed and operated Python data applications on Kubernetes with GitLab CI/CD; drove infrastructure automation in agile DevOps team" | K8s + CI/CD ownership = core platform signal |
| SW-1 | AWS migration | "Migrated pipelines in his owned domains from legacy Teradata/Oracle processing onto Swisscom's AWS platform (Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation)" | Scoped migration delivery plus AWS breadth |
| SW-2 | Component Owner | "Owned Fulfillment ETL pipelines (Oracle/Kafka → Teradata) — platform reliability, Data Governance compliance, 2nd/3rd-level support and on-call duty" | Platform SLA + on-call = reliability engineer signal |
| BS-1 | ML inference | "Containerized and orchestrated ML inference (Docker, K8s, Ansible) into a continuously operating 24/7 semiconductor production environment" | Production-grade containerization in an environment that cannot be paused. **Do not write *zero-downtime*** — canonical BS-1 evidences integration into continuous production, not a measured zero-downtime deployment property |
| BS-4 | ELK PoC | "Built an anomaly-detection **proof of concept** on ELK + Kafka (Docker) with Grafana, Prometheus and Loki monitoring, validating centralized logging and alerting for 24/7 semiconductor production" | PoC-scoped observability breadth — **the PoC framing is mandatory, not optional** |
| SW-5 | Security Champion | "2025/2026 team Security Champion; include only if the JD explicitly requires security or DevSecOps exposure" | Secondary team-role evidence, not ownership or certification |
| BS-6 | Linux/Ansible | "Administered and automated Linux servers carrying the ML platform, Docker hosts and backend services at Bosch; wrote Ansible extensions including a credential plugin with local caching" | **Infrastructure-as-Code and Linux operations evidence.** Added 2026-09-11 (review F07): BS-6 existed in `claims.json` and `experience_bosch.md` since 2026-08-27 but appeared in NO bundle, so the selection paths could not see it. Currency limit: employer-side Linux/Ansible ended Dec 2022; `PP-3` (personal Debian server) carries the current half and must be named as personal. GitOps stays forbidden — execution was push-based from Jenkins/GitLab, not agent-reconciled |
| BS-2 | Data services | "Built multi-language data services (Python/Java/C#) over OracleDB and Hadoop/ImpalaSQL — platform-layer data access for semiconductor analysis teams" | Enterprise DB + Hadoop infrastructure |
| BS-3 | App Owner | "Application Owner for semiconductor analytics platform — SLOs, reliability, vendor management, on-call coverage" | Platform SLA ownership |
| FC-1 | CI/CD initiative | "Independently introduced Jenkins CI/CD pipeline with quality gates at Fraunhofer CML — first build automation adopted by the research team" | Initiative: built CI/CD from zero |
---
## S4: Skills Guide
**Bold tools (resume Technical Skills section):**
Kubernetes, Docker, AWS (S3 · Glue · Athena · Redshift · CloudFormation), Kafka, GitLab CI/CD
**Must-include skills (ATS match):**
- Kubernetes, Docker, Ansible
- AWS (S3, Glue, Athena, Redshift, CloudFormation, Airflow), Apache Iceberg
- GitLab CI/CD, Jenkins
- Kafka, Apache Airflow
- Python, SQL
- ELK Stack, Grafana, Prometheus
- IaC / CloudFormation
- DevSecOps
**Nice-to-have (include if JD mentions):**
- Terraform (not evidenced — do NOT claim; flag if JD requires)
- Loki (log aggregation — from Bosch PoC)
- PySpark (distributed processing on platform)
- Ansible (Bosch ML orchestration)
- Oracle DB, Teradata (enterprise data platform experience)
**Omit:**
- BDD, Selenium, HP Quality Center, UIPath (testing — irrelevant)
- Tibco Spotfire, SAP BODS (application tools — irrelevant)
- RPA/Camunda (process automation — irrelevant)
**Certifications to highlight:**
- AWS Certified Solutions Architect – Associate → HIGH (platform credibility, architecture knowledge)
- Data Engineering with AWS → supporting
- iSAQB CPSA Foundation Level → MED (software architecture — relevant for platform design decisions)
---
## S5: Cover Letter Guide
**Institution type:** Cloud-first tech company, scale-up with AWS-heavy stack, enterprise platform team, or data infrastructure consultancy
**Opening hook pattern:**
> "Across my career at Swisscom and Bosch, I've owned data infrastructure at two ends of the spectrum: migrating my own domains' pipelines onto Swisscom's AWS platform (CloudFormation, Glue, Athena with Iceberg, Airflow) as part of its wider cloud programme, while operating Kubernetes-deployed Python applications with GitLab CI/CD — and containerizing ML inference into a 24/7 semiconductor production line at Bosch using Docker, Kubernetes, and Ansible. In both cases, the infrastructure had to be production-grade with no tolerance for downtime. [Tie to their platform challenge]."
> **Scope warning (corrected 2026-08-26).** This hook previously read "*migrating Swisscom's legacy
> ETL stack to a cloud-native AWS platform*" — a full-ownership framing on a company-scale object,
> contradicting `claims.json` SW-1 (`forbidden`: "migrated the company warehouse", "led the migration
> of the legacy warehouse"). Same defect fixed in `bundle_data_engineer.md` on 2026-08-21; this
> bundle was missed by that sweep. Never pair a full-ownership verb with a company-scale object.
> See CLAUDE.md → Scope Discipline.
**Key narrative thread:**
1. **Production Kubernetes** — SW-3 + BS-1: K8s at two employers, in different contexts (data apps at Swisscom, ML inference at Bosch). Cross-employer K8s ownership is a strong signal.
2. **AWS platform breadth** — SW-1: not just one AWS service — migrating his own domains' pipelines with CloudFormation/IaC, inside the wider company programme, shows platform-level thinking. **Never write "an entire ETL infrastructure" or any company-scale object here** (corrected 2026-08-26).
3. **Observability initiative** — BS-4: Self-initiated ELK + Prometheus + Grafana PoC shows platform engineer mindset (monitoring is not optional).
4. **Operational accountability** — use Component/Application Owner evidence. Security Champion is optional and never a substitute for production ownership.
**"Why them" angle to research:**
- What is their cloud stack? If AWS-heavy → your SAA cert + migration experience is directly relevant
- Do they use Kubernetes in production? → Cross-employer K8s experience is the signal
- Are they building their data platform from scratch vs. maintaining existing? → Tailor SW-1 (migration) vs. BS-4 (observability initiative) accordingly
- Terraform vs. CloudFormation? → Note that your experience is CloudFormation; Terraform familiarity may need bridging
**Avoid:**
- Leading with analytics or BI outcomes (platform audience cares about reliability and infrastructure)
- Claiming SRE/pure DevOps title (you were a data engineer with platform ownership)
- Overstating Terraform/Helm experience (not confirmed — do not claim)
- Mentioning SCEDAS, maritime research, BDD, or RPA
## Data-warehouse and mentoring evidence (added 2026-09-11 from the Arbeitszeugnisse)
Both were documented all along and reached no bundle, so the selection paths could not see them.
Same failure mode as BS-6 (Linux/Ansible), found the same week.
- **Data warehouse (SW-2).** The Swisscom Zwischenzeugnis documents *Komponentenverantwortung* for
the ETL pipelines that load business-critical Fulfillment data from Oracle into the **Teradata
Data Warehouse (DWH)**. Use this whenever a JD names data warehousing — it was previously
screened as absent, which cost a correct answer on at least one posting.
**Scope limit:** this is documented **Betrieb** (operation) of a DWH, not **Aufbau**
(construction). A required line saying *"Aufbau und Betrieb von Data-Warehouse-Lösungen"* is only
half met — say which half.
- **Microsoft SQL Server (FC-1).** Fraunhofer's SCEDAS ran on MSSQL with C# and Entity Framework.
Historical and single-project; do not present it as data-platform depth.
- **Mentoring (BS-7).** *"Fachliche Betreuung von Studierenden, auch im Rahmen von
Abschlussarbeiten"* — documented technical supervision, including thesis supervision. Use it when
a JD asks about developing other engineers (SBB asked explicitly and the answer had to fall back
on team roles). **Technical supervision, NOT people management.**