feat: rebuild evidence-first application workflow
This commit is contained in:
@@ -56,7 +56,7 @@
|
||||
|----|----------------|--------------------|--------------------|
|
||||
| SW-4 | B2B products + automation | **Lead bullet** — "Delivered data products, analyses and dashboards for B2B stakeholders; drove automation of recurring technical workflows" | Stakeholder-facing delivery |
|
||||
| SW-2 | Component Owner ETL | "Owned Fulfillment ETL pipelines (Oracle/Kafka → Teradata) — ensuring data availability for downstream analytics with SLA accountability" | Pipeline → analytics link |
|
||||
| SW-1 | AWS migration | "Migrated ETL stack to AWS (S3, Glue, Athena/Iceberg, Redshift, Airflow) — enabling scalable, query-optimized analytics on a cloud data lakehouse" | Iceberg/Athena = analytics stack |
|
||||
| SW-1 | AWS migration | "Migrated pipelines in his owned domains onto Swisscom's AWS platform (S3, Glue, Athena/Iceberg, Redshift, Airflow)" | Scoped delivery on a current analytics stack; no unverified scale claim |
|
||||
| BS-3 | Application Owner | "Application Owner for semiconductor data analysis platforms — defined SLOs, trained users, managed vendor relationships and stakeholder expectations" | Ownership + analytics platform |
|
||||
| BS-2 (generic) | Data services | "Built data services supplying analysis teams with on-demand structured access to manufacturing process data" | Analytics enablement framing |
|
||||
| BS-2 (semi JD) | Data services | "Built data services enabling Defect Management, Parameter Testing and Process Analysis teams with on-demand data access" | Semiconductor domain specificity |
|
||||
@@ -109,12 +109,12 @@ Python, SQL (Oracle · Teradata · Athena), AWS (S3 · Glue · Athena · Redshif
|
||||
**Key narrative thread:**
|
||||
1. **Analytics platform ownership** — App Owner at Bosch: not just building queries, but owning the analytics software that teams depend on
|
||||
2. **Pipeline-to-insight chain** — Fulfillment Component Owner at Swisscom: show the full chain from raw Oracle/Kafka data → Teradata DWH → B2B analytics
|
||||
3. **Cloud analytics stack** — AWS migration with Athena/Iceberg/Glue: modern lakehouse architecture for analytics workloads
|
||||
3. **Cloud analytics stack** — hands-on migration of owned-domain pipelines using Athena/Iceberg/Glue within a wider programme
|
||||
4. **Semiconductor domain** (for semi JDs): Defect Management + Parameter Testing + Process Analysis — rare domain expertise in an Analytics Engineer candidate
|
||||
|
||||
**"Why them" angle to research:**
|
||||
- What business domain are their analytics teams serving? Map to Swisscom (telecom) or Bosch (manufacturing) experience
|
||||
- What is their analytics stack? AWS-heavy → your SW-1 migration is directly relevant
|
||||
- What is their analytics stack? AWS-heavy roles can use SW-1 directly when company-wide ownership is not implied
|
||||
- Do they use dbt? Flag if so — not in your stack, but Airflow/Glue is adjacent
|
||||
|
||||
**Avoid:**
|
||||
|
||||
@@ -56,7 +56,7 @@
|
||||
| ID | Default Framing | This Role's Framing | Key Metric / Signal |
|
||||
|----|----------------|--------------------|--------------------|
|
||||
| SW-2 | Component Owner, Fulfillment ETL | **Lead bullet** — "owned business-critical Fulfillment pipelines end-to-end, on-call SLA, Data Governance compliance" | Component Owner title, on-call accountability |
|
||||
| SW-1 | AWS migration | "Migrated legacy Teradata/Oracle ETL stack to AWS (S3, Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation)" | Cloud-native stack breadth; Iceberg signals modern data lakehouse |
|
||||
| SW-1 | AWS migration | "Migrated his domains' Teradata/Oracle pipelines onto Swisscom's AWS platform (S3, Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation)" | Scoped migration delivery; Iceberg shows current lakehouse practice |
|
||||
| SW-3 | K8s + GitLab CI/CD | "Deployed and operated Python data apps on Kubernetes with GitLab CI/CD in agile DevOps team" | K8s + CI/CD = full DevOps ownership |
|
||||
| BS-3 | Application Owner | "Application Owner for semiconductor analytics suite — SLOs, vendor management, training, documentation" | SLO ownership = senior signal |
|
||||
| BS-1 | ML inference in fab | "Containerized ML inference (Docker, K8s, Ansible) into 24/7 production; automated image-based defect classification" | Production ML in constrained environment |
|
||||
@@ -106,7 +106,7 @@ Python, Kafka, AWS (S3 · Glue · Athena · Redshift · Airflow · CloudFormatio
|
||||
|
||||
**Key narrative thread:**
|
||||
1. **Ownership at scale** — Component Owner at Swisscom, Application Owner at Bosch: not just building pipelines, but running them in production with SLA accountability
|
||||
2. **Cloud-native evolution** — AWS migration (Athena/Iceberg, Glue, Airflow, CloudFormation): led the transition, not just participated
|
||||
2. **Cloud-native evolution** — primary engineer for his domains' migration work and contributor to the wider programme; never imply company-wide leadership
|
||||
3. **Production ML integration** — Bosch: ML inference containerized into 24/7 fab; demonstrates that "data engineer who can own the ML data layer"
|
||||
4. **Consistent seniority arc** — Bosch promotion (mid → Senior), Swisscom promotion (Senior → Staff)
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
## S1: Role Profile & Priority Matrix
|
||||
|
||||
**Positioning:** Dennis's data platform and infrastructure experience is woven throughout his career rather than being a dedicated "platform engineer" role — but the evidence is substantive: Kubernetes ownership at two employers, AWS migration with CloudFormation/IaC, GitLab CI/CD automation, Docker containerization of ML workloads, observability stack (ELK + Grafana + Prometheus), and 3 consecutive years as Swisscom Security Champion (DevSecOps). Position as "Data Engineer with strong platform and infrastructure ownership" rather than a dedicated Platform/SRE/DevOps role.
|
||||
**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.
|
||||
|
||||
@@ -39,7 +39,7 @@
|
||||
- "Kubernetes-based containerized pipeline deployment"
|
||||
- "AWS IaC (CloudFormation)" — infrastructure-as-code signal
|
||||
- "AWS migration" — hands-on cloud platform experience
|
||||
- "DevSecOps / Security Champion" — security-aware platform engineer
|
||||
- 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 observability stack"
|
||||
|
||||
**Tone:** Infrastructure-minded engineer who thinks about reliability, observability, and security — not just data throughput. Platform thinking embedded in data work.
|
||||
@@ -56,11 +56,11 @@
|
||||
| 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 legacy ETL stack to cloud-native AWS (S3, Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation) — full IaC stack provisioned via CloudFormation" | CloudFormation/IaC + full AWS service breadth |
|
||||
| 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 | "Designed and delivered observability stack: ELK + Kafka, Grafana dashboards, Prometheus metrics, Loki log aggregation — full monitoring suite for manufacturing infrastructure" | Full observability stack implementation |
|
||||
| SW-5 | Security Champion | "Swisscom Security Champion ×3 (2023–2026) — DevSecOps ownership, security compliance, risk monitoring and deviation tracking for Data Lake team" | Security ownership in platform context |
|
||||
| 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 |
|
||||
@@ -112,7 +112,7 @@ Kubernetes, Docker, AWS (S3 · Glue · Athena · Redshift · CloudFormation), Ka
|
||||
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. **Full AWS platform stack** — SW-1: Not just using one AWS service — migrating an entire ETL infrastructure to AWS with CloudFormation/IaC shows platform-level thinking.
|
||||
3. **Observability initiative** — BS-4: Self-initiated ELK + Prometheus + Grafana PoC shows platform engineer mindset (monitoring is not optional).
|
||||
4. **Security ownership** — SW-5: Security Champion ×3 = DevSecOps embedded in platform work, not an afterthought.
|
||||
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
|
||||
|
||||
@@ -63,7 +63,7 @@
|
||||
| SW-2 | Component Owner | "Owned business-critical ETL pipelines (Oracle/Kafka → Teradata) — reliable data supply for downstream ML and analytics" | Data reliability for ML input |
|
||||
| FC-2 | ARTUS NLP | "Contributed ML and speech recognition components to ARTUS — Fraunhofer research project targeting automatic sea rescue transcription" | Applied NLP in safety-critical domain |
|
||||
| BS-4 | ELK PoC | "Delivered anomaly detection PoC: ELK + Kafka pipeline with Grafana/Prometheus monitoring — ML-adjacent signal processing" | Anomaly detection / observability |
|
||||
| SW-5 | Security Champion | "Swisscom Security Champion ×3 — security and compliance ownership for ML pipeline data governance and DevSecOps" | Security in ML data pipeline context |
|
||||
| SW-5 | Security Champion | Omit by default. If explicitly relevant: "2025/2026 team Security Champion" | Security exposure only; not responsible-AI, model-security or compliance ownership |
|
||||
| BS-2 | Data services | "Built data services (Python/Java/C#) over OracleDB and Hadoop enabling ML model input pipelines in semiconductor manufacturing" | Data infrastructure for ML |
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
# Bundle: Semiconductor Data / AI Engineer
|
||||
|
||||
## 1. Role Profile and Evidence Priority
|
||||
|
||||
**Positioning:** Production data and ML-integration engineer with three years of direct semiconductor-fab experience. Lead with Bosch domain evidence, then Swisscom production data ownership. Do not present Dennis as a process engineer, model researcher or computer-vision model owner.
|
||||
|
||||
**Good-fit roles:** Semiconductor data engineer, manufacturing analytics engineer, ML platform/MLOps engineer, data-infrastructure engineer, analytics-application owner.
|
||||
|
||||
**Hard-gate cautions:** Treat process-integration ownership, yield engineering, model research/training, embedded/edge inference, cleanroom equipment engineering and relocation requirements as direct gaps unless the JD makes them optional.
|
||||
|
||||
| Priority | Achievement | Why |
|
||||
|---|---|---|
|
||||
| HIGH | BS-1 ML inference integration | Direct production-ML evidence in a 24/7 fab |
|
||||
| HIGH | BS-3 Application Owner | Operational accountability, vendors, SLOs, training |
|
||||
| HIGH | BS-2 Data services | Python/Java/C# plus Oracle and Hadoop/Impala in fab domains |
|
||||
| MED | BS-5 Spotfire co-ownership | Fab analytics, C# extensions, user enablement |
|
||||
| MED | BS-4 Observability PoC | Honest proof-of-concept evidence for monitoring |
|
||||
| MED | SW-2 Component Owner | Current production ownership and on-call responsibility |
|
||||
| MED | SW-1 Scoped AWS migration | Current cloud/data-platform evidence |
|
||||
| LOW | Older software roles | Use only to support a required language or delivery practice |
|
||||
|
||||
## 2. Summary Guide
|
||||
|
||||
Use at most 2--3 rendered lines. State the Bosch fab context, production ML integration and current Staff-level data ownership. Avoid generic claims about petabyte-scale fabs, yield impact or zero downtime unless directly verified.
|
||||
|
||||
## 3. Reframing Rules
|
||||
|
||||
| Source evidence | Safe semiconductor framing |
|
||||
|---|---|
|
||||
| BS-1 | Integrated containerized ML inference into a continuously operating 300mm fab environment |
|
||||
| BS-2 | Built services giving internal analysis teams access to defect-management and process-analysis data |
|
||||
| BS-3 | Owned analytics applications and upstream pipelines operationally |
|
||||
| BS-4 | Built an anomaly-detection and monitoring proof of concept; never call it the fab observability platform |
|
||||
| BS-5 | Co-owned Spotfire and built wafer-map visualizations; preserve co-ownership |
|
||||
| SW-2/SW-1 | Current production data ownership and AWS migration work; do not force semiconductor vocabulary onto Swisscom |
|
||||
|
||||
## 4. Skills Guide
|
||||
|
||||
Prefer: Python, SQL, Oracle, Hadoop/Impala, Docker, Kubernetes, Ansible, Kafka, ELK, Grafana, Prometheus, C#, Java, Spotfire. Include only skills allowed by `resume_builder/canonical/claims.json`.
|
||||
|
||||
## 5. Cover Letter Guide
|
||||
|
||||
Generate a letter only when requested or when the Bosch-to-target-company domain connection adds information not obvious from the resume. Use first-person evidence from Bosch. Company/fab scale belongs to context, never to Dennis's personal achievement. Do not use the generic petabyte or yield-value claims from significance research.
|
||||
@@ -0,0 +1,281 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"last_verified": "2026-07-27",
|
||||
"authority": {
|
||||
"description": "Machine-readable source of truth for all future application documents.",
|
||||
"precedence": ["canonical claims", "config corrections", "verified references", "experience files", "bundles"],
|
||||
"raw_extractions_are_immutable": true,
|
||||
"historical_outputs_are_never_sources": true
|
||||
},
|
||||
"identity": {
|
||||
"name": "Dennis Thiessen",
|
||||
"degree_suffix": "M.Eng.",
|
||||
"email": "dennis@thiessen.io",
|
||||
"phone": "+41 795 955 585",
|
||||
"location": "Bern, Switzerland",
|
||||
"linkedin": "linkedin.com/in/dennis-thiessen",
|
||||
"citizenship": "German citizen (EU)",
|
||||
"swiss_permit": "B residence permit",
|
||||
"swiss_work_authorization": "Authorized to work in Switzerland; no visa or employer sponsorship required",
|
||||
"work_authorization_source": "User-confirmed 2026-07-27",
|
||||
"resume_usage": "Work authorization is optional in the header; mention the B permit or no-sponsorship status when it resolves recruiter uncertainty or the application asks for it",
|
||||
"languages": {"German": "native", "English": "fluent", "Norwegian": "basic", "Russian": "basic"},
|
||||
"forbidden_personal_data": ["date of birth", "marital status", "gender", "children"]
|
||||
},
|
||||
"education": [
|
||||
{
|
||||
"id": "EDU-MENG",
|
||||
"degree": "M.Eng. Computer Aided Engineering",
|
||||
"display_focus": "Software Design & Engineering",
|
||||
"institution": "Universitat der Bundeswehr Munchen",
|
||||
"start": "2012-04",
|
||||
"end": "2013-10",
|
||||
"thesis_institution": "Tongji University, Shanghai",
|
||||
"thesis_title": "Development of a Web-Based Remote Fault Diagnosis System",
|
||||
"thesis_grade": "1.0"
|
||||
},
|
||||
{
|
||||
"id": "EDU-BENG",
|
||||
"degree": "B.Eng. Information and Telecommunication Technologies",
|
||||
"institution": "Universitat der Bundeswehr Munchen",
|
||||
"start": "2009-10",
|
||||
"end": "2012-10"
|
||||
}
|
||||
],
|
||||
"employment": [
|
||||
{
|
||||
"id": "SWISSCOM",
|
||||
"employer": "Swisscom (Schweiz) AG",
|
||||
"location": "Bern, Switzerland",
|
||||
"display_title": "Staff Data, Analytics & AI Engineer",
|
||||
"start": "2023-10",
|
||||
"end": "present",
|
||||
"title_history": [
|
||||
{"title": "Senior Data, Analytics & AI Engineer", "start": "2023-10", "end": "2025-04"},
|
||||
{"title": "Staff Data, Analytics & AI Engineer", "start": "2025-04", "end": "present"}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "BOSCH",
|
||||
"employer": "Robert Bosch Semiconductor Manufacturing Dresden GmbH",
|
||||
"location": "Dresden, Germany",
|
||||
"official_title": "Engineer / Senior Engineer, Data Analysis",
|
||||
"display_title": "Senior Engineer, Data Analysis (Data & ML Engineering)",
|
||||
"start": "2020-02",
|
||||
"end": "2022-12"
|
||||
},
|
||||
{
|
||||
"id": "FRAUNHOFER",
|
||||
"employer": "Fraunhofer-Center for Maritime Logistics and Services CML",
|
||||
"location": "Hamburg, Germany",
|
||||
"official_title": "Wissenschaftlicher Mitarbeiter",
|
||||
"display_title": "Research Software Engineer",
|
||||
"start": "2018-09",
|
||||
"end": "2019-10"
|
||||
},
|
||||
{
|
||||
"id": "VIZRT",
|
||||
"employer": "Vizrt",
|
||||
"location": "Bergen, Norway",
|
||||
"official_title": "Test Automation Engineer",
|
||||
"display_title": "Test Automation / DevOps Engineer",
|
||||
"start": "2017-07",
|
||||
"end": "2018-05"
|
||||
},
|
||||
{
|
||||
"id": "GENERALI",
|
||||
"employer": "Generali Deutschland Informatik Services GmbH",
|
||||
"location": "Hamburg, Germany",
|
||||
"display_title": "IT Consultant",
|
||||
"start": "2015-05",
|
||||
"end": "2017-06"
|
||||
},
|
||||
{
|
||||
"id": "CAPGEMINI",
|
||||
"employer": "Capgemini Deutschland GmbH",
|
||||
"location": "Hamburg, Germany",
|
||||
"display_title": "Software Engineer",
|
||||
"start": "2014-11",
|
||||
"end": "2015-05"
|
||||
}
|
||||
],
|
||||
"claims": [
|
||||
{
|
||||
"id": "SW-1",
|
||||
"scope": "Primary engineer for pipelines in owned Fulfillment and Product Analysis domains; contributor to the wider company migration.",
|
||||
"allowed_verbs": ["migrated", "implemented", "contributed"],
|
||||
"forbidden": ["led the migration of the legacy warehouse", "sole technical lead", "migrated the company warehouse", "owned the full migration"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "SW-2",
|
||||
"scope": "Component Owner for business-critical Fulfillment ETL pipelines, including operation, data quality, governance, incidents and on-call obligations.",
|
||||
"allowed_verbs": ["own", "operate", "maintain", "serve"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "SW-3",
|
||||
"scope": "Build and operate Python data applications on Kubernetes with GitLab CI/CD within the team environment.",
|
||||
"allowed_verbs": ["build", "deploy", "operate"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "SW-4",
|
||||
"scope": "Deliver data products, dashboards and analyses with internal B2B stakeholders and product owners; not external consulting or strategic-account delivery.",
|
||||
"allowed_verbs": ["deliver", "translate", "partner", "support"],
|
||||
"forbidden": ["customer-embedded delivery", "strategic customer delivery", "C-suite advisor"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "SW-5",
|
||||
"scope": "Mandatory rotating team Security Champion role for 2025/2026 only; not an award, certification or multi-year distinction.",
|
||||
"allowed_verbs": ["serve"],
|
||||
"forbidden": ["3 consecutive years", "2023-2026", "Security Champion x3", "owning DevSecOps compliance"],
|
||||
"metrics": "100 hours of training and an assessment are source-backed; use only when relevant"
|
||||
},
|
||||
{
|
||||
"id": "SW-6",
|
||||
"scope": "Hands-on PySpark use at Swisscom; scale and performance metrics are not verified.",
|
||||
"allowed_verbs": ["use", "develop", "process"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "SW-7",
|
||||
"scope": "Build governed data products and onboard sources within Swisscom's company-wide Data Mesh; never claim ownership or construction of the shared mesh/platform.",
|
||||
"allowed_verbs": ["build", "model", "onboard", "contribute"],
|
||||
"forbidden": ["built a Data Mesh", "built the Data Mesh", "built AWS Data Mesh", "own the AWS data platform", "own the data platform"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "SW-8",
|
||||
"scope": "Configured domain-grounded LLM assistants in a Swisscom-owned web interface by selecting available models and supplying curated knowledge. Separate exposure includes LiteLLM API use, custom GPTs, Copilot and Kiro.",
|
||||
"allowed_verbs": ["configured", "used", "integrated"],
|
||||
"forbidden": ["built production LLM systems", "deployed LLM systems", "built LangChain", "agent orchestration", "formal LLM evaluation", "fine-tuned models"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "BS-1",
|
||||
"scope": "Designed and executed integration of containerized ML inference into a 24/7 semiconductor production environment; model-development ownership is not established.",
|
||||
"allowed_verbs": ["integrated", "containerized", "deployed", "orchestrated"],
|
||||
"forbidden": ["trained the image classification model", "owned the full ML lifecycle"],
|
||||
"metrics": "qualitative reduction in manual classification is source-backed; exact amount unverified"
|
||||
},
|
||||
{
|
||||
"id": "BS-2",
|
||||
"scope": "Developed data services in Python, Java and C# over Oracle and Hadoop/Impala for internal analysis teams.",
|
||||
"allowed_verbs": ["developed", "built"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "BS-3",
|
||||
"scope": "Confirmed Application Owner responsibilities for analytics applications and upstream pipelines, including SLOs, vendors, training and documentation.",
|
||||
"allowed_verbs": ["served", "owned", "managed", "defined"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "BS-4",
|
||||
"scope": "Built an ELK/Kafka anomaly-detection proof of concept and monitoring; not a company-wide observability platform.",
|
||||
"allowed_verbs": ["built", "implemented", "validated"],
|
||||
"forbidden": ["built the observability platform", "enterprise observability platform"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "BS-5",
|
||||
"scope": "Co-owned the TIBCO Spotfire environment, built C# extensions and co-presented at TIBCO Analytics Forum 2022.",
|
||||
"allowed_verbs": ["co-owned", "built", "co-presented"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "FC-1",
|
||||
"scope": "Set up Jenkins CI/CD and contributed to SCEDAS development and maintenance.",
|
||||
"allowed_verbs": ["set up", "developed", "maintained"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "FC-2",
|
||||
"scope": "Contributed ML/NLP components to ARTUS; no publication or model-training ownership.",
|
||||
"allowed_verbs": ["contributed", "implemented", "supported"],
|
||||
"forbidden": ["led ARTUS", "trained the speech model"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "FC-3",
|
||||
"scope": "Developed containerized microservices for the MISSION research platform.",
|
||||
"allowed_verbs": ["developed", "built"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "VZ-1",
|
||||
"scope": "Contributed Python and C++ engineering to a distributed video-transcoding backend. Named broadcasters are product context, not direct delivery claims.",
|
||||
"allowed_verbs": ["developed", "engineered", "contributed"],
|
||||
"forbidden": ["for CNN, BBC and Al Jazeera", "delivered to CNN", "customer-embedded"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "VZ-2",
|
||||
"scope": "Developed automated audio/video integration tests and connected quality gates to CI/CD.",
|
||||
"allowed_verbs": ["developed", "automated", "integrated"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "GN-1",
|
||||
"scope": "Introduced BDD through a proof of concept and held technical responsibility for test automation, training and Jenkins jobs.",
|
||||
"allowed_verbs": ["introduced", "owned", "trained", "administered"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "GN-2",
|
||||
"scope": "Developed UIPath RPA proofs of concept and acted as an internal contact.",
|
||||
"allowed_verbs": ["developed", "served"],
|
||||
"metrics": "unverified"
|
||||
},
|
||||
{
|
||||
"id": "GN-3",
|
||||
"scope": "Developed Java/J2EE workflow application features and contributed to integration proofs of concept.",
|
||||
"allowed_verbs": ["developed", "contributed", "migrated"],
|
||||
"metrics": "unverified"
|
||||
}
|
||||
],
|
||||
"skills": [
|
||||
{"name": "Python", "evidence": "production-current", "output": "allowed"},
|
||||
{"name": "SQL", "evidence": "production-current", "output": "allowed"},
|
||||
{"name": "PySpark", "evidence": "production-current", "output": "allowed"},
|
||||
{"name": "Kafka", "evidence": "production-current", "output": "allowed"},
|
||||
{"name": "Airflow", "evidence": "production-current", "output": "allowed"},
|
||||
{"name": "AWS", "evidence": "production-current", "output": "allowed"},
|
||||
{"name": "CloudFormation", "evidence": "production-current", "output": "allowed"},
|
||||
{"name": "Kubernetes", "evidence": "production-current-and-historical", "output": "allowed"},
|
||||
{"name": "Docker", "evidence": "production-current-and-historical", "output": "allowed"},
|
||||
{"name": "Java", "evidence": "production-historical", "output": "allowed-with-context"},
|
||||
{"name": "C#", "evidence": "production-historical", "output": "allowed-with-context"},
|
||||
{"name": "C++", "evidence": "production-historical-limited", "output": "allowed-with-context"},
|
||||
{"name": "JavaScript", "evidence": "production-historical-limited", "output": "allowed-with-context"},
|
||||
{"name": "LiteLLM", "evidence": "hands-on-current", "output": "allowed-with-context"},
|
||||
{"name": "custom GPTs", "evidence": "hands-on-current", "output": "allowed-with-context"},
|
||||
{"name": "Kiro", "evidence": "hands-on-current", "output": "allowed-with-context"},
|
||||
{"name": "Copilot", "evidence": "hands-on-current", "output": "allowed-with-context"},
|
||||
{"name": "TensorFlow/Keras", "evidence": "certification", "output": "certification-context-only"},
|
||||
{"name": "PyTorch", "evidence": "coursework-or-personal-unverified", "output": "certification-context-only"},
|
||||
{"name": "TypeScript", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "FastAPI", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "Flask", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "Django", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "LangChain", "evidence": "never-used", "output": "forbidden"},
|
||||
{"name": "LangGraph", "evidence": "never-used", "output": "forbidden"},
|
||||
{"name": "LlamaIndex", "evidence": "never-used", "output": "forbidden"},
|
||||
{"name": "formal model evaluation", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "LLM fine-tuning", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "Azure", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "GCP", "evidence": "unverified", "output": "forbidden"},
|
||||
{"name": "Terraform", "evidence": "unverified", "output": "forbidden"}
|
||||
],
|
||||
"global_forbidden_output_patterns": [
|
||||
"petabyte scale",
|
||||
"petabyte-scale",
|
||||
"own the AWS data platform",
|
||||
"LangChain-based",
|
||||
"customer-embedded delivery",
|
||||
"formal model evaluation",
|
||||
"3 consecutive years"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,23 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"policy": "Generated output is never a source for a new application. Regenerate from canonical claims and normalized experience files.",
|
||||
"unsafe_do_not_reuse": [
|
||||
{"folder": "output/Apple_Data_Engineer", "reasons": ["fabricated LangChain", "unsupported petabyte scale", "overstated platform and agentic ownership"]},
|
||||
{"folder": "output/Infineon_AI_Engineer", "reasons": ["fabricated LangChain"]},
|
||||
{"folder": "output/Equinor_AI_Manager", "reasons": ["unsupported model serving and evaluation", "inflated responsible-AI and security ownership"]},
|
||||
{"folder": "output/Microsoft_ISE_Senior_SWE", "reasons": ["unsupported model-evaluation skill", "customer-delivery framing exceeds verified evidence"]},
|
||||
{"folder": "output/Kraken_SRE_AI_Agents", "reasons": ["Security Champion scope inflation", "stretch-role framing requires complete regeneration"]},
|
||||
{"folder": "output/Kraken_AI_Infrastructure", "reasons": ["pre-canonical package", "agent-infrastructure bridges require revalidation"]}
|
||||
],
|
||||
"historical_revalidate": [
|
||||
"output/Google_Senior_Data_Engineer",
|
||||
"output/Snowflake_Observe_Enterprise",
|
||||
"output/QuantCo_Cloud_Engineer",
|
||||
"output/NATO_AI_ENGINEER",
|
||||
"output/BIS",
|
||||
"output/Isovalent_DataEngineer",
|
||||
"output/Infineon",
|
||||
"output/Microsoft_Principal_FDE_SWE"
|
||||
],
|
||||
"paused_no_package": ["output/Google_FDE_GenAI"]
|
||||
}
|
||||
@@ -1,5 +1,7 @@
|
||||
# Experience: Software Engineer → IT Consultant — Generali Deutschland Informatik Services GmbH (GDIS)
|
||||
## May 2015 – June 2017 | Hamburg/Cologne, Germany
|
||||
## May 2015 – June 2017 | Hamburg, Germany
|
||||
|
||||
> **Location — corrected 2026-07-27 (user-confirmed).** Base was **Hamburg**. **Cologne and Vienna were stations during the international graduate traineeship**, several months each. The Zeugnis extraction's "Köln" is the source of the old error. Resume/CV line must read **Hamburg, Germany** — never "Cologne" or "Hamburg/Cologne". The Cologne/Vienna rotations are a minor international-mobility signal: omit from resume bullets, but usable in a cover letter or interview when the JD values international or travel-heavy delivery. See `[[feedback_generali_location]]`.
|
||||
|
||||
### Cross-Position Section
|
||||
|
||||
|
||||
@@ -3,24 +3,26 @@
|
||||
|
||||
### Cross-Position Section
|
||||
|
||||
**Career arc framing:** Swisscom is Dennis's current and most senior role — a promotion from Senior to Staff (Engineer IV) in April 2025. This is the anchor position for all target role types. It demonstrates the full stack: owned pipelines, cloud migration, containerized delivery, security ownership, and stakeholder-facing data products. At a major national telco operating AWS-heavy infrastructure, this is the clearest signal for Staff/Senior Data Engineering, Data Platform, and ML Engineering roles.
|
||||
**Career arc framing:** Swisscom is Dennis's current and most senior role — a promotion from Senior to Staff (Engineer IV) in April 2025. This is the anchor position for all target role types. It demonstrates owned pipeline components, scoped cloud-migration delivery, containerized operation and stakeholder-facing data products. The 2025/2026 Security Champion assignment is a secondary team role, not a core ownership claim.
|
||||
|
||||
**CL framing (for cover letters):** "My current role at Swisscom — Switzerland's largest telco — gives me end-to-end ownership of business-critical data pipelines at scale: from Oracle and Kafka ingestion through Teradata DWH to AWS cloud-native architecture. I've led the migration of legacy pipelines to serverless AWS services and own the full DevOps lifecycle including Kubernetes deployment, GitLab CI/CD, and on-call support."
|
||||
**CL framing (for cover letters):** "At Swisscom I own business-critical pipeline components in the Fulfillment domain, from Oracle and Kafka ingestion through production support. I migrated my domains' pipelines onto the company's AWS platform and build governed data products within its wider Data Mesh, while contributing to the broader migration programme."
|
||||
|
||||
---
|
||||
|
||||
### Achievement SW-1: AWS Migration of Legacy ETL Stack
|
||||
|
||||
**Source:** thiessen_swisscom_zwischenzeugnis.md, thiessen_cv_master_profile.md
|
||||
**User's role:** Primary owner / sole technical lead
|
||||
**User's role:** Primary engineer for the migration of **his own domains'** pipelines; contributor to the wider company migration programme. **NOT a solo lead** — user-corrected 2026-07-27.
|
||||
**Status:** Active / ongoing operational achievement
|
||||
|
||||
**Context:** Legacy ETL pipelines ran on Teradata and Oracle. Migration to AWS cloud-native stack reduces operational overhead, improves scalability, and positions the team for modern serverless workflows.
|
||||
**Context:** Legacy ETL pipelines ran on Teradata and Oracle. Dennis implemented migration work for pipelines in his own domains using the company's AWS platform. No cost, scale or time-saving metric has been verified.
|
||||
|
||||
**Bullet variants:**
|
||||
- **2L:** Migrated legacy Teradata/Oracle ETL pipelines to AWS cloud-native architecture (S3, Glue, Athena with Apache Iceberg, Redshift, Airflow, CloudFormation), reducing manual operational overhead and enabling scalable, serverless data processing for downstream analytics.
|
||||
- **3L:** Led migration of legacy Teradata/Oracle ETL stack to a fully cloud-native AWS architecture using S3, Glue Jobs and Tables, Athena with Apache Iceberg (open table format), Redshift, Lambda, Step Functions, Airflow, and CloudFormation for IaC; reduced operational overhead, improved pipeline observability, and enabled scalable serverless processing — directly accelerating data availability for B2B stakeholder analytics.
|
||||
- **1L:** Migrated legacy ETL stack to AWS (S3, Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation) for scalable serverless data processing.
|
||||
**Bullet variants:** (scope-corrected 2026-07-27 — object must be **his domains'** pipelines, never "the" company stack)
|
||||
- **2L:** Migrated his domains' legacy Teradata/Oracle ETL pipelines to AWS cloud-native architecture (S3, Glue, Athena with Apache Iceberg, Redshift, Airflow, CloudFormation), reducing manual operational overhead and enabling scalable, serverless data processing for downstream analytics.
|
||||
- **3L:** Migrated the Fulfillment and Product Analysis domains' legacy Teradata/Oracle ETL pipelines to a cloud-native AWS architecture using S3, Glue Jobs and Tables, Athena with Apache Iceberg (open table format), Redshift, Lambda, Step Functions, Airflow, and CloudFormation for IaC; reduced operational overhead, improved pipeline observability, and enabled scalable serverless processing — contributing to Swisscom's wider cloud migration programme.
|
||||
- **1L:** Migrated his domains' ETL pipelines to AWS (S3, Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation) for serverless processing.
|
||||
|
||||
**Overclaiming warning:** Do NOT write "Led migration of the legacy stack" or imply sole ownership of a company-wide migration. See CLAUDE.md Scope Discipline and `[[feedback_bigcorp_ownership_scope]]`.
|
||||
|
||||
**Key skills:** AWS, S3, Glue, Athena, Apache Iceberg, Redshift, Lambda, Step Functions, Airflow, CloudFormation, IaC, ETL migration, cloud-native architecture
|
||||
**ATS keywords:** AWS, data pipeline migration, ETL, serverless, Airflow, Redshift, Glue, Athena, Apache Iceberg, CloudFormation, IaC
|
||||
@@ -99,26 +101,29 @@
|
||||
|
||||
---
|
||||
|
||||
### Achievement SW-5: Security Champion — 3 Consecutive Years
|
||||
### Achievement SW-5: Security Champion — 2025/2026 (team role, NOT an award)
|
||||
|
||||
**Source:** thiessen_swisscom_security_champion.md, thiessen_swisscom_zwischenzeugnis.md
|
||||
**User's role:** Designated Security Champion (annually renewed)
|
||||
**Status:** Active (2025/26 badge current)
|
||||
**User's role:** Designated Security Champion — a mandatory team role (security point of contact), **not an award or honor**
|
||||
**Status:** Active — **2025/2026 only**
|
||||
|
||||
**Context:** Swisscom's Security Champion program requires 100h of structured training covering Cloud Security, DevSecOps, Security by Design, and Risk Management, plus a 40-question assessment (>80% passing grade). Dennis has held this role for 3 consecutive years.
|
||||
> **CORRECTED 2026-07-27 (user-confirmed, second time).** This was previously written as "3 consecutive years (2023/24–2025/26)" — that is **wrong**. Dennis holds the badge for **2025/2026 only**. It is a rotating team role, not a distinction. See `config.md` KB Corrections and `[[feedback_security_champion]]`.
|
||||
>
|
||||
> **Default action: OMIT from resume and CV.** Include only when the JD explicitly requires security or DevSecOps experience. Never list under Awards/Honors.
|
||||
|
||||
**Bullet variants:**
|
||||
- **2L:** Named Swisscom Security Champion for 3 consecutive years (2023/24–2025/26), owning security compliance, risk monitoring and deviation tracking for the team's pipelines; completed 100h annual DevSecOps training with >80% assessment score.
|
||||
- **3L:** Designated as Security Champion for Swisscom's Data Lake team for 3 consecutive years (2023/24, 2024/25, 2025/26) — responsible for security compliance in development and operation, risk monitoring, and deviation reporting; fulfilled annual 100h structured training across Cloud Security, DevSecOps, Security by Design, and Security Risk Management, passing a 40-question comprehensive assessment with >80% score each year.
|
||||
- **1L:** Swisscom Security Champion for 3 consecutive years (2023–2026) — DevSecOps, risk monitoring, 100h training + assessment.
|
||||
**Context:** Swisscom's Security Champion program requires 100h of structured training covering Cloud Security, DevSecOps, Security by Design, and Risk Management, plus a 40-question assessment (>80% passing grade).
|
||||
|
||||
**Bullet variants:** (use ONLY if the JD explicitly asks for security/DevSecOps)
|
||||
- **2L:** Serve as Security Champion for the team (2025/2026), covering security compliance, risk monitoring and deviation tracking for the team's pipelines; completed 100h DevSecOps training with >80% assessment score.
|
||||
- **1L:** Team Security Champion (2025/2026) — DevSecOps, risk monitoring, 100h training + assessment.
|
||||
|
||||
**Key skills:** DevSecOps, security compliance, risk management, security awareness, Security by Design
|
||||
**ATS keywords:** DevSecOps, security champion, security compliance, risk management, cloud security
|
||||
**Reframing notes:**
|
||||
- Data Platform/Infra: HIGH relevance — embed security in infrastructure angle
|
||||
- Staff/Senior DE: include as supporting signal for senior-level ownership breadth
|
||||
- Data Platform/Infra: LOW by default; include only when the JD explicitly requires security or DevSecOps exposure
|
||||
- Staff/Senior DE: LOW by default; do not use as a generic seniority signal
|
||||
- Analytics Engineer: LOW — de-emphasize or omit unless JD asks for security awareness
|
||||
- ML/AI: include for AI-adjacent roles where model security/compliance is relevant
|
||||
- ML/AI: include only when the JD explicitly asks for security/compliance; this is not responsible-AI ownership
|
||||
|
||||
---
|
||||
|
||||
@@ -146,22 +151,22 @@
|
||||
### Achievement SW-7: Data Mesh, Data Products & Metadata Management (AWS) — Foundation for Agentic AI
|
||||
|
||||
**Source:** User-verified current work (2026), thiessen_cv_master_profile.md (AWS stack)
|
||||
**User's role:** Primary developer / current Staff-level focus area
|
||||
**User's role:** Builds and models governed data products and onboards sources within Swisscom's company-wide Data Mesh; does not own or architect the shared company-wide mesh.
|
||||
**Status:** Active / ongoing (current emphasis)
|
||||
|
||||
**Context:** Current Staff-level work building decentralized **Data Mesh** architecture, reusable **data products**, and active **metadata management** on AWS (Glue, Athena, CloudFormation, AWS CLI, CI/CD deployments). This is the governed, discoverable data foundation that downstream AI and **agentic workflows** depend on — enabling "AI speak-to-data" / grounded retrieval over enterprise data. Directly maps to agentic reference-architecture and MCP-based tool/data-access requirements.
|
||||
**Context:** Current Staff-level work builds reusable governed **data products**, active metadata and source onboarding within Swisscom's shared Data Mesh on AWS (Glue, Athena, CloudFormation, AWS CLI, CI/CD). These products can support downstream analytics and AI use cases. Do not convert this into ownership of agent architecture, MCP tooling or the company-wide platform.
|
||||
|
||||
**Bullet variants:**
|
||||
- **2L:** Built decentralized Data Mesh and reusable data products with active metadata management on AWS (Glue, Athena, CloudFormation, CI/CD) — the governed, discoverable data foundation that downstream AI and agentic workflows query directly.
|
||||
- **3L:** Architected decentralized Data Mesh with reusable, governed data products and active metadata management on AWS (Glue, Athena, CloudFormation, AWS CLI, automated CI/CD) — establishing the discoverable, well-described data foundation that downstream AI and agentic workflows depend on for grounded, "speak-to-data" retrieval over enterprise sources.
|
||||
- **1L:** Built AWS Data Mesh, data products and metadata management — the governed data foundation for downstream AI/agentic workflows.
|
||||
- **2L:** Build governed data products with active metadata management within Swisscom's company-wide Data Mesh on AWS (Glue, Athena, CloudFormation), supporting discoverable data access for analytics and AI use cases.
|
||||
- **3L:** Model and build governed data products, onboard source systems and maintain active metadata within Swisscom's company-wide Data Mesh on AWS (Glue, Athena, CloudFormation and CI/CD), giving downstream teams discoverable, well-described data without claiming ownership of the shared platform.
|
||||
- **1L:** Build governed data products and metadata within Swisscom's company-wide AWS Data Mesh.
|
||||
|
||||
**Key skills:** Data Mesh, data products, metadata management, data catalog, data governance, AWS, Glue, Athena, CloudFormation, AWS CLI, CI/CD, agentic data foundation, grounded retrieval
|
||||
**ATS keywords:** Data Mesh, data products, metadata management, AWS, Glue, Athena, CloudFormation, CI/CD, data governance, grounded retrieval, agentic AI foundation
|
||||
**Reframing notes:**
|
||||
- ML/AI (agentic): HIGH — lead bridge to "reference architecture for agentic systems" + "grounded retrieval / MCP tool-data access"; frame data layer as what agents query
|
||||
- ML/AI: MED — evidence for data readiness and grounded enterprise data, not agent architecture or retrieval ownership
|
||||
- Data Platform/Infra: HIGH — Data Mesh + metadata + AWS IaC is core platform signal
|
||||
- Staff/Senior DE: HIGH — decentralized architecture ownership at scale
|
||||
- Staff/Senior DE: HIGH — governed data-product delivery within a company-wide architecture
|
||||
- Analytics Engineer: MED — data products enable self-serve analytics
|
||||
|
||||
---
|
||||
@@ -193,7 +198,7 @@
|
||||
| Component Owner / Fulfillment ETL | SW-2 | HIGH | HIGH | MED | HIGH |
|
||||
| Kubernetes + GitLab CI/CD | SW-3 | HIGH | MED | HIGH | HIGH |
|
||||
| B2B Data Products + Automation | SW-4 | MED | HIGH | MED | MED |
|
||||
| Security Champion | SW-5 | MED | LOW | MED | HIGH |
|
||||
| Security Champion | SW-5 | LOW | LOW | LOW | LOW |
|
||||
| PySpark | SW-6 | MED | LOW | MED | MED |
|
||||
| Data Mesh / Data Products / Metadata (agentic foundation) | SW-7 | HIGH | MED | HIGH | HIGH |
|
||||
| Domain-Grounded LLM Agents | SW-8 | MED | LOW | HIGH | MED |
|
||||
|
||||
@@ -1,198 +1,101 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Count rendered characters in LaTeX resume/CV bullets.
|
||||
Strips LaTeX markup to show what a reader actually sees on the page.
|
||||
"""Report readable length diagnostics for LaTeX resume bullets.
|
||||
|
||||
This helper has no target bands and no page-fill logic. Rendered character and
|
||||
word counts are observations; they do not determine whether a bullet is good.
|
||||
|
||||
Usage:
|
||||
python3 char_count.py "\\textbf{DFT} analysis of \\ce{TiO2} surfaces"
|
||||
echo "bullet text" | python3 char_count.py
|
||||
python3 char_count.py -f cv output/file.tex
|
||||
python3 char_count.py --raw "bullet text" # just the number
|
||||
python resume_builder/helpers/char_count.py "\\item Built ..."
|
||||
python resume_builder/helpers/char_count.py output/Role/resume.tex
|
||||
python resume_builder/helpers/char_count.py --raw "bullet text"
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import re
|
||||
import sys
|
||||
import argparse
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
def strip_latex(text):
|
||||
"""Strip LaTeX markup to get rendered text."""
|
||||
# Remove \item[] prefix
|
||||
text = re.sub(r'\\item\s*(\[\s*\])?\s*', '', text)
|
||||
# \href{url}{text} -> text
|
||||
text = re.sub(r'\\href\{[^}]*\}\{([^}]*)\}', r'\1', text)
|
||||
# \textbf{X} -> X
|
||||
text = re.sub(r'\\textbf\{([^}]*)\}', r'\1', text)
|
||||
# \textit{X} -> X
|
||||
text = re.sub(r'\\textit\{([^}]*)\}', r'\1', text)
|
||||
# \underline{X} -> X
|
||||
text = re.sub(r'\\underline\{([^}]*)\}', r'\1', text)
|
||||
# \emph{X} -> X
|
||||
text = re.sub(r'\\emph\{([^}]*)\}', r'\1', text)
|
||||
# \ce{X} -> X (subscript digits still count as 1 char each)
|
||||
text = re.sub(r'\\ce\{([^}]*)\}', r'\1', text)
|
||||
# Greek letters -> 1 char each
|
||||
greeks = [
|
||||
'alpha', 'beta', 'gamma', 'delta', 'epsilon', 'zeta', 'eta', 'theta',
|
||||
'iota', 'kappa', 'lambda', 'mu', 'nu', 'xi', 'pi', 'rho', 'sigma',
|
||||
'tau', 'upsilon', 'phi', 'chi', 'psi', 'omega',
|
||||
'Alpha', 'Beta', 'Gamma', 'Delta', 'Theta', 'Lambda', 'Sigma',
|
||||
'Phi', 'Psi', 'Omega',
|
||||
]
|
||||
for g in greeks:
|
||||
text = text.replace(f'$\\{g}$', 'G')
|
||||
text = text.replace(f'\\{g}', 'G')
|
||||
# $^\circ$ -> 1 char
|
||||
text = re.sub(r'\$\^\{?\\circ\}?\$', 'D', text)
|
||||
# $^\dagger$ -> 1 char
|
||||
text = re.sub(r'\$\^\{?\\dagger\}?\$', 'D', text)
|
||||
# Superscripts: $^{2}$ or $^2$ -> content
|
||||
text = re.sub(r'\$\^\{([^}]*)\}\$', r'\1', text)
|
||||
text = re.sub(r'\$\^(.)\$', r'\1', text)
|
||||
# Subscripts: $_{2}$ or $_2$ -> content
|
||||
text = re.sub(r'\$_\{([^}]*)\}\$', r'\1', text)
|
||||
text = re.sub(r'\$_(.)\$', r'\1', text)
|
||||
# \sim -> 1 char (~)
|
||||
text = text.replace('$\\sim$', '~')
|
||||
text = text.replace('\\sim', '~')
|
||||
text = text.replace('\\textasciitilde', '~')
|
||||
# $<$ $>$ -> 1 char
|
||||
text = re.sub(r'\$([<>])\$', r'\1', text)
|
||||
# --- -> em-dash (1 char but ~2x wide)
|
||||
text = text.replace('---', '\u2014')
|
||||
# -- -> en-dash (1 char)
|
||||
text = text.replace('--', '\u2013')
|
||||
# Remove remaining $ (math mode delimiters)
|
||||
text = text.replace('$', '')
|
||||
# Remove remaining \commands
|
||||
text = re.sub(r'\\[a-zA-Z]+\s*', '', text)
|
||||
# Remove remaining braces
|
||||
text = text.replace('{', '').replace('}', '')
|
||||
# Collapse multiple spaces
|
||||
text = re.sub(r' +', ' ', text)
|
||||
return text.strip()
|
||||
def strip_latex(text: str) -> str:
|
||||
"""Approximate reader-visible text without imposing layout targets."""
|
||||
text = re.sub(r"\\item\s*(\[\s*\])?\s*", "", text)
|
||||
text = re.sub(r"\\href\{[^}]*\}\{([^}]*)\}", r"\1", text)
|
||||
for command in ("textbf", "textit", "underline", "emph", "ce"):
|
||||
text = re.sub(rf"\\{command}\{{([^}}]*)\}}", r"\1", text)
|
||||
text = re.sub(r"\$\^\{?\\circ\}?\$", "°", text)
|
||||
text = re.sub(r"\$\^\{([^}]*)\}\$", r"\1", text)
|
||||
text = re.sub(r"\$\^(.)\$", r"\1", text)
|
||||
text = text.replace("$\\sim$", "~").replace("\\sim", "~")
|
||||
text = text.replace("---", "—").replace("--", "–")
|
||||
text = text.replace("\\&", "&").replace("\\%", "%")
|
||||
text = re.sub(r"\\[A-Za-z]+\s*", "", text)
|
||||
text = text.replace("$", "").replace("{", "").replace("}", "")
|
||||
return re.sub(r"\s+", " ", text).strip()
|
||||
|
||||
|
||||
def count_bold_chars(text):
|
||||
"""Count characters inside \\textbf{} commands."""
|
||||
return sum(len(m) for m in re.findall(r'\\textbf\{([^}]*)\}', text))
|
||||
|
||||
|
||||
def count_em_dashes(text):
|
||||
"""Count em-dashes (---) which render ~2x wide."""
|
||||
return len(re.findall(r'---', text))
|
||||
|
||||
|
||||
def classify_bullet(char_count, bold_chars, fmt):
|
||||
"""Classify bullet into variant and check limits."""
|
||||
if fmt == 'resume':
|
||||
base = 119
|
||||
penalty = 0.5
|
||||
tiers = [
|
||||
('1L', 105, 111, 117, None),
|
||||
('2L', 189, 205, 218, 78),
|
||||
]
|
||||
else:
|
||||
base = 91
|
||||
penalty = 0.25
|
||||
tiers = [
|
||||
('1L', 88, 93, 101, None),
|
||||
('2L', 168, 182, 190, 65),
|
||||
('3L', 250, 268, 280, 65),
|
||||
]
|
||||
|
||||
effective = base - (penalty * bold_chars)
|
||||
|
||||
for variant, lo, hi, hard_max, orphan in tiers:
|
||||
if char_count <= hard_max:
|
||||
if char_count < lo:
|
||||
status = 'SHORT'
|
||||
elif char_count <= hi:
|
||||
status = 'OK'
|
||||
else:
|
||||
status = 'NEAR MAX'
|
||||
return variant, status, lo, hi, hard_max, orphan, effective
|
||||
|
||||
return 'OVER', 'OVER LIMIT', 0, 0, 0, None, effective
|
||||
|
||||
|
||||
def format_one(raw, fmt):
|
||||
"""Format analysis for a single bullet."""
|
||||
rendered = strip_latex(raw)
|
||||
n = len(rendered)
|
||||
bold = count_bold_chars(raw)
|
||||
em = count_em_dashes(raw)
|
||||
|
||||
variant, status, lo, hi, hard_max, orphan, eff = classify_bullet(n, bold, fmt)
|
||||
|
||||
parts = [f" {n:3d} chars | {variant} {fmt.upper()} | {status} (target {lo}-{hi}, max {hard_max})"]
|
||||
if bold:
|
||||
parts.append(f" Bold: {bold} chars -> effective limit/line: {eff:.0f}")
|
||||
if em:
|
||||
parts.append(f" Em-dashes: {em} (each ~2x wide, budget +{em} extra)")
|
||||
parts.append(f" Rendered: {rendered}")
|
||||
return '\n'.join(parts), variant
|
||||
|
||||
|
||||
def extract_items(text):
|
||||
"""Extract \\item lines from .tex source."""
|
||||
items = []
|
||||
for line in text.split('\n'):
|
||||
s = line.strip()
|
||||
if s.startswith('\\item'):
|
||||
items.append(s)
|
||||
def extract_items(source: str) -> list[str]:
|
||||
"""Extract item bodies, including wrapped source lines."""
|
||||
items: list[str] = []
|
||||
current: list[str] = []
|
||||
for line in source.splitlines():
|
||||
stripped = line.strip()
|
||||
if stripped.startswith("\\item"):
|
||||
if current:
|
||||
items.append(" ".join(current))
|
||||
current = [stripped]
|
||||
elif current and not stripped.startswith("\\end{itemize}"):
|
||||
current.append(stripped)
|
||||
elif current:
|
||||
items.append(" ".join(current))
|
||||
current = []
|
||||
if current:
|
||||
items.append(" ".join(current))
|
||||
return items
|
||||
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(
|
||||
description='Count rendered characters in LaTeX resume/CV bullets')
|
||||
parser.add_argument('input', nargs='?',
|
||||
help='Bullet text or .tex file path')
|
||||
parser.add_argument('-f', '--format', choices=['resume', 'cv'],
|
||||
default='resume', help='Document format (default: resume)')
|
||||
parser.add_argument('--raw', action='store_true',
|
||||
help='Output only char count (for scripting)')
|
||||
def diagnose(raw: str) -> tuple[str, int, int, int]:
|
||||
rendered = strip_latex(raw)
|
||||
words = re.findall(r"\b[\w+#./-]+\b", rendered, flags=re.UNICODE)
|
||||
clauses = len(re.findall(r"[;:]|\s—\s", rendered)) + 1 if rendered else 0
|
||||
return rendered, len(rendered), len(words), clauses
|
||||
|
||||
|
||||
def format_report(raw: str) -> str:
|
||||
rendered, characters, words, clauses = diagnose(raw)
|
||||
note = ""
|
||||
if words > 35 or clauses > 3:
|
||||
note = "\n Review: potentially dense; check whether it contains multiple accomplishments."
|
||||
return (
|
||||
f" {words} words | {characters} rendered characters | {clauses} clause(s)\n"
|
||||
f" Rendered: {rendered}{note}"
|
||||
)
|
||||
|
||||
|
||||
def main() -> None:
|
||||
parser = argparse.ArgumentParser(description="Report LaTeX bullet length diagnostics")
|
||||
parser.add_argument("input", nargs="?", help="Bullet text or .tex file")
|
||||
parser.add_argument("--raw", action="store_true", help="Output rendered character count only")
|
||||
args = parser.parse_args()
|
||||
|
||||
if args.input and args.input.endswith('.tex'):
|
||||
with open(args.input) as f:
|
||||
items = extract_items(f.read())
|
||||
if args.input and args.input.endswith(".tex") and Path(args.input).is_file():
|
||||
items = extract_items(Path(args.input).read_text(encoding="utf-8"))
|
||||
if not items:
|
||||
print("No \\item lines found.")
|
||||
print("No \\item bullets found.")
|
||||
return
|
||||
total_lines = 0
|
||||
print(f"Found {len(items)} bullets ({args.format} format):\n")
|
||||
for i, item in enumerate(items, 1):
|
||||
for index, item in enumerate(items, 1):
|
||||
if args.raw:
|
||||
print(len(strip_latex(item)))
|
||||
print(diagnose(item)[1])
|
||||
else:
|
||||
report, variant = format_one(item, args.format)
|
||||
print(f"Bullet {i}:")
|
||||
print(report)
|
||||
print()
|
||||
if variant not in ('OVER',):
|
||||
total_lines += int(variant[0])
|
||||
if not args.raw:
|
||||
print(f"Total rendered lines: {total_lines}")
|
||||
elif args.input:
|
||||
if args.raw:
|
||||
print(len(strip_latex(args.input)))
|
||||
else:
|
||||
report, _ = format_one(args.input, args.format)
|
||||
print(report)
|
||||
else:
|
||||
for line in sys.stdin:
|
||||
line = line.strip()
|
||||
if not line:
|
||||
continue
|
||||
if args.raw:
|
||||
print(len(strip_latex(line)))
|
||||
else:
|
||||
report, _ = format_one(line, args.format)
|
||||
print(report)
|
||||
print()
|
||||
print(f"Bullet {index}:\n{format_report(item)}\n")
|
||||
return
|
||||
|
||||
raw = args.input if args.input is not None else sys.stdin.read().strip()
|
||||
if not raw:
|
||||
parser.error("provide bullet text, a .tex file, or stdin")
|
||||
print(diagnose(raw)[1] if args.raw else format_report(raw))
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
|
||||
@@ -0,0 +1,80 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Record and summarize the controlled ten-application cohort."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import json
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
ROOT = Path(__file__).resolve().parents[2]
|
||||
TRACKER = ROOT / "job_scout" / "state" / "application_cohort.json"
|
||||
FIT_CLASSES = ("core", "adjacent", "stretch")
|
||||
CHANNELS = ("strong", "moderate", "weak")
|
||||
|
||||
|
||||
def load() -> dict:
|
||||
return json.loads(TRACKER.read_text(encoding="utf-8"))
|
||||
|
||||
|
||||
def save(data: dict) -> None:
|
||||
TRACKER.write_text(json.dumps(data, indent=2, ensure_ascii=False) + "\n", encoding="utf-8")
|
||||
|
||||
|
||||
def summary(data: dict) -> None:
|
||||
applications = data["applications"]
|
||||
print(f"Cohort: {data['cohort_id']} ({len(applications)}/10 applications)")
|
||||
for fit_class in FIT_CLASSES:
|
||||
count = sum(item["fit_class"] == fit_class for item in applications)
|
||||
target = data["target_mix"][fit_class]
|
||||
print(f" {fit_class}: {count}/{target}")
|
||||
for channel in CHANNELS:
|
||||
count = sum(item["channel"] == channel for item in applications)
|
||||
print(f" channel {channel}: {count}")
|
||||
outcomes: dict[str, int] = {}
|
||||
for item in applications:
|
||||
outcome = item.get("outcome", "open")
|
||||
outcomes[outcome] = outcomes.get(outcome, 0) + 1
|
||||
print(" outcomes: " + ", ".join(f"{key}={value}" for key, value in sorted(outcomes.items())))
|
||||
|
||||
|
||||
def main() -> None:
|
||||
parser = argparse.ArgumentParser()
|
||||
subparsers = parser.add_subparsers(dest="command", required=True)
|
||||
subparsers.add_parser("summary")
|
||||
add = subparsers.add_parser("add")
|
||||
add.add_argument("--company", required=True)
|
||||
add.add_argument("--role", required=True)
|
||||
add.add_argument("--date", required=True)
|
||||
add.add_argument("--fit-class", choices=FIT_CLASSES, required=True)
|
||||
add.add_argument("--evidence-fit", type=float, required=True)
|
||||
add.add_argument("--channel", choices=CHANNELS, required=True)
|
||||
add.add_argument("--hard-gate", choices=("pass", "fail"), required=True)
|
||||
add.add_argument("--outcome", default="open")
|
||||
|
||||
args = parser.parse_args()
|
||||
data = load()
|
||||
if args.command == "add":
|
||||
if len(data["applications"]) >= 10:
|
||||
raise SystemExit("cohort already contains ten applications")
|
||||
if args.hard_gate == "fail" and args.fit_class != "stretch":
|
||||
raise SystemExit("a hard-gate failure must be recorded as stretch")
|
||||
data["applications"].append(
|
||||
{
|
||||
"company": args.company,
|
||||
"role": args.role,
|
||||
"application_date": args.date,
|
||||
"fit_class": args.fit_class,
|
||||
"evidence_fit": args.evidence_fit,
|
||||
"hard_gate": args.hard_gate,
|
||||
"channel": args.channel,
|
||||
"outcome": args.outcome,
|
||||
}
|
||||
)
|
||||
save(data)
|
||||
summary(data)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,170 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Validate canonical resume data, generation sources, and generated documents.
|
||||
|
||||
Usage:
|
||||
python resume_builder/helpers/validate_resume_system.py
|
||||
python resume_builder/helpers/validate_resume_system.py --document output/Acme/resume.tex
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import json
|
||||
import re
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
ROOT = Path(__file__).resolve().parents[2]
|
||||
CLAIMS_PATH = ROOT / "resume_builder" / "canonical" / "claims.json"
|
||||
HISTORY_PATH = ROOT / "resume_builder" / "canonical" / "historical_outputs.json"
|
||||
|
||||
|
||||
def load_json(path: Path) -> dict:
|
||||
with path.open(encoding="utf-8") as handle:
|
||||
return json.load(handle)
|
||||
|
||||
|
||||
def read_text(path: Path) -> str:
|
||||
return path.read_text(encoding="utf-8")
|
||||
|
||||
|
||||
def canonical_checks(claims: dict, history: dict) -> tuple[list[str], list[str]]:
|
||||
errors: list[str] = []
|
||||
warnings: list[str] = []
|
||||
|
||||
if claims.get("schema_version") != 1:
|
||||
errors.append("claims.json schema_version must be 1")
|
||||
if history.get("schema_version") != 1:
|
||||
errors.append("historical_outputs.json schema_version must be 1")
|
||||
|
||||
for key in ("identity", "education", "employment", "claims", "skills"):
|
||||
if not claims.get(key):
|
||||
errors.append(f"claims.json missing non-empty {key}")
|
||||
|
||||
for collection in ("education", "employment", "claims"):
|
||||
ids = [item.get("id") for item in claims.get(collection, [])]
|
||||
if None in ids:
|
||||
errors.append(f"{collection} contains an item without id")
|
||||
duplicates = sorted({item for item in ids if ids.count(item) > 1})
|
||||
if duplicates:
|
||||
errors.append(f"duplicate {collection} ids: {', '.join(duplicates)}")
|
||||
|
||||
skills = claims.get("skills", [])
|
||||
skill_names = [item.get("name") for item in skills]
|
||||
duplicates = sorted({item for item in skill_names if skill_names.count(item) > 1})
|
||||
if duplicates:
|
||||
errors.append(f"duplicate skills: {', '.join(duplicates)}")
|
||||
for skill in skills:
|
||||
if skill.get("output") not in {
|
||||
"allowed",
|
||||
"allowed-with-context",
|
||||
"certification-context-only",
|
||||
"forbidden",
|
||||
}:
|
||||
errors.append(f"invalid output policy for skill {skill.get('name')}")
|
||||
|
||||
config = read_text(ROOT / "config.md")
|
||||
bundle_names = re.findall(r"\|\s*(bundle_[a-z0-9_]+\.md)\s*\|", config)
|
||||
for bundle_name in bundle_names:
|
||||
if not (ROOT / "resume_builder" / "bundles" / bundle_name).exists():
|
||||
errors.append(f"configured bundle does not exist: {bundle_name}")
|
||||
|
||||
expected_files = [
|
||||
ROOT / "resume_builder" / "templates" / "resume_template.tex",
|
||||
ROOT / "resume_builder" / "reference" / "resume_reference.md",
|
||||
ROOT / "resume_builder" / "reference" / "critique_framework.md",
|
||||
]
|
||||
for path in expected_files:
|
||||
if not path.exists():
|
||||
errors.append(f"required workflow file missing: {path.relative_to(ROOT)}")
|
||||
|
||||
history_folders: list[str] = []
|
||||
for key in ("unsafe_do_not_reuse", "historical_revalidate"):
|
||||
for item in history.get(key, []):
|
||||
history_folders.append(item["folder"] if isinstance(item, dict) else item)
|
||||
duplicates = sorted({item for item in history_folders if history_folders.count(item) > 1})
|
||||
if duplicates:
|
||||
errors.append(f"historical output folders classified twice: {', '.join(duplicates)}")
|
||||
|
||||
if claims["identity"].get("swiss_permit", "").startswith("UNVERIFIED"):
|
||||
warnings.append("Swiss permit type remains unverified; generators must ask before naming it")
|
||||
return errors, warnings
|
||||
|
||||
|
||||
def workflow_checks() -> list[str]:
|
||||
errors: list[str] = []
|
||||
checks = {
|
||||
ROOT / "resume_builder" / "templates" / "resume_template.tex": [
|
||||
"Research Experience",
|
||||
"FLIPPED format",
|
||||
"Selected Publications",
|
||||
],
|
||||
ROOT / "resume_builder" / "reference" / "resume_reference.md": [
|
||||
"ALL variable bullets",
|
||||
"<= 3 lines white space",
|
||||
"20-21 variable bullets",
|
||||
],
|
||||
ROOT / ".agents" / "skills" / "critique" / "SKILL.md": [
|
||||
"Publications 10%",
|
||||
"Eight-Dimension Scoring",
|
||||
],
|
||||
}
|
||||
for path, forbidden_phrases in checks.items():
|
||||
text = read_text(path).lower()
|
||||
for phrase in forbidden_phrases:
|
||||
if phrase.lower() in text:
|
||||
errors.append(f"obsolete workflow rule remains in {path.relative_to(ROOT)}: {phrase}")
|
||||
return errors
|
||||
|
||||
|
||||
def scan_document(path: Path, claims: dict) -> list[str]:
|
||||
errors: list[str] = []
|
||||
text = read_text(path)
|
||||
lowered = text.lower()
|
||||
for pattern in claims.get("global_forbidden_output_patterns", []):
|
||||
if pattern.lower() in lowered:
|
||||
errors.append(f"{path}: forbidden output pattern: {pattern}")
|
||||
for skill in claims.get("skills", []):
|
||||
if skill.get("output") == "forbidden" and skill["name"].lower() in lowered:
|
||||
errors.append(f"{path}: forbidden or unverified skill: {skill['name']}")
|
||||
if "\\begin{rsubsection}" in lowered:
|
||||
for line_number, line in enumerate(text.splitlines(), 1):
|
||||
if "\\begin{rSubsection}" not in line:
|
||||
continue
|
||||
if re.search(r"Production Ownership|AI-Ready|Customer-Embedded|Shipping ML", line, re.I):
|
||||
errors.append(f"{path}:{line_number}: marketing theme used before formal employer/title")
|
||||
return errors
|
||||
|
||||
|
||||
def main() -> int:
|
||||
parser = argparse.ArgumentParser()
|
||||
parser.add_argument("--document", action="append", default=[], help="Generated .tex file to validate")
|
||||
args = parser.parse_args()
|
||||
|
||||
claims = load_json(CLAIMS_PATH)
|
||||
history = load_json(HISTORY_PATH)
|
||||
errors, warnings = canonical_checks(claims, history)
|
||||
errors.extend(workflow_checks())
|
||||
for document in args.document:
|
||||
path = Path(document)
|
||||
if not path.is_absolute():
|
||||
path = ROOT / path
|
||||
if not path.exists():
|
||||
errors.append(f"document not found: {path}")
|
||||
else:
|
||||
errors.extend(scan_document(path, claims))
|
||||
|
||||
for warning in warnings:
|
||||
print(f"WARN: {warning}")
|
||||
for error in errors:
|
||||
print(f"ERROR: {error}")
|
||||
if errors:
|
||||
print(f"FAIL: {len(errors)} error(s), {len(warnings)} warning(s)")
|
||||
return 1
|
||||
print(f"PASS: canonical system valid ({len(warnings)} warning(s))")
|
||||
return 0
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
@@ -0,0 +1,74 @@
|
||||
# Application Strategy
|
||||
|
||||
## Positioning
|
||||
|
||||
Default professional identity:
|
||||
|
||||
> Staff/Senior Data Engineer with production platform ownership, AWS data products, Kubernetes delivery and direct production-ML integration experience.
|
||||
|
||||
Core targets:
|
||||
|
||||
- Senior/Staff Data Engineer.
|
||||
- AWS-oriented Data Platform Engineer when Terraform/SRE background is not mandatory.
|
||||
- ML Platform/MLOps roles centered on deployment, infrastructure and operation.
|
||||
- Semiconductor data, analytics and production-ML infrastructure roles.
|
||||
- Swiss/DACH enterprise data-engineering roles.
|
||||
|
||||
Stretch targets include LLM/agent engineer, AI Manager, pure SRE, strategic-account FDE, and Principal roles requiring company-wide architecture or external-customer authority.
|
||||
|
||||
## Application Gate
|
||||
|
||||
Before generating a resume, complete Evidence Fit from `critique_framework.md`.
|
||||
|
||||
- **Core:** 75+ and no hard-gate failure.
|
||||
- **Adjacent:** 60--74, no required Gap, normally at most one serious preferred gap.
|
||||
- **Stretch:** below 60 or a defining responsibility is only Adjacent.
|
||||
- **No-go:** required/title-defining Gap or unresolved practical constraint.
|
||||
|
||||
Do not spend a full resume/cover-letter cycle on a no-go role. Record the decision and move on.
|
||||
|
||||
## Controlled Ten-Application Cohort
|
||||
|
||||
The next diagnostic cohort uses:
|
||||
|
||||
- 7 Core applications.
|
||||
- 2 Adjacent applications.
|
||||
- 1 Stretch application maximum.
|
||||
|
||||
Track fit class, hard gates, channel, application date, stage and outcome. Evaluate the cohort only after ten applications or a meaningful screen/interview result; do not infer profile quality from a few high-variance FAANG outcomes.
|
||||
|
||||
## Channel Strategy
|
||||
|
||||
For every Core application, attempt at least one warm action before or immediately after applying:
|
||||
|
||||
- credible internal referral;
|
||||
- targeted note to a relevant recruiter;
|
||||
- concise outreach to the hiring manager or team member;
|
||||
- former colleague/customer/vendor connection who can establish work quality.
|
||||
|
||||
Record the channel as Strong, Moderate or Weak. Tailoring alone does not upgrade a cold channel.
|
||||
|
||||
## Resume Strategy
|
||||
|
||||
- Use International Tech format by default.
|
||||
- Keep the first half page focused on identity, compact skills and current evidence.
|
||||
- Preserve conventional employer/title/date hierarchy.
|
||||
- Favor 11--14 strong bullets over padding.
|
||||
- Capture verified impact rather than inventing metrics.
|
||||
- Generate the Swiss/DACH variant only when local conventions fit the employer.
|
||||
|
||||
## Cover-Letter Strategy
|
||||
|
||||
Apply the decision gate in `cl_reference.md`. A letter is not a default package component. Put effort into portal questions, referral context and outreach when those have higher information value.
|
||||
|
||||
## Feedback Loop
|
||||
|
||||
After the ten-application cohort, compare:
|
||||
|
||||
- Core vs Adjacent/Stretch progression.
|
||||
- Warm vs cold progression.
|
||||
- Recruiter rejection vs hiring-manager rejection.
|
||||
- Tool/domain patterns among successful and unsuccessful roles.
|
||||
- Whether resume changes affected outcomes.
|
||||
|
||||
Change one major variable at a time. Do not react to a single rejection by adding unsupported skills or broader positioning.
|
||||
@@ -1,104 +1,62 @@
|
||||
# Cover Letter Generation — Reference
|
||||
# Cover Letter Reference
|
||||
|
||||
> CL-specific rules. Read by `/make-cl` and `/edit-resume` (for CL edits).
|
||||
> Shared rules (provenance, anti-fabrication, LaTeX notation): `CLAUDE.md`
|
||||
> A cover letter is optional by default. The resume must earn a screen on its own.
|
||||
|
||||
---
|
||||
## Decision Gate
|
||||
|
||||
## CL Format Rules
|
||||
Generate a cover letter when at least one is true:
|
||||
|
||||
- Cover letter with resume: 1 page (250-300 words)
|
||||
- Cover letter with CV: 1-2 pages (350-450 words). If 2 pages, page 2 >= half filled before signature.
|
||||
- Full package: Resume + CL = 3 pages | CV + CL = 6-7 pages
|
||||
- The posting or portal requests one.
|
||||
- The employer is a traditional Swiss/DACH institution, public body, NGO or mission-led organization where motivation is material.
|
||||
- A credible career/location/domain transition needs a short explanation.
|
||||
- Work authorization, language, relocation or a genuine personal connection materially strengthens the application.
|
||||
- The user explicitly requests a letter.
|
||||
|
||||
---
|
||||
Normally skip it when:
|
||||
|
||||
## Institution Type Detection
|
||||
- The portal provides no upload field.
|
||||
- A standardized process already asks motivation questions.
|
||||
- It would merely repeat the resume or paraphrase company news.
|
||||
|
||||
- **Industry:** Any company (manufacturing, tech, consulting, energy, etc.)
|
||||
- **National Lab:** DOE labs, national research facilities, government lab fellowships
|
||||
- **Academic:** University postdoc or faculty positions
|
||||
Record `Cover Letter Decision: YES/NO` and the reason in the session file before writing.
|
||||
|
||||
---
|
||||
## Evidence Rules
|
||||
|
||||
## INDUSTRY Cover Letter (250-300 words, 3 paragraphs)
|
||||
1. Read `resume_builder/canonical/claims.json` first.
|
||||
2. Every work claim must be traceable to the resume and canonical registry.
|
||||
3. Significance files supply optional context only; reverify external claims from current primary sources.
|
||||
4. Company or industry scale never becomes Dennis's personal scale or impact.
|
||||
5. Do not introduce a skill, metric, customer, ownership claim or result absent from the resume.
|
||||
|
||||
**P1 — HOOK:** Connect their product/technology to your achievement. State core identity + position. Open with a specific reference to their work, not a generic opener. Minimize jargon for HR readers.
|
||||
## International Tech / Industry Letter
|
||||
|
||||
**P2 — EVIDENCE:** 2-3 achievements translated to business value. Max 3-4 quantified claims. Mirror JD terms. Frame as deliverables.
|
||||
- One page, normally 200--300 words.
|
||||
- Two or three short paragraphs.
|
||||
- Open with the candidate-role connection, not a company press-release summary.
|
||||
- Use one or two proof points and explain why they matter for this role.
|
||||
- Add motivation or context the resume cannot show.
|
||||
- Close directly and professionally.
|
||||
|
||||
**P3 — CLOSING:** Forward-looking value + active call to action. Address "why industry" positively if pivoting — frame what industry enables, not what academia lacks.
|
||||
## Swiss/DACH Letter
|
||||
|
||||
---
|
||||
- One A4 page.
|
||||
- Match the language and formality of the posting.
|
||||
- Explain motivation, relevant evidence and practical fit such as location/language.
|
||||
- References and diplomas remain separate attachments when requested.
|
||||
|
||||
## NATIONAL LAB Cover Letter (350-450 words, 4 paragraphs)
|
||||
## Employer-Specific Formats
|
||||
|
||||
**P1 — HOOK:** Mission alignment + division/group + position. Reference specific programmatic thrust or group's publication. Technical vocabulary OK.
|
||||
For NATO, government or academic applications, follow the employer's explicit format and portal fields. Do not force a generic three-paragraph industry structure when the application requests a motivation statement or competency answers.
|
||||
|
||||
**P2 — CURRENT POSITION:** Current work with mission framing. Theory-experiment bridge. HPC scale. Collaborative tone.
|
||||
## Hook Verification
|
||||
|
||||
**P3 — PRIOR WORK:** Transferable methodology arc. Custom tools → ML infrastructure. International collaboration. Quantify.
|
||||
Verify every named product, programme, paper, executive statement or current company initiative before use. Prefer first-party sources. Record the source in the session file. If a hook is not necessary, omit it rather than spending a paragraph proving company familiarity.
|
||||
|
||||
**P4 — CLOSING:** Programmatic vision + collaboration offer + seminar availability. Lab vocabulary: "thrust area," "programmatic direction."
|
||||
## Quality Checks
|
||||
|
||||
---
|
||||
|
||||
## ACADEMIC Cover Letter (350-450 postdoc, 450-650 faculty; 4 paragraphs)
|
||||
|
||||
**P1 — HOOK:** Connection to PI's specific paper + your identity + position. Name the PI.
|
||||
|
||||
**P2 — CURRENT RESEARCH:** Current position with field-context framing (use significance files if available). Future direction: 1-2 sentences MANDATORY.
|
||||
|
||||
**P3 — PRIOR FOUNDATION:** Transferable methodology + collaboration + mentorship. Faculty: departmental fit narrative.
|
||||
|
||||
**P4 — CLOSING:** Forward-looking + name 2-3 faculty for collaboration. Postdoc: "contribute to your research program." Faculty: "build independent research program complementing..."
|
||||
|
||||
---
|
||||
|
||||
## Universal CL Rules
|
||||
|
||||
- Open with a specific reference to their work — avoid generic openers like "I am writing to express my interest"
|
||||
- Add narrative context the CV cannot — motivation, "why this company," research vision
|
||||
- Limit quantified claims to 3-5 per CL
|
||||
- Credentials woven into body paragraphs, not dumped in closing
|
||||
- Active call to action in closing — not passive "Thank you for your consideration"
|
||||
- If pivoting domains: lead with methodology in P1, not apologetic framing
|
||||
|
||||
---
|
||||
|
||||
## Jargon Calibration
|
||||
|
||||
- **Industry:** Assume HR reads first. Minimize subfield jargon.
|
||||
- **National Lab / Academic:** Domain expert reads. Use field vocabulary.
|
||||
|
||||
---
|
||||
|
||||
## Package Reading Rules
|
||||
|
||||
- Resume/CV must stand alone — many hiring managers never read the CL
|
||||
- CL deepens, not introduces — every major CL claim traceable to a resume/CV bullet
|
||||
- No contradictions between documents
|
||||
- Resume + CL = 3 pages | CV + CL = 6-7 pages
|
||||
|
||||
---
|
||||
|
||||
## CL Hook Verification (MANDATORY)
|
||||
|
||||
Before presenting any CL draft to the user, web-search and verify every external reference:
|
||||
- **Academic:** PI name + cited paper title/topic → confirm paper exists, journal, year
|
||||
- **National Lab:** Named program, thrust area, or group publication → confirm it exists
|
||||
- **Industry:** Product name, technology claim, or company news → confirm accuracy
|
||||
|
||||
**If verified:** Note source URL in session file Cover Letter Plan.
|
||||
**If unverified:** Flag as **"UNVERIFIED — please confirm"** in the draft. Never guess names, titles, or journal details.
|
||||
|
||||
---
|
||||
|
||||
## CL Anti-Patterns
|
||||
|
||||
- No generic opener ("I am writing to express my interest...")
|
||||
- No defensive framing ("Despite my background in...")
|
||||
- No credential dump in closing paragraph
|
||||
- No repeating resume bullets verbatim — CL deepens, doesn't duplicate
|
||||
- Limit quantified claims to 3-5 per CL
|
||||
- **Em-dashes in CLs:** Max 2 per document. CLs are prose-heavy and em-dashes compound quickly. Use commas for parenthetical asides, colons for elaborations, periods for new sentences. Paired em-dashes (X --- detail --- Y) should use commas or parentheses instead.
|
||||
- The resume stands alone.
|
||||
- The letter adds motivation, decision context or a meaningful connection.
|
||||
- The voice is direct and natural.
|
||||
- No generic opening, credential dump, defensive gap list or copied resume bullet.
|
||||
- The canonical validator passes for the cover-letter `.tex`.
|
||||
- The compiled document is one readable page unless the employer explicitly requests otherwise.
|
||||
|
||||
@@ -1,78 +1,14 @@
|
||||
# Critical Rules — Compact Re-Read
|
||||
# Critical Rules — Generation Preflight
|
||||
|
||||
> Quick reference for Phase 2 generation. Full rules in `resume_reference.md`.
|
||||
|
||||
## Character Limits
|
||||
|
||||
**Resume (10pt, textwidth=7.5in):**
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 105-111 chars | 117 | -- |
|
||||
| 2 lines | 189-205 chars | 218 | Last line >= 78 chars |
|
||||
|
||||
**CV (11pt, textwidth=7.5in):**
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 88-93 chars | 101 | -- |
|
||||
| 2 lines | 168-182 chars | 190 | Last line >= 65 chars |
|
||||
| 3 lines | 250-268 chars | 280 | Last line >= 65 chars |
|
||||
|
||||
### Variant Naming
|
||||
|
||||
| Variant | Document | Lines | Target Range | HARD MAX | Orphan | Word Target |
|
||||
|---------|----------|-------|-------------|----------|--------|-------------|
|
||||
| Resume-1L | 1/2-page resume | 1 | 105-111 | 117 | -- | ~13 words |
|
||||
| Resume-2L | 2-page resume | 2 | 189-205 | 218 | >= 78 | ~23-25 words |
|
||||
| CV-2L | 5-page CV | 2 | 168-182 | 190 | >= 65 | ~21-22 words |
|
||||
| CV-3L | 5-page CV | 3 | 250-268 | 280 | >= 65 | ~31-32 words |
|
||||
|
||||
## Bold Width Penalty
|
||||
|
||||
Resume (10pt): Effective limit = 119 - (0.5 x bold_char_count)
|
||||
CV (11pt): Effective limit = 91 - (0.25 x bold_char_count)
|
||||
|
||||
## Orphan Rule
|
||||
|
||||
Multi-line bullet last rendered line must fill >= 70% of line width.
|
||||
Resume 2L: last line >= 78 chars. CV 2L: >= 65 chars. CV 3L: >= 65 chars.
|
||||
|
||||
## FIXED Sections — NEVER Modify
|
||||
|
||||
All FIXED sections (internships, education, publications, honors/awards, header block) are set in the template.
|
||||
NEVER change: \vspace values, \geometry settings, .cls formatting, header layout.
|
||||
Only modify VARIABLE sections: Summary, Technical Skills, Experience bullets/headers.
|
||||
|
||||
## Provenance Flags
|
||||
|
||||
See `CLAUDE.md` for your project-specific provenance flags. Common patterns:
|
||||
|
||||
| Item Status | Rule |
|
||||
|-------------|------|
|
||||
| Under review | State journal name: "under review at [Journal]" |
|
||||
| Unpublished | No specific numbers or publication claims |
|
||||
| Internal/proprietary | "infrastructure I developed" — not peer-reviewed |
|
||||
| Preprint only | Always flag provenance |
|
||||
|
||||
## LaTeX Notation Quick-Ref
|
||||
|
||||
| Item | Correct LaTeX | Wrong | Rendered |
|
||||
|------|--------------|-------|----------|
|
||||
| Chemical formulas | `\ce{H2O}` | `H2O`, `H$_2$O` | H₂O |
|
||||
| Superscript labels | `X$^2$Y` | `X2Y` | X²Y |
|
||||
| R² values | `R$^2$=0.99` | `R^2`, `R2` | R² |
|
||||
| Greek letters | `$\alpha$-phase` | `alpha-phase` | α-phase |
|
||||
| Approximately | `$\sim$64` | `~64` (LaTeX non-breaking space!) | ~64 |
|
||||
|
||||
CRITICAL: ~ in LaTeX = non-breaking space. Use $\sim$ for "approximately."
|
||||
|
||||
## KB Corrections
|
||||
|
||||
See `CLAUDE.md` for your project-specific KB corrections log. Always check before generation to avoid re-introducing known errors.
|
||||
|
||||
## Budget Reminder
|
||||
|
||||
Resume: ~20 variable bullets (exact count depends on skills config + immigration line). CV: 19-21 bullets, 45 rendered lines.
|
||||
Resume bullets: ALL 2L. CV bullets: 2L/3L mix OK.
|
||||
**CV Page 1 rule:** First bullet of first experience MUST be 2L. A 3L first bullet overflows page 1.
|
||||
1. Read `resume_builder/canonical/claims.json`; it overrides every narrative source.
|
||||
2. Run `python resume_builder/helpers/validate_resume_system.py` before generation.
|
||||
3. Never use an `output/` resume or cover letter as source material.
|
||||
4. Choose International Tech by default; use Swiss/DACH only for an appropriate employer.
|
||||
5. Put employer, formal title and dates before any narrative framing.
|
||||
6. Use an optional 2--3 line summary, 4--6 skills lines and normally 11--14 evidence-led bullets.
|
||||
7. Mix natural bullet lengths. There is no character target and no page-fill quota.
|
||||
8. Do not list unverified skills, metrics, customers, scale or causal impact.
|
||||
9. Scope Swisscom migration and Data Mesh claims to Dennis's domains, components and products.
|
||||
10. Security Champion means the 2025/2026 team role only; omit by default.
|
||||
11. LLM evidence is configuration/integration level; no LangChain, fine-tuning, formal evaluation or production LLM ownership.
|
||||
12. Run the canonical document validator, compile, inspect and test extracted text before presenting.
|
||||
|
||||
@@ -1,494 +1,99 @@
|
||||
# Critique Framework — Consolidated Multi-Perspective Protocol
|
||||
# Application Critique Framework
|
||||
|
||||
**Purpose:** Single-pass comprehensive critique that catches what would otherwise take multiple passes. Run AFTER generation but BEFORE presenting to user.
|
||||
> Never collapse candidate-role fit and document polish into one score.
|
||||
|
||||
**Key insight:** 85% of score improvement typically comes from ONE thing — domain reframing. The Achievement Reframing Guide handles this during generation. The critique's job is to catch what leaked through, identify remaining gaps, and assess interview likelihood from multiple reader perspectives.
|
||||
## 1. Hard-Gate Audit
|
||||
|
||||
---
|
||||
Classify each JD requirement as **Direct**, **Adjacent**, **Gap**, or **Constraint**.
|
||||
|
||||
## Part 0: Domain-Specialist Lens (generate BEFORE the five perspectives)
|
||||
Flag a **NO-GO** when:
|
||||
|
||||
Before running the five-perspective read-through, construct a domain-specialist lens for THIS specific JD + company. The lens is not a static lookup — it is generated fresh each time by analyzing the JD, the company, and the hiring context.
|
||||
- A minimum/required qualification is a Gap.
|
||||
- A title-defining capability is not Direct.
|
||||
- The level requires absent scope, such as people management, strategic external-account ownership, or company-wide architecture authority.
|
||||
- Location, authorization, clearance, travel, or mandatory relocation is unresolved.
|
||||
|
||||
### Build the Lens
|
||||
An employer's general "apply anyway" message does not erase a title-defining or minimum gap.
|
||||
|
||||
**If a session file exists** (`output/session_<name>.md`) with JD Analysis and Company Context sections, use those as the foundation for the lens instead of re-researching from scratch. Supplement only the elements not already covered (competitive landscape, methodology transfer test, reviewer persona details).
|
||||
## 2. Evidence Fit Score — 0 to 100
|
||||
|
||||
**If no session file exists,** research THIS company + THIS JD from scratch. No pre-built templates. No reference lenses.
|
||||
Score the candidate-role pairing before reading tailored prose.
|
||||
|
||||
**For each critique, produce these 7 elements:**
|
||||
| Dimension | Weight | Question |
|
||||
|---|---:|---|
|
||||
| Required qualifications | 35 | How many are Direct? |
|
||||
| Core responsibilities | 25 | Has Dennis performed the actual function? |
|
||||
| Level and ownership | 15 | Do title, decisions and leadership match? |
|
||||
| Recency and depth | 10 | Is the strongest evidence current and substantial? |
|
||||
| Domain/tool transfer | 10 | Are missing tools genuinely substitutable? |
|
||||
| Practical constraints | 5 | Are location, language, authorization and travel workable? |
|
||||
|
||||
1. **Reviewer persona construction:** Who actually reads this resume? Construct from the JD's reporting line, department name, level, and company context.
|
||||
- Their job title and seniority
|
||||
- What they do daily (what tools they use, what problems they solve)
|
||||
- How many CVs they've read for this posting (estimate from company size + role level)
|
||||
- What they've seen 100 times before that makes them roll their eyes
|
||||
- What would genuinely surprise or impress them
|
||||
- **75--100 Core:** apply when no hard gate fails.
|
||||
- **60--74 Adjacent:** selective; normally no more than one serious preferred gap.
|
||||
- **Below 60 Stretch:** normally do not cold-apply.
|
||||
- Any hard-gate failure overrides the number.
|
||||
|
||||
2. **Company research:** What does this company MAKE, SELL, or RESEARCH?
|
||||
- Core business and revenue model
|
||||
- R&D culture: academic-leaning? patent-driven? product-shipping? mission-driven?
|
||||
- Recent news, strategic priorities, or technology bets (if known)
|
||||
- What vocabulary signals "insider who understands our business" vs "outsider applying generically"?
|
||||
- Note any assumptions and flag uncertainty
|
||||
## 3. Document Quality Score — 0 to 100
|
||||
|
||||
3. **JD deep read — vocabulary extraction:**
|
||||
- Read the JD 3 times. First for requirements, second for culture signals, third for vocabulary.
|
||||
- Extract the 8-10 most important terms/phrases (ranked by: frequency in JD, placement in title/header vs body, and whether they represent binary capabilities vs spectrum skills)
|
||||
- For each: what does THIS company mean by this term? (e.g., "emerging computing paradigms" at a given company might mean quantum/neuromorphic — not just "we use ML")
|
||||
- Identify the JD's implicit hierarchy: what's the #1 thing they need vs nice-to-haves?
|
||||
| Dimension | Weight | Question |
|
||||
|---|---:|---|
|
||||
| Truth and provenance | 25 | Does every claim match canonical scope? |
|
||||
| Information hierarchy | 20 | Are employer, title, dates and strongest evidence obvious? |
|
||||
| Bullet evidence and impact | 20 | Are bullets specific and scoped without invention? |
|
||||
| Relevance and terminology | 15 | Does it cover the JD naturally? |
|
||||
| Skills evidence | 10 | Is every skill evidence-backed and interview-ready? |
|
||||
| Mechanics/readability | 10 | Does it compile, parse and read cleanly? |
|
||||
|
||||
4. **Domain vocabulary map:** For this specific JD, what are the 5-8 vocabulary swaps that separate "outsider applying" from "insider who gets it"? Generate these purely from the JD's language and the company context you just researched.
|
||||
Truth/provenance below 8/10 is an automatic document failure.
|
||||
|
||||
Format:
|
||||
| Resume currently says | Should say for THIS JD | Why |
|
||||
|---|---|---|
|
||||
| [term] | [replacement] | [JD uses this language because...] |
|
||||
## 4. Channel Strength — Separate Rating
|
||||
|
||||
5. **Fatal vs cosmetic gap ranking:** Which missing JD keywords would cause immediate rejection vs which are nice-to-have?
|
||||
- **Fatal gaps:** Binary capabilities the JD requires (e.g., "CFD" — you either do it or you don't), terms in the JD title, or phrases repeated 3+ times
|
||||
- **Serious gaps:** Preferred qualifications that multiple competitive candidates will have
|
||||
- **Cosmetic gaps:** Terms buried in preferred quals that most candidates also won't have
|
||||
- For each gap: can it be bridged truthfully? Or is it a hard limitation of the candidate's background?
|
||||
|
||||
6. **Methodology transfer test:** For each of the candidate's top 5 resume achievements, write one sentence explaining how a domain expert at THIS company would see it mapping to THEIR work.
|
||||
- If you CAN write that sentence naturally: the resume has bridged the gap
|
||||
- If you STRUGGLE to write it: the resume hasn't made the transfer explicit enough
|
||||
- If you CAN'T write it honestly: this is a hard gap, not a reframing problem
|
||||
|
||||
7. **Competitive landscape intuition:** Who else is applying for this role?
|
||||
- What background does the "obvious fit" candidate have?
|
||||
- What does THIS candidate offer that the obvious fit doesn't? (e.g., high-venue publication, cross-scale breadth, platform building)
|
||||
- What does the obvious fit offer that this candidate doesn't? (e.g., domain-specific publications, direct tool experience)
|
||||
- This determines what the resume must EMPHASIZE (unique strengths) and what it must BRIDGE (gaps relative to the obvious fit)
|
||||
|
||||
### Output and persist the lens
|
||||
|
||||
Write out all 7 elements as a structured section at the top of the critique file. This lens then informs EVERY subsequent perspective in Parts 1-6. The five readers (ATS, Recruiter, HR, HM, Technical) all read through this lens — they are people at THIS company, not generic archetypes.
|
||||
|
||||
**Persistence rule:** The lens is built ONCE per JD, during the first critique. If the resume is revised and critiqued again (multi-pass), reuse the same lens — do NOT re-research. The lens lives in the critique output file (`output/critique_[name].md`) and is carried forward across passes. Only rebuild the lens if the JD itself changes.
|
||||
|
||||
---
|
||||
|
||||
## Part 1: Five-Perspective Read-Through
|
||||
|
||||
Read the resume/CV from five different personas, in order. Each persona sees only what they'd actually read in their time window. Flag issues per persona.
|
||||
|
||||
### Perspective 1: ATS Robot (0 seconds — keyword scan)
|
||||
|
||||
**What it does:** Pattern-matches JD keywords against resume text. No context, no synonyms (unless configured), no reading comprehension.
|
||||
|
||||
**Check:**
|
||||
- Extract top 20 JD keywords/phrases (tools, methods, domain terms, soft skills)
|
||||
- For each: verbatim match? Semantic match? Absent?
|
||||
- Count match rate: >=70% = PASS, 60-69% = MARGINAL, <60% = FAIL
|
||||
- Flag any JD keyword that appears 3+ times in JD but 0 times in resume (high-priority gap)
|
||||
- Check domain bridges — do they appear enough to pass a domain-specific ATS filter?
|
||||
|
||||
**Output:** Keyword match table + match rate + top 3 missing keywords that could be added truthfully.
|
||||
|
||||
### Perspective 2: Recruiter Glance (10 seconds)
|
||||
|
||||
**What they read:** Name, current title/employer, education line, header tagline, first 2 lines of summary. Nothing else.
|
||||
|
||||
**What they decide:** "Forward to hiring manager or reject?"
|
||||
|
||||
**Check:**
|
||||
- Does the header tagline use target-domain language (not source-domain)?
|
||||
- Does the current employer signal credibility for this role type?
|
||||
- Does the education line clear the bar? If pedigree gap exists, does the summary compensate in the first 2 lines?
|
||||
- Is there a prestige signal in the first 2 lines (top venue, major metric)?
|
||||
- Would a non-technical recruiter understand what this person does?
|
||||
|
||||
**Output:** "Forward" / "Maybe" / "Reject" + one-sentence reasoning.
|
||||
|
||||
### Perspective 3: HR Screen (30 seconds)
|
||||
|
||||
**What they read:** Full summary + skills section headers + first bullet per position + education.
|
||||
|
||||
**What they decide:** "Does this person meet the basic qualifications? Schedule phone screen?"
|
||||
|
||||
**Check:**
|
||||
- Does the summary bridge from actual domain to target domain? (The bridge sentence is the single most important sentence in the document)
|
||||
- Do skills group NAMES (not just content) signal target-domain relevance?
|
||||
- Does the first bullet under each position deliver the strongest JD-relevant achievement?
|
||||
- Are years of experience consistent with JD requirements?
|
||||
- Immigration status present if required?
|
||||
|
||||
**Output:** "Phone screen" / "Borderline" / "Pass" + one-sentence reasoning.
|
||||
|
||||
### Perspective 4: Hiring Manager Read (2 minutes)
|
||||
|
||||
**What they read:** Everything on the resume/CV. They're a domain expert.
|
||||
|
||||
**What they decide:** "Interview or not? What would I ask?"
|
||||
|
||||
**Check:**
|
||||
- **Methodology transfer:** For each major bullet, can the HM see how this applies to THEIR work? Or do they have to imagine the transfer themselves? (If the HM has to do the translation, you've lost points)
|
||||
- **Narrative arc:** Does the story progress logically? (Typical good arc: deep science → engineering discipline → leadership → tools/platforms)
|
||||
- **Red flags:** Any overclaiming? Any "this person doesn't know what we do" signals? Any keyword stuffing that feels forced?
|
||||
- **Differentiation:** What makes this candidate different from other applicants? Is that differentiator visible?
|
||||
- **Domain gap honesty:** Does the resume acknowledge what it ISN'T (transparent about actual domain) while showing what transfers? Honest reframing beats pretend expertise.
|
||||
|
||||
**Output:** "Interview" / "Maybe" / "No" + top 3 things HM would notice + predicted first interview question.
|
||||
|
||||
### Perspective 5: Deep Technical Reviewer (10 minutes)
|
||||
|
||||
**What they do:** Read every bullet carefully. Check publications. Assess truthfulness. Look for inconsistencies.
|
||||
|
||||
**Check:**
|
||||
- **Truthfulness audit:** For each quantitative claim, is it verified against extractions/experience files?
|
||||
- **Provenance flags:** All works-in-progress or under-review items properly flagged?
|
||||
- **Verb discipline:** Contributing-author bullets use hedged verbs? Full-ownership verbs only where justified?
|
||||
- **Publication coherence:** Do pub tags match the resume's domain framing? Do paper titles (which can't be changed) create cognitive dissonance with the reframed bullets?
|
||||
- **Internal consistency:** Does the summary match the bullets? Does the cover letter match the resume?
|
||||
- **Over-saturation:** Any keyword repeated >8 times? (Borderline at 6-8, concern at 9+)
|
||||
|
||||
**Output:** Truthfulness table (claim → verified? → source) + any inconsistencies found.
|
||||
|
||||
---
|
||||
|
||||
## Part 2: Eight-Dimension Scoring
|
||||
|
||||
Score each dimension independently, then compute weighted total.
|
||||
|
||||
| # | Dimension | Weight | What to Assess |
|
||||
|---|-----------|--------|---------------|
|
||||
| 1 | ATS Keyword Match | 15% | JD keyword coverage rate, verbatim vs semantic, missing high-value terms |
|
||||
| 2 | Summary | 10% | Bridge sentence, target-domain language, prestige signals, forward-looking intent |
|
||||
| 3 | Skills Section | 10% | Group names (domain signal), content relevance, bold accuracy, no wasted entries |
|
||||
| 4 | Bullet Quality | 25% | Per-bullet JD alignment (HIGH/MEDIUM/LOW), reframing quality, quantification, action verbs |
|
||||
| 5 | Publication Selection | 10% | Venue prestige, tag relevance, first-author ratio, domain gap acknowledgment |
|
||||
| 6 | Narrative Coherence | 15% | Header-to-footer story, domain thread count, first-impression timing |
|
||||
| 7 | Page Fill & Visual | 5% | Budget compliance, orphan check, compile clean, slack acceptable |
|
||||
| 8 | Credibility Signals | 10% | Venue quality, metrics (papers, citations, awards), platform adoption, leadership evidence |
|
||||
|
||||
**Scoring rubric per dimension:**
|
||||
- 9-10: Essentially optimal for this candidate-JD pairing
|
||||
- 8-8.5: Strong, minor improvements possible but diminishing returns
|
||||
- 7-7.5: Good but identifiable gaps that reframing could close
|
||||
- 6-6.5: Significant gaps — missing domain bridge, wrong vocabulary, weak bullets
|
||||
- <6: Major problems — wrong role framing, overclaiming, format violations
|
||||
|
||||
**Overall score interpretation:**
|
||||
- 85+: At or near ceiling. Submit.
|
||||
- 80-84: Strong. 1-2 targeted improvements could push to ceiling.
|
||||
- 75-79: Good foundation but missing domain reframing or key bullets.
|
||||
- 70-74: First-draft quality. Needs systematic reframing pass.
|
||||
- <70: Fundamental issues (wrong role type, missing sections, accuracy problems).
|
||||
|
||||
---
|
||||
|
||||
## Part 3: Interview Likelihood Assessment
|
||||
|
||||
After scoring, assess interview probability from each reader's perspective.
|
||||
|
||||
### Assessment Matrix
|
||||
|
||||
| Reader | Time | Question They Ask | Likely Outcome |
|
||||
|--------|------|-------------------|----------------|
|
||||
| ATS | 0 sec | "Do keywords match?" | PASS / FAIL |
|
||||
| Recruiter | 10 sec | "Credible for this level?" | FORWARD / REJECT |
|
||||
| HR | 30 sec | "Meets basic quals?" | PHONE SCREEN / PASS |
|
||||
| Hiring Manager | 2 min | "Would I learn something in an interview?" | INTERVIEW / MAYBE / NO |
|
||||
| Technical Panel | 10 min | "Can this person do the work?" | STRONG YES / YES / CONCERNS |
|
||||
|
||||
For each reader, give a probability estimate (e.g., "80% forward") and the single factor that most influences their decision.
|
||||
|
||||
### Ceiling Analysis
|
||||
|
||||
| Scenario | Estimated Score |
|
||||
|----------|----------------|
|
||||
| Current resume | [X] |
|
||||
| + Top 3 improvements applied | [X + delta] |
|
||||
| Theoretical max (this candidate + this JD) | [X_max] |
|
||||
| Hard ceiling (structural background gap) | [X_ceiling] |
|
||||
| What would close the gap | [e.g., "1 domain publication → +3 pts"] |
|
||||
|
||||
---
|
||||
|
||||
## Part 4: Actionable Improvements (Ranked)
|
||||
|
||||
List ALL identified improvements in three tiers:
|
||||
|
||||
### Tier 1: HIGH IMPACT (each worth >= 1 point)
|
||||
These are the improvements that move the score meaningfully. Typically:
|
||||
- Domain reframing that was missed during generation
|
||||
- Missing JD keyword that can be added truthfully
|
||||
- Bullet swap (weak bullet → stronger unused achievement)
|
||||
- Summary bridge sentence missing or weak
|
||||
|
||||
For each: Current text → Proposed text → Why → Expected point impact.
|
||||
|
||||
### Tier 2: MEDIUM IMPACT (each worth 0.3-0.9 points)
|
||||
- Minor reframing (vocabulary swap)
|
||||
- Publication tag refinements
|
||||
- Skills group name adjustments
|
||||
- One additional keyword insertion
|
||||
|
||||
### Tier 3: COSMETIC / DIMINISHING RETURNS (each worth < 0.3 points)
|
||||
- Keyword saturation reduction
|
||||
- Minor wording polish
|
||||
- Alternative pub selection
|
||||
|
||||
### Verdict
|
||||
State clearly: "Apply Tier 1 changes. Tier 2 are optional. Tier 3 are not worth the edit."
|
||||
|
||||
---
|
||||
|
||||
## Part 5: Interview Bridge Points
|
||||
|
||||
For each major resume topic, provide the verbal bridge the candidate should use if asked in an interview. Format:
|
||||
|
||||
| Resume Topic | Target Domain Equivalent | Opening Line for Interview |
|
||||
|---|---|---|
|
||||
| [Achievement X] | [How it maps to target] | "The same methodology I used for X applies directly to Y because..." |
|
||||
|
||||
This section converts resume claims into interview talking points. Include 5-7 bridges covering highlights from all positions.
|
||||
|
||||
---
|
||||
|
||||
## Part 6: Cover Letter Critique (Context-Aware)
|
||||
|
||||
If a cover letter was generated in the same session, run all checks below. Detect institution type first: Industry / National Lab / Academic.
|
||||
|
||||
### 6A. Anti-Pattern Checklist
|
||||
- [ ] Does NOT open with "I am writing to express my interest" or similar generic opener
|
||||
- [ ] Does NOT rehash CV bullet points in prose (adds narrative context instead)
|
||||
- [ ] Names a specific PI/group/product/paper from the target institution
|
||||
- [ ] Has a clear "why THIS position at THIS institution" sentence (not generic)
|
||||
- [ ] Strongest qualification appears in paragraph 1, not buried in P3/P4
|
||||
- [ ] No defensive/apologetic language about background gaps ("Although my background is not in...")
|
||||
- [ ] Closing has active call to action, not passive "Thank you for your consideration"
|
||||
- [ ] Credentials (pubs, awards) woven into body paragraphs, not dumped in closing
|
||||
|
||||
### 6B. Tailoring Signal Checklist
|
||||
- [ ] Names specific PI/group/program (academic/lab) or product/technology (industry)
|
||||
- [ ] Uses at least 3 JD terms that supplement (not just duplicate) resume keywords
|
||||
- [ ] References institution's mission, culture, or recent work
|
||||
- [ ] Proposes specific connection between candidate's method and their need
|
||||
- [ ] Correctly identifies institutional type and adjusts tone/emphasis accordingly
|
||||
|
||||
### 6C. Context-Specific Checks
|
||||
|
||||
**Industry:**
|
||||
- [ ] Business value translation present for each achievement? ("enabling X, reducing Y")
|
||||
- [ ] "Why industry" addressed positively? (not "leaving academia")
|
||||
- [ ] Jargon minimized for HR/recruiter first reader?
|
||||
|
||||
**National Lab:**
|
||||
- [ ] Mission alignment in P1? (specific programmatic thrust, not generic "clean energy")
|
||||
- [ ] HPC/collaboration signals present?
|
||||
- [ ] Lab vocabulary used? ("thrust area," "programmatic direction," "capability development")
|
||||
|
||||
**Academic:**
|
||||
- [ ] PI named with specific research connection?
|
||||
- [ ] Future research direction included? (mandatory even for postdoc, 1-2 sentences minimum)
|
||||
- [ ] Departmental fit articulated? ("Your department's strength in X...")
|
||||
|
||||
### 6D. CL ATS Keyword Check
|
||||
- Extract 10 high-priority JD keywords
|
||||
- Check how many appear in CL (target: 5-8 that supplement resume keywords)
|
||||
- Industry/lab: keywords matter (~60% of large employers use ATS/AI on CLs). Academic: less critical.
|
||||
|
||||
### 6E. Structural Checks
|
||||
- [ ] **Consistency:** Key claims match resume bullets (no contradictions, no unsupported new claims)
|
||||
- [ ] **Complementarity:** Adds narrative context the resume cannot (motivation, "why this company," research vision)
|
||||
- [ ] **Word count:** Industry 250-300, Lab 350-450, Academic postdoc 350-450, Academic faculty 450-650
|
||||
- [ ] **Tone match:** Industry = results-driven, Lab = mission-aligned, Academic = scholarly/forward-looking
|
||||
- [ ] **Quantification:** 3-5 quantified claims (more = fact sheet, fewer = vague)
|
||||
- [ ] **Domain pivot:** If pivoting, leads with methodology in P1, not apologetic framing
|
||||
|
||||
### 6F. Package Cohesion Check
|
||||
- [ ] **Resume/CV stands alone:** If CL were deleted, does the resume/CV independently earn an interview? No critical context only in CL.
|
||||
- [ ] **CL deepens, not introduces:** Every major CL claim is traceable to a resume/CV bullet. CL adds context/significance, not new achievements.
|
||||
- [ ] **No contradictions:** Dates, metrics, claims, and framing consistent across both documents.
|
||||
- [ ] **Complement, not repeat:** CL is NOT a prose restatement of resume bullets. It adds motivation, "why this institution," research vision, methodology arc.
|
||||
- [ ] **Page budget:** Resume+CL = 3pp, CV+CL = 6-7pp. If CV CL is 2 pages, page 2 >= half filled before signature.
|
||||
|
||||
---
|
||||
|
||||
## Critique Output Template
|
||||
|
||||
```markdown
|
||||
# Critique: [Company] [Role Title] ([Job ID])
|
||||
|
||||
**Resume/CV File:** `output/[filename].tex`
|
||||
**Date:** [date]
|
||||
|
||||
---
|
||||
|
||||
## Domain-Specialist Lens (researched for this JD)
|
||||
|
||||
### Reviewer Persona
|
||||
[Constructed persona — who reads this, what they do daily, what they've seen before]
|
||||
|
||||
### Company Context
|
||||
[What they make/do, R&D culture, strategic priorities]
|
||||
|
||||
### JD Vocabulary Extraction (top 8-10 terms, ranked)
|
||||
| # | JD Term | Frequency | Meaning at THIS Company | Resume Match? |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [term] | [N times] | [what they mean by it] | YES/PARTIAL/NO |
|
||||
|
||||
### Domain Vocabulary Map
|
||||
| Resume Currently Says | Should Say for This JD | Why |
|
||||
|---|---|---|
|
||||
| [term] | [replacement] | [reasoning] |
|
||||
|
||||
### Gap Ranking
|
||||
- **Fatal:** [gaps that cause rejection]
|
||||
- **Serious:** [gaps competitive candidates won't have]
|
||||
- **Cosmetic:** [nice-to-have, most candidates also miss]
|
||||
|
||||
### Methodology Transfer Test
|
||||
| Achievement | How THIS Company's Expert Sees It |
|
||||
| Rating | Evidence |
|
||||
|---|---|
|
||||
| [achievement] | "[one sentence transfer explanation]" |
|
||||
| Strong | Referral/internal sponsor plus targeted hiring-team contact |
|
||||
| Moderate | Recruiter conversation, known hiring manager or warm introduction |
|
||||
| Weak | Tailored cold application only |
|
||||
|
||||
### Competitive Landscape
|
||||
- **Obvious fit candidate:** [description]
|
||||
- **Our advantage:** [what we offer they don't]
|
||||
- **Their advantage:** [what they offer we don't]
|
||||
Do not mix channel strength into either score. A polished cold application remains a weak channel.
|
||||
|
||||
---
|
||||
## 5. Competitive Read
|
||||
|
||||
## Five-Perspective Read-Through
|
||||
Describe the obvious-fit competitor and compare direct function, cloud/tool ecosystem, domain, level/scope, and access to the team. State Dennis's real advantage and the competitor's real advantage. Do not value a bridge as highly as direct evidence.
|
||||
|
||||
### ATS Robot (keyword scan)
|
||||
[Keyword match table]
|
||||
**Match rate:** X/20 = Y%
|
||||
## 6. Reader Sequence
|
||||
|
||||
### Recruiter Glance (10 seconds)
|
||||
**Verdict:** [Forward/Maybe/Reject]
|
||||
[Reasoning]
|
||||
Use verdicts, not invented probability percentages:
|
||||
|
||||
### HR Screen (30 seconds)
|
||||
**Verdict:** [Phone screen/Borderline/Pass]
|
||||
[Reasoning]
|
||||
1. **Parser/ATS:** extraction and relevant terms.
|
||||
2. **Recruiter glance:** Forward / Borderline / Reject, with one reason.
|
||||
3. **Hiring manager:** Interview / Maybe / No, focused on functional evidence.
|
||||
4. **Technical reviewer:** credibility and likely first challenge.
|
||||
|
||||
### Hiring Manager (2 minutes)
|
||||
**Verdict:** [Interview/Maybe/No]
|
||||
**Top 3 observations:**
|
||||
1. [What they notice first]
|
||||
2. [What impresses or concerns them]
|
||||
3. [What they'd ask about]
|
||||
**Predicted first interview question:** "[question]"
|
||||
## 7. Claim Audit
|
||||
|
||||
### Technical Reviewer (10 minutes)
|
||||
**Truthfulness:** [All verified / N concerns]
|
||||
**Consistency:** [Clean / N issues]
|
||||
Audit every material summary, skills and high-value bullet claim:
|
||||
|
||||
---
|
||||
|
||||
## Eight-Dimension Scoring
|
||||
|
||||
| Dimension | Score | Weight | Weighted | Notes |
|
||||
| Claim | Canonical ID/evidence | Direct/Adjacent | Safe? | Fix |
|
||||
|---|---|---|---|---|
|
||||
| ATS Keywords | X/10 | 15% | X.XX | [1-line note] |
|
||||
| Summary | X/10 | 10% | X.XX | |
|
||||
| Skills Section | X/10 | 10% | X.XX | |
|
||||
| Bullet Quality | X/10 | 25% | X.XX | |
|
||||
| Publications | X/10 | 10% | X.XX | |
|
||||
| Narrative Coherence | X/10 | 15% | X.XX | |
|
||||
| Page Fill & Visual | X/10 | 5% | X.XX | |
|
||||
| Credibility Signals | X/10 | 10% | X.XX | |
|
||||
| **Total** | | **100%** | **XX.X** | |
|
||||
|
||||
---
|
||||
Run `validate_resume_system.py --document` first. Any validator failure is Tier 1.
|
||||
|
||||
## Interview Likelihood
|
||||
## 8. Cover Letter
|
||||
|
||||
| Reader | Probability | Key Factor |
|
||||
|--------|------------|------------|
|
||||
| ATS | X% | [factor] |
|
||||
| Recruiter (10s) | X% | [factor] |
|
||||
| HR (30s) | X% | [factor] |
|
||||
| Hiring Manager (2m) | X% | [factor] |
|
||||
| Technical Panel (10m) | X% | [factor] |
|
||||
If present, assess whether the letter was useful under the decision gate, adds information, uses current first-party hooks, and contains only canonical/resume claims. Consider whether deleting it would improve the application.
|
||||
|
||||
**Ceiling:** Current [X] → Max achievable [Y] → Hard ceiling [Z]
|
||||
If absent, assess whether the resume stands alone. Do not penalize an optional missing letter.
|
||||
|
||||
---
|
||||
## 9. Required Critique Output
|
||||
|
||||
## Actionable Improvements
|
||||
1. Fit verdict and hard-gate failures.
|
||||
2. Evidence Fit score with dimension table.
|
||||
3. Document Quality score with dimension table.
|
||||
4. Channel Strength rating.
|
||||
5. Competitive read and reader sequence.
|
||||
6. Claim audit.
|
||||
7. Tier 1 truth/fit fixes and Tier 2 presentation improvements.
|
||||
8. Cover-letter decision/critique.
|
||||
9. Mechanical verification.
|
||||
|
||||
### Tier 1 (HIGH — do these)
|
||||
1. [Change] — [+N pts]
|
||||
|
||||
### Tier 2 (MEDIUM — optional)
|
||||
1. [Change] — [+N pts]
|
||||
|
||||
### Tier 3 (COSMETIC — skip)
|
||||
1. [Change]
|
||||
|
||||
---
|
||||
|
||||
## Interview Bridge Points
|
||||
|
||||
| Resume Topic | Target Equivalent | Opening Line |
|
||||
|---|---|---|
|
||||
| [topic] | [equivalent] | "[bridge statement]" |
|
||||
|
||||
---
|
||||
|
||||
*End of critique.*
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Part 6G: AI Fingerprint Scan
|
||||
|
||||
Run the 12-item checklist from `resume_builder/support/ai_fingerprint_rules.md` Section 6. Key scans:
|
||||
- Count em-dashes (`---`) in full document — flag if >2
|
||||
- Scan all bullet endings for -ing analysis phrases (the #1 structural AI marker)
|
||||
- Search for any Tier 1 banned word (delve, tapestry, multifaceted, pivotal, etc.)
|
||||
- Check CL for generic opener and uniform sentence length
|
||||
|
||||
Any failure is a Tier 1 fix in Part 4.
|
||||
|
||||
---
|
||||
|
||||
## Part 7: Post-Generation Verification
|
||||
|
||||
Final mechanical checklist. Run AFTER all other critique parts. These are pass/fail checks, not scored dimensions.
|
||||
|
||||
### Mechanical Checks
|
||||
- [ ] All bullets within char limits (no OVER violations from char_count.py)
|
||||
- [ ] All multi-line bullets pass orphan check (last line >= 70% fill)
|
||||
- [ ] Page fill within budget (resume: <= 3 lines white space on page 2; CV: 45 rendered bullet lines)
|
||||
- [ ] No ordering errors in bullet sequencing
|
||||
|
||||
### Content Checks
|
||||
- [ ] ATS keywords present (>= 70% match rate)
|
||||
- [ ] All provenance flags correct (see CLAUDE.md for project-specific flags)
|
||||
- [ ] No forbidden terms (see CLAUDE.md for project-specific corrections)
|
||||
- [ ] No inflation (contributing-author verbs hedged, no false claims)
|
||||
- [ ] Publication entries match pub_metadata.md (titles, journals, years)
|
||||
- [ ] Cover letter claims traceable to resume/CV bullets
|
||||
|
||||
### Structural Checks
|
||||
- [ ] Company/institution name spelled correctly throughout
|
||||
- [ ] .tex file has complete preamble (will compile standalone)
|
||||
- [ ] Date format consistent (Mon YYYY -- Mon YYYY)
|
||||
- [ ] Email address is correct (see CLAUDE.md for configured email)
|
||||
- [ ] Page count correct after compile (resume=2, CV=5)
|
||||
|
||||
**If any check fails, flag it as a Tier 1 fix in Part 4.**
|
||||
|
||||
---
|
||||
|
||||
## When to Use Multi-Pass vs Single-Pass
|
||||
|
||||
**Single pass (this framework):** Use for ALL new generations going forward. The Achievement Reframing Guide ensures the first draft is already reframed, so one comprehensive critique should catch remaining issues.
|
||||
|
||||
**Multi-pass (iterative refinement):** Only needed when:
|
||||
- Score is below 80 after first critique (indicates systematic reframing failure)
|
||||
- User requests specific changes and wants re-evaluation
|
||||
- A fundamentally new approach is tried (e.g., switching role-type framing mid-stream)
|
||||
|
||||
When doing multi-pass, each subsequent critique should:
|
||||
1. State "Changes Since Pass N" at the top
|
||||
2. Only re-score dimensions that changed
|
||||
3. Track score trajectory (Pass 1 → Pass 2 → ...)
|
||||
4. Declare ceiling when score stops moving (typically after 2-3 passes with the reframing guide)
|
||||
Never issue a single overall score or call a package submit-ready solely because Document Quality is high.
|
||||
|
||||
@@ -1,315 +1,127 @@
|
||||
# Resume & CV Generation — Reference
|
||||
# Resume Generation Reference
|
||||
|
||||
> Resume/CV-specific rules. Read by `/make-resume` and `/edit-resume`.
|
||||
> Companion files: `cl_reference.md` (CL rules), `critical_rules.md` (compact re-read).
|
||||
> Shared rules (provenance, anti-fabrication, LaTeX notation): `CLAUDE.md`
|
||||
> Default audience: International Tech employers hiring in Europe.
|
||||
> Canonical authority: `resume_builder/canonical/claims.json`.
|
||||
|
||||
---
|
||||
## 1. Audience Profile Selection
|
||||
|
||||
## QUICK BUDGET CARD (read this FIRST)
|
||||
Choose before planning content:
|
||||
|
||||
```
|
||||
RESUME (2-page, resume.cls): ~20 variable bullets | Skills 13 lines (4-3-2-2-2) | 5 pubs | 5 awards
|
||||
CV (5-page, cv.cls): 19-21 variable bullets (45 rendered lines) | Skills 17 lines (4-4-3-3-3) | all pubs | 6 awards
|
||||
| Profile | Use when | Defaults |
|
||||
|---|---|---|
|
||||
| International Tech | FAANG, US-tech, international scale-up, English-language engineering role | 2 pages; no photo or demographic data; conventional headers |
|
||||
| Swiss/DACH | Traditional Swiss/German/Austrian employer or explicit local dossier request | 2 pages normally; optional photo only by user choice; references/certificates separate |
|
||||
| Employer-specific | NATO, public sector, academic or a mandated portal format | Follow the employer's explicit rules |
|
||||
|
||||
Resume bullet: max 2 rendered lines | 1L: 105-111 chars | 2L: 189-205 chars (target ~200)
|
||||
CV bullet: max 3 rendered lines | 2L: 168-182 chars | 3L: 250-268 chars (target ~175/~260)
|
||||
International Tech is the default even when the role is physically located in Europe.
|
||||
|
||||
Cover letter: Resume = 1 page (250-300 words) | CV = 1-2 pages (350-450 words)
|
||||
Full package: Resume + CL = 3 pages | CV + CL = 6-7 pages
|
||||
```
|
||||
## 2. Evidence Preflight
|
||||
|
||||
**If your bullet count doesn't match the budget above, STOP and fix before generating.**
|
||||
Before selecting or writing content:
|
||||
|
||||
---
|
||||
1. Read `resume_builder/canonical/claims.json` completely.
|
||||
2. Run `python resume_builder/helpers/validate_resume_system.py`.
|
||||
3. Read `config.md` corrections and the relevant experience files.
|
||||
4. Never use a historical output as a source or starting draft.
|
||||
5. Apply each canonical claim's scope, allowed verbs and forbidden phrases.
|
||||
6. If a metric is unverified, omit it or ask the user. Never estimate it.
|
||||
|
||||
## Section-by-Section Specs
|
||||
Accuracy remains: **Accuracy > Relevance > Impact > ATS > Brevity**.
|
||||
|
||||
### Resume (resume.cls)
|
||||
## 3. Information Hierarchy
|
||||
|
||||
1. **Summary** (bundle Section 2): 4-5 sentences, exactly 5 body lines. 500-555 rendered chars (HARD MAX 570, floor ~490). Orphan: last line >= 78 chars.
|
||||
- **Headline Tagline:** 80-95 rendered chars, exactly 1 line.
|
||||
2. **Technical Skills** (bundle Section 4 + skills_taxonomy.md): Format C — 5 groups, default 4-3-2-2-2 (13 lines). Each dash = exactly 1 rendered line. Bold penalty: 119 - (0.5 x bold_chars).
|
||||
3. **Research Experience** (experience files + achievement_reframing_guide.md): Write bullets FRESH per Experience Bullet Writing Protocol (below). Max 2 rendered lines per bullet. Run char_count.py after each position.
|
||||
- resume.cls: Args 3+4 on SAME italic line
|
||||
- **After all positions: verify total variable bullet count matches budget**
|
||||
4. **Education**: FIXED — copy from template
|
||||
5. **Selected Publications** (pub_metadata.md): 5 publications scored per JD. Copy FIXED author+journal blocks, GENERATE JD-shortened title + tags. 2 rendered lines hard limit per entry.
|
||||
6. **Honors & Awards**: FIXED — items from template
|
||||
7. **Immigration notice**: FIXED for USA JDs. Delete for non-USA JDs.
|
||||
The reader must see these items in this order:
|
||||
|
||||
### CV (cv.cls)
|
||||
1. Name, professional identity, contact/location/work authorization.
|
||||
2. Optional 2--3 line summary.
|
||||
3. Four to six compact skills lines.
|
||||
4. Professional Experience, reverse chronological.
|
||||
5. Education and relevant certifications once.
|
||||
|
||||
1. **Research Summary** (bundle Section 2): Exactly 6 body lines. 500-540 rendered chars (HARD MAX 545, floor ~490). Orphan: last line >= 62 chars. Technical identity, not narrative.
|
||||
2. **Education**: FIXED — copy verbatim from cv_template.tex
|
||||
3. **Technical Expertise** (bundle Section 4 + skills_taxonomy.md): 4-4-3-3-3 ALWAYS (17 body lines). Bold penalty: 91 - (0.25 x bold_chars).
|
||||
4. **Research Experience**: Exactly 45 rendered bullet lines across 19-21 bullets, plus sub-theme lines.
|
||||
- cv.cls: Args 3+4 on SEPARATE italic lines
|
||||
- Max 3 rendered lines per bullet. CV-2L <= 190, CV-3L <= 280 (target ~175/~260)
|
||||
- **Running total must reach exactly 45 rendered lines**
|
||||
5. **Fellowships & Honors**: FIXED — items from cv_template.tex
|
||||
6. **Publications**: FIXED — full list from cv_template.tex
|
||||
7-10. **Presentations, Mentorship, Collaborations, Computing**: All FIXED from cv_template.tex
|
||||
Every experience header uses:
|
||||
|
||||
---
|
||||
- Bold employer first.
|
||||
- Dates on the same line.
|
||||
- Formal or transparent normalized title second.
|
||||
- Location second.
|
||||
|
||||
## Character Limits (HARD STOPS — ZERO TOLERANCE)
|
||||
Do not place a JD-tailored marketing theme before the employer/title. Never turn a target phrase into a historical credential.
|
||||
|
||||
**MANDATORY: Count rendered characters for EVERY bullet BEFORE writing it.** Do not write a bullet and check afterward — pre-calculate the count. If a bullet exceeds the limit, rewrite it BEFORE moving to the next bullet. This is not a post-generation check; it is a per-bullet gate.
|
||||
Work authorization is optional in the visible header. Dennis is a German/EU
|
||||
citizen with a Swiss B residence permit and requires no visa or employer
|
||||
sponsorship. Use the shortest useful form only when it resolves uncertainty or
|
||||
the application explicitly asks; otherwise location and contact details are enough.
|
||||
|
||||
**How to count rendered characters:**
|
||||
Strip all LaTeX markup before counting: `\textbf{X}` -> X, `\textit{X}` -> X, `\ce{X}` -> X, `$\beta$` -> 1 char, `\sim` -> 1 char, `$<$` -> 1 char, `$^\dagger$` -> 1 char, `--` -> 1 char (en-dash), `\underline{X}` -> X, `\href{url}{text}` -> text only.
|
||||
Count: all remaining characters including spaces.
|
||||
## 4. Content Allocation
|
||||
|
||||
**Resume (10pt, textwidth=7.5in):**
|
||||
Use relevance and evidence, not page-filling quotas. For Dennis's normal 2-page resume:
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 105-111 chars | 117 | -- |
|
||||
| 2 lines | 189-205 chars | 218 | Last line >= 78 chars |
|
||||
- Swisscom: 4--5 bullets.
|
||||
- Bosch: 3--4 bullets.
|
||||
- Fraunhofer, Vizrt and Generali: 0--1 bullet each.
|
||||
- Capgemini/Bundeswehr: include only when directly relevant.
|
||||
- Typical total: 11--14 bullets. This is a guide, not a requirement.
|
||||
|
||||
**CV (11pt, textwidth=7.5in):**
|
||||
A strong shorter resume is better than a full page padded with weak evidence. White space is acceptable when hierarchy and readability are strong.
|
||||
|
||||
| Target Lines | Rendered Char Range | HARD MAX | Orphan Threshold |
|
||||
|-------|---------------|---------|------------------|
|
||||
| 1 line | 88-93 chars | 101 | -- |
|
||||
| 2 lines | 168-182 chars | 190 | Last line >= 65 chars |
|
||||
| 3 lines | 250-268 chars | 280 | Last line >= 65 chars |
|
||||
## 5. Summary
|
||||
|
||||
> **WARNING: AIM FOR THE MIDDLE OF THE TARGET RANGE — NOT THE HARD MAX.**
|
||||
> A Resume-2L bullet should target ~200 chars, not 218. A CV-2L should target ~175, not 190.
|
||||
> The hard max exists as a safety valve, not a target. Proportional fonts have variable char widths —
|
||||
> a bullet at the hard max WILL overflow if it contains wide characters (m, w, W, capitals, em-dashes).
|
||||
> Em-dash (---) counts as 1 char but renders ~2x wide. Budget 2 extra chars per em-dash in the bullet.
|
||||
The summary is optional. When used:
|
||||
|
||||
### Variant Naming
|
||||
- Keep it to 2--3 rendered lines and normally two sentences.
|
||||
- State the demonstrated professional identity and two strongest proof points.
|
||||
- Do not state the desired role as if it were prior experience.
|
||||
- Avoid credential lists and unsupported scale claims.
|
||||
|
||||
| Variant | Document | Lines | Target Range | HARD MAX | Orphan | Word Target |
|
||||
|---------|----------|-------|-------------|----------|--------|-------------|
|
||||
| Resume-1L | 1/2-page resume | 1 | 105-111 | 117 | -- | ~13 words |
|
||||
| Resume-2L | 2-page resume | 2 | 189-205 | 218 | >= 78 | ~23-25 words |
|
||||
| CV-2L | 5-page CV | 2 | 168-182 | 190 | >= 65 | ~21-22 words |
|
||||
| CV-3L | 5-page CV | 3 | 250-268 | 280 | >= 65 | ~31-32 words |
|
||||
## 6. Skills
|
||||
|
||||
> **Word targets** are approximate first-draft heuristics for prose bullets (~7.9 chars/word). After drafting, always verify with precise char count. Skills dashes: NO word proxy -- use iterative char count only (technical tool lists average ~11 chars/word).
|
||||
- Use 4--6 compact lines from `skills_taxonomy.md`.
|
||||
- List only canonical `allowed` or context-appropriate `allowed-with-context` skills.
|
||||
- Certification-only skills stay in certification context.
|
||||
- Do not use Expert/Proficient/Familiar self-ratings.
|
||||
- Do not list a technology merely because it appears in the JD.
|
||||
- Be ready with a specific example for every listed skill.
|
||||
|
||||
### Bold Width Penalty (COMPILE-VERIFIED)
|
||||
## 7. Bullet Writing
|
||||
|
||||
Bold characters render wider than normal text. Adjust effective char limits accordingly.
|
||||
Write bullets from canonical facts and experience records, not from old resume wording.
|
||||
|
||||
**Resume (10pt):** Effective limit = 119 - (0.5 x bold_char_count)
|
||||
- 0 bold: safe up to 119 chars/line
|
||||
- 2-4 bold tools (~10-25 bold chars): 107-112 effective --> use 105-111 as default
|
||||
- 5+ bold tools (~28+ bold chars): ~105 effective --> tighten to 99-105
|
||||
Each bullet should make clear:
|
||||
|
||||
**CV (11pt):** Effective limit = 91 - (0.25 x bold_char_count)
|
||||
- 0 bold: safe up to 91 chars/line (HARD MAX 93)
|
||||
- 2-3 bold tools (~10-18 bold chars): 85-88 effective --> use 83-88 as default
|
||||
- 5+ bold tools (~28+ bold chars): 83-85 effective --> tighten to 80-85
|
||||
- what Dennis did;
|
||||
- the system/domain and relevant scope;
|
||||
- why the work mattered, only when evidence supports that result.
|
||||
|
||||
Practical rule: count bold characters, subtract half (resume) or quarter (CV) from base limit.
|
||||
Natural one-, two- and three-line bullets may be mixed. There are no target character bands. Flag only bullets that are genuinely difficult to scan (normally over about 35 words or containing more than two distinct accomplishments).
|
||||
|
||||
**Per-bullet enforcement protocol:**
|
||||
1. Write the bullet text (LaTeX source)
|
||||
2. Strip all markup mentally → count rendered chars
|
||||
3. If count > HARD MAX → rewrite immediately (do NOT proceed)
|
||||
4. If multi-line and last line < orphan threshold → rewrite to fill or shorten
|
||||
5. **Aim for the middle of the range**, not the max. A bullet at 220 rendered chars (resume 2L) is risky — target ~200.
|
||||
Use metrics only when verified. Company size, customer names, generic industry volumes and market economics are context, not personal impact.
|
||||
|
||||
**Orphan rule:** For any multi-line bullet, the last rendered line must fill at least 70% of the line width. If it doesn't, rewrite to either fill the line or shorten to one fewer line.
|
||||
## 8. Titles and Seniority
|
||||
|
||||
### Char Verification Protocol (EVERY written element)
|
||||
- Preserve official titles when recognizable.
|
||||
- A transparent normalized parenthetical is allowed, e.g. `Senior Engineer, Data Analysis (Data & ML Engineering)`.
|
||||
- Do not self-promote to Principal, Architect, Manager, SRE, Forward Deployed Engineer or Consultant without verified title/function evidence.
|
||||
- Preserve promotion timing at Swisscom.
|
||||
|
||||
For each element you write from scratch or modify (summary, skills dash, tagline, any edited bullet):
|
||||
## 9. Mechanical Verification
|
||||
|
||||
1. **DRAFT** -- Use word-count target as initial guess (prose only, NOT skills dashes)
|
||||
2. **STRIP** -- Remove LaTeX markup (\textbf{}, \ce{}, $..$) to get rendered text
|
||||
3. **COUNT** -- Count rendered characters precisely. In Claude Code, use the helper: `python3 resume_builder/helpers/char_count.py "bullet text"` or verify a full .tex file: `python3 resume_builder/helpers/char_count.py -f [resume|cv] output/file.tex`
|
||||
4. **CHECK** -- Compare against target range (use tighter targets from Variant Naming table, not HARD MAX)
|
||||
5. **FIX** -- If OVER and attempts < 3: rewrite/trim, go to step 2
|
||||
6. **FLAG** -- If OVER after 3 attempts: add `% OVER LIMIT: [N] chars, target [M]` LaTeX comment, move on
|
||||
7. **PASS** -- If within range: move to next element
|
||||
After generation:
|
||||
|
||||
**RULE: Never move to the next section with a violation in the current one. Fix first, then proceed.**
|
||||
1. Run `python resume_builder/helpers/validate_resume_system.py --document <file.tex>`.
|
||||
2. Compile with the local LaTeX distribution.
|
||||
3. Verify exactly 2 pages unless the chosen profile explicitly allows otherwise.
|
||||
4. Extract text with `pdftotext` and confirm employer/title/date order.
|
||||
5. Inspect the rendered PDF: no clipping, overlap, tiny text, isolated headings or awkward page break.
|
||||
6. Check that experience begins comfortably on page 1 and certifications are not duplicated.
|
||||
|
||||
---
|
||||
Do not add content merely to reduce bottom whitespace.
|
||||
|
||||
## Page Fill Budgets
|
||||
## 10. Gap and Bridge Rules
|
||||
|
||||
**2-Page Resume (resume.cls, 10pt):**
|
||||
Classify every JD requirement as:
|
||||
|
||||
Technical Skills uses Format C (categorized dash sub-items, 5 groups).
|
||||
Any internship/fixed position is ALWAYS present (FIXED bullets, not counted in variable budget).
|
||||
- **Direct:** demonstrated with a canonical professional example.
|
||||
- **Adjacent:** a real related method/tool with an explicit transfer explanation.
|
||||
- **Gap:** no reliable evidence.
|
||||
|
||||
**Variable Bullet Budget (Format C):**
|
||||
|
||||
The exact variable bullet count depends on your skills configuration and whether a USA immigration line is present. Typical range: **20-21 variable bullets** across all research positions. Count your FIXED bullets separately — they are set in the template.
|
||||
|
||||
**Adjustments:**
|
||||
- Adding a skills line (e.g., 4-4-2-2-2 instead of 4-3-2-2-2): -1 variable bullet
|
||||
- Removing immigration line (non-USA JD): +1 variable bullet in some configurations
|
||||
|
||||
**5-Page CV (cv.cls, 11pt) — LOCKED:**
|
||||
|
||||
Total: **~209 rendered text lines** across 5 pages. 1-2 lines slack at bottom of page 5 is acceptable.
|
||||
|
||||
The exact line budget depends on your template's FIXED sections (publications, presentations, awards, etc.). Count the FIXED lines in your template, then allocate the remainder to JD-dependent content. The key constraints:
|
||||
|
||||
| Category | Status |
|
||||
|----------|--------|
|
||||
| Header, Education, Honors, Pubs, Presentations, etc. | FIXED (count from template) |
|
||||
| Research Summary | JD-DEPENDENT (typically 7 lines: 1 heading + 6 body) |
|
||||
| Technical Expertise | JD-DEPENDENT (typically 18 lines: 1 heading + 17 body) |
|
||||
| Experience bullets | JD-DEPENDENT (**target 45 rendered lines**, 19-21 bullets, 2L/3L mix) |
|
||||
| Sub-theme names | JD-DEPENDENT (varies by position count) |
|
||||
|
||||
**Experience bullet mix options (45 rendered lines):**
|
||||
- 18x2L + 3x3L = 21 bullets | 15x2L + 5x3L = 20 | 12x2L + 7x3L = 19
|
||||
- Allocate more bullets to JD-relevant positions, fewer to tangential ones
|
||||
|
||||
**Sub-theme rebalancing:** To shift bullet weight toward a more JD-relevant sub-theme: (a) drop the weakest bullet from a less-relevant sub-theme (-2L), (b) split a high-content 3L achievement into two 2L bullets (method + finding, +1L). Net = -1L saved while adding a bullet where it matters. Both split bullets must stay within char limits. Never split a 2L bullet — it becomes two 1L fragments that look thin.
|
||||
|
||||
**Position header rule:** The position title + date must fit on ONE line. If the title is too long, shorten the title so the date doesn't wrap to a second line. Wrapped dates waste a full vertical line and break visual alignment. Test by compiling — if the date wraps, trim the title.
|
||||
|
||||
**CV Page 1 rule:** The FIRST bullet of the FIRST experience position MUST be 2L (not 3L). A 3L first bullet pushes content below the page 1 fold, wasting prime real estate. Plan this during Phase 1 bullet planning — if the top-priority achievement needs 3L, make it the SECOND bullet and lead with a strong 2L bullet instead.
|
||||
|
||||
**Budget workflow:** The line budget is pre-calculated from your template. Do NOT recalculate. Use the bullet counts above directly. After generation, verify that total bullet rendered lines = 45 (count each bullet's rendered lines and sum).
|
||||
|
||||
---
|
||||
|
||||
## Experience Bullet Writing Protocol (Experience-File-First)
|
||||
|
||||
**DO NOT use pre-written bullets.** Write every bullet FRESH from experience files, reframed for the target JD.
|
||||
|
||||
**Required files:** Experience files (all) + achievement_reframing_guide.md + bundle Section 1 (Priority Matrix) + bundle Section 3 (Reframing Map)
|
||||
|
||||
**Protocol:**
|
||||
1. Determine document format -> look up bullet variant (Resume-1L/2L, CV-2L/3L) and budget
|
||||
2. Allocate bullet count per position by JD relevance
|
||||
3. For each position, consult bundle's **Priority Matrix** (Section 1) to rank achievements
|
||||
4. For each achievement, consult **Achievement Reframing Guide** for role-type-specific framing directives
|
||||
5. Write the bullet FRESH using target-domain vocabulary from bundle's **Reframing Map** (Section 3)
|
||||
6. Verify char count per-bullet BEFORE moving to the next bullet
|
||||
7. After all bullets written: run the **First-Pass Reframing Checklist** (in achievement_reframing_guide.md)
|
||||
|
||||
**Reframing during writing (NOT after):** Every bullet should use target-domain vocabulary from the start. Do not write in academic language and then "translate" -- write in target language directly using the Reframing Map. This is the single highest-ROI step: reframing alone moves scores from ~60 to ~85.
|
||||
|
||||
**Hybrid JDs (two role types):** Use primary role type's Priority Matrix for achievement ranking. Use secondary role type's Reframing Map for 1-2 bullets that bridge to the secondary domain.
|
||||
|
||||
---
|
||||
|
||||
## Position Title Format
|
||||
|
||||
**Resume -- FLIPPED format (JD theme as bold title, role as subtitle):**
|
||||
Bold line = JD-customized domain theme (the single most powerful JD customization lever).
|
||||
Italic subtitle = formal role + institution.
|
||||
|
||||
| Position | Bold Line (JD-customizable) | Subtitle |
|
||||
|----------|-----------------------------|----------|
|
||||
| Position 1 | [Theme, e.g., "First-Principles Discovery & ML-Accelerated Simulation"] | [Your Role], [Institution] |
|
||||
| Position 2 | [Theme] ([Notable Award if applicable]) | [Your Role], [Institution] |
|
||||
| Position 3 | [Theme] ([Fellowship if applicable]) | [Your Role], [Institution 1] & [Institution 2] |
|
||||
| Internship | [Theme — FIXED] | [Your Role], [Company] | FLIPPED but FIXED |
|
||||
|
||||
**CV -- CONVENTIONAL format:**
|
||||
Bold line = formal role title. Mentors on separate line. Sub-headers = story threads (underlined).
|
||||
|
||||
---
|
||||
|
||||
## Immutable Elements — NEVER Modify
|
||||
|
||||
The following elements are set in the `.cls` files and templates. **NEVER change them in generated output:**
|
||||
|
||||
- **`\vspace` values** between sections — these are calibrated. Do not add, remove, or adjust.
|
||||
- **`\geometry` settings** (margins, textwidth, textheight) — locked per template.
|
||||
- **FIXED section content** (Education, Fellowships, Publications, Presentations, Mentorship, Collaborations, Computing, Internship) — copy verbatim from template. Never rewrite, trim, or reorder.
|
||||
- **`.cls` formatting** (font sizes, section rules, item separators, skill group spacing) — never override with inline LaTeX.
|
||||
- **Header layout** (name, email, location, icons) — structure is template-locked. Only the email address and link URLs are configurable.
|
||||
|
||||
**If content spills to an extra page (orphan lines):** Fix by shortening VARIABLE content only (summary, skills dashes, experience bullets). Count rendered characters to ensure bullets actually fit their target line count (2L or 3L). A bullet that is "2L" in the budget but renders as 3L due to character overflow is the most common cause of page spill. Before declaring any output done, compile with pdflatex and verify page count matches target (resume=2, CV=5).
|
||||
|
||||
**When updating an existing .tex output (not generating from scratch):** Only modify VARIABLE content — summary text, skills group names/dashes, experience bullet text, sub-theme names. Never touch FIXED sections, vspaces, geometry, or cls overrides, even if a critique flags them as improvable. If a critique targets a FIXED section, note it for the next full regeneration instead.
|
||||
|
||||
---
|
||||
|
||||
## Post-Generation Verification
|
||||
|
||||
Run this checklist after compile gate passes, before critique. Also used as Part 7 of critique_framework.md.
|
||||
|
||||
Before presenting final output, verify:
|
||||
|
||||
- [ ] All mechanical checks pass (chars, orphans, page fill, no submitted, sequences, variants)
|
||||
- [ ] Em-dash count: max 2 per document (resume or CL). Fellowships items use `. ` not `---`.
|
||||
- [ ] No -ing analysis endings on bullets ("...advancing the field", "...contributing to Y"). Restructure to end with a concrete result or metric.
|
||||
- [ ] All content checks pass (ATS, terms, inflation, provenance, pubs, cover letter)
|
||||
- [ ] All narrative checks pass (scan test, per-position flow, cross-position arc, CV sub-headers)
|
||||
- [ ] Company/institution name spelled correctly throughout
|
||||
- [ ] .tex file has complete preamble (will compile standalone)
|
||||
- [ ] Date format consistent (Mon YYYY -- Mon YYYY)
|
||||
|
||||
---
|
||||
|
||||
## Role-Type Decision Tree
|
||||
|
||||
| If JD mentions... | Primary profile | Secondary (hybrid) |
|
||||
|-------------------|----------------|-------------------|
|
||||
| _[your domain keywords]_ | _[your role type]_ | _[secondary or --]_ |
|
||||
| _Example: national lab, DOE, postdoc_ | _National Lab_ | _--_ |
|
||||
| _Example: machine learning, neural networks_ | _ML/AI_ | _National Lab_ |
|
||||
| _Example: protein modeling, structural biology_ | _Computational Biology_ | _--_ |
|
||||
|
||||
**Hybrid resumes:** When a JD spans two role types, merge the two profiles. Primary sets priority matrix; secondary contributes supplementary bullets and keywords.
|
||||
|
||||
Customize the decision tree above with your own role types, tools, and domains in `CLAUDE.md`.
|
||||
|
||||
---
|
||||
|
||||
## Gap Assessment & Bridge Mappings
|
||||
|
||||
For each identified gap, assess:
|
||||
- **Gap description:** What the JD asks for
|
||||
- **Bridge framing (if available):** Use "methodology transferable to X" or "equivalent experience with Y" -- NEVER "experienced with X" unless directly demonstrated
|
||||
- **Bridge confidence:** HIGH / MEDIUM / LOW
|
||||
- **User decision:** Omit or bridge? (User decides per gap)
|
||||
|
||||
**Example bridge mappings** (customize for your own tools/methods):
|
||||
- Tool A → "Custom solvers (Tool B/Tool C; computational methodology transferable to Tool A)" [HIGH]
|
||||
- Framework A → "Deep learning framework expertise (Framework B; directly transferable to Framework A)" [HIGH]
|
||||
- Simulation Package A → "Molecular dynamics expertise (Package B; transferable to Package A)" [HIGH]
|
||||
- Language A → "Scientific computing (Language B, Language C; transferable to Language A)" [MEDIUM]
|
||||
|
||||
---
|
||||
|
||||
## Content Density Rules
|
||||
|
||||
| Format | Bullets | Publications | Awards | Presentations |
|
||||
|--------|---------|-------------|--------|---------------|
|
||||
| 1-page resume | ~6 | 3-5 | 2 | Omit |
|
||||
| 2-page resume | ~12+ | 5-8 | 2-3 | May omit |
|
||||
| 5-page CV | Comprehensive | All published + under review | All | All |
|
||||
| Full CV | Everything | All published + under review | All | All |
|
||||
|
||||
---
|
||||
|
||||
## Files to Upload (by format)
|
||||
|
||||
**For resumes (1-page or 2-page):**
|
||||
1. `bundle_[role_type].md` — Role-specific generation content (Sections 1-5)
|
||||
2. `achievement_reframing_guide.md` — Role-type framing directives for all achievements
|
||||
3. `skills_taxonomy.md` — Full skills inventory for Format C generation
|
||||
4. `pub_metadata.md` — Publication database with scoring tags
|
||||
5. `resume.cls` — Document class file
|
||||
6. `resume_template.tex` — Structural template (contains FIXED sections)
|
||||
7. Experience files from `resume_builder/experience/`
|
||||
|
||||
**For CVs (5-page or full):**
|
||||
1. `bundle_[role_type].md` — Role-specific generation content (Sections 1-5)
|
||||
2. `achievement_reframing_guide.md` — Role-type framing directives for all achievements
|
||||
3. `skills_taxonomy.md` — Full skills inventory for Technical Expertise generation
|
||||
4. `pub_metadata.md` — Publication database with scoring tags
|
||||
5. `cv.cls` — Document class file
|
||||
6. `cv_template.tex` — Structural template (contains FIXED sections)
|
||||
7. Experience files from `resume_builder/experience/`
|
||||
|
||||
**Role type to bundle mapping:**
|
||||
Bundles live in `resume_builder/bundles/`. Map each JD role type to its corresponding bundle file (e.g., `bundle_[role_type].md`).
|
||||
Never turn Adjacent into Direct by vocabulary substitution. A required, title-defining Gap is an application-fit problem, not a resume-writing problem.
|
||||
|
||||
@@ -1,118 +1,77 @@
|
||||
# Session File Template
|
||||
|
||||
Every JD gets a persistent session file: `output/<FolderName>/session_<name>.md`
|
||||
|
||||
## Template
|
||||
Every JD gets `output/<Folder>/session_<name>.md`.
|
||||
|
||||
```markdown
|
||||
# Session: [Company] [Role Title]
|
||||
# Session: [Company] — [Role]
|
||||
|
||||
## JD Info
|
||||
- **File:** JDs/[file].txt
|
||||
- **Role:** [title]
|
||||
- **Company:** [company] ([context])
|
||||
- **Bundle:** [role_type]
|
||||
- **Format:** [Resume/CV] ([N]-page, [cls]) + [N]-page cover letter
|
||||
- **Salary/Details:** [if available]
|
||||
## JD Integrity
|
||||
- File/source:
|
||||
- Retrieval method and date:
|
||||
- Verbatim posting: YES/NO
|
||||
- Posting status:
|
||||
|
||||
## JD Analysis
|
||||
### Requirements
|
||||
| # | Requirement | Match | Evidence |
|
||||
|---|-------------|-------|----------|
|
||||
| 1 | ... | Direct/Bridge/Gap | ... |
|
||||
## Application Decision
|
||||
- Audience profile: International Tech / Swiss-DACH / Employer-specific
|
||||
- Evidence Fit: [0-100]
|
||||
- Fit class: Core / Adjacent / Stretch
|
||||
- Hard gate: PASS / FAIL — [reason]
|
||||
- Channel Strength: Strong / Moderate / Weak
|
||||
- Channel plan: [referral/recruiter/hiring-team/cold]
|
||||
- Cohort slot: Core [n]/7, Adjacent [n]/2, Stretch [n]/1
|
||||
- Decision: PROCEED / HOLD / NO-GO
|
||||
|
||||
### ATS Keywords
|
||||
- **ML/AI:** ...
|
||||
- **Domain:** ...
|
||||
- **Methods:** ...
|
||||
- **Tools:** ...
|
||||
- **Soft Skills:** ...
|
||||
## Requirements
|
||||
| # | Requirement | Required/preferred | Direct/Adjacent/Gap/Constraint | Canonical evidence | Gate? |
|
||||
|---|---|---|---|---|---|
|
||||
|
||||
### Gap Assessment
|
||||
- **Direct:** [list]
|
||||
- **Bridge:** [list with confidence]
|
||||
- **Gap:** [list -- what we can't claim]
|
||||
|
||||
## Company Context
|
||||
- **Mission:** ...
|
||||
- **This role:** Why it exists, what success looks like
|
||||
- **Culture:** ...
|
||||
- **"Why them" angle:** ...
|
||||
## Competitive Read
|
||||
- Obvious-fit candidate:
|
||||
- Dennis's advantage:
|
||||
- Their advantage:
|
||||
- Level/scope comparison:
|
||||
|
||||
## Framing Strategy
|
||||
- **Lead narrative:** ...
|
||||
- **Reframing map:** [domain term] → [JD term]
|
||||
- **Emphasize:** ...
|
||||
- **Downplay:** ...
|
||||
- **CL hooks:** ...
|
||||
- **User directives:** ...
|
||||
- Professional identity:
|
||||
- Strongest proof points:
|
||||
- Honest adjacent bridges:
|
||||
- Explicit gaps:
|
||||
- User directives:
|
||||
|
||||
## Critique Context (captured in Phase 0, used in /critique)
|
||||
- **Reviewer persona:** Who reads this? Their title, daily work, what impresses/bores them
|
||||
- **Competitive landscape:** Who else applies? What does the "obvious fit" have that we don't?
|
||||
- **Domain vocabulary:** What terms separate insider from outsider at THIS company?
|
||||
## Resume Plan
|
||||
- Summary: omit / 2--3 lines
|
||||
- Skills: [4--6 evidence-backed lines]
|
||||
- Swisscom: [4--5 selected canonical IDs]
|
||||
- Bosch: [3--4 selected canonical IDs]
|
||||
- Earlier experience: [0--1 per role]
|
||||
- Total bullets: [normally 11--14; no page-fill quota]
|
||||
- Impact evidence still needed:
|
||||
|
||||
## Cover Letter Plan
|
||||
- **Institution type:** Industry / National Lab / Academic
|
||||
- **Paragraph count:** [N] paragraphs, [word count target]
|
||||
- **P1 hook:** [specific product/paper/program to reference]
|
||||
- **P2-P3 evidence:** [which achievements to highlight, how to frame]
|
||||
- **Domain pivot:** [methodology bridge sentence, if pivoting]
|
||||
- **Jargon level:** HR-safe / Technical / Academic
|
||||
- **"Why them" hook:** [specific connection to their work]
|
||||
|
||||
## Bullet Plan
|
||||
|
||||
Note: Any FIXED positions (e.g., internships) are not included in this plan.
|
||||
|
||||
### Position 1 ([N] bullets, [N] rendered lines)
|
||||
| # | ID | Achievement | Variant | Lines | Rationale |
|
||||
|---|-----|------------|---------|-------|-----------|
|
||||
|
||||
### Position 2 ([N] bullets, [N] rendered lines)
|
||||
[same table]
|
||||
|
||||
### Position 3 ([N] bullets, [N] rendered lines)
|
||||
[same table]
|
||||
|
||||
**Budget:** [N] variable bullets, [N] rendered lines vs target [N]
|
||||
## Cover Letter Decision
|
||||
- YES/NO:
|
||||
- Reason:
|
||||
- Information it adds beyond resume:
|
||||
- Verified hook sources:
|
||||
|
||||
## Output Files
|
||||
- Resume/CV: `output/<FolderName>/e2e_<name>_[resume|cv].tex`
|
||||
- Cover Letter: `output/<FolderName>/e2e_<name>_cover_letter.tex`
|
||||
- Critique: `output/<FolderName>/critique_<name>.md`
|
||||
- Resume:
|
||||
- Cover letter: [path or intentionally omitted]
|
||||
- Critique:
|
||||
|
||||
## Critique Summary
|
||||
- **Score:** [N]/100
|
||||
- **Key findings:** ...
|
||||
- **Tier 1 fixes:** ...
|
||||
|
||||
## Edit History
|
||||
### Edit [N] ([date]): [description]
|
||||
- Changes: ...
|
||||
- Source: [critique item # / user request / auto-detected]
|
||||
- Verification: [gates passed]
|
||||
- Evidence Fit:
|
||||
- Hard gate:
|
||||
- Document Quality:
|
||||
- Channel Strength:
|
||||
- Tier 1 fixes:
|
||||
|
||||
## Status
|
||||
- Phase 0: [PENDING | DONE]
|
||||
- Phase 1: [PENDING | DONE (N bullets confirmed)]
|
||||
- Phase 2 Resume:
|
||||
- Summary: [PENDING | DONE]
|
||||
- Skills: [PENDING | DONE]
|
||||
- Position 1 ([N] bullets): [PENDING | DONE | IN_PROGRESS]
|
||||
- Position 2 ([N] bullets): [PENDING | DONE | IN_PROGRESS]
|
||||
- Position 3 ([N] bullets): [PENDING | DONE | IN_PROGRESS]
|
||||
- Compile: [PENDING | DONE]
|
||||
- Cover Letter: [PENDING | IN_PROGRESS | DONE]
|
||||
- Critique: [PENDING | IN_PROGRESS | CURRENT (score) | STALE]
|
||||
- **Next:** [exact command to copy after /clear]
|
||||
- **Next CL:** /make-cl output/<FolderName>/session_<name>.md
|
||||
- **Next Critique:** /critique output/<FolderName>/session_<name>.md
|
||||
- Fit gate:
|
||||
- Resume:
|
||||
- Cover letter:
|
||||
- Critique:
|
||||
- Application/outcome:
|
||||
- Next:
|
||||
```
|
||||
|
||||
## Context Efficiency Notes
|
||||
|
||||
- Session 1 (resume): resume_reference.md + critical_rules.md re-read + experience files + bundle + support files + template. Peak depends on knowledge base size.
|
||||
- Session 2 (CL): cl_reference.md + significance files (if available) + session file + resume .tex + bundle S5. Much lighter context.
|
||||
- Session 3 (critique): critique_framework.md + session file + both .tex + bundle. Moderate context.
|
||||
- Folder created in Phase 0 — all files go to output/<FolderName>/ from the start.
|
||||
The session file records application state, but it is not evidence authority. Canonical claims remain authoritative.
|
||||
|
||||
@@ -1,158 +1,91 @@
|
||||
# Shared Operations — All Skills
|
||||
# Shared Operations — All Application Skills
|
||||
|
||||
> Referenced by `/make-resume`, `/make-cl`, `/critique`, and `/edit-resume`.
|
||||
> Read this file at skill startup. Skills reference specific sections by name.
|
||||
## Canonical Evidence Preflight
|
||||
|
||||
---
|
||||
Before generation, editing or critique:
|
||||
|
||||
## JD Integrity (MANDATORY — applies to every skill)
|
||||
1. Read `resume_builder/canonical/claims.json` completely.
|
||||
2. Read `config.md` and `AGENTS.md` corrections/status.
|
||||
3. Run `python resume_builder/helpers/validate_resume_system.py`.
|
||||
4. Treat canonical claims as higher authority than extractions, experience files, bundles, sessions or outputs.
|
||||
5. Never use a file under `output/` as source content for a new application. Consult `resume_builder/canonical/historical_outputs.json`.
|
||||
6. Omit or ask about anything absent, ambiguous or unverified.
|
||||
|
||||
The job description is **ground truth**. Every requirement classification, framing decision, ATS keyword, and critique is derived from it. A wrong JD silently corrupts the entire package. Therefore:
|
||||
## JD Integrity
|
||||
|
||||
1. **The JD must be the real posting, verbatim.** Use the exact text of the live posting. Never invent, "reconstruct," paraphrase, summarize, infer, or fill gaps from training knowledge or a JD "template." There is **no such thing as a reconstructed JD** — if you don't have the real text, you don't have a JD.
|
||||
2. **A URL is not a JD.** If the user gives a link, you must fetch the actual posting text from it before doing anything else.
|
||||
3. **`WebFetch` is JS-blind on careers boards** (Google, Cisco, Apple, Meta, Workday/Phenom/Greenhouse/Lever/Recruitee SPAs). It returns the static shell or a stale search cache — do NOT trust it for JD text. Use the headless-browser scraper instead (recipe below).
|
||||
4. **If you cannot obtain the real JD text, STOP and ask the user to paste it.** Do not proceed to Phase 0/bullets/critique on a guessed JD. Blocking is correct; fabricating is not.
|
||||
5. **Record provenance.** The session file `JD source` line must state how the JD was obtained: `pasted by user` / `live scrape <date> via Playwright` / `file provided`. Never label a JD as authoritative unless it is the real text.
|
||||
- Use the real posting text verbatim.
|
||||
- A URL is not a JD; retrieve the visible posting body first.
|
||||
- Do not reconstruct, infer or complete a missing posting.
|
||||
- If the real JD cannot be obtained, stop and ask the user to paste it.
|
||||
- Record source, retrieval method, retrieval date and posting status in the session.
|
||||
- Recheck that a live role still exists before investing in a package.
|
||||
|
||||
### Fetching a JS-gated JD (Playwright recipe)
|
||||
For JavaScript-heavy boards, use the in-app Browser skill or the existing Playwright environment under `job_scout`. Save the retrieved text in the output folder.
|
||||
|
||||
The job_scout repo ships a Chromium + Playwright venv: `C:\Workspace\claude-resume-kit\job_scout\.venv\Scripts\python.exe` (the bare `py`/`python` on PATH do NOT have Playwright). To pull a single posting's full text:
|
||||
## Fit Before Writing
|
||||
|
||||
```bash
|
||||
cd "C:/Workspace/claude-resume-kit/job_scout" && .venv/Scripts/python.exe -c "
|
||||
import scout, io
|
||||
b = scout._get_browser(); ctx = b.new_context(); p = ctx.new_page()
|
||||
p.goto('<JOB_URL>', timeout=45000, wait_until='domcontentloaded')
|
||||
p.wait_for_timeout(5000)
|
||||
io.open('jd_dump.txt','w',encoding='utf-8').write(p.inner_text('body'))
|
||||
scout._close_browser()"
|
||||
```
|
||||
Read `resume_builder/reference/application_strategy.md` and `critique_framework.md`. Complete the Evidence Fit and hard-gate assessment before planning bullets.
|
||||
|
||||
Then Read `job_scout/jd_dump.txt`, extract the posting body (Minimum/Preferred qualifications, About, Responsibilities), and save it verbatim to `output/<FolderName>/JD_<name>.txt`. (Windows console can't print some Unicode — always write to a UTF-8 file, then Read it; don't `print()` the body.) See `[[reference_live_posting_check]]` in memory.
|
||||
- Core: proceed.
|
||||
- Adjacent: proceed selectively and state the serious gap.
|
||||
- Stretch: confirm cohort capacity and user intent before full generation.
|
||||
- No-go: record the decision; do not generate a package unless the user explicitly overrides after seeing the gate.
|
||||
|
||||
If the scrape fails (selector/timeout/captcha), fall back to rule 4: ask the user to paste the JD.
|
||||
## Audience and Cover-Letter Decisions
|
||||
|
||||
---
|
||||
Select International Tech, Swiss/DACH or Employer-specific format before writing. International Tech is default.
|
||||
|
||||
## Three-Session Workflow
|
||||
Apply `cl_reference.md` and record `Cover Letter Decision: YES/NO`. A deliberately omitted letter is a valid complete package.
|
||||
|
||||
Standard JD pipeline uses 3 sessions for token efficiency + quality:
|
||||
## Session Files
|
||||
|
||||
Session 1: `/make-resume JDs/JD_xyz.txt`
|
||||
→ Phase 0 (research) → STOP → Phase 1 (bullets) → STOP → Phase 2 (resume) → STOP
|
||||
→ "Resume done. Copy after /clear: /make-cl output/<Folder>/session_<name>.md"
|
||||
Store each application at `output/<Folder>/session_<name>.md`; use `session_file_template.md` for new sessions.
|
||||
|
||||
Session 2: `/make-cl output/<Folder>/session_<name>.md`
|
||||
→ Load context → generate CL → compile → STOP
|
||||
→ "CL done. Copy after /clear: /critique output/<Folder>/session_<name>.md"
|
||||
Derive `<name>` from company and role using lowercase underscores. Related files use the same key:
|
||||
|
||||
Session 3: `/critique output/<Folder>/session_<name>.md`
|
||||
→ Full package critique → STOP
|
||||
→ If approved: finalization check → "Package complete in output/<Folder>/"
|
||||
- `session_<name>.md`
|
||||
- `e2e_<name>_resume.tex`
|
||||
- optional `e2e_<name>_cover_letter.tex`
|
||||
- `critique_<name>.md`
|
||||
|
||||
If edits needed after critique:
|
||||
/clear → /edit-resume output/<Folder>/e2e_<name>_cv.tex output/<Folder>/critique_<name>.md
|
||||
/clear → /critique output/<Folder>/session_<name>.md (re-critique)
|
||||
To find a session from a `.tex` path, strip `e2e_` and the document suffix, search the same folder, then `output/**/session_*<company>*.md`.
|
||||
|
||||
---
|
||||
Re-read the session at the start of each phase and resume from its Status. Do not restart completed work.
|
||||
|
||||
## Fresh Session Startup
|
||||
## Folder Creation
|
||||
|
||||
CLAUDE.md is auto-loaded. These files are NOT — read them at skill start:
|
||||
1. `CLAUDE.md` — check Active Sessions and KB Corrections Log
|
||||
2. If resuming work on an existing JD: read its session file and pick up at Status → Next
|
||||
3. If starting a new JD: proceed to Phase 0
|
||||
At the start of an approved application:
|
||||
|
||||
---
|
||||
1. Create `output/<Folder>/`.
|
||||
2. Copy the verbatim JD into it.
|
||||
3. Create the session file.
|
||||
4. Copy `resume.cls` and the selected template only when generation begins.
|
||||
|
||||
## Session File System
|
||||
Do not copy a prior application resume.
|
||||
|
||||
Every JD gets a persistent session file: `output/<FolderName>/session_<name>.md` — the single source of truth for all context.
|
||||
## Validation and Visual QA
|
||||
|
||||
**Naming:** Derive `<name>` from company/role — lowercase, underscores (e.g., `acme_engineer`, `natlab_postdoc`).
|
||||
After creating or editing a document:
|
||||
|
||||
**All output files use the same key:**
|
||||
- `output/<FolderName>/session_<name>.md` — context file
|
||||
- `output/<FolderName>/e2e_<name>_resume.tex` or `_cv.tex` — generated document
|
||||
- `output/<FolderName>/e2e_<name>_cover_letter.tex` — cover letter
|
||||
- `output/<FolderName>/critique_<name>.md` — critique
|
||||
1. Run `python resume_builder/helpers/validate_resume_system.py --document <file.tex>`.
|
||||
2. Compile with the local LaTeX distribution.
|
||||
3. Inspect the PDF at normal size.
|
||||
4. Extract text with `pdftotext` and verify heading/employer/title/date order.
|
||||
5. Check page count, clipping, overlap, page breaks and contact information.
|
||||
|
||||
**Re-read the session file at the start of EVERY phase** to restore context after compaction.
|
||||
Character counts may diagnose an unwieldy bullet, but there are no target character bands and no page-fill quota.
|
||||
|
||||
---
|
||||
## Finalization
|
||||
|
||||
## Session File Derivation (for /make-cl, /critique, and /edit-resume)
|
||||
After explicit approval:
|
||||
|
||||
From .tex path: strip `e2e_` prefix (if present) + `_resume.tex`/`_cv.tex`/`_cover_letter.tex` suffix → `<name>`.
|
||||
1. Verify the session, resume source/PDF and critique exist.
|
||||
2. Verify the cover-letter source/PDF only when the session decision is YES.
|
||||
3. Run the canonical validator again on every submitted document.
|
||||
4. Copy final PDFs to `Dennis_Thiessen_Resume.pdf` and, when applicable, `Dennis_Thiessen_Cover_Letter.pdf`.
|
||||
5. Record submission date, fit class, Evidence Fit, hard gate, channel and outcome status.
|
||||
6. Add the application to the active cohort with `cohort_tracker.py add`.
|
||||
|
||||
Example: `output/Acme/e2e_acme_engineer_resume.tex` → `acme_engineer` → look for `session_acme_engineer.md`
|
||||
## Progress and Recovery
|
||||
|
||||
**Search order:**
|
||||
1. Direct path from $ARGUMENTS
|
||||
2. Folder path: `output/<FolderName>/session_<name>.md` (derive FolderName from JD filename or session name)
|
||||
3. Flat `output/` (legacy): `output/session_<name>.md`
|
||||
4. `CLAUDE.md` Active Sessions pointer
|
||||
5. Glob: `output/**/session_*<company>*.md`
|
||||
|
||||
**If still not found:**
|
||||
- `/edit-resume`: Tell user — "No session file exists. Run `/make-resume` first, or I can create a minimal one (JD Info + Framing Strategy inferred from .tex content)."
|
||||
- `/critique`: Do 1-2 web searches to build minimal context. Note in critique: "No session file — framing context is approximate."
|
||||
- `/make-cl`: Tell user — "No session file exists. Run `/make-resume` first."
|
||||
|
||||
---
|
||||
|
||||
## Progress Commentary
|
||||
|
||||
Provide brief status updates at each major step. Minimum: what you're doing + what you found.
|
||||
|
||||
If a step takes more than ~30 seconds of silent processing, output a progress line. The user should never wonder if things are stuck.
|
||||
|
||||
Per-phase examples are in each SKILL.md.
|
||||
|
||||
---
|
||||
|
||||
## Char Count Enforcement
|
||||
|
||||
Run `python3 resume_builder/helpers/char_count.py` after each section or position you write/edit.
|
||||
|
||||
The tool is authoritative — never trust mental math for char counts. If the tool fails, fall back to manual count and flag: "char_count.py unavailable — manual count, verify after compile."
|
||||
|
||||
---
|
||||
|
||||
## Folder Creation (Phase 0 of /make-resume)
|
||||
|
||||
**Trigger:** Start of Phase 0 in `/make-resume`.
|
||||
|
||||
**Steps:**
|
||||
1. Derive folder name from JD filename: `JDs/JD_Acme.txt` → `output/Acme/`
|
||||
2. `mkdir -p output/<FolderName>/`
|
||||
3. Copy JD file into output folder: `cp JDs/<filename> output/<FolderName>/`
|
||||
4. Write session file to `output/<FolderName>/session_<name>.md`
|
||||
5. All subsequent output files (from ALL skills) go in this folder
|
||||
|
||||
## Finalization (after /critique approval)
|
||||
|
||||
**Trigger:** User approves final output at `/critique` STOP.
|
||||
|
||||
**Steps:**
|
||||
1. Verify all expected files exist in `output/<FolderName>/`:
|
||||
- `session_<name>.md`
|
||||
- `e2e_<name>_[resume|cv].tex` + `.pdf` + compile artifacts
|
||||
- `e2e_<name>_cover_letter.tex` + `.pdf` + compile artifacts
|
||||
- `critique_<name>.md`
|
||||
2. Rename final PDFs for submission (derive name from `config.md` Personal Info):
|
||||
- `cp e2e_<name>_[resume|cv].pdf <Firstname>_<Lastname>_[Resume|CV].pdf`
|
||||
- `cp e2e_<name>_cover_letter.pdf <Firstname>_<Lastname>_Cover_Letter.pdf`
|
||||
- Keep originals alongside
|
||||
3. Confirm to user: "Package complete in output/<FolderName>/ — [N] files"
|
||||
|
||||
---
|
||||
|
||||
## Session End Protocol
|
||||
|
||||
Before the session ends or user does `/clear`:
|
||||
|
||||
1. **Update session file Status** — reflects actual state (which phase completed, what's next)
|
||||
2. **Update memory pointer** in `CLAUDE.md` Active Sessions
|
||||
3. **If mid-phase:** Write a `## Resume Point` section to the session file noting exactly where you stopped and what remains
|
||||
Give short progress updates at major steps. Before ending or clearing context, update session Status and the Active Sessions pointer. If interrupted, add a Resume Point describing completed work and the exact next action.
|
||||
|
||||
@@ -21,14 +21,14 @@ Each achievement has a **Significance** line (why it matters to any reader) and
|
||||
---
|
||||
|
||||
### SW-1: AWS Migration of Legacy ETL Stack
|
||||
**Significance:** Demonstrates hands-on cloud migration ownership at scale — a tier-1 signal for all data engineering and platform roles. AWS is the market-dominant cloud; owning a full migration from legacy to serverless is a top-of-market achievement.
|
||||
**Significance:** Demonstrates hands-on migration delivery for pipelines in Dennis's owned domains and contribution to a wider enterprise programme. It is a strong AWS/data-engineering signal without implying ownership of the company-wide migration.
|
||||
|
||||
| Role Type | Priority | Lead Verb | Framing Angle |
|
||||
|-----------|----------|-----------|---------------|
|
||||
| Staff/Senior Data Engineer | HIGH | Migrated | Lead with scale + operational impact (reduced overhead) |
|
||||
| Analytics Engineer | HIGH | Migrated | Lead with "enabling analytics outcomes" — tie to downstream stakeholder value |
|
||||
| ML/AI Engineer | MED | Migrated | Frame as "building the data infrastructure enabling ML workflows" |
|
||||
| Data Platform/Infra | HIGH | Architected | Lead with cloud-native architecture decisions; de-emphasize analytics framing |
|
||||
| Data Platform/Infra | HIGH | Migrated / implemented | Lead with verified AWS services and the owned-domain scope; do not claim company-wide architecture ownership |
|
||||
|
||||
**Overclaiming warning:** No specific throughput/volume numbers available — do not invent. Use qualitative impact (operational overhead reduction, scalability improvement).
|
||||
|
||||
@@ -72,15 +72,15 @@ Each achievement has a **Significance** line (why it matters to any reader) and
|
||||
|
||||
---
|
||||
|
||||
### SW-5: Security Champion — 3 Consecutive Years
|
||||
**Significance:** 3 consecutive years = institutional trust, not just a one-time training. Signals security ownership across the DevSecOps lifecycle — rare for a data engineer to hold this level of security designation.
|
||||
### SW-5: Security Champion — 2025/2026 (team role, NOT an award)
|
||||
**Significance:** Modest. This is a **rotating team role** (security point of contact), held for **2025/2026 only** — corrected 2026-07-27. It is not an award, not a distinction, and not "3 consecutive years" (an earlier version of this file claimed that; it was wrong).
|
||||
|
||||
**DEFAULT: OMIT.** Include only when the JD explicitly requires security or DevSecOps experience. Never place under Awards/Honors.
|
||||
|
||||
| Role Type | Priority | Lead Verb | Framing Angle |
|
||||
|-----------|----------|-----------|---------------|
|
||||
| Staff/Senior Data Engineer | MED | Designated | Include as breadth signal for senior roles; shows accountability beyond code |
|
||||
| Analytics Engineer | LOW | — | Omit — not differentiating for this audience |
|
||||
| ML/AI Engineer | MED | Designated | Include for AI product companies where model security/compliance is relevant |
|
||||
| Data Platform/Infra | HIGH | Designated | Lead DevSecOps angle — infrastructure roles care about security compliance |
|
||||
| All role types (JD silent on security) | OMIT | — | Leave it out — it costs a bullet slot and reads as padding |
|
||||
| Any role type (JD explicitly requires security/DevSecOps) | MED | Serve as | State plainly as a team role for 2025/2026; cite the 100h training + assessment, claim no more |
|
||||
|
||||
---
|
||||
|
||||
@@ -298,7 +298,7 @@ Each achievement has a **Significance** line (why it matters to any reader) and
|
||||
| SW-2 Component Owner | HIGH | HIGH | MED | HIGH |
|
||||
| SW-3 K8s + GitLab | HIGH | MED | HIGH | HIGH |
|
||||
| SW-4 B2B Products | MED | HIGH | LOW | LOW |
|
||||
| SW-5 Security Champion | MED | LOW | MED | HIGH |
|
||||
| SW-5 Security Champion | LOW | LOW | LOW | LOW |
|
||||
| SW-6 PySpark | MED | LOW | MED | MED |
|
||||
| BS-1 ML Inference | HIGH | LOW | HIGH | HIGH |
|
||||
| BS-2 Data Services | HIGH | MED | MED | HIGH |
|
||||
|
||||
@@ -1,133 +1,44 @@
|
||||
# AI Fingerprint Avoidance Rules
|
||||
# Authenticity and Natural-Writing Rules
|
||||
|
||||
> **Architecture note:** The primary defense against AI detection is the generation protocol — specific facts from experience files, char limits, JD-specific vocabulary, named entities. This file is a secondary safety net for word/phrase/structural patterns.
|
||||
> The primary defense against generic or suspicious application writing is verifiable specificity.
|
||||
> There is no reliable punctuation checklist for determining whether text was written with AI.
|
||||
|
||||
---
|
||||
## Mandatory Authenticity Checks
|
||||
|
||||
## 1. Banned Words
|
||||
1. Trace every experience claim to `resume_builder/canonical/claims.json` and an experience file.
|
||||
2. Preserve ownership scope and allowed verbs. Never intensify a verb merely to match the JD.
|
||||
3. Use the JD's terminology only when it accurately names the demonstrated work.
|
||||
4. Do not copy long phrases from the JD or mirror its requirement order mechanically.
|
||||
5. Do not add a tool, scale, customer, metric or outcome because it is plausible.
|
||||
6. Keep bridges explicit: say the demonstrated technology first, then explain transferability if useful.
|
||||
7. Prefer a concrete fact over a generic adjective.
|
||||
8. A claim must be answerable in an interview with a specific example.
|
||||
|
||||
**Tier 1 — Dead Giveaways (NEVER use in any output):**
|
||||
delve, tapestry, multifaceted, pivotal, realm, synergy, paradigm, holistic, nuanced, foster, embark, leverage (as verb), utilize, harness, spearhead, cornerstone, landscape (metaphorical), journey (metaphorical), cutting-edge, novel, innovative (unless quoting a JD), groundbreaking
|
||||
## Natural Resume Writing
|
||||
|
||||
**Banned Adjectives (use replacement):**
|
||||
- Start bullets with the work or result, not a framing phrase.
|
||||
- Mix short and longer bullets according to information content; identical lengths are not a goal.
|
||||
- Use ordinary action verbs. Repetition is acceptable when the same verb is accurate.
|
||||
- Avoid empty claims such as innovative, cutting-edge, proven track record, uniquely positioned or passionate about.
|
||||
- Use metrics only when verified. Qualitative outcomes are acceptable when their source is clear.
|
||||
- Keep the employer, formal title, dates and location more prominent than tailored narrative language.
|
||||
- Do not use first person in the resume. First person is appropriate in a cover letter.
|
||||
|
||||
| Banned | Replacement |
|
||||
|--------|-------------|
|
||||
| robust | strong, reliable |
|
||||
| comprehensive | thorough, broad |
|
||||
| innovative | new, original (or omit) |
|
||||
| pivotal | key, central |
|
||||
| meticulous | careful, precise |
|
||||
| diverse | varied, wide-ranging |
|
||||
| extensive | broad, deep, 10+ years of |
|
||||
## Natural Cover-Letter Writing
|
||||
|
||||
**Banned Verbs (use replacement):**
|
||||
- Write a letter only when it adds value or the employer requests it.
|
||||
- Open with the candidate-role connection; company research should support that connection, not dominate it.
|
||||
- Use one or two specific reasons for interest, not a paragraph of company-news paraphrase.
|
||||
- Do not repeat resume bullets. Explain a decision, motivation, transition or working style the resume cannot show.
|
||||
- Avoid defensive gap lists. A necessary bridge should be short and evidence-led.
|
||||
- Contractions and normal punctuation are allowed. There is no em-dash quota and no ban on sentences ending in an -ing word.
|
||||
|
||||
| Banned | Replacement |
|
||||
|--------|-------------|
|
||||
| leverage | use, apply, draw on |
|
||||
| utilize | use |
|
||||
| harness | apply, use, draw on |
|
||||
| spearhead | lead, start, launch |
|
||||
| foster | support, build, grow |
|
||||
| facilitate | run, lead, coordinate, enable |
|
||||
| showcase | show, demonstrate |
|
||||
| underscore | show, highlight |
|
||||
| bolster | strengthen, support |
|
||||
## Post-Generation Checklist
|
||||
|
||||
**Banned Adverbs:** meticulously, notably, subsequently (use "then" or "later"), remarkably, seamlessly, thereby
|
||||
|
||||
**Banned Nouns (metaphorical use):** tapestry, landscape, journey, realm, synergy, paradigm, cornerstone
|
||||
|
||||
**Technical exceptions:** "landscape" is fine when literal (e.g., "free energy landscape," "threat landscape"). "Novel" is fine when quoting a JD verbatim. Judge by context.
|
||||
|
||||
---
|
||||
|
||||
## 2. Banned Phrases
|
||||
|
||||
**Opening / transition phrases:**
|
||||
- "In today's rapidly evolving..."
|
||||
- "At the forefront of..."
|
||||
- "It is worth noting that..."
|
||||
- "This experience has taught me..."
|
||||
- "I am uniquely positioned to..."
|
||||
- "In an era of..."
|
||||
|
||||
**Resume / CL specific:**
|
||||
- "proven track record"
|
||||
- "passionate about" (use specific interest instead)
|
||||
- "I am excited to apply" (use concrete reason instead)
|
||||
- "demonstrated ability to" (just state what you did)
|
||||
- "strong foundation in"
|
||||
- "well-versed in"
|
||||
- "adept at"
|
||||
|
||||
**Academic / research:**
|
||||
- "groundbreaking research"
|
||||
- "cutting-edge methodology"
|
||||
- "novel approach" (say what is new about it)
|
||||
- "significant contributions to the field"
|
||||
- "at the intersection of X and Y" (name the specific intersection)
|
||||
|
||||
---
|
||||
|
||||
## 3. Structural Rules
|
||||
|
||||
### Sentence-Level
|
||||
- **No reframe pattern:** Never use "It's not X — it's Y" constructions
|
||||
- **No rhetorical Q+A:** Never ask a question then answer it ("What makes this unique? The answer is...")
|
||||
- **No gerund fragment stacking:** Avoid sequences of 3+ "-ing" phrases ("developing, testing, and deploying...")
|
||||
- **No -ing analysis endings on bullets:** This is the **#1 structural AI marker**. Bullets must NOT end with "-ing" phrases like "...advancing the field," "...contributing to improved Y," "...enabling new Z." Fix: restructure so the bullet ends with a concrete result, metric, or object. Example: "...contributing to a 15% reduction" is fine (ends with metric); "...contributing to improved efficiency" is not (vague -ing ending).
|
||||
- **Max 2 em-dashes per document:** Count all `---` in the full .tex file (resume or CL). If more than 2, replace extras with commas, semicolons, or parentheses. Fellowships/Honors items use `. ` not `---`.
|
||||
- **Post-gen scan:** After generating any document, scan all bullets for -ing endings. Flag and fix any found.
|
||||
|
||||
### Prose-Level
|
||||
- **Vary sentence length:** Mix short (8-12 words) with long (20-30 words). Three consecutive same-length sentences flag as AI.
|
||||
- **No same-structure paragraph starts:** If P1 opens "My research...", P2 must NOT open "My experience..." P3 must NOT open "My approach..."
|
||||
- **No constant triplet structures:** Avoid "X, Y, and Z" in more than 2 sentences per document. Use pairs, single items, or lists of 4+.
|
||||
|
||||
---
|
||||
|
||||
## 4. Positive Markers (signals of human writing)
|
||||
|
||||
1. **Specific details:** "Ran 847 MD simulations on protein variants" not "Conducted extensive simulations"
|
||||
2. **Front-loaded specifics:** Lead with the concrete thing, not the framing
|
||||
3. **Named entities:** Tool names, method names, journal names, institution names
|
||||
4. **Audience-appropriate jargon:** Use the JD's vocabulary, not generic synonyms
|
||||
5. **Short connecting words:** "so," "but," "and," "then" — not "consequently," "however," "additionally," "subsequently"
|
||||
6. **First-person specificity in CLs:** "I built" not "Was responsible for building"
|
||||
7. **Inside knowledge:** Reference specific group names, facility names, programmatic areas
|
||||
8. **Sentence length variety:** Deliberate mix of 8-word and 25-word sentences
|
||||
9. **Occasional "And"/"But" sentence openers** in CLs (1-2 per page max)
|
||||
10. **Contractions in CLs:** "I've" and "didn't" are acceptable in industry CLs (not academic)
|
||||
11. **One human detail per CL page:** A specific lab memory, a conference conversation, a problem that kept you up — concrete and brief
|
||||
|
||||
---
|
||||
|
||||
## 5. CL-Specific Note
|
||||
|
||||
Cover letters are the most vulnerable document to AI detection because they are prose-heavy and readers have strong intuitions about "how people write." All rules above apply with extra weight in CLs. Pay special attention to:
|
||||
- Opening sentence (must be specific to the company, not generic)
|
||||
- Sentence length variety (CLs with uniform 15-20 word sentences read as AI)
|
||||
- Em-dash usage (CLs accumulate em-dashes fastest — max 2 for the entire letter)
|
||||
|
||||
---
|
||||
|
||||
## 6. Post-Generation Critique Scan Checklist
|
||||
|
||||
Run this 12-item scan on every generated document before presenting to the user:
|
||||
|
||||
1. [ ] Any Tier 1 banned word present? (Search for each)
|
||||
2. [ ] Any banned phrase from Section 2?
|
||||
3. [ ] More than 2 em-dashes (`---`) in the document?
|
||||
4. [ ] Any bullet ending with an -ing analysis phrase?
|
||||
5. [ ] Three or more consecutive sentences of similar length?
|
||||
6. [ ] Paragraph starts repeat the same structure (e.g., "My research...", "My experience...")?
|
||||
7. [ ] More than 2 "X, Y, and Z" triplet structures in the document?
|
||||
8. [ ] CL opens with a generic phrase instead of a company-specific reference?
|
||||
9. [ ] Any metaphorical use of "landscape," "journey," "realm," or "tapestry"?
|
||||
10. [ ] Passive voice in more than 20% of bullet verbs?
|
||||
11. [ ] Fellowships/Honors items use `---` instead of `. `?
|
||||
12. [ ] Any adverb from the banned list (meticulously, notably, subsequently, etc.)?
|
||||
|
||||
**If any item fails:** Fix before presenting. These are not optional polish — they are detectable AI patterns.
|
||||
- [ ] Every claim passes the canonical validator.
|
||||
- [ ] Every listed skill has an interview-ready evidence example.
|
||||
- [ ] No sentence converts company or industry scale into personal impact.
|
||||
- [ ] No marketing headline is presented as a historical job title or customer-delivery fact.
|
||||
- [ ] No unsupported metric or causal result appears.
|
||||
- [ ] The resume sounds like one technically precise person, not a rearranged JD.
|
||||
- [ ] The cover letter is optional by policy and adds information beyond the resume.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Significance Research: Bosch Semiconductor — Data Analysis Engineer
|
||||
|
||||
> Use in cover letters and summaries — NOT in resume bullet text.
|
||||
> Particularly valuable for semiconductor industry JDs.
|
||||
> Optional semiconductor context only. Reverify external claims before use.
|
||||
> Never convert generic fab scale, yield economics or industry trends into Dennis's personal impact.
|
||||
|
||||
---
|
||||
|
||||
@@ -16,19 +16,19 @@
|
||||
- Offline ML analysis (batch — not real-time, misses process drifts)
|
||||
- Inline ML inference (real-time, containerized — current best practice)
|
||||
|
||||
**Why Dennis's experience matters:** Deploying ML inference into a 24/7 fab is operationally much harder than deploying to a web server. There are no maintenance windows, hardware is constrained, and a model failure affects production throughput. Dennis designed and executed the integration strategy for this environment — a level of MLOps maturity that few data engineers have encountered.
|
||||
**Why Dennis's experience matters:** Dennis designed and executed an integration strategy for containerized ML inference in a continuously operating fab environment. Do not add claims about maintenance windows, hardware constraints, throughput impact or rarity unless they are verified for his system.
|
||||
|
||||
**Differentiation:** The combination of Docker containerization + Kubernetes orchestration + Ansible automation in a 24/7 constrained environment is a rare and credible production ML deployment signal.
|
||||
**Differentiation:** Docker, Kubernetes and Ansible used for production inference integration provide direct deployment evidence. This supports ML-platform/MLOps positioning without implying model-development ownership.
|
||||
|
||||
---
|
||||
|
||||
### Semiconductor Data Domains — Field Context
|
||||
|
||||
**Defect Management:**
|
||||
Semiconductor defect management involves tracking, classifying, and correlating defects found during inline inspection (optical, SEM) and end-of-line electrical test. Key data challenges: high-dimensional spatial data (wafer maps), multi-step process correlation, and connecting defect signatures to root causes (process excursions, equipment issues). Dennis built data pipelines and ML systems directly in this domain.
|
||||
Semiconductor defect management provides the domain context for Dennis's work. His verified contributions cover data services, analytics applications, wafer-map visualizations and ML-inference integration; do not generalize this into ownership of every defect-management pipeline or ML system.
|
||||
|
||||
**Semiconductor Parameter Testing:**
|
||||
Parametric testing measures electrical characteristics (threshold voltages, leakage currents, resistance) of test structures on each wafer. The data volume is massive — hundreds of parameters across thousands of dies per wafer, across thousands of wafers per day. Data engineering for parametric test requires efficient storage, fast query access, and statistical analysis capabilities. Dennis built data services that fed parametric testing analysis teams.
|
||||
Dennis built data services for semiconductor analysis teams in the parameter-testing domain. Generic wafer or data-volume figures must not be presented as the scale of his systems without direct evidence.
|
||||
|
||||
**Process Analysis:**
|
||||
Process analysis correlates equipment parameters (temperature, pressure, gas flow) with downstream wafer yield and defect outcomes. This is the domain where data engineering meets process engineering — the pipelines must be reliable and the data must be accurate, because process decisions (equipment maintenance, recipe adjustments) depend on it.
|
||||
@@ -40,13 +40,13 @@ Process analysis correlates equipment parameters (temperature, pressure, gas flo
|
||||
### Field Overview: Data & AI in Semiconductor Manufacturing (2024–2026)
|
||||
|
||||
The semiconductor industry is undergoing a major digital transformation driven by:
|
||||
1. **Process complexity:** 300mm fabs with 1000+ process steps generate petabytes of data; manual analysis can no longer keep pace
|
||||
2. **Yield pressure:** At leading-edge nodes, even 1% yield improvement has enormous economic value — data-driven yield optimization is a strategic priority
|
||||
1. **Process complexity:** 300mm semiconductor production creates complex data and operational requirements; do not attach generic petabyte or process-step figures to Dennis's work
|
||||
2. **Yield and quality:** Data-driven process and defect analysis matter commercially, but Dennis has no verified personal yield-improvement metric
|
||||
3. **AI/ML adoption:** Computer vision for inline inspection, predictive maintenance for equipment, and ML-based process optimization are all actively deployed at tier-1 fabs (TSMC, Intel, Samsung)
|
||||
4. **Talent scarcity:** Candidates who combine data engineering depth with semiconductor domain knowledge are extremely rare — most data engineers lack the domain; most process engineers lack the data skills
|
||||
4. **Candidate distinction:** Dennis combines production data engineering with direct semiconductor-fab application experience; avoid unsourced scarcity claims
|
||||
|
||||
**Target companies for semiconductor JDs:**
|
||||
ASML, Infineon, GlobalFoundries, ams OSRAM, Microchip Technology, ON Semiconductor, Renesas, NXP, STMicroelectronics, Bosch (again), TSMC (Europe fabs in Dresden area), Wolfspeed, SiCrystal, Elmos
|
||||
|
||||
**CL hook for semiconductor JDs:**
|
||||
> "Semiconductor manufacturing analytics is one of the most data-intensive and operationally demanding domains in industry. At Bosch Semiconductor in Dresden, I worked directly in the data domains that matter most — Defect Management, Semiconductor Parameter Testing, and Process Analysis — building the pipelines and analytics platforms that engineers relied on for real-time production decisions. That domain knowledge, combined with my experience deploying ML-based defect classification into a 24/7 fab, is what I'd bring to [Company]."
|
||||
> "At Bosch Semiconductor in Dresden, I developed data services and analytics applications for defect-management and process-analysis teams, and integrated containerized ML inference into a 24/7 fab environment. That combination of domain familiarity and production delivery is what I would bring to [Company]."
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Significance Research: Swisscom — Staff Data, Analytics & AI Engineer
|
||||
|
||||
> Use in cover letters and summaries — NOT in resume bullet text.
|
||||
> Provides field context demonstrating awareness of the data engineering landscape.
|
||||
> Optional context only. Reverify every market/company statement from a current primary source before use.
|
||||
> Never convert company scale, industry trends or likely benefits into Dennis's personal impact.
|
||||
|
||||
---
|
||||
|
||||
@@ -9,24 +9,24 @@
|
||||
|
||||
**The problem:** Legacy enterprise data warehouses (Teradata, Oracle) are expensive to scale, inflexible for modern analytics workloads, and difficult to integrate with ML pipelines. The industry-wide shift to cloud-native data platforms (AWS, Azure, GCP) is driven by cost, elasticity, and the rise of the data lakehouse pattern.
|
||||
|
||||
**Competing approaches:** Most enterprises face a choice between lift-and-shift (rehosting on cloud VMs — minimal benefit), re-platforming (moving to managed services like Redshift), or full re-architecture to a lakehouse (S3 + Athena/Iceberg + Glue). The lakehouse pattern (Apache Iceberg on S3 + Athena) is increasingly the de facto standard for cost-efficient, ACID-compliant analytics at scale.
|
||||
**Architecture context:** Enterprise migrations may involve rehosting, re-platforming or re-architecture. Use this only to explain the technical choices in a verified job-specific context; do not assert a universal standard.
|
||||
|
||||
**Why this matters:** Swisscom serves millions of Swiss customers across mobile, broadband, and enterprise — the data volume is significant. Moving Fulfillment data pipelines to a cloud-native architecture directly affects the speed and cost of analytics for business-critical processes.
|
||||
**Why this matters:** Fulfillment pipelines are business-critical. No personal data-volume, cost-saving or speed-improvement metric is currently verified.
|
||||
|
||||
**Differentiation:** Dennis didn't just configure existing pipelines in a new environment — he introduced Apache Iceberg (open table format with time-travel and schema evolution), AWS Glue Tables as the catalog, and CloudFormation for IaC provisioning. This reflects current best practices in data lakehouse architecture, not a basic ETL migration.
|
||||
**Candidate-specific evidence:** Dennis used Iceberg, AWS Glue/Athena and CloudFormation while migrating pipelines in his owned domains. Do not claim he selected these technologies for Swisscom or introduced them company-wide unless separately verified.
|
||||
|
||||
**Field overview: Data Lakehouse Architecture (2024–2026)**
|
||||
The data lakehouse pattern — combining the scalability of data lakes (S3, ADLS) with the ACID guarantees and query performance of data warehouses — has become the dominant architecture for new data platform builds. Apache Iceberg has emerged as the leading open table format, supported by AWS (Athena, Glue), Databricks (as Delta Lake alternative), and Snowflake. Engineers who have implemented Iceberg in production (not just read about it) are in high demand as organizations migrate off proprietary DWH systems.
|
||||
Open table formats such as Apache Iceberg are relevant context for lakehouse roles. Reverify any market-share or "dominant architecture" statement from current primary sources before using it in a cover letter. Context must never be converted into a claim about Dennis's personal system scale or architecture authority.
|
||||
|
||||
---
|
||||
|
||||
### SW-2: Component Ownership at Scale — Field Context
|
||||
|
||||
**The problem:** In large data engineering teams at enterprise companies, the "Component Owner" model is how organizations assign accountability for production systems. Unlike a ticket-based dev model, Component Owners are responsible for a system's full lifecycle: reliability, compliance, SLA, on-call, and stakeholder communication. This is a Staff-engineer-level responsibility.
|
||||
**The evidence:** At Swisscom, Dennis's Component Owner role covers production operation, data quality, governance, incidents and on-call obligations for Fulfillment ETL pipelines. Describe those verified responsibilities directly; do not use a generic title-equivalence claim.
|
||||
|
||||
**Why this matters:** Swisscom's Fulfillment domain carries business-critical data — provisioning, activating, and tracking customer service orders for Switzerland's largest telecom. Pipeline failures in this domain directly impact customer experience and revenue.
|
||||
**Why this matters:** Swisscom's Fulfillment domain carries business-critical operational data. Avoid claiming a quantified customer or revenue effect without evidence.
|
||||
|
||||
**Differentiation:** Dennis holds this responsibility as a Staff Engineer (Engineer IV) — the same person building the pipelines is accountable for their reliability in production. This is the "full-stack data engineer" model that platform teams increasingly demand.
|
||||
**Candidate-specific value:** Dennis combines implementation with production accountability for his components. That is the defensible distinction; broader market-demand claims require fresh sourcing.
|
||||
|
||||
---
|
||||
|
||||
@@ -34,7 +34,7 @@ The data lakehouse pattern — combining the scalability of data lakes (S3, ADLS
|
||||
|
||||
**The problem:** Data pipelines have traditionally been deployed on bare metal or VMs, leading to environment inconsistency, difficult scaling, and slow deployments. The shift to Kubernetes for data workloads (not just web services) reflects the maturation of the data platform discipline.
|
||||
|
||||
**Industry trend:** Running data applications (Airflow, Spark, custom Python pipelines) on Kubernetes is now standard practice at mature data organizations. GitLab CI/CD with Kubernetes deployment is the Swiss/European enterprise standard (as opposed to GitHub Actions + AWS ECS in US-heavy startups).
|
||||
**Industry context:** Kubernetes and CI/CD are recognizable production-delivery signals. Do not claim a regional or industry standard without current sourcing.
|
||||
|
||||
**Differentiation:** Swisscom's use of Kubernetes for Python data applications confirms production-grade container orchestration for data workloads — not just a dev/test environment.
|
||||
|
||||
@@ -44,8 +44,8 @@ The data lakehouse pattern — combining the scalability of data lakes (S3, ADLS
|
||||
|
||||
The data engineering discipline has undergone a significant shift in the past 3 years:
|
||||
1. **From batch to streaming:** Kafka-based event-driven architectures have replaced many nightly batch processes
|
||||
2. **From proprietary DWH to open lakehouse:** Teradata/Oracle → S3 + Athena/Iceberg is the dominant migration pattern
|
||||
2. **From proprietary DWH to open lakehouse:** Dennis has direct experience moving owned-domain pipelines from Teradata/Oracle processing to S3 + Athena/Iceberg within a wider programme
|
||||
3. **From manual to automated infra:** CloudFormation, Terraform, and Pulumi have made IaC standard for data platform teams
|
||||
4. **From separated to embedded ML:** Data engineers who can own the ML data layer (not just supply data to a separate ML team) are increasingly valuable
|
||||
|
||||
Dennis's current stack (Kafka, PySpark, AWS S3/Glue/Athena/Iceberg, Kubernetes, GitLab CI/CD, CloudFormation) maps precisely to this modern paradigm.
|
||||
Dennis's current stack includes Kafka, PySpark, AWS S3/Glue/Athena/Iceberg, Kubernetes, GitLab CI/CD and CloudFormation. Use the named evidence; avoid generic claims that it maps "precisely" to every target platform.
|
||||
|
||||
@@ -1,195 +1,107 @@
|
||||
# Skills Taxonomy — Dennis Thiessen
|
||||
# Skills Taxonomy — Evidence-First
|
||||
|
||||
> Generated: 2026-03-28
|
||||
> Sources: All 10 extractions + 6 experience files
|
||||
> Use this file when populating the Technical Skills section of resume/CV.
|
||||
> Canonical authority: `resume_builder/canonical/claims.json`.
|
||||
> This file helps select and group skills; it may not promote a skill beyond its canonical evidence level.
|
||||
|
||||
---
|
||||
## Evidence Levels
|
||||
|
||||
## Summary Stats
|
||||
| Level | Meaning | Output rule |
|
||||
|---|---|---|
|
||||
| Production — current | Used in current professional delivery | May appear plainly when relevant |
|
||||
| Production — historical | Shipped professionally, but not current | Include with role/date context when recency matters |
|
||||
| Hands-on — current | Used directly, but without verified production ownership | Use precise verbs such as used, configured or integrated |
|
||||
| Project / proof of concept | Used in a bounded PoC | Label the PoC; never imply platform-scale operation |
|
||||
| Certification / coursework | Learned through formal study | Keep in certification context; not professional experience |
|
||||
| Unverified / never used | No reliable evidence | Do not include |
|
||||
|
||||
- **Total unique skills:** 65+
|
||||
- **Proficiency levels:** Expert (daily use, owned systems) | Proficient (shipped work, comfortable teaching) | Familiar (used in project, not current)
|
||||
- **Certification-backed skills:** AWS (SAA cert + Udacity DataEng), Software Architecture (iSAQB), AI/ML (Udacity AI for Trading, IBM AI Engineering)
|
||||
Do not use Expert/Proficient/Familiar labels in resumes. Evidence and recency are more useful than self-ratings.
|
||||
|
||||
---
|
||||
## Current Production Core
|
||||
|
||||
## Category 1: Programming Languages
|
||||
| Skill | Evidence | Typical use |
|
||||
|---|---|---|
|
||||
| Python | Swisscom pipelines/apps; prior Bosch/Vizrt work | Always for data/platform roles |
|
||||
| SQL | Swisscom and prior data roles | Always for data roles |
|
||||
| PySpark | Swisscom current work | When distributed processing is relevant |
|
||||
| Apache Kafka | Swisscom production ingestion | Data/event-driven roles |
|
||||
| Apache Airflow | Swisscom AWS migration scope | Orchestration/data roles |
|
||||
| AWS | Swisscom production work; SAA certification | AWS-relevant roles |
|
||||
| S3, Glue, Athena, Iceberg, Redshift | Swisscom owned-domain migration/data products | Name only relevant services |
|
||||
| CloudFormation / IaC | Swisscom production provisioning | Say CloudFormation; never substitute Terraform |
|
||||
| Kubernetes, Docker | Swisscom application delivery; Bosch ML integration | Production platform/MLOps roles |
|
||||
| GitLab CI/CD | Swisscom delivery | Platform and engineering roles |
|
||||
| Oracle, Teradata | Swisscom pipelines | Data roles when relevant |
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| Python | Expert | Swisscom (pipelines, apps), Bosch (data services), Fraunhofer (ML/NLP), Vizrt (backend + tests) | HIGH |
|
||||
| SQL (multi-dialect) | Expert | All positions — Oracle, Impala, Teradata, MS SQL, Postgres, MySQL | HIGH |
|
||||
| PySpark | Proficient | Swisscom Staff level (LinkedIn confirmed) | HIGH |
|
||||
| Java | Proficient | Fraunhofer (SCEDAS, MISSION), Bosch (data services), Generali (J2EE), Capgemini | MED |
|
||||
| C# | Proficient | Bosch (data services, Spotfire extensions), Fraunhofer (SCEDAS) | MED |
|
||||
| JavaScript / TypeScript | Proficient | Fraunhofer (MISSION, Express.js), CV skills list | MED |
|
||||
| C++ | Proficient | Vizrt (backend transcoding), Generali (CV) | LOW |
|
||||
| VBA | Familiar | Student assistant role (Bundeswehr Uni, 2013) — very minor | LOW |
|
||||
## Historical Production Evidence
|
||||
|
||||
---
|
||||
| Skill | Evidence | Constraint |
|
||||
|---|---|---|
|
||||
| Java | Bosch, Fraunhofer, Generali | Historical; do not imply current daily use |
|
||||
| C# | Bosch and Fraunhofer | Historical; strong when Spotfire/.NET is relevant |
|
||||
| C++ | Vizrt distributed backend | Limited historical evidence |
|
||||
| JavaScript / Express.js | Fraunhofer MISSION | Historical and bounded; TypeScript is unverified |
|
||||
| Hadoop / Impala | Bosch data services | Historical production context |
|
||||
| Ansible | Bosch ML integration | Historical production context |
|
||||
| Jenkins | Fraunhofer and Generali | Historical production context |
|
||||
| BDD, Selenium, JBehave | Generali | Earlier-career testing evidence |
|
||||
| TIBCO Spotfire | Bosch co-ownership and C# extensions | Preserve co-ownership |
|
||||
|
||||
## Category 2: Data Engineering & Pipelines
|
||||
## ML, AI and Observability
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| ETL/ELT design & operation | Expert | Swisscom (component owner), Bosch (data services) | HIGH |
|
||||
| Apache Kafka | Expert | Swisscom (ingestion pipelines), Bosch (ELK PoC) | HIGH |
|
||||
| Apache Airflow | Proficient | Swisscom (AWS migration stack) | HIGH |
|
||||
| SAP BODS | Proficient | Swisscom (legacy ETL) | MED |
|
||||
| Teradata DWH | Proficient | Swisscom (DWH architecture + operation) | MED |
|
||||
| Hadoop / ImpalaSQL | Proficient | Bosch (data services over Hadoop) | MED |
|
||||
| Data modeling | Proficient | Swisscom (data products), Bosch (pipeline design) | MED |
|
||||
| SQL performance tuning | Proficient | CV (explain plans, indexes, partitions) | MED |
|
||||
| Apache Spark / PySpark | Proficient | Swisscom (big data processing) | HIGH |
|
||||
| dbt | Not confirmed | Not in any extraction — do not claim | — |
|
||||
| Skill | Evidence level | Safe framing |
|
||||
|---|---|---|
|
||||
| ML inference deployment | Production — historical | Integrated containerized inference into a 24/7 Bosch fab |
|
||||
| Image classification | Production application context | Worked on inference integration; model-training ownership not verified |
|
||||
| MLOps | Bounded production evidence | Use only when defined as deployment/operation, not full model lifecycle |
|
||||
| NLP / speech recognition | Research-project contribution | Contributed components at Fraunhofer; no publication/model ownership |
|
||||
| ELK, Kafka anomaly detection | Proof of concept | Always retain the PoC label |
|
||||
| Grafana, Prometheus, Loki | Proof-of-concept/monitoring context | Do not imply enterprise observability ownership |
|
||||
| LiteLLM | Hands-on — current | LLM API gateway use/integration; no serving-platform ownership |
|
||||
| Domain-grounded assistants/custom GPTs | Hands-on — current | Configured with curated knowledge; no fine-tuning or formal evaluation |
|
||||
| Copilot, Kiro | Hands-on — current | AI-assisted engineering tools, not LLM product engineering |
|
||||
|
||||
---
|
||||
## Certification-Only Signals
|
||||
|
||||
## Category 3: Cloud & Infrastructure
|
||||
| Skill | Evidence |
|
||||
|---|---|
|
||||
| TensorFlow / Keras | IBM AI Engineering coursework |
|
||||
| PyTorch | Coursework/personal evidence only; verify before listing outside certification context |
|
||||
| Spark ML | Coursework context only unless professional evidence is added |
|
||||
| AI for Trading / quantitative ML | Udacity/WorldQuant Nanodegree |
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| AWS (overall) | Proficient | Swisscom (migration), AWS SAA cert (2024), Udacity DataEng cert (2026) | HIGH |
|
||||
| AWS S3 | Proficient | Swisscom AWS migration | HIGH |
|
||||
| AWS Glue | Proficient | Swisscom AWS migration | HIGH |
|
||||
| AWS Athena | Proficient | Swisscom AWS migration (with Apache Iceberg table format) | HIGH |
|
||||
| AWS Glue (Jobs + Tables) | Proficient | Swisscom — Glue jobs for ETL + Glue Data Catalog / Glue Tables | HIGH |
|
||||
| Apache Iceberg | Proficient | Swisscom — S3 + Athena with Iceberg table format (open table format, time-travel, schema evolution) | HIGH |
|
||||
| AWS Redshift | Proficient | Swisscom AWS migration | HIGH |
|
||||
| AWS Lambda | Proficient | Swisscom AWS migration | MED |
|
||||
| AWS Step Functions | Proficient | Swisscom AWS migration | MED |
|
||||
| AWS CloudFormation | Proficient | Swisscom — IaaS, infrastructure provisioning as code | HIGH |
|
||||
| Kubernetes (K8s) | Expert | Swisscom (Python app deployment), Bosch (ML inference orchestration) | HIGH |
|
||||
| Docker | Expert | Bosch (ML containerization, ELK PoC), Fraunhofer (MISSION), Swisscom | HIGH |
|
||||
| Ansible | Proficient | Bosch (ML orchestration) | MED |
|
||||
| GitLab CI/CD | Proficient | Swisscom (confirmed Zeugnis) | HIGH |
|
||||
| Jenkins | Proficient | Fraunhofer (independently set up), Generali (BDD build jobs) | MED |
|
||||
| CI/CD (general) | Expert | Swisscom, Fraunhofer, Vizrt, Generali — cross-position | HIGH |
|
||||
| IaC (Infrastructure as Code) | Proficient | Swisscom — AWS CloudFormation confirmed by user | HIGH |
|
||||
| DevSecOps | Proficient | Swisscom Security Champion ×3 (2023–2026), 100h training | MED |
|
||||
## Forbidden Until New Evidence Is Added
|
||||
|
||||
---
|
||||
- LangChain, LangGraph, LlamaIndex, AutoGen, CrewAI or Semantic Kernel
|
||||
- Azure, Azure ML, Azure OpenAI or AKS
|
||||
- GCP, BigQuery, Dataflow or Flume hands-on experience
|
||||
- Terraform
|
||||
- Formal model or LLM evaluation
|
||||
- LLM fine-tuning, red-teaming or model-training ownership
|
||||
- FastAPI, Flask or Django
|
||||
- TypeScript
|
||||
- Petabyte-scale ownership
|
||||
|
||||
## Category 4: Databases & Storage
|
||||
## Certifications
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| Oracle DB | Expert | Swisscom (Fulfillment pipelines), Bosch (data services), Generali (web portal) | HIGH |
|
||||
| Teradata | Proficient | Swisscom (DWH target, architecture) | MED |
|
||||
| MS SQL Server | Proficient | Fraunhofer (SCEDAS — Entity Framework) | LOW |
|
||||
| PostgreSQL | Familiar | CV skills list | LOW |
|
||||
| MySQL | Familiar | CV skills list, RiskAhead project | LOW |
|
||||
| SQLite | Familiar | Fraunhofer (MISSION microservices) | LOW |
|
||||
| Hadoop / Impala | Proficient | Bosch (ImpalaSQL data services) | MED |
|
||||
| Certification | Issuer | Year/status |
|
||||
|---|---|---|
|
||||
| AWS Certified Solutions Architect — Associate | AWS | 2024; active to Sep 2027 |
|
||||
| Data Engineering with AWS Nanodegree | Udacity | 2026 |
|
||||
| iSAQB CPSA — Foundation | iSAQB | 2016; no expiry |
|
||||
| ITIL Foundation | PEOPLECERT / AXELOS | 2016; no expiry |
|
||||
| AI for Trading Nanodegree | Udacity / WorldQuant | 2021 |
|
||||
| IBM AI Engineering Specialization | IBM / Coursera | Completion year not recorded |
|
||||
|
||||
---
|
||||
The Swisscom Security Champion assignment is not a certification and does not belong in this table.
|
||||
|
||||
## Category 5: ML & AI
|
||||
## Resume Grouping
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| ML inference deployment | Proficient | Bosch (Docker/K8s in 24/7 fab — primary responsibility) | HIGH |
|
||||
| Image classification | Proficient | Bosch (automated quality monitoring in semiconductor fab) | MED |
|
||||
| NLP / Speech recognition | Familiar | Fraunhofer ARTUS research project (contributing role) | MED |
|
||||
| PyTorch | Familiar | CV skills list | LOW |
|
||||
| Scikit-learn | Familiar | CV skills list | LOW |
|
||||
| Pandas / NumPy | Proficient | CV (data analysis, pipeline work) | MED |
|
||||
| Matplotlib / Plotly | Proficient | CV (data visualization, dashboards) | LOW |
|
||||
| MLOps (general) | Proficient | Bosch (full ML lifecycle: containerize → deploy → monitor in production) | HIGH |
|
||||
| AI for Trading / Quant ML | Familiar | Udacity AI for Trading Nanodegree (2021) — personal study, not professional | LOW |
|
||||
| TensorFlow / Keras | Familiar | IBM AI Engineering Specialization (Coursera) | LOW |
|
||||
| Apache Spark ML | Familiar | IBM AI Engineering (Spark ML course) | LOW |
|
||||
Use 4--6 compact lines, selected for the JD. A normal International Tech grouping is:
|
||||
|
||||
**Proficiency note:** For ML/AI roles, frame Bosch ML deployment as primary evidence. NLP/ARTUS and the Udacity/IBM certs as supporting signals. Do not overstate ML modeling depth — the core strength is ML *infrastructure and deployment*, not research.
|
||||
1. Languages: Python, SQL; selected historical languages only when required.
|
||||
2. Data: Kafka, Airflow, PySpark, Oracle/Teradata, data products and governance.
|
||||
3. Cloud/platform: AWS services, CloudFormation, Kubernetes, Docker, GitLab CI/CD.
|
||||
4. ML/operations: ML inference deployment and bounded observability evidence.
|
||||
5. Certifications: one line, only the most relevant credentials.
|
||||
|
||||
---
|
||||
|
||||
## Category 6: Testing & Quality Engineering
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| Test automation | Expert | Capgemini, Generali, Vizrt — consistent across 3 positions | MED (earlier career) |
|
||||
| BDD (Behaviour-Driven Development) | Proficient | Generali — introduced PoC, held technical ownership | MED |
|
||||
| Serenity-BDD / JBehave | Proficient | Generali (confirmed Zeugnis) | LOW |
|
||||
| Selenium | Proficient | Generali (UI test automation) | LOW |
|
||||
| pytest | Proficient | CV skills list | MED |
|
||||
| TDD | Proficient | Capgemini, Generali (confirmed) | LOW |
|
||||
| HP Quality Center / ALM | Familiar | Capgemini (Zeugnis confirmed) | LOW |
|
||||
| UIPath RPA | Familiar | Generali (POC developer, confirmed Zeugnis + LinkedIn) | LOW |
|
||||
| Camunda BPMN | Familiar | Generali (LinkedIn confirmed) | LOW |
|
||||
| Quality gates (CI/CD) | Proficient | Vizrt (CI/CD integration), Fraunhofer (Jenkins quality gates) | MED |
|
||||
|
||||
---
|
||||
|
||||
## Category 7: Observability, Monitoring & DevOps Tooling
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| ELK Stack (Elasticsearch/Logstash/Kibana) | Proficient | Bosch (anomaly detection PoC — primary developer) | MED |
|
||||
| Grafana | Proficient | Bosch (monitoring dashboards) | MED |
|
||||
| Prometheus | Proficient | Bosch (metrics) | MED |
|
||||
| Loki | Familiar | Bosch (log aggregation, part of PoC) | LOW |
|
||||
| Git | Expert | All positions | HIGH |
|
||||
| Agile / Scrum | Proficient | Swisscom (confirmed Zeugnis — backlog, sprint planning, Product Owner collaboration) | MED |
|
||||
| Tibco Spotfire | Familiar | Bosch (C# extensions, LinkedIn confirmed) | LOW |
|
||||
|
||||
---
|
||||
|
||||
## Category 8: Frameworks & APIs
|
||||
|
||||
| Skill | Proficiency | Evidence | Resume Weight |
|
||||
|-------|-------------|----------|---------------|
|
||||
| Flask / FastAPI / Django | Proficient | CV skills list | MED |
|
||||
| Express.js | Familiar | Fraunhofer MISSION (microservices) | LOW |
|
||||
| Entity Framework (.NET) | Proficient | Fraunhofer SCEDAS | LOW |
|
||||
| Spring Boot | Familiar | Generali (Dispatcher PoC, Apache Camel) | LOW |
|
||||
| Apache Camel | Familiar | Generali (Dispatcher PoC) | LOW |
|
||||
| SQLAlchemy | Familiar | CV skills list | LOW |
|
||||
| Swagger / OpenAPI | Familiar | CV skills list | LOW |
|
||||
|
||||
---
|
||||
|
||||
## Category 9: Domain Knowledge
|
||||
|
||||
| Domain | Depth | Source | Resume Weight |
|
||||
|--------|-------|--------|---------------|
|
||||
| Telecom / Enterprise data platforms | Proficient | Swisscom (2+ years, current) | HIGH |
|
||||
| Semiconductor manufacturing / Industry 4.0 | Proficient | Bosch (3 years) — data domains: Defect Management, Semiconductor Parameter Testing, Process Analysis, Image-based Quality Inspection | MED |
|
||||
| Maritime logistics | Familiar | Fraunhofer CML (1 year research) | LOW |
|
||||
| Broadcast technology | Familiar | Vizrt (1 year) | LOW |
|
||||
| Insurance IT / Business process automation | Familiar | Generali (2 years) | LOW |
|
||||
| Security / DevSecOps | Proficient | Swisscom Security Champion ×3 | MED |
|
||||
| Blockchain / Web3 | Familiar | Personal — RPC APIs, basic Solidity, Kraken since 2017 | LOW (bonus only) |
|
||||
|
||||
---
|
||||
|
||||
## Category 10: Certifications (Skills Signals)
|
||||
|
||||
| Certification | Issuer | Year | Active | Resume Weight |
|
||||
|--------------|--------|------|--------|---------------|
|
||||
| AWS Certified Solutions Architect – Associate | AWS | 2024 | Yes (until Sep 2027) | HIGH |
|
||||
| Data Engineering with AWS (Nanodegree) | Udacity | 2026 | Yes | HIGH |
|
||||
| iSAQB Certified Professional for Software Architecture — Foundation Level | iSAQB | 2016 | Yes (no expiry) | MED |
|
||||
| ITIL® Foundation Certificate in IT Service Management | PEOPLECERT / AXELOS | 2016 | Yes (no expiry) | LOW |
|
||||
| AI for Trading Nanodegree | Udacity / WorldQuant | 2021 | Yes | LOW (niche) |
|
||||
| Swisscom Security Champion | Swisscom (internal) | 2023–2026 | Active | MED (as bullet, not cert line) |
|
||||
| IBM AI Engineering Specialization | IBM / Coursera | — | Yes | LOW |
|
||||
|
||||
---
|
||||
|
||||
## Skills Config Guide (for resume generation)
|
||||
|
||||
Refers to `config.md` skills layout: **4-3-2-2-2** (resume) or **4-4-3-3-3** (CV).
|
||||
|
||||
### Suggested Resume Skills Groups (5 groups)
|
||||
|
||||
| Group | Label | Skills to include |
|
||||
|-------|-------|------------------|
|
||||
| 1 (4 lines) | Languages & Data | Python, PySpark, SQL (Oracle · Impala · Teradata · Postgres), Java · C# |
|
||||
| 2 (3 lines) | Cloud & Infra | AWS (S3 · Glue · Athena · Redshift · Airflow), Kubernetes · Docker · Ansible, GitLab CI/CD · Jenkins |
|
||||
| 3 (2 lines) | Pipelines & Platforms | Kafka · Airflow · SAP BODS · Hadoop, Teradata DWH · ETL/ELT design |
|
||||
| 4 (2 lines) | ML & Observability | ML inference deployment · MLOps · PyTorch · Scikit-learn, ELK Stack · Grafana · Prometheus |
|
||||
| 5 (2 lines) | Certifications | AWS Certified Solutions Architect – Associate (active), iSAQB CPSA Foundation · ITIL v3 · Data Engineering with AWS (Udacity) |
|
||||
|
||||
**Adjust per JD:** For ML/AI roles, swap group 4 to lead with ML; for Platform/Infra roles, expand cloud group. The cert line (group 5) is fixed per `config.md`.
|
||||
Never add a skill only to mirror a JD. Every listed skill must have a canonical evidence level and an interview-ready example.
|
||||
|
||||
@@ -1,43 +1,58 @@
|
||||
\documentclass[11pt,a4paper,roman]{moderncv}
|
||||
\usepackage[english]{babel}
|
||||
\moderncvstyle{classic}
|
||||
\moderncvcolor{green}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{ragged2e}
|
||||
\usepackage[scale=0.79]{geometry}
|
||||
\usepackage[version=4,arrows=pgf-filled]{mhchem}
|
||||
\renewcommand*{\makeletterclosing}{\par\vspace{2ex}\closingname\par}
|
||||
% Generate only when the session records Cover Letter Decision: YES.
|
||||
% Keep to one page and use only claims present in the canonical registry and resume.
|
||||
|
||||
% ========== CUSTOMIZE THESE ==========
|
||||
\name{[YOUR FIRST]}{[YOUR LAST]}
|
||||
\address{[Your City, State ZIP]}
|
||||
\phone[mobile]{[+1 XXXXXXXXXX]}
|
||||
\email{[your@email.com]}
|
||||
% ======================================
|
||||
\documentclass[11pt,a4paper]{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{lmodern}
|
||||
\usepackage[a4paper,left=0.85in,right=0.85in,top=0.7in,bottom=0.7in]{geometry}
|
||||
\usepackage{parskip}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{hyperref}
|
||||
\hypersetup{hidelinks}
|
||||
\pagestyle{empty}
|
||||
\setlength{\parindent}{0pt}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\recipient{To}{Hiring Committee\\[Department/Group Name]\\[Division Name]\\[Company/Institution Name]\\[City, State ZIP]}
|
||||
\date{\today}
|
||||
\opening{Dear Members of the Hiring Committee,}
|
||||
\makelettertitle
|
||||
{\Large\bfseries Dennis Thiessen, M.Eng.}\par
|
||||
% Add "Swiss B permit; no employer sponsorship required" only when useful.
|
||||
Bern, Switzerland $\vert$
|
||||
\href{mailto:dennis@thiessen.io}{dennis@thiessen.io} $\vert$ +41 795 955 585 $\vert$
|
||||
\href{https://linkedin.com/in/dennis-thiessen}{LinkedIn}
|
||||
|
||||
\begin{justify}
|
||||
% GENERATE: Paragraph 1 — Hook. Connect their work to your methodology. State the position.
|
||||
\vspace{1.5em}
|
||||
\textit{Hiring manager or team}\\
|
||||
\textit{Company}\\
|
||||
\textit{City, country}
|
||||
|
||||
% GENERATE: Paragraph 2 — Current position. Key results with quantified metrics.
|
||||
\vspace{1em}
|
||||
\today
|
||||
|
||||
% GENERATE: Paragraph 3 — Previous positions. Transferable methodology arc. Quantify.
|
||||
\vspace{1em}
|
||||
\textbf{Application for \textit{exact role title}}
|
||||
|
||||
% GENERATE: Paragraph 4 (if National Lab/Academic) — Closing. Vision + collaboration + call to action.
|
||||
\end{justify}
|
||||
\vspace{0.8em}
|
||||
Dear \textit{name or Hiring Team},
|
||||
|
||||
\vspace{0.3cm}
|
||||
% ========== CUSTOMIZE THESE ==========
|
||||
{Sincerely,\\
|
||||
[Your Full Name, Degree]\\
|
||||
[Your Current Title]\\
|
||||
[Your Current Institution]}
|
||||
% ======================================
|
||||
% Paragraph 1: specific reason for this employer/role. Use a verified first-party
|
||||
% hook only. State the strongest direct match without repeating the summary.
|
||||
\textit{Employer-specific motivation and role thesis.}
|
||||
|
||||
% Paragraph 2: one or two connected examples already supported by canonical IDs
|
||||
% and present in the resume. Explain scope, method and relevance. Do not invent a
|
||||
% metric or imply ownership of a company-wide platform.
|
||||
\textit{Evidence paragraph.}
|
||||
|
||||
% Optional paragraph 3: explain a transition, location/work-authorization point,
|
||||
% or motivation that materially helps the decision. Delete if it adds no value.
|
||||
\textit{Optional context paragraph.}
|
||||
|
||||
I would welcome the opportunity to discuss how this experience could support \textit{specific team or outcome}.
|
||||
|
||||
Kind regards,
|
||||
|
||||
\vspace{1.5em}
|
||||
Dennis Thiessen
|
||||
|
||||
\end{document}
|
||||
|
||||
@@ -1,199 +1,59 @@
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% Medium Length Professional CV - RESUME CLASS FILE
|
||||
%
|
||||
% This template has been downloaded from:
|
||||
% http://www.LaTeXTemplates.com
|
||||
%
|
||||
% This class file defines the structure and design of the template.
|
||||
%
|
||||
% Original header:
|
||||
% Copyright (C) 2010 by Trey Hunner
|
||||
%
|
||||
% Copying and distribution of this file, with or without modification,
|
||||
% are permitted in any medium without royalty provided the copyright
|
||||
% notice and this notice are preserved. This file is offered as-is,
|
||||
% without any warranty.
|
||||
%
|
||||
% Created by Trey Hunner and modified by www.LaTeXTemplates.com
|
||||
%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\ProvidesClass{resume}[2026/07/27 Evidence-first professional resume]
|
||||
\LoadClass[11pt,a4paper]{article}
|
||||
|
||||
\ProvidesClass{resume}[2018/09/25 v1.0 Resume class]
|
||||
\RequirePackage{enumitem}
|
||||
\RequirePackage{ifthen}
|
||||
\RequirePackage{lastpage}
|
||||
\RequirePackage{parskip}
|
||||
\RequirePackage{needspace}
|
||||
|
||||
\LoadClass[10pt, a4paper]{article} % Font size and paper type
|
||||
\usepackage{lastpage}
|
||||
\usepackage[parfill]{parskip} % Remove paragraph indentation
|
||||
\usepackage{array} % Required for boldface (\bf and \bfseries) tabular columns
|
||||
\usepackage{ifthen} % Required for ifthenelse statements
|
||||
\usepackage{enumitem}
|
||||
\pagestyle{empty} % Suppress page numbers
|
||||
\pagestyle{empty}
|
||||
\setlength{\parindent}{0pt}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% HEADINGS COMMANDS: Commands for printing name and address
|
||||
%----------------------------------------------------------------------------------------
|
||||
\def\@resumename{}
|
||||
\def\@resumeheadline{}
|
||||
\def\@resumecontact{}
|
||||
|
||||
\def \name#1{\def\@name{#1}} % Defines the \name command to set name
|
||||
\def \@name {} % Sets \@name to empty by default
|
||||
\newcommand{\name}[1]{\def\@resumename{#1}}
|
||||
\newcommand{\headline}[1]{\def\@resumeheadline{#1}}
|
||||
\newcommand{\contactline}[1]{\def\@resumecontact{#1}}
|
||||
|
||||
\def \addressSep {$|$} % Set default address separator to a diamond
|
||||
|
||||
% One, two or three address lines can be specified
|
||||
\let \@addressone \relax
|
||||
\let \@addresstwo \relax
|
||||
\let \@addressthree \relax
|
||||
\let \@addressfour \relax
|
||||
|
||||
% \address command can be used to set the first, second, and third address (last 2 optional)
|
||||
\def \address #1{
|
||||
\@ifundefined{@addresstwo}{
|
||||
\def \@addresstwo {#1}
|
||||
}{
|
||||
\@ifundefined{@addressthree}{
|
||||
\def \@addressthree {#1}
|
||||
}{
|
||||
\@ifundefined{@addressfour}{
|
||||
\def \@addressfour {#1}
|
||||
} {\def \@addressone {#1}
|
||||
}
|
||||
|
||||
}
|
||||
}
|
||||
\newcommand{\printresumeheader}{%
|
||||
{\LARGE\bfseries \@resumename}\par
|
||||
\vspace{0.15em}
|
||||
\ifthenelse{\equal{\@resumeheadline}{}}{}{\@resumeheadline\par}
|
||||
\vspace{0.1em}
|
||||
{\small \@resumecontact}\par
|
||||
\vspace{0.45em}
|
||||
}
|
||||
|
||||
% \printaddress is used to style an address line (given as input)
|
||||
\def \printaddress #1{
|
||||
\begingroup
|
||||
\def \\ {\addressSep\ }
|
||||
{#1}
|
||||
% \centerline{#1}
|
||||
\endgroup
|
||||
\par
|
||||
% \addressskip
|
||||
}
|
||||
\AtBeginDocument{\printresumeheader}
|
||||
|
||||
% \printname is used to print the name as a page header
|
||||
\def \printname {
|
||||
\begingroup
|
||||
% \MakeUppercase
|
||||
{\namesize\bf \@name} \hfil
|
||||
% \hfil{\MakeUppercase{\namesize\bf \@name}}\hfil
|
||||
\nameskip\break
|
||||
\endgroup
|
||||
}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% PRINT THE HEADING LINES
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
\let\ori@document=\document
|
||||
\renewcommand{\document}{
|
||||
\ori@document % Begin document
|
||||
% \begin{center}
|
||||
\printname % Print the name specified with \name
|
||||
\@ifundefined{@addressone}{}{ % Print the first address if specified
|
||||
\printaddress{\@addressone}}
|
||||
\@ifundefined{@addresstwo}{}{ % Print the second address if specified
|
||||
\printaddress{\@addresstwo}}
|
||||
\@ifundefined{@addressthree}{}{ % Print the third address if specified
|
||||
\printaddress{\@addressthree}}
|
||||
\@ifundefined{@addressfour}{}{ % Print the third address if specified
|
||||
\printaddress{\@addressfour}}
|
||||
|
||||
% \end{center}
|
||||
}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% SECTION FORMATTING
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
% Defines the rSection environment for the large sections within the CV
|
||||
\newenvironment{rSection}[1]{ % 1 input argument - section name
|
||||
\sectionskip
|
||||
{\bf #1}
|
||||
% \MakeUppercase{\bf #1} % Section title
|
||||
\sectionlineskip
|
||||
\hrule % Horizontal line
|
||||
\begin{list}{}{ % List for each individual item in the section
|
||||
\setlength{\leftmargin}{0.50em} % Margin within the section
|
||||
}
|
||||
\item[]
|
||||
}{
|
||||
\end{list}
|
||||
}
|
||||
|
||||
\newenvironment{rSection2}[1]{ % 1 input argument - section name
|
||||
\sectionskip
|
||||
{\bf #1} % Section title
|
||||
\sectionlineskip
|
||||
\hrule % Horizontal line
|
||||
\medskip
|
||||
\begin{list}{$\bullet$}{\setlength{\leftmargin}{1.5em}}
|
||||
\itemsep -0.3em \vspace{-0.5em} % Compress items in list together for aesthetics
|
||||
}{
|
||||
\end{list}
|
||||
\vspace{0.5em}
|
||||
}
|
||||
|
||||
\newenvironment{rSection3}[1]{ % 1 input argument - section name
|
||||
\sectionskip
|
||||
{\bf #1} % Section title
|
||||
\sectionlineskip
|
||||
\hrule % Horizontal line
|
||||
\medskip
|
||||
\begin{enumerate}[]{\setlength{\leftmargin}{1.5em}}
|
||||
\itemsep -0.3em \vspace{-0.5em} % Compress items in list together for aesthetics
|
||||
}{
|
||||
\end{enumerate}
|
||||
\vspace{0.5em}
|
||||
}
|
||||
%----------------------------------------------------------------------------------------
|
||||
% WORK EXPERIENCE FORMATTING
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
\newenvironment{rSubsection}[4]{ % 4 input arguments - company name, year(s) employed, job title and location
|
||||
{\bf #1} \hfill {#2} % Bold company name and date on the right
|
||||
\ifthenelse{\equal{#3}{}}{}{ % If the third argument is not specified, don't print the job title and location line
|
||||
\\
|
||||
{\em #3} \quad {\em #4} % Italic job title and location
|
||||
}\smallskip
|
||||
\begin{list}{$\cdot$}{\leftmargin=1.5em} % \cdot used for bullets, no indentation
|
||||
\itemsep -0.2em \vspace{-0.2em} % Compress items in list together for aesthetics
|
||||
}{
|
||||
\end{list}
|
||||
\vspace{0.2 em} % Some space after the list of bullet points
|
||||
}
|
||||
|
||||
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% FORMAT C SKILLS COMMANDS
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
% Skills group environment: \begin{skillgroup}{Group Name} ... \end{skillgroup}
|
||||
% Renders bold header + indented dash sub-items. Each \skilldash = exactly 1 rendered line.
|
||||
\newenvironment{skillgroup}[1]{%
|
||||
\textbf{#1}\par\nopagebreak%
|
||||
\vspace{-\parskip}%
|
||||
\begin{list}{--}{\leftmargin=0.8em \labelsep=0.3em \itemsep=0pt \topsep=0.1em \parsep=0pt \partopsep=0pt}%
|
||||
\newenvironment{rSection}[1]{%
|
||||
\vspace{0.35em}
|
||||
{\bfseries #1}\par
|
||||
\vspace{0.1em}\hrule\vspace{0.35em}
|
||||
}{%
|
||||
\end{list}%
|
||||
\vspace{-\parskip}\vspace{0.45em}%
|
||||
\vspace{0.2em}
|
||||
}
|
||||
|
||||
% Single dash sub-item within a skillgroup. Content must fit 1 rendered line.
|
||||
% Char limit: 119 - (0.5 x bold_char_count) at 10pt
|
||||
\newcommand{\skilldash}[1]{\item #1}
|
||||
% Arguments: employer, dates, formal title, location.
|
||||
\newenvironment{rSubsection}[4]{%
|
||||
\Needspace{6\baselineskip}%
|
||||
{\bfseries #1}\hfill{\small #2}\par
|
||||
{\itshape #3}\hfill{\itshape #4}\par
|
||||
\vspace{0.1em}
|
||||
\begin{itemize}[leftmargin=1.25em,label=\textbullet,itemsep=0.18em,topsep=0.15em,parsep=0pt,partopsep=0pt]
|
||||
}{%
|
||||
\end{itemize}
|
||||
\vspace{0.25em}
|
||||
}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% EXPERIENCE SUB-THEME COMMAND
|
||||
%----------------------------------------------------------------------------------------
|
||||
\newcommand{\skillline}[2]{%
|
||||
\textbf{#1:} #2\par
|
||||
\vspace{0.08em}
|
||||
}
|
||||
|
||||
% Sub-theme underline header within rSubsection
|
||||
\newcommand{\subtheme}[1]{\item[] \underline{#1}}
|
||||
|
||||
% The below commands define the whitespace after certain things in the document - they can be \smallskip, \medskip or \bigskip
|
||||
\def\namesize{\huge} % Size of the name at the top of the document
|
||||
\def\addressskip{\smallskip} % The space between the two address (or phone/email) lines
|
||||
\def\sectionlineskip{\medskip} % The space above the horizontal line for each section
|
||||
\def\nameskip{\medskip} % The space after your name at the top
|
||||
\def\sectionskip{\medskip} % The space after the heading section
|
||||
\newcommand{\compactentry}[2]{%
|
||||
\textbf{#1}\hfill #2\par
|
||||
}
|
||||
|
||||
@@ -1,236 +1,83 @@
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% TEMPLATE: Resume (resume.cls) -- structural reference for Claude generation
|
||||
% Copy this structure exactly. Replace [GENERATE: ...] placeholders with JD-tailored content.
|
||||
% FIXED sections: contain actual data -- never modify during generation
|
||||
% GENERATE sections: Claude fills in per JD using the uploaded bundle
|
||||
%
|
||||
% SETUP INSTRUCTIONS:
|
||||
% 1. Fill [CONFIG: ...] markers with values from your config.md
|
||||
% 2. Fill FIXED sections (Education, Awards, etc.) with your actual content
|
||||
% 3. Leave [GENERATE: ...] markers -- Claude fills these per JD
|
||||
% 4. Calibrate page budget after filling FIXED content (compile + count lines)
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% Default profile: International Tech resume for US-tech/FAANG-style roles in Europe.
|
||||
% Copy this file and resume.cls into a new output folder. Generate only from
|
||||
% resume_builder/canonical/claims.json plus normalized experience files.
|
||||
|
||||
\documentclass{resume}
|
||||
\usepackage{hyperref}
|
||||
\usepackage{enumitem}
|
||||
\usepackage{fontawesome}
|
||||
\usepackage{tikz}
|
||||
\usepackage{graphicx}
|
||||
\hypersetup{
|
||||
colorlinks = true,
|
||||
linkcolor = [rgb]{0.9,0.4,0.4},
|
||||
anchorcolor = [rgb]{0.9,0.4,0.4},
|
||||
citecolor = [rgb]{0.4,0.4,0.4},
|
||||
filecolor = [rgb]{0.4,0.4,0.4},
|
||||
urlcolor = [rgb]{0.0,0.0,0.99},
|
||||
}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{lmodern}
|
||||
\usepackage[a4paper,left=0.65in,right=0.65in,top=0.55in,bottom=0.55in]{geometry}
|
||||
\usepackage{xcolor}
|
||||
\usepackage[version=4,arrows=pgf-filled]{mhchem}
|
||||
\usepackage[includefoot,left=0.5in,top=0.5in,right=0.5in,bottom=0.2in,textwidth=7.5in,textheight=10.8in]{geometry}
|
||||
\usepackage{hyperref}
|
||||
\hypersetup{hidelinks}
|
||||
\usepackage[version=4]{mhchem}
|
||||
\usepackage{fancyhdr}
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
\renewcommand{\headrulewidth}{0pt}
|
||||
\fancyfoot[R]{\hfill \thepage/\pageref{LastPage}}
|
||||
\newcommand{\tab}[1]{\hspace{.2667\textwidth}\rlap{#1}}
|
||||
\newcommand{\itab}[1]{\hspace{0em}\rlap{#1}}
|
||||
\fancyfoot[R]{\small \thepage/\pageref{LastPage}}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% HEADER — FIXED (fill from config.md)
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
% FIXED: Name -- from config.md
|
||||
\name{[CONFIG: Full Name, Degree]}
|
||||
|
||||
% FIXED: Links -- include whichever you have; delete unused lines
|
||||
\address{\href{[CONFIG: website URL]}{[CONFIG: site display]} \\ \href{[CONFIG: LinkedIn URL]}{LinkedIn} \\ \href{[CONFIG: Google Scholar URL]}{Google Scholar}}
|
||||
% FIXED: Contact
|
||||
\address{[CONFIG: email] \\ [CONFIG: phone]}
|
||||
% GENERATE: Relocation target per JD
|
||||
\address{[CONFIG: City, State] (Open to relocation to [Target City])}
|
||||
% GENERATE: Tagline -- rewrite per JD using bundle Section 2 building blocks
|
||||
% Use $\vert$ as separator between tagline phrases
|
||||
\address{{[GENERATE: Role Title $\vert$ Domain Specialty $\vert$ Key Method or Impact]}}
|
||||
\name{Dennis Thiessen, M.Eng.}
|
||||
% Tailor this professional identity only within verified evidence.
|
||||
\headline{Staff Data Engineer $\vert$ AWS Data Platforms $\vert$ Production ML Delivery}
|
||||
% Optional when relevant: Swiss B permit; no employer sponsorship required.
|
||||
\contactline{Bern, Switzerland $\vert$ \href{mailto:dennis@thiessen.io}{dennis@thiessen.io} $\vert$ +41 795 955 585 $\vert$ \href{https://linkedin.com/in/dennis-thiessen}{LinkedIn}}
|
||||
|
||||
\begin{document}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% GENERATION REFERENCE (for Claude -- not rendered in PDF)
|
||||
%----------------------------------------------------------------------------------------
|
||||
% CHARACTER LIMITS (rendered chars — strip \textbf{}, \textit{}, \ce{}, $..$ before counting):
|
||||
% Chars per line (CPL): ~111-115 at 10pt (varies with char width distribution)
|
||||
%
|
||||
% Resume-1L bullet: target 105-111 chars | HARD MAX 117
|
||||
% Resume-2L bullet: target 189-205 chars | HARD MAX 218 | orphan >= 78 chars
|
||||
%
|
||||
% AIM FOR TARGET MIDDLE (200 for 2L) — NOT the hard max.
|
||||
% Em-dash (---) counts as 1 char but renders ~2x wide. Budget 2 extra per em-dash.
|
||||
% Bold in bullets: ~0.42 penalty/bold char (10 bold chars ≈ lose 4 chars capacity).
|
||||
%
|
||||
% PAGE FILL BUDGET:
|
||||
% After filling FIXED sections, compile and count rendered lines per page.
|
||||
% Remaining lines = your variable bullet budget.
|
||||
% Example for 2-page resume with 5 skill groups:
|
||||
% Skills 4-3-2-2-2 (13 lines): ~21 variable bullets (2L each)
|
||||
% Skills 4-4-2-2-2 (14 lines): ~20 variable bullets
|
||||
% Variable bullets = sum of all GENERATE position bullets
|
||||
% FIXED position bullets are NOT counted in the variable budget.
|
||||
%
|
||||
% POSITION FORMAT (FLIPPED):
|
||||
% Bold line = JD-customized domain theme (strongest customization lever)
|
||||
% Subtitle (italic) = formal role + institution
|
||||
% FIXED positions keep the same theme in every resume.
|
||||
|
||||
\vspace{-0.15cm}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% SUMMARY — GENERATE per JD
|
||||
%----------------------------------------------------------------------------------------
|
||||
% GENERATE: Rewrite per JD using bundle Section 2 building blocks
|
||||
% 5 body lines (4-5 sentences). Lead with years of experience + primary methods.
|
||||
% End with publication/citation metrics if applicable.
|
||||
% Max 1 paragraph -- no line breaks.
|
||||
\begin{rSection}{Summary}
|
||||
[GENERATE: [Domain] scientist with [N]+ years combining \textbf{[primary method]} and \textbf{[secondary method]} for [application domain]. [1-2 sentences on key accomplishments tailored to JD]. [Metrics: publications, citations, awards if applicable].]
|
||||
Staff data engineer with 12+ years of production software experience across telecom, semiconductor manufacturing, broadcast technology and insurance. Owns business-critical pipeline components at Swisscom and previously integrated containerized ML inference into a continuously operating Bosch semiconductor fab.
|
||||
\end{rSection}
|
||||
\vspace{-0.15cm}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% TECHNICAL SKILLS — GENERATE per JD (Format C)
|
||||
%----------------------------------------------------------------------------------------
|
||||
% GENERATE: 5 groups in Format C (categorized dash sub-items)
|
||||
% Default config from config.md (e.g. 4-3-2-2-2 = 13 content lines)
|
||||
% Load skills_taxonomy.md to map JD keywords to skill entries
|
||||
% Group names are JD-customizable; order most JD-relevant first
|
||||
% Bold 6-8 tools that most directly match JD keywords
|
||||
% Each dash item = exactly 1 rendered line (~105-111 chars), no wrapping
|
||||
\begin{rSection}{Technical Skills}
|
||||
% FORMAT C: Use \skillgroup{} and \skilldash{} commands from resume.cls
|
||||
% Each \skilldash = exactly 1 rendered line. Char limit: 119 - (0.5 x bold_chars)
|
||||
\skillline{Languages}{Python, SQL; Java and C\# (professional, historical); C++ and JavaScript (limited historical use)}
|
||||
\skillline{Data}{Apache Kafka, Airflow, PySpark, Oracle, Teradata, Hadoop/Impala, data products, metadata and governance}
|
||||
\skillline{Cloud and platform}{AWS (S3, Glue, Athena/Iceberg, Redshift), CloudFormation, Kubernetes, Docker, GitLab CI/CD, Ansible}
|
||||
\skillline{ML delivery}{Production inference deployment and support, on-call operations; ELK, Grafana and Prometheus proof-of-concept work}
|
||||
\skillline{Certifications}{AWS Solutions Architect -- Associate; Data Engineering with AWS; iSAQB CPSA-F; ITIL Foundation}
|
||||
\end{rSection}
|
||||
|
||||
\begin{skillgroup}{[GENERATE: Most JD-Relevant Domain]}
|
||||
\skilldash{[GENERATE: tools, methods — max ~105-111 chars with bold penalty]}
|
||||
\skilldash{[GENERATE]}
|
||||
\skilldash{[GENERATE]}
|
||||
\end{skillgroup}
|
||||
\begin{rSection}{Professional Experience}
|
||||
|
||||
\begin{skillgroup}{[GENERATE: Second Domain]}
|
||||
\skilldash{[GENERATE]}
|
||||
\skilldash{[GENERATE]}
|
||||
\end{skillgroup}
|
||||
\begin{rSubsection}{Swisscom (Schweiz) AG}{Oct 2023 -- Present}{Staff Data, Analytics \& AI Engineer (promoted from Senior, Apr 2025)}{Bern, Switzerland}
|
||||
\item Own Fulfillment ETL pipeline components as Component Owner, covering production operation, data quality, governance, incidents and on-call obligations across Oracle, Kafka, Python and Teradata processing.
|
||||
\item Migrated pipelines in the Fulfillment and Product Analysis domains onto Swisscom's AWS platform using Glue, Athena/Iceberg, Redshift, Airflow and CloudFormation while contributing to the wider migration programme.
|
||||
\item Build governed data products and active metadata within Swisscom's company-wide Data Mesh, supporting discoverable data access for analytics and AI use cases.
|
||||
\item Build and operate Python data applications on Kubernetes with GitLab CI/CD, covering containerized delivery from test through production operation.
|
||||
\end{rSubsection}
|
||||
\end{rSection}
|
||||
|
||||
\begin{skillgroup}{[GENERATE: Third Domain]}
|
||||
\skilldash{[GENERATE]}
|
||||
\end{skillgroup}
|
||||
% Default two-page balance: keep the most recent role on page 1 and start the
|
||||
% second major evidence block on page 2. Recheck this break after tailoring.
|
||||
\newpage
|
||||
|
||||
\begin{skillgroup}{[GENERATE: Fourth Domain]}
|
||||
\skilldash{[GENERATE]}
|
||||
\end{skillgroup}
|
||||
\begin{rSection}{Professional Experience (continued)}
|
||||
\begin{rSubsection}{Robert Bosch Semiconductor Manufacturing Dresden GmbH}{Feb 2020 -- Dec 2022}{Senior Engineer, Data Analysis (Data \& ML Engineering)}{Dresden, Germany}
|
||||
\item Integrated containerized ML inference with Docker, Kubernetes and Ansible into a continuously operating semiconductor-fab environment for automated image-based defect classification.
|
||||
\item Served as Application Owner for analytics applications and upstream pipelines, defining SLOs and transition scope while coordinating vendors, user training and documentation.
|
||||
\item Developed Python, Java and C\# data services over Oracle and Hadoop/Impala for defect-management and process-analysis teams.
|
||||
\item Co-owned the TIBCO Spotfire environment, built C\# extensions and wafer-map visualizations, and co-presented the work at TIBCO Analytics Forum 2022.
|
||||
\end{rSubsection}
|
||||
|
||||
\begin{skillgroup}{[GENERATE: Programming \& Tools]}
|
||||
\skilldash{[GENERATE]}
|
||||
\end{skillgroup}
|
||||
\begin{rSubsection}{Fraunhofer CML}{Sep 2018 -- Oct 2019}{Research Software Engineer}{Hamburg, Germany}
|
||||
\item Set up Jenkins CI/CD with quality gates, developed C\#/.NET software and built containerized microservices for maritime research platforms.
|
||||
\end{rSubsection}
|
||||
|
||||
\begin{rSubsection}{Vizrt}{Jul 2017 -- May 2018}{Test Automation / DevOps Engineer}{Bergen, Norway}
|
||||
\item Contributed Python and C++ engineering to a distributed video-transcoding backend and developed automated audio/video integration tests connected to CI/CD quality gates.
|
||||
\end{rSubsection}
|
||||
|
||||
\begin{rSubsection}{Generali Deutschland Informatik Services GmbH}{May 2015 -- Jun 2017}{IT Consultant}{Hamburg, Germany}
|
||||
\item Introduced BDD test automation through a proof of concept, held technical responsibility for the suite and Jenkins jobs, and trained colleagues in the Java community.
|
||||
\end{rSubsection}
|
||||
|
||||
\end{rSection}
|
||||
\vspace{-0.15cm}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% EXPERIENCE — GENERATE bullets per JD; position headers are FIXED
|
||||
%----------------------------------------------------------------------------------------
|
||||
% Add one rSubsection per position. Most recent first.
|
||||
% FLIPPED format: Bold line = JD-customized theme; italic = formal role + institution.
|
||||
% Mark any position as FIXED if its bullets never change across JDs.
|
||||
\begin{rSection}{Research Experience}
|
||||
|
||||
% --- Position 1 (most recent) ---
|
||||
% GENERATE: Select bullets from bundle; bold theme line customized to JD
|
||||
\begin{rSubsection}{[GENERATE: JD-Customized Theme]}{\textcolor{black!60}{[FIXED: Start -- End]}}{[FIXED: Title, Institution]}{}
|
||||
\item [GENERATE: Bullet 1 -- strongest JD-relevant accomplishment]
|
||||
\item [GENERATE: Bullet 2]
|
||||
\item [GENERATE: ...]
|
||||
\end{rSubsection}
|
||||
|
||||
% --- Position 2 ---
|
||||
\begin{rSubsection}{[GENERATE: JD-Customized Theme]}{\textcolor{black!60}{[FIXED: Start -- End]}}{[FIXED: Title, Institution]}{}
|
||||
\item [GENERATE: Bullet 1]
|
||||
\item [GENERATE: ...]
|
||||
\end{rSubsection}
|
||||
|
||||
% --- Position 3 ---
|
||||
\begin{rSubsection}{[GENERATE: JD-Customized Theme]}{\textcolor{black!60}{[FIXED: Start -- End]}}{[FIXED: Title, Institution]}{}
|
||||
\item [GENERATE: Bullet 1]
|
||||
\item [GENERATE: ...]
|
||||
\end{rSubsection}
|
||||
|
||||
% --- Optional: FIXED position (e.g. early-career internship that never changes) ---
|
||||
% Uncomment and fill if you have a short position whose bullets are always the same:
|
||||
% \begin{rSubsection}{[FIXED: Theme]}{\textcolor{black!60}{[FIXED: Dates]}}{[FIXED: Title, Institution]}{}
|
||||
% \item [FIXED: Bullet — same in every resume]
|
||||
% \item [FIXED: Bullet — same in every resume]
|
||||
% \end{rSubsection}
|
||||
|
||||
\end{rSection}
|
||||
\vspace{-0.15cm}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% EDUCATION — FIXED: Fill with your actual education
|
||||
%----------------------------------------------------------------------------------------
|
||||
% Each entry: {Degree (honors)} \hfill {Years} \\ {Institution}, Location \hfill GPA
|
||||
|
||||
\begin{rSection}{Education}
|
||||
{[FIXED: Degree Title]} \hfill {\textcolor{black!60}{[FIXED: Start -- End]}}\\
|
||||
{[FIXED: Institution]}, [FIXED: Location] \hfill GPA: \textbf{[FIXED]}/[FIXED]
|
||||
\compactentry{M.Eng. Computer Aided Engineering (Software Design \& Engineering), Universität der Bundeswehr München}{Apr 2012 -- Oct 2013}
|
||||
Thesis at Tongji University, Shanghai: \textit{Development of a Web-Based Remote Fault Diagnosis System}; grade 1.0.
|
||||
|
||||
{[FIXED: Degree Title]} \hfill {\textcolor{black!60}{[FIXED: Start -- End]}}\\
|
||||
{[FIXED: Institution]}, [FIXED: Location] \hfill GPA: \textbf{[FIXED]}/[FIXED]
|
||||
\compactentry{B.Eng. Information and Telecommunication Technologies, Universität der Bundeswehr München}{Oct 2009 -- Oct 2012}
|
||||
\end{rSection}
|
||||
\vspace{-0.15cm}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% SELECTED PUBLICATIONS — GENERATE: Claude picks 5 per JD relevance
|
||||
%----------------------------------------------------------------------------------------
|
||||
% GENERATE: Score publications per JD relevance using pub_metadata.md
|
||||
% Copy-paste FIXED author + journal LaTeX blocks from pub_metadata.md
|
||||
% GENERATE JD-shortened title + JD-relevant keyword tags at runtime
|
||||
% 2-line hard limit per entry, last line >= 70% filled
|
||||
% Prioritize: first-author > co-first > contributing; high-impact > standard
|
||||
\begin{rSection2}{Selected Publications (\href{[CONFIG: Google Scholar URL]}{Google Scholar}: [FIXED: N] papers $\vert$ [FIXED: N]+ citations)}
|
||||
|
||||
\item [GENERATE: Publication 1 -- most JD-relevant, short format]
|
||||
|
||||
\item [GENERATE: Publication 2]
|
||||
|
||||
\item [GENERATE: Publication 3]
|
||||
|
||||
\item [GENERATE: Publication 4]
|
||||
|
||||
\item [GENERATE: Publication 5]
|
||||
|
||||
\end{rSection2}
|
||||
\vspace{-0.15cm}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% HONORS & AWARDS — FIXED: Fill with your actual awards
|
||||
%----------------------------------------------------------------------------------------
|
||||
% Format: \item \textbf{Award}, Granting Body (Year). Brief context.
|
||||
% Aim for 1 rendered line each. Adjust count to fit page budget.
|
||||
|
||||
\begin{rSection2}{Honors \& Awards}
|
||||
\item \textbf{[FIXED: Award]}, [FIXED: Body] ([FIXED: Year]). [FIXED: context].
|
||||
\item \textbf{[FIXED: Award]}, [FIXED: Body] ([FIXED: Year]). [FIXED: context].
|
||||
\item \textbf{[FIXED: Award]}, [FIXED: Body] ([FIXED: Year]). [FIXED: context].
|
||||
\end{rSection2}
|
||||
\vspace{-0.1cm}
|
||||
|
||||
%----------------------------------------------------------------------------------------
|
||||
% IMMIGRATION — FIXED content, include/exclude per JD
|
||||
% USA JD: keep this block | Non-USA JD: delete (frees ~2 lines)
|
||||
%----------------------------------------------------------------------------------------
|
||||
|
||||
\begin{center}
|
||||
\vspace{0.15cm}
|
||||
\textit{[CONFIG: Immigration status line from config.md]}
|
||||
\end{center}
|
||||
|
||||
\end{document}
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
% Swiss/DACH alternative. Use only when local conventions suit the employer.
|
||||
% The photo remains opt-in; never add one automatically.
|
||||
\input{resume_template.tex}
|
||||
|
||||
% Generation instructions:
|
||||
% 1. Keep the same conventional employer/title/date structure and evidence rules.
|
||||
% 2. A professional photo may be added only after explicit user approval.
|
||||
% 3. Swiss B residence permit and no-sponsorship status are verified. Mention
|
||||
% them only when useful; they do not need to consume header space by default.
|
||||
% 4. Attach employer references and diplomas as separate portal files only when requested.
|
||||
% 5. Do not add date of birth, marital status, gender or children.
|
||||
Reference in New Issue
Block a user