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>
6.8 KiB
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.