dennisthiessenandClaude Opus 5
468116959e
User-confirmed 2026-09-11, extending the Arbeitszeugnis line about supervising students and their theses. Zweitpruefer (second examiner) is a FORMAL role carrying assessment responsibility, not informal mentoring. That matters because "developing other engineers" keeps appearing as a JD requirement and the profile has otherwise only team-role evidence to offer - Security Champion, the Generali Java community, Application Owner training. SBB asked for it explicitly and the prepared answer had to fall back on exactly those. Limits recorded with it: exactly ONE thesis is confirmed as second-examiner work, so it must not be pluralised; the wider number of students supervised is not recorded; and none of it is people management. `forbidden` now blocks "supervised multiple theses", "lecturer", "taught a course" and an academic appointment reading. Carried into both data bundles so it can actually be selected - the BS-6 lesson from the same week: evidence that reaches no bundle cannot be chosen. Validator PASS, 37/37 tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM
167 lines
12 KiB
Markdown
167 lines
12 KiB
Markdown
# 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. He also
|
||
served as **Zweitprüfer (second examiner) and supervisor for one Bachelor thesis** at Bosch
|
||
(user-confirmed 2026-09-11) — a formal role carrying assessment responsibility, which is
|
||
materially stronger than the team-role evidence the profile otherwise falls back on. Use it when
|
||
a JD asks about developing other engineers (SBB asked explicitly and the answer had to fall back
|
||
on Security Champion and the Java community). **Technical supervision and formal examining, NOT
|
||
people management. Exactly one thesis as second examiner — do not pluralise.**
|