dennisthiessenandClaude Opus 5.5
504fa373f7
Application - Kongsberg Discovery / Seatex, Lead Engineer DevOps and Test Infrastructure (Trondheim): resume, cover letter (+ paste text), verbatim JD, session and critique. Submitted 2026-10-08 via EasyCruit as a deliberate cold application on a user override of the embedded-SW hard gate (Evidence Fit 69, Document Quality 84). Recorded in applications.json and decisions.json. - Google Senior SWE Full Stack Commerce: session and verbatim JD from 2026-10-03 (no-go on the frontend gap, held, not submitted). Knowledge base - claims.json: ED-1 (embedded/robotics coursework, none since studies), SW-9 (current unit testing, pytest), new skills (pytest, unit testing, embedded systems (coursework), VHDL, robotics (coursework)), and Jenkins and GitLab CI/CD registered from existing GN-1/FC-1/BS-6/SW-3 scopes. - Earlier uncommitted KB work: 2026-09-18 Python frameworks / enterprise SaaS clarification, 2026-10-03 data-product design / no-frontend clarification, 2026-10-06 working-model rule (3 homeoffice days baseline) in config.md and application_strategy.md, plus related experience/bundle/taxonomy updates. - CLAUDE.md corrections log: 2026-10-08 entry for the three canonical gaps. Scout - 2026-10-08 run triaged by JD read: NVIDIA DGX Cloud Senior Production Engineer, Google SRE III Prod AI / Senior SRE / Staff Shopping Graph and Amazon RIVR DevOps logged as maybe; GenAI FDE family, Kraken AI Platform, PostFinance DevOps and five Kdo Cy reqs logged as skip with reasons. Housekeeping - .gitignore: ignore .cache/ and raw HTML page dumps under output/. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
128 lines
6.8 KiB
Markdown
128 lines
6.8 KiB
Markdown
# 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.
|
|
|
|
## Working Model and Total Package
|
|
|
|
User clarification, 2026-10-06: the current position provides 3 homeoffice days per week.
|
|
Fewer days are acceptable only for a clear overall improvement over the current role.
|
|
Assess compensation, scope, development, commute, working time and benefits together;
|
|
the user has not specified a numerical improvement threshold. Clarify these terms early.
|
|
Do not treat fewer than 3 homeoffice days as an automatic no-go or assume a prestigious
|
|
employer compensates for reduced flexibility. The user expects such improvements mainly
|
|
at FAANG or comparable employers; this remains an expectation rather than an employer restriction.
|
|
|
|
The internal Swisscom Geo Platform application is a separate task change: according to
|
|
the user (2026-10-06), position and seniority remain unchanged and salary would not change
|
|
substantially. Assess it independently of the external-upgrade objective. The external search
|
|
continues without waiting for its outcome and remains active even if the internal move succeeds.
|
|
|
|
## 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.
|
|
|
|
## Application Record (no quotas)
|
|
|
|
**Policy change, 2026-09-05, user decision: the 7 Core / 2 Adjacent / 1 Stretch caps are DROPPED.**
|
|
|
|
The caps were arbitrary -- no derivation existed for those numbers -- and they were routed around
|
|
whenever they bound (RUAG AI Engineer went in at Evidence Fit 74 with a hard-gate FAIL; Citadel was
|
|
recorded Adjacent when the strict reading said Stretch). A rule that is overridden whenever it binds
|
|
governs nothing and only adds friction.
|
|
|
|
The cohort was also a confounded experiment. It was designed to test **fit class**, but the variable
|
|
it silently held constant was **channel**: all six applications were Weak/cold. It therefore could not
|
|
distinguish "Stretch does not convert" from "cold does not convert", and the results point away from
|
|
fit class anyway -- the highest-scoring package in the log (Snowflake, ~86) drew no reply in 80 days,
|
|
while the one interview (SBB) came from a cold Core submit whose resume was *missing* the three ATS
|
|
literals the session had flagged as risky.
|
|
|
|
**What is kept: the recording, not the rationing.** Every application still records fit class, hard
|
|
gate, channel, date, stage and outcome. That record is what makes patterns visible instead of
|
|
re-derived. `job_scout/state/applications.json` is the durable registry; `application_cohort.json` is
|
|
a generated historical-cohort projection. `cohort_tracker.py summary` is a read-only view. There is no slot to consume and no
|
|
application is blocked for lack of one.
|
|
|
|
**Fit class is now a preparation signal, not a spend limit.** An Evidence Fit of 64 does not mean
|
|
"do not apply" -- it means know which two questions you will be asked and have honest answers ready.
|
|
Hard gates and NO-GO triggers are unchanged: a required Gap or an unresolved practical constraint is
|
|
still a real finding that must be surfaced before the user decides.
|
|
|
|
### Real constraints that survive independently of any quota
|
|
|
|
These are not cohort discipline and must not be dropped with it:
|
|
|
|
- **Google: 3 applications per rolling 30 days**, and a 90-day wait before reapplying to the *same*
|
|
role. An external, enforced limit.
|
|
- **Do not stack a second cold application on one organisation while the first is pending** -- a
|
|
judgment call, made deliberately before (Snowflake Metrics was paused for exactly this).
|
|
- **Each package costs real hours.** Volume is limited by effort, not by policy.
|
|
|
|
## Channel Strategy
|
|
|
|
**Channel is the rationed variable, replacing the old slot budget** (2026-09-05). It is the constraint
|
|
with a plausible effect and an untested one: the record stands at **six consecutive cold submits, one
|
|
interview**, with zero Strong or Moderate channels ever attempted.
|
|
|
|
**Rule: no application goes out cold when a named contact is published and reachable.**
|
|
|
|
This has been available and unused repeatedly -- Marco Heinzen at RUAG (published direct line), Andri
|
|
Wienandts at SBB (published number, and it still converted), Per Olav Marthinsen at Aker BP. Making
|
|
contact costs one phone call or one short email and is the cheapest experiment left.
|
|
|
|
For every 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.
|
|
When no contact is published anywhere, a cold submit is fine -- record it as Weak and move on.
|
|
|
|
## 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
|
|
|
|
Review the record whenever a meaningful screen or interview result lands, and compare:
|
|
|
|
- Warm vs cold progression -- **the primary question now, and still unanswered.**
|
|
- Core vs Adjacent/Stretch 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.
|