Recruiting & HR systems

LinkedIn Talent Solutions Integration Consulting

Where I can help

• Diagnosing failures in the Jobs API — posting, updating and expiry flows that behave differently in production than in documentation
• Automated Job Postings issues where jobs post partially, silently or not at all
• Job Wrapping breakage, typically when a career site changes markup and the scraper stops finding what it expects
• Authentication handshake failures and permission problems that present as intermittent sync errors
• Data-mapping review between your ATS candidate and job schema and the LinkedIn model
• Acting as technical translator between your engineering team and platform support, so escalations carry evidence solid enough to be actioned

HAR analysis, specifically

A large share of these problems are only diagnosable from the actual HTTP exchange. I ran in-depth HAR file analysis daily at LinkedIn to trace request and response flows, identify which API call was genuinely failing as opposed to which one surfaced the error, debug authentication handshakes, and pinpoint latency bottlenecks.

If you have a reproducible failure and can capture a HAR file, that is usually enough to establish what is actually happening — and it is the single most useful artefact to bring to a first conversation.

Job Wrapping and scraper breakage

Job Wrapping depends on scraping customer career sites, which means it breaks whenever a customer redesigns their careers page. At LinkedIn I fixed breakages in the Python scrapers behind it when XPath selectors changed, updating the scraper code, running and testing the revised script locally in Docker, and handing the verified fix to the development team through JIRA for review and deployment.

If your careers site has changed and your LinkedIn job feed has quietly degraded since, this is a well-understood failure mode rather than a mystery.

Why this is unusually hard to hire for

Very few independent consultants have worked on the platform side of these integrations. Most experience in the market is from the ATS vendor's perspective, or from a recruiting-operations perspective, and stops at the point where the integration returns an unhelpful error.

Working inside LinkedIn meant seeing which failures were genuinely customer-side configuration, which were partner-specific quirks, and which needed a code-level change from Engineering. I collaborated directly with Engineering, Product and Business Development on partner-specific changes, which is a very different vantage point from reading the public documentation.

Turning escalations into fewer escalations

Resolving individual tickets is the least valuable part of this work. At LinkedIn I built escalation trend reporting that gave Product a ranked, evidence-backed view of what was actually breaking, which fed directly into fix prioritisation, and converted repeat cases into Tier 1 enablement material so the same issues stopped reaching senior support.

I also co-led an internal AI copilot support chatbot, including historical ticket ingestion and retrieval, with enforced boundaries between internal and customer-facing content. If you are considering something similar over your own support history, I have seen where that approach helps and where it quietly misleads people.

Typical engagements

Diagnostic and advisory rather than long-term implementation. A focused investigation into a failing integration. A pre-build review of how you intend to map your data. Support for an internal team that owns the build but wants someone who has seen these failure modes before.

Common questions