The intro
In part one, I built the security foundation for Doomscroll, my bot that job hunts for me on AWS. No stored passwords, two permission levels, and a ceiling the automation can't raise.
This milestone was the fun part. Make it actually find jobs.
It took ten seconds for the first run to pull 3,354 real postings from four job sites. SpaceX, Palantir, federal agencies, and a big job aggregator. Every API answered. Nothing crashed.
It matched zero.
That's like hiring a recruiter who reads 3,354 resumes and comes back with "nah, nobody." The machine worked perfectly. The instructions were wrong.
Zero Wasn't a Bug. It Was a Clue.
The tempting move here is to start guessing. Loosen the keywords. Add more job titles. Throw stuff at the wall.
I did the opposite. I wrote a small diagnostic tool that showed, for every job site, exactly where each posting got cut and why.
The answer was obvious in about thirty seconds. Keywords weren't the problem. Location was. The filter threw out 309 jobs for location and only 126 for seniority.
Every Website Spells "Tampa" Differently
Here's what was actually happening. I told the bot to look for jobs in Tampa. But jobs at the air force base in Tampa are listed as "MacDill AFB, Florida." Jobs on Florida's Space Coast say "Cape Canaveral," not "Melbourne." One site writes "Washington, D.C." Another writes "Washington, DC." The federal government writes "Washington, District of Columbia."
Same places. Different labels. My filter only knew one spelling of each, so it quietly threw away the exact defense jobs I was looking for.
If you run a business, you've seen this exact problem. It's the CRM with "Acme Inc," "ACME," and "Acme Incorporated" listed as three different customers. Software is literal. It does exactly what you say, not what you mean.
After I fixed the location names and widened my search to the regions I'd actually relocate to, the next run saved 64 real jobs. An AWS consulting role in Virginia. A DevOps role at Palantir in DC. Federal cybersecurity roles where my Security+ certification is the baseline requirement.
[Image: DynamoDB table of real matched jobs]
Same bot. Same code. Better instructions.
Then a Job Site Went Down at 1 AM
Around 1 AM, one of the four job sites started returning errors. Its servers were temporarily unavailable.
cj@Chriss-MacBook-Pro-2 ~/Projects/doomscroll fix/filters-dc-supervisory aws logs tail /aws/lambda/doomscroll-fetch-jobs --since 15m --filter-pattern source_failed
2026-10-11T05:01:08.993000+00:00 2026/10/11/[$LATEST]2d6e1be10eec4b8aa4efc07c2ff41c5f [WARNING] 2026-10-11T05:01:08.993Z d32ec941-0c12-4112-be78-400a00303bc8 {"event": "source_failed", "source": "adzuna", "error": "HTTPError: HTTP Error 503: Service Temporarily Unavailable"}
Here's why that was a good night. I designed the bot so one broken source never takes down the others. The other three sites still saved their 5 new jobs. Then the bot raised its hand and reported the failure, so I'd know.
That's the difference between a demo and a system. A demo works when everything works. A system has a plan for when something doesn't. Every outside service you depend on, from payment processors to shipping APIs, will go down eventually. The question is whether it takes your whole operation with it.
The next day, I added automatic retries. Now if a site hiccups, the bot waits two seconds and tries again, then five seconds. Last night's outage would have fixed itself without me ever knowing.
It Found Something I Almost Published
One quieter win from this milestone. Before committing test data to my public code, I scanned it for my API keys. One job site was embedding my account ID inside every single job link it returned. Five times, in one small file.
It wasn't my password, but it didn't belong in public either. I scrubbed it before it ever left my laptop.
The lesson for any team: vendors leak your information in places you'd never think to look. Check the data, not just the code.
Now It Runs Itself
The last piece was a schedule. Every morning at 6 AM Eastern, the bot wakes up, checks all four sites, keeps the new matches, and goes back to sleep. Each run takes about ten seconds.
One detail I'm weirdly proud of: I set the schedule in Eastern time instead of the server's default clock. When daylight saving time ends in November, a lot of automated schedules quietly drift an hour. Mine stays at 6 AM.
The first unattended run found 5 new jobs and correctly skipped the 58 it had already seen. Nobody touched it.
Three Things This Milestone Taught Me
- Your filters are your strategy. The bot was only as good as my definition of a good job. Tightening and loosening that definition with real data beat every guess I would have made.
- Plan for the outage, not the demo. Things you don't control will break. Design so a single failure stays small.
- Debug from evidence. Zero results felt like a failure. It was actually the most useful data I got all week.
What's Next
Right now the jobs land in a database. Next milestone, they land in my inbox. A daily email digest, a simple way to track every application from "applied" to "offer," an alert when something breaks, and a budget alarm so this never costs more than a few dollars.
Yes, I'm still building a robot to help me get hired. If you're hiring for cloud or DevOps roles and you like how I work through problems, let's talk.
