dennisthiessenandClaude Opus 5
ce5b7f511f
The review's key point is that the error ran BOTH ways. Overstatement, narrowed to canonical scope: - BS-1 variants claimed "eliminated manual wafer inspection", "no manual intervention" and "unattended quality monitoring". Canonical BS-1 supports a qualitative reduction whose size is unverified. Reworded; the scope limit is now stated inline where the variants are written. - bundle_data_platform called BS-1 a "zero-downtime constrained deployment". Integration into a fab that runs continuously is not a measured zero-downtime property. - experience_swisscom carried "grounded retrieval" as a skill and ATS keyword while SW-8 records retrieval implementation as explicitly unknown, and its reframing note invited "evaluation discipline" although formal model evaluation is a globally forbidden pattern. Both removed. - PyTorch sat in bundle_ml_ai_engineer as a bold tool and an ATS must-include with no certification context - the exact way the context gets lost. Undervaluation, the half that quietly costs him roles: - BS-6 (Linux administration, intensive Ansible incl. self-written extensions) has been canonical since 2026-08-27 but appeared in NO bundle, so the normal selection paths could not see it. Added to the data-platform and data-engineer bundles with its currency limit (employer-side ended Dec 2022; PP-3 is personal) and the standing GitOps prohibition. - Linux, Ansible and Bash were missing from skills_taxonomy entirely. - skills_taxonomy still said the IBM certification year was "not recorded" and that PyTorch needed verification; both were settled on 2026-08-27. Not rewritten, deliberately: the NVIDIA and RUAG cover letters state the production line could not be stopped. That exceeds the canonical record but is plausible and both are already submitted. Recorded as an OPEN ITEM in experience_bosch.md to be confirmed with the user before any reuse. Validator PASS, 31/31 tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM
144 lines
10 KiB
Markdown
144 lines
10 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
|