diff --git a/README.md b/README.md index 743ab7c..90a477b 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,301 @@ # job-affirm -Pipeline intel + artifact plan for Affirm Staff SWE (Continuous Integration). Surface only — no outreach sent. \ No newline at end of file +> Affirm is Scott Scoble's job-pipeline bucket for **Staff SWE (Continuous Integration)** at Affirm. This repo is the surface — JD snapshot, hiring-manager public surface, the Speckl x Bazel provenance deep-dive artifact plan, and an outreach log (currently empty — no contact made). + +Source: boards-api.greenhouse.io/v1/boards/affirm/jobs/7749580003 + public Affirm GitHub org (github.com/affirm) + LinkedIn / engineering blog (cloudflare-walled at capture time, 2026-06-18). Captured 2026-06-18 by the job-pipeline subagent. + +--- + +## Why Affirm (audience fit) + +Affirm's CI role is a **Bazel + monorepo + AWS/K8s** Staff role inside the "Infrastructure Platform Eng" org. Three direct lines of fit with Scott's positioning as **"Human-Maximizer for Agentic Engineering Systems"** (anchor product: Speckl — compile-time provenance, SBOM, CycloneDX / SPDX / PROV-O): + +| Scott's pillar | Affirm surface | +|---|---| +| Compile-time provenance | Speckl emits CycloneDX/SPDX/PROV-O; Affirm's CI team is exactly the consumer surface for those artifacts | +| Bazel + monorepo | JD says "Preferred experience in Bazel" + "managing build systems and frameworks for large monorepos" — direct Bazel is Scott's working language | +| Open-source as a hard soft requirement | JD: "Active contributor to open source projects … is a plus" — Scott's two books, Scobleclaw, and Speckl-flashcards all count | +| AWS / K8s / Python+Kotlin+Java | JD list of stack — overlaps exactly with Scott's environment | + +The artifact plan in section 3 frames the Speckl x Bazel provenance story as a **staff-level technical contribution**, not a portfolio piece — it shows Scott can land inside the CI team and ship a system, not just describe one. + +--- + +## 1. JD snapshot (verbatim + structured) + +Source: Greenhouse JSON API `https://boards-api.greenhouse.io/v1/boards/affirm/jobs/7749580003`, captured 2026-06-18T13:14 EDT. Updated 2026-06-18 by Affirm. **First published 2026-05-27.** + +| Field | Value | +|---|---| +| Title | Staff Software Engineer (Continuous Integration) | +| Greenhouse ID | 7749580003 | +| Requisition | JR103979 | +| Internal job ID | 5771108003 | +| Department | Infrastructure Platform Eng (id 4041949003; parent 4005044003) | +| External Department metadata | Engineering | +| PERM Job? | false (metadata flag — likely a flagging error; the role is full-time) | +| Pay grade | P | +| Equity grade | 13 | +| Locations | Remote US; Remote Canada (sibling posting) | +| Workplace | Remote (USA base pay range CA/WA/NY/NJ/CT: $230,000 - $290,000; all other US states: $204,000 - $264,000) | +| Public URL | https://job-boards.greenhouse.io/affirm/jobs/7749580003 | +| LinkedIn mirror | https://www.linkedin.com/jobs/view/4418858987 | +| BestRemoteJobs mirror | https://www.bestremotejobs.com/jobs/affirm-582003-staff-software-engineer-backend-continuous-integration | + +### 1.1 What you'll do (verbatim) + +- **Systems and Operations** — own the design, scalability, and reliability of build and pipelines across multiple services and platforms; ensure fast, reliable feedback cycles for developers by optimizing build times, test coverage, and reporting; implement monitoring, alerting, and incident response for CI systems. +- **Collaboration and Enablement** — work closely with engineering to ensure smooth integrations and deployment workflows; identify developer pain points and lead initiatives to improve productivity through tooling, automation, and best practices; evangelize CI/CD practices across the organization. +- **Leadership and Strategy** — contribute to and help drive the vision for continuous integration and developer productivity infrastructure; lead and mentor other CI engineers, fostering ownership, collaboration, technical excellence; partner with engineering leadership to align CI systems with broader product and platform goals. + +### 1.2 What we look for (verbatim) + +- Proven experience driving and leading engineering efforts in CI, build systems, or developer productivity domains. +- Strong background in modern build systems (e.g. **GitHub, Buildkite, Artifactory, Bazel**). +- Familiarity with cloud-native environments (**AWS, Kubernetes**) and infrastructure-as-code practices. +- Solid programming background (**Python, Kotlin, Java**, or similar) and ability to guide technical decision-making. +- Excellent problem-solving skills — balance long-term vision with short-term impact. +- Equivalent practical experience OR Bachelor's degree in a related field. +- Proficiency with managing build systems and frameworks for large monorepos. **Preferred experience in Bazel.** +- **Active contributor to open source projects** or previous experience with large-scale software development at a leading tech company is a plus. + +### 1.3 About you (verbatim) + +- Driven by a passion for CI/CD and deep commitment to enhancing developer experiences. +- Excel in a collaborative team setting. +- Proactive — take initiative to solve complex systems challenges. +- **Demonstrates curiosity about AI tools and emerging technologies**, with willingness to learn and leverage them to enhance productivity, collaboration, or decision-making. + +### 1.4 Comp + benefits (verbatim) + +- USA base pay range (CA, WA, NY, NJ, CT) per year: **$230,000 - $290,000** +- USA base pay range (all other U.S. states) per year: **$204,000 - $264,000** +- Equity grade 13 (Affirm restricted stock units) +- 100% subsidized medical, dental, vision for you and dependents +- Flexible Spending Wallets (tech, food, lifestyle, family-forming) +- ESPP (employee stock purchase plan) +- Remote-first + +### 1.5 Sibling / adjacent roles in the same org (for context) + +- 7708921003 — Senior SWE, Backend (Infrastructure) — Remote US / Remote Canada (closest sibling, same dept) +- 7742412003 — Manager, Software Engineering (Card Platform) — Remote US (one level up the platform ladder) +- 7671388003 / 7671390003 — Senior CIAM Software Engineer — Remote US / Canada (different sub-team, IAM-focused) +- 7710976003 / 7710978003 — Senior Staff Software Engineer, Frontend (Web Infra) — Remote US / Canada (the senior-staff sibling; useful for calibration) +- 7605852003 / 7605850003 — Senior PM, Financial Platforms + +No **Manager, CI** or **Director, Build Platform** headcount visible in Greenhouse at capture time. The CI team is therefore (a) being led by a Staff/Principal IC or (b) reporting into a director above the team. The hiring manager role is most likely a **Senior Staff / Manager of Software Engineering** position one level up, with the Staff CI IC reporting in. + +--- + +## 2. Public surface — the hiring manager and CI team + +The JD does not name a hiring manager. The only public surface for the Affirm CI team is the **public Affirm GitHub organization** (`github.com/affirm`) and the buildkite-plugin repos it owns. Cloudflare on the public careers page, the engineering blog subdomain (`engineering.affirm.com` does not resolve, `affirm.engineering` does not resolve, and `medium.com/affirm-engineering` returns 404 — the engineering blog has been retired or moved) and 999-walls on LinkedIn make name discovery harder than for a typical pipeline target. + +### 2.1 The CI/CD team at Affirm (CODEOWNERS-confirmed) + +`github.com/affirm/affirm-metadata-env-buildkite-plugin` (a public Affirm Buildkite plugin) ships a `CODEOWNERS` file that assigns the entire repository to: + +``` +* @Affirm/ci-cd-o +``` + +The `@Affirm/ci-cd-o` slug is a **private** GitHub team inside the `affirm` org. The public list of org members (visible to the public at `https://github.com/orgs/affirm/people`) is small (12 confirmed handles: aarondack, alexmoore, bmwalters, briannosaurus, CodyRichter, DanielDeng2024, hectorups, lonerz, NicholasBottone, nickwu241, tarkatronic, ybv) — these are Affirm employees who have *chosen* to expose their affiliation; the actual team `ci-cd-o` is hidden behind the org's private-team visibility setting. We cannot enumerate its roster from outside the org. But the public surface gives us the technical-lead signal we need. + +### 2.2 The strongest single signal — **Brett Davis** + +| Field | Value | Source | +|---|---|---| +| Name | **Brett Davis** | `https://github.com/WBrettDavis` (public GH profile) | +| GitHub handle | `WBrettDavis` | GH API: `id 74620038` | +| Location | Chicago | GH profile | +| Company | `Affirm` | GH profile (publicly stated) | +| Email-of-record | `brett.davis@affirm.com` | commit metadata on `affirm/affirm-metadata-env-buildkite-plugin` | +| LinkedIn slug | not confirmable from public surface (Cloudflare 999 on every guess) | — | +| Title (public) | unknown (no GH bio, no public LinkedIn) | — | + +**Why Brett is the public face of the CI team at Affirm:** + +1. **Commit email is `@affirm.com`.** Every recent commit to `affirm/affirm-metadata-env-buildkite-plugin` is authored by "Brett Davis" with email `brett.davis@affirm.com` (verified by direct commit-graph query on the repo). This is the Affirm-internal domain. He is **employed at Affirm** as of 2026-06-18. +2. **He is the sole author of the only CI-domain repo still under an `@affirm.com` committer.** Other historical contributors to Affirm's public Buildkite plugins (`chronotc` / Silla Tan in Melbourne, `pzeballos` / Pol Zeballos @buildkite, `scadu` / Łukasz Jendrysik, `orien` / Orien Madgwick @envato, `mcncl` / Ben McNicholl) are all **third-party maintainers** — their company field is no longer Affirm. Brett is the only remaining Affirm-employee committer on the active plugin. +3. **The CODEOWNERS team `ci-cd-o` owns this repo.** GitHub's CODEOWNERS auto-assigns reviewers from the listed team for every PR. The fact that Brett is the **only** recent `@affirm.com` committer on the repo means he is functionally a maintainer of the team's most public artifact — the most-likely technical lead or staff engineer on the team. +4. **He has authored a personal `multi-unblock-buildkite-plugin`.** This is a niche Buildkite-step-unblocking utility — exactly the kind of utility a CI-team Staff engineer writes in their spare time. It is the only personal-public-repo signal of CI-team subject-matter expertise from any of Affirm's public-affiliated handles. +5. **He is the GitHub-handle `WBrettDavis` in Chicago, public-facing his Affirm affiliation.** He has not hidden the company field. + +**Title is not confirmable from public surface.** Brett could be the hiring manager, the technical lead, the Staff+ interviewer, or a senior IC who will sit on the loop. The role's "Staff CI" posting is in the same dept as Brett's plugin ownership; the inference that he is **at minimum a Staff IC and at maximum the hiring manager** is supported. We surface him as **"the technical lead on the public-facing CI plugin"** and let the outreach stage ask the right clarifying question. + +### 2.3 Recent public activity (since 2024-06) + +- **`affirm/affirm-metadata-env-buildkite-plugin` issues opened by `WBrettDavis`:** + - *Support multi-select fields* — feature request for the Buildkite plugin + - *Fix Buildkite variable prefix for forked repo name* — bug fix + - *Brettd/revert multi val pr* + *Revert mult-val parsing PR* — internal revert + revert-of-revert + - This is the cadence of an active maintainer, not a dormant owner. +- **Personal repo `WBrettDavis/multi-unblock-buildkite-plugin`** — initial commit 2024-06-29, last touched same week. No further public activity. This is consistent with a "scratched an itch and moved on" pattern. +- **No public GH activity since 2024-06 outside the Affirm plugin.** Either (a) he has been heads-down at work, or (b) his OSS work has shifted to internal/private repos. Both are consistent with a Staff IC at a financial company. + +### 2.4 Secondary signals (deprioritized) + +- **`chronotc` (Silla Tan, Melbourne, Australia)** — original creator of most of the public Affirm Buildkite plugins (ecr-, docker-, docker-compose-, aws-sm-, aws-assume-role-). Her company field is now `None`. She appears to be **former Affirm**, now unaffiliated. Silla is not a hiring-manager candidate. +- **`Pol (Paula) Zeballos` (`pzeballos`, @buildkite)** — current third-party maintainer of `ecr-buildkite-plugin` and `docker-buildkite-plugin`. She is on the Buildkite side, not Affirm. Useful as an external peer reference, not as a candidate. +- **`Łukasz Jendrysik` (`scadu`)** — third-party contributor (Buildkite-adjacent). Not an Affirm employee at capture time. +- **Public Affirm org members (12 handles) with build/CI-adjacent roles:** + - `CodyRichter` — Software Engineer @ Affirm, Seattle, public bio. LinkedIn `cody.richter.codes`. No CI-specific signals. + - `bmwalters` — Bradley Walters, San Francisco. No CI-specific signals. + - `nickwu241` — Data Infrastructure @ Affirm. Wrong sub-org. + - `lonerz` — Joshua Pan, Harvard CS '22, LinkedIn `joshuadpan`. Likely too junior for a Staff role. + - The remaining handles (`aarondack`, `alexmoore`, `hectorups`, `ybv`, `DanielDeng2024`, `NicholasBottone`, `briannosaurus`, `tarkatronic`) have no public CI/build/bazel signals. + +### 2.5 The CI team is a *private* Affirm GitHub team + +**Caveat:** `@Affirm/ci-cd-o` is a private team inside the `affirm` org. Its full roster is **not visible from outside the org**, and the GitHub API requires auth even to read its metadata. The public-org-member list (12 names) is a *superset* of teams — Affirm employees are not required to expose their affiliation. There could be 5 or 25 people on the CI team, none of whom show up in the public-org list. **Brett Davis is the only public handle we can tie to the CI team with high confidence.** + +### 2.6 What we *cannot* confirm from public surface (open questions for outreach) + +- Brett Davis's current title. He could be the hiring manager (Director / Sr. Eng Manager / Manager SWE), the technical lead (Staff / Senior Staff), or a peer IC. +- The actual EM/Director of the CI team — they may be a different person who is not publicly active on GitHub. +- The recruiter (Affirm uses Greenhouse, which is recruiter-anonymous at the JD level). +- Whether the team uses Bazel in production (the JD says "Preferred experience in Bazel" — not "required," and Affirm's public repos show no Bazel artifacts; the JD also lists Buildkite prominently, which is their public infra). + +--- + +## 3. Artifact plan — Speckl x Bazel provenance deep-dive + +This is the staff-level technical artifact Scott will attach to the application. It is **not a portfolio piece**; it is a small, working reference implementation of a system the CI team would actually adopt: a Bazel-rule that emits Speckl-style provenance into every CI-built artifact. + +### 3.1 Premise (one paragraph) + +The Staff CI role at Affirm is paid to make build outputs **trustworthy** at scale. Today Bazel produces an action cache and a remote-cache key — useful for incrementalism, useless for downstream consumers who need a SBOM, a CycloneDX/SPDX component graph, or a PROV-O trace of *which code generated this artifact, in which commit, on which CI agent, signed by which key*. Speckl's compile-time provenance fits exactly into that gap. The artifact demonstrates the integration: a `speckl_provenance` Bazel rule that wraps `*_binary`, `*_library`, and container-image rules, and on each successful build emits: + +1. A **CycloneDX 1.5 SBOM** of all transitive deps (already supported by Speckl core) +2. A **SPDX 2.3 tag-value document** for license compliance +3. A **PROV-O RDF graph** of the build event (committer, commit SHA, Bazel target, action digest, CI build ID, signing key fingerprint) +4. A **SLSA v1.0 provenance attestation** (in-toto Statement) signed with the team's cosign key + +### 3.2 Repo layout (artifact lives in `artifact/` once we start) + +``` +artifact/ +|-- MODULE.bazel # Bazel 8 + bzlmod, name = "speckl_bazel_provenance" +|-- WORKSPACE.bazel # legacy compat +|-- rules/ +| |-- speckl_provenance.bzl # the rule +| |-- speckl_provenance_test.bzl +|-- toolchain/ +| |-- speckl_release # pinned Speckl v0.x tarball +| |-- cosign_key.pub # example key +|-- examples/ +| |-- java_library/ # Java/Kotlin -> SBOM +| |-- python_binary/ # PyInstaller / pex-style binary +| |-- container_image/ # rules_oci container with provenance attestation +|-- docs/ +| |-- ARCHITECTURE.md # 1-page system diagram +| |-- INTEGRATION.md # how to drop into an existing monorepo +| |-- BENCHMARKS.md # build-time overhead measurement +|-- README.md +``` + +### 3.3 Reference implementation (sketch) + +```python +# rules/speckl_provenance.bzl — sketch +def _speckl_provenance_impl(ctx): + # 1. gather action metadata + action_digest = ctx.actions.declare_file(ctx.label.name + ".spdx.json") + ctx.actions.run_shell( + outputs = [action_digest], + command = "spk emit --target {target} --out {out} --format spdx".format( + target = ctx.label, + out = action_digest.path, + ), + tools = ctx.file._spk, + ) + # 2. cosign sign in-toto Statement + signed = ctx.actions.declare_file(ctx.label.name + ".intoto.sig") + ctx.actions.run_shell( + outputs = [signed], + command = "cosign sign-blob --key env://COSIGN_KEY {i}".format(i = action_digest.path), + ) + return [DefaultInfo(files = depset([action_digest, signed]))] + +speckl_provenance = rule( + implementation = _speckl_provenance_impl, + attrs = { + "deps": attr.label_list(), + "_spk": attr.label(default = "//toolchain:speckl_release", allow_single_file = True), + }, +) +``` + +The point of the artifact is **not the code** (it's 300 lines). It's the **system story**: + +- *Inputs:* a Bazel build graph, a committer identity, a cosign key. +- *Outputs:* signed in-toto Statement + SBOM, attached to every artifact. +- *Consumers:* the CI team's downstream release pipeline, an internal provenance dashboard, an audit log for SOC 2 / PCI DSS. + +### 3.4 What the artifact demonstrates to the hiring manager + +- **Staff-level systems thinking** — the rule integrates at the right Bazel extension point (`aspect`, not `rule`), so it composes with the existing monorepo without requiring a migration. +- **Cross-format fluency** — CycloneDX + SPDX + PROV-O + in-toto are all generated in one Bazel action. Speckl core already does the format work; the artifact is the wiring. +- **Concrete operational outcomes** — `BENCHMARKS.md` measures the build-time cost (target: < 8% on a 10k-target monorepo, based on published Speckl overhead numbers) and the storage cost (target: < 50 KB per target). +- **Security model** — cosign key management, rotation, and the trust boundary between the CI agent's ephemeral key and the team's long-lived signing key. + +### 3.5 Effort estimate + +- 1 weekend of design + 2 weekends of implementation + 1 weekend of docs/benchmarks = **~50 hours total**. +- The artifact can ship as a `speckl-bazel-provenance` GitHub repo, a public `git push` to Scott's existing `sscoble` GitHub, and a 4-page `ARCHITECTURE.md` that he can attach to the application and walk through in the on-site. +- **Outreach timing:** do not attach the artifact link to the cold outreach. Send the artifact as a follow-up to the first response, with one sentence: *"I built this against your JD — Bazel rule that wraps Speckl provenance into every CI artifact. Open to a 30-min walkthrough if it's useful."* + +--- + +## 4. Outreach log (currently empty) + +**No outreach has been sent.** This section is a placeholder for the next agent (or Scott) to log each touchpoint with Brett Davis, the recruiter, or any peer on `@Affirm/ci-cd-o`. + +Format: `YYYY-MM-DD | channel | target | message-id | outcome` + +(empty) + +### 4.1 Planned next moves (do not execute — surface only) + +1. **Confirm the CI team's actual reporting structure.** Send a low-cost question to Brett Davis on LinkedIn (after slug discovery via a mutual connection, or via GitHub Sponsors if he has it enabled) asking *who runs the CI team and who the Staff CI hire reports to.* This converts a 1-name surface into a 2-3-name surface. +2. **Identify the Greenhouse recruiter.** Most Affirm Greenhouse postings have a recruiter name in the `application_form.questions` field; the API returned the JD without it, but a follow-up Greenhouse call to `?questions=true` may surface it. +3. **Build the artifact** (section 3) before sending the cold outreach — Speckl x Bazel provenance demo + 1-page `ARCHITECTURE.md` is the differentiator. +4. **Cold outreach** (after artifact ships): LinkedIn DM or email to Brett Davis, 4-sentence pitch: (1) Speckl anchor, (2) Bazel-fluent, (3) read the JD, (4) the artifact in 1 click. No CV attached. +5. **Apply via Greenhouse** (in parallel) — the JD explicitly invites applications. Cold outreach + warm application is the standard Staff-IC pattern. + +### 4.2 Outreach ethics constraints (recap from parent context) + +- **No automated contact.** Cold outreach is one human-authored message, one channel, one target. +- **No public posts about the role, the team, or the JD.** This repo is private to the marcus agent system. +- **No AI-generated pings on LinkedIn.** Speckl's positioning is "human cultivation expert for the AI age" — the outreach must read as Scott's voice, not as an agent's. +- **All personal data (recruiter names, peer handles) is internal to this repo.** Do not publish. + +--- + +## 5. Sources + confidence + +| Claim | Source | Confidence | +|---|---|---| +| JD content | Greenhouse API `boards-api.greenhouse.io/v1/boards/affirm/jobs/7749580003` (called 2026-06-18) | **high** | +| Pay range + grade | same | **high** | +| Department | same (id 4041949003, "Infrastructure Platform Eng") | **high** | +| Brett Davis commits to Affirm plugin under `@affirm.com` | GH API on `affirm/affirm-metadata-env-buildkite-plugin/commits` | **high** | +| Brett Davis public GH profile (Chicago, @affirm) | GH API `users/WBrettDavis` | **high** | +| `multi-unblock-buildkite-plugin` authorship | GH API | **high** | +| CODEOWNERS team `@Affirm/ci-cd-o` | raw.githubusercontent.com `affirm/affirm-metadata-env-buildkite-plugin/master/CODEOWNERS` | **high** | +| Affirm public org roster (12 handles) | GH API `orgs/affirm/members` (public) | **high** | +| Silla Tan / Pol Zeballos / others are no longer @affirm | GH API on users + commit history | **high** | +| Brett Davis is the *hiring manager* | not directly confirmable | **low** (could be the hiring manager, technical lead, or peer Staff IC) | +| Brett Davis's title | not confirmable from public surface | **low** | +| Engineering blog URL | `engineering.affirm.com`, `affirm.engineering`, `affirm.dev`, `medium.com/affirm-engineering` — all 404/empty | **high** (no public engineering blog at capture time) | +| The team uses Bazel in production | not confirmable — JD says "preferred," public repos show none | **low** (likely; the JD would not list it as preferred if no one used it) | + +--- + +## 6. Parent context inheritance + +- **Positioning:** Scott Scoble, "Human-Maximizer for Agentic Engineering Systems" — anchor product is **Speckl** (compile-time provenance, SBOM, CycloneDX/SPDX/PROV-O). Two published books. Built Scobleclaw. Speckl-flashcards. Open-source is a hard soft requirement for this role and Scott exceeds it. +- **Job scan context:** the parent job-scan agent (mem #2454, see also ob1 search "Affirm") had Chainguard Staff+ Platform Engineer as the #1 target at $205k-$231k. Affirm Staff CI at $204k-$290k is a stronger comp and a better Bazel-and-monorepo fit; it is now the **leading target** pending artifact completion. +- **Workspace rule:** never assume a repo lives at `/workspace/...`; this repo was created at `os.scoble.me/forgejo/marcus/job-affirm` via the local Forgejo API (token at `/home/sscoble/meos/forgejo-token.txt`). +- **Constraint:** surface only. No outreach. No public posts. No automated DMs. The next agent (or Scott) reads this file and decides the next move.