marcus/job-affirm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
job-affirm/README.md

301 lines
23 KiB
Markdown
Raw Blame History

# job-affirm
> 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.
Reference in a new issue View git blame Copy permalink