Job Placement Digest · research appendix
Placement Method and Evidence
Method published 13 Jul 2026 · Ledger reconciled 21 Jul 2026
This appendix holds the research that would slow the recruiter-facing case down: the full keyword ledger, the screen, its denominator, every current row state, and the decisions I overturned. Posting status is a dated observation, not a promise that a vacancy is still open.
The 34-term keyword ledger
The source set contains five Solutions Engineer postings: Automattic WordPress VIP (A), Webflow (W), Contentful (Ct, market signal only), Cloudflare (CF), and OpenAI (O). I recorded required qualifications (R), desirable qualifications (D), responsibilities (Rp), and application screeners (Scr) separately.
Taxonomy
Demonstrated means a tagged, merged, live, or otherwise loadable artifact supports the term. Partial means I have an engineering analogue but not the sales-cycle fact the posting asks for. Gap means no qualifying artifact exists. Demonstrated terms may shape résumé bullets; Partial terms require exact-scope language; Gaps stay visible and out of the bullets.
Demonstrated10
| Keyword | Posting signal | Evidence boundary |
|---|---|---|
| Solution design / architecture | A, W, Ct, O responsibilities · 4/5 | HPerkins Tokens, AI Provider for Codex, DJ Lee, and Flavor Agent |
| WordPress / PHP | A required · 1/5 | HPerkins Tokens, AI Provider for Codex, WordPress/ai PR #501, and labeled Flavor Agent work |
| API understanding / design | W desirable; O responsibility · 2/5 | WordPress AI Client and Abilities API use; issue #529 shipped and #732 remains open |
| Communication — written / verbal | A and Ct required; W and CF desirable · 4/5 | Public issues, PR documentation, and essays; senior-leader scope excluded |
| AI problem-solving / fluency | W required and desirable · 1/5 | AI Provider for Codex, labeled Flavor Agent work, and upstream record |
| Delivered generative-AI / ML prototypes | O required · 1/5 | AI Provider for Codex is beyond prototype; Flavor Agent has loadable RC tags |
| End-to-end problem ownership | O required · 1/5 | HPerkins Tokens, Codex runtime isolation, and DJ Lee V1-to-V2 iteration |
| CMS / content-platform implementation | Ct required · 1/5 | Theme and plugin authorship; this is practitioner evidence, not Contentful product experience |
| JavaScript | O required through Python-or-JavaScript; W desirable · 2/5 | DJ Lee V2 and the public V1 React/TypeScript source; clears the OpenAI alternative through JavaScript |
| Documentation / guides | O responsibility · 1/5 | WordPress/ai PR #501 and loadable project READMEs |
Partial11
| Keyword | Posting signal | Exact boundary |
|---|---|---|
| Proofs of concept | A required; Ct and CF responsibilities · 3/5 | Public prototypes, not sales-cycle PoCs |
| Technical presentations / demos | A required; W, Ct, CF, and O responsibilities · 5/5 | Loadable demonstrations, not customer-discovery demo delivery |
| Consultative approach / solution-based selling | W required; A responsibility · 2/5 | One named client delivery, no sales-cycle consultation record |
| Customer requirements translation | A required · 1/5 | Upstream technical translation, not discovery or RFP work |
| Product feedback into product organization | W, Ct, and O responsibilities · 3/5 | Maintainer loop, not a Product Management channel |
| Security / compliance | O required and responsibility; CF desirable · 2/5 | Inspectable secret-isolation design, no compliance-support artifact |
| Enterprise business models / content distribution / audience engagement | A required · 1/5 | Published analysis, no enterprise account record |
| Competitive landscape | CF desirable; A and Ct responsibilities · 3/5 | Platform analysis, no sales-cycle positioning |
| MACH / composable architecture | Ct desirable · 1/5 | Narrow DJ Lee V2 analogue, no framework engagement |
| React / Next.js / Vercel | Ct desirable · 1/5 | React demonstrated; Next.js and Vercel absent |
| Cloud / network architecture | O required; CF desirable · 2/5 | Cloudflare edge deployment only; hyperscaler architecture absent |
Gap13
| Keyword | Posting signal | Current boundary |
|---|---|---|
| RFP / RFI responses | A and Ct responsibilities · 2/5 | No artifact |
| Account Executive partnership | A required; W responsibility · 2/5 | No artifact |
| Pre-sales years | O required; CF desirable · 2/5 | No qualifying pre-sales tenure |
| SE / customer-facing tenure | A and W required · 2/5 | No tenure at the level these postings require |
| C-level relationship management | O required · 1/5 | No artifact |
| Executive presentation / communication | O required; CF desirable · 2/5 | Senior-leader scope not established |
| Emotional intelligence in multi-stakeholder meetings | Ct required · 1/5 | No artifact in the required meeting context |
| Storytelling in discovery | W desirable · 1/5 | Published writing is not discovery delivery |
| Python | O required through Python-or-JavaScript · 1/5 | Requirement cleared through JavaScript; Python not shipped |
| High-traffic WordPress migration | A application screener · 1/5 | No staged zero-downtime migration |
| Technical sale won with a custom or complex demo | A application screener · 1/5 | No truthful qualifying example |
| Networking depth — CDN, routing, SD-WAN | CF desirable · 1/5 | Edge serving is narrower than the requested depth |
| SIEM / log analytics | CF desirable · 1/5 | Request logging is adjacent, not SIEM |
A claim has to survive inspection by someone who isn’t me.
What I optimize for in my next role
I favor roles where technical and customer outcomes produce inspectable evidence—code, releases, live systems, documented incidents, or customer-facing artifacts—in addition to narrative reporting.
1. Will the work survive inspection by someone who isn’t me?
Merged pull requests, tagged releases, live systems, changelogs, documented incidents, and customer-facing artifacts can be checked. Narrative reporting can still matter, but it cannot be the only evidence the role produces.
2. Is the customer’s problem operational WordPress at scale—a payroll problem wearing a technical symptom?
The role should put WordPress at the operational center of the customer problem. A single consumer site or a stack where WordPress is incidental does not meet that screen merely because the title includes “engineer.”
3. Is this a rung or a detour?
I want hands-on Support Engineer work now, with deeper customer-facing technical leadership as the longer direction. A role belongs in the set when it builds that record through real WordPress diagnosis, customer communication, or platform work rather than moving away from it.
Screening denominator and funnel
As of 21 Jul 2026, this funnel is calculated from the public workbook’s 20 data rows. It reports the workbook’s current states and verdicts; it does not reconstruct the earlier research screen.
| Measure | Count | Workbook rule |
|---|---|---|
| Rows in public ledger | 20 | Every row after the seven-column header |
| Current live passes | 9 | Current state “Live”; verdict “Pass” or “Pass — manual review” |
| Verification unresolved | 1 | Current state “Verification pending” or “Unverified”; verdict “Needs verification” |
| Historical, not-current passes | 5 | Screen verdict “Pass — historical” |
| Replaced postings | 1 | Current state “Replaced”; verdict “Needs new screen” |
| Expired before screening | 1 | Current state begins “Expired”; verdict “Not screened — expired” |
| Human failures | 3 | Screen verdict “Fail” or “Fail — overturned” |
Last checked distribution: 2026-07-21 — 1 row; 2026-07-20 — 10 rows; 2026-07-18 — 4 rows; not recorded — 5 rows.
WordPress Job Market Screen — Live States
This is the sanitized 20-row research ledger reconciled on 21 July 2026. The six non-URL fields reproduce the workbook’s displayed values verbatim; a non-empty canonical URL is rendered as a safe link to that exact value, and an empty workbook cell remains empty. Delisted, replaced, paused, pending, unverified, removed, and human-failed rows remain visible but are not presented as current opportunities.
| Job title | Company | Canonical posting URL | Last checked | Current state | Screen verdict | Concise reasoning |
|---|---|---|---|---|---|---|
| Support Engineer, VIP | Automattic (WordPress VIP) | Open posting | 2026-07-20 | Live | Pass | Q1–Q3 pass: code-level WordPress troubleshooting and customer-facing technical work. |
| Customer Success Engineer, VIP | Automattic (WordPress VIP) | Open posting | 2026-07-20 | Live | Pass | Q1–Q3 pass: enterprise WordPress troubleshooting, scalability, performance, and security. |
| Technical Account Manager, Newspack | Automattic (Newspack) | Open posting | 2026-07-18 | Live | Pass — manual review | Q1 passes because the output is an inspectable, migrated live news site. |
| Support Engineer | Kinsta | Open posting | 2026-07-20 | Live | Pass — manual review | Q1 passes because successful troubleshooting produces an inspectable repaired customer site. |
| Software Developer | Alley | Open posting | 2026-07-20 | Live | Pass | Q1–Q3 pass: PHP and WordPress development with a required code sample. |
| Senior Web Engineer (Contract) | Fueled (10up practice) | Open posting | 2026-07-18 | Live | Pass | Q1–Q3 pass: deep WordPress/PHP, Gutenberg architecture, and Git workflow. |
| Senior WordPress Engineer (Freelance) | XWP | Open posting | 2026-07-20 | Live | Pass — manual review | Q1–Q3 pass: enterprise WordPress and Gutenberg work; the listing is an evergreen pipeline. |
| Freelance Senior Web Engineer | Human Made (Altis DXP) | Open posting | 2026-07-18 | Live | Pass | Q1–Q3 pass: large-scale WordPress work in PHP or JavaScript. |
| Senior WordPress Engineer | Syde | Open posting | Verification pending | Needs verification | Automated checks returned HTTP 503; current liveness remains unconfirmed. | |
| Technical Support Engineer, Pressable | Automattic (Pressable) | Open posting | 2026-07-20 | Delisted | Pass — historical | Passed the screen; the employer listing is no longer available. |
| Solutions Engineer, WordPress VIP | Automattic (WordPress VIP) | Open posting | 2026-07-20 | Delisted | Pass — historical | Passed the screen; the employer removed the listing from its job board. |
| Solutions Engineer — Media, WordPress VIP | Automattic (WordPress VIP) | 2026-07-20 | Delisted | Pass — historical | Passed the screen; the employer removed the listing from its job board. | |
| Full Stack Web Engineer | 10up (Fueled) | 2026-07-20 | Replaced | Needs new screen | The original listing closed; replacement content does not inherit the prior verdict. | |
| Customer support role (anonymized) | Target-ecosystem employer (anonymized) | Live when screened | Fail — overturned | Q2 fails: the customer context is consumer and single-site, not operational WordPress at scale. | ||
| Staff Web Engineer | 10up (Fueled) | 2026-07-18 | 404 / removed | Fail | Q2 fails: WordPress is optional rather than the operational center of the role. | |
| Technical Support Team Lead | Pressable | Open posting | Live when screened | Fail | Q3 fails: the role manages the support queue rather than doing the target troubleshooting work. | |
| News Software Engineer — WordPress | NBCUniversal | Expired posting | 2026-07-21 | Expired — confirmed 2026-07-21 | Not screened — expired | Canonical ATS posting on NBCUniversal’s SmartRecruiters board confirmed expired (verified 2026-07-21; a third-party mirror shows the listing closed 2026-07-01); prior third-party link replaced with the employer URL. Designated fully remote (US); requisition nominally based in NYC (30 Rockefeller Plaza). Official comp $90K–$145K; the $115K–$175K figure is a third-party AI estimate, not NBCU’s. |
| Technical Support L1 | WP Engine | 2026-07-20 | Live | Pass | Q1–Q3 pass: WordPress, DNS, Linux command-line, and customer troubleshooting work. | |
| Sr. WordPress Engineer | Multidots | Open posting | Paused | Pass — historical | Q1–Q3 pass; the employer has paused the listing. | |
| Technical Support Engineer (WordPress) | rtCamp | Open posting | Delisted | Pass — historical | Passed the screen; the listing now appears dead or delisted. |
Delisted postings and overturned decisions
Delistings remain part of the record
Five validated rows are now delisted, replaced, or dead, and one additional role is paused. I retain them because removal is part of the market evidence, but I do not present them as current opportunities. A dated ledger should show when a good match stopped being actionable.
Three human overturns
- A consumer support role failed because the customer context was single-site rather than operational WordPress at scale.
- A staff web-engineering role failed because its own copy made WordPress interchangeable with another CMS; the posting later returned 404.
- A support-team-lead role failed because managing the queue is not the hands-on diagnosis and customer work this search targets.
False-pass analysis
The AI passed one role because the employer’s brand matched my target ecosystem, even though the customer context did not satisfy my screen. Its own rationale contained the disqualifying evidence. I overturned the result.
The failure was not missing data. The role text and the model’s rationale both contained the consumer, single-site context. The error came when an employer-level association overrode row-level evidence about the customer. The corrective control is simple: each question must cite the posting evidence that answers it, and an explicit failure cannot be canceled by the company name or job title.
The company name had answered a question about the customer. I overturned it.
A screen you can’t watch working is a screen you take on faith.
The method supports the case
Return to the work and inspect the proof.
The research is here so the claims remain bounded. The recruiter-facing page makes the shorter argument: I want Support Engineer work now, I can show how I diagnose WordPress failures, and I state the enterprise-scale gap directly.