Job Sidecar

The bottleneck wasn't finding jobs. It was deciding where to spend my time.

The job search had three competing demands:

COVERAGE: relevant postings were scattered across job boards, email alerts, and individual company career pages.

EVALUATION: I needed to determine not just whether I could technically apply, but whether my experience actually matched the role, and whether my resume communicated that match clearly enough to get through an ATS.

CUSTOMIZATION: once I decided to apply, the resume, cover letter, and application questions all needed attention.

Doing all three manually meant spending a lot of time on roles that ultimately weren't worth pursuing, while creating pressure to rush the roles that were.

I turned the job search into a decision pipeline.

I treated the job search as five connected problems rather than one automation project. Jobs first enter through multiple discovery channels. They're deduplicated and evaluated against a structured fit model. Only roles that make it through that evaluation move into the application workflow. Once submitted, the application is tracked, and the confirmation email provides a verifiable record.

The important design decision was that automation didn't replace my judgment. It handled the repetitive work around the decision.

The first version was too simple.

My first version tried to answer the entire question with one number: how good is this job for me? It quickly became obvious that this wasn't enough. The same overall score could represent very different situations. A role could have excellent product experience alignment but a meaningful domain gap. Another could have strong terminology overlap without actually matching the work I'd done.

So I stopped treating the score as the answer and started treating it as a structured decision.

A score is only useful if I can understand why it exists.

The current model weighs four dimensions by percentage: ATS terminology (40%), core role fit (30%), transferability (20%), and domain experience (10%). The score itself approximates automated ATS matching or a structured human scorecard, since not every platform screens with an algorithm, using term and requirement presence rather than how well a bullet is written.

On top of that score, hard requirements sit outside the weighting entirely as a separate flag, so one I don't meet can't hide inside a strong overall number. The model displays exactly which requirements are unmet and recommends where to strengthen a bullet with concrete evidence to better hit the posting's keywords. Those gaps are also logged over time, so a requirement that keeps recurring across postings points to where future learning or training would actually move the needle.

The output isn't a score. It's a decision-ready application.

Once a role clears evaluation, Job Sidecar shifts from analysis to preparation. The score identifies where my resume needs to be adjusted for that particular posting. I work through those recommendations rather than rewriting the entire resume from scratch. Cover letters are drafted against an established style guide, but they're anchored in a specific detail from the company or role rather than generic claims.

Application questions still call for judgment. If a question requires a specific skill, Job Sidecar helps me find the strongest match for it from my own experience, rather than starting from a blank page each time. The goal isn't to automate the application. It's to remove the repetitive work surrounding it.

The most important bug wasn't a crash. It was a believable answer.

The most important lesson came from a failure I didn't initially see. The resume-reading step failed twice. The first approach relied on a local device connection that didn't work reliably during scheduled runs. The second approach appeared to work, but when the system ran headlessly, it silently fell back to an outdated summary of my resume. There was no obvious error. The pipeline kept running and produced scores that looked completely reasonable.

Then one role came back with a score of 92. When I checked the underlying evidence, it should have been 73. The system had missed an important domain gap. That changed the problem from "fix the automation" to "ensure hard requirements are highlighted at the decision-level," which is what led to pulling hard requirements out as their own explicit flag instead of blending them into the score.

The system changed how I spend my time.

Job Sidecar is now operating as an ongoing system rather than a one-time experiment. It screens more than 200 postings each week across three discovery channels. Only about 19% make it through to an application, which means the system intentionally filters out the majority before I spend time customizing anything.

Building the system taught me where automation can be trusted. And where it falls short.

The biggest learning wasn't technical. It was architectural. Searching, scoring, applying, tracking, and logging looked like one problem at first. They turned out to be five different problems that needed to work together. I also learned that automation needs observability. The most dangerous failure wasn't the one that stopped the system, it was the one that let it keep running with bad information. And finally, I learned that the best use of AI wasn't replacing my judgment. It was giving me better information, faster, so I could spend my limited time making the decisions that actually mattered.