marcus/job-affirm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Pipeline intel + artifact plan for Affirm Staff SWE (Continuous Integration). Surface only — no outreach sent.
2 commits 1 branch 0 tags 43 KiB
Find a file
Exact
sscoble 4891707f32 init: job-affirm README with JD, surface, artifact plan, outreach log
2026-06-18 13:28:41 -07:00
README.md init: job-affirm README with JD, surface, artifact plan, outreach log 2026-06-18 13:28:41 -07:00

README.md

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)

# 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.