dennisthiessen/claude-resume-kit
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a0ec2fedb5dcb77ea82139bdbc49ae0b7edf2f20
claude-resume-kit/resume_builder/bundles/bundle_data_platform.md
T
dennisthiessenandClaude Opus 5 a0ec2fedb5 feat: NVIDIA Sr DevOps application, drop cohort caps, fix Workday/decision-log bugs 
Scout run 2026-09-04 (36 companies, 778 eligible) plus the NVIDIA package it
surfaced, and the tooling and policy fixes found along the way.

Application
- NVIDIA Senior DevOps Engineer, Zurich (JR2024256): submitted 2026-09-05.
  Evidence Fit 64/100 Stretch, hard gate FAIL x2, channel Weak. Sent on an
  explicit user override with the working model unresolved, so hybrid-vs-onsite
  is a live screening topic. 2pp resume + 1pp cover letter, both validators
  PASS, 0 boxes, 0 Tier 1 findings open.

Policy
- Drop the 7 Core / 2 Adjacent / 1 Stretch cohort caps. They had no derivation
  and were overridden whenever they bound, and the cohort was confounded: it
  tested fit class while holding channel constant at Weak across all six
  applications. Keep the recording, drop the rationing.
- Channel replaces the slot budget as the rationed variable: no application
  goes out cold when a named contact is published and reachable.
- Propagated through shared_ops, session_file_template, cohort_tracker
  (counts, never counts-against-a-target) and application_cohort.json.

Tool fixes
- fetch_workday emitted 404 URLs for every Workday company (NVIDIA, Novartis,
  Equinor): externalPath is site-relative and needs the locale + site prefix.
  6/6 short-form 404, 3/3 long-form 200. 773 dead links repaired across 42
  archived reports.
- find_decision_url silently de-linked decisions on two boards, which is why
  ruled-out roles kept resurfacing as undecided. RUAG rotates its UUID on
  repost; BIS migrated its vacancy URL scheme, orphaning 5 decisions including
  a live application. Fixed as a two-tier match, not a slug key -- slugs
  collide (two live RUAG reqs shared one).

Knowledge base
- claims.json: add Bash / shell scripting, the third canonical gap of this
  shape after Ansible and Linux administration.
- bundle_data_platform: BS-4 was framed as a delivered observability stack over
  what claims.json calls a proof of concept -- the defect the 2026-08-21 sweep
  was told to look for.
- CLAUDE.md and AGENTS.md: correct the RUAG Data Lakehouse shortlist claim,
  which the JD does not support and which both files still asserted.
- resume_template: comment-guard the missing babel/ngerman language block.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QFb8tTCig5r1KzkQiNXcYt
2026-09-05 13:24:44 +02:00

143 lines
9.6 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 24/7 semiconductor production — zero-downtime constrained deployment" | Production-grade containerization under hardest constraints |
| 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-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
Reference in new issue View Git Blame Copy Permalink