I treated my own job search as an operations problem

Context

To be clear about authorship: the engine itself is open source and someone else's work. What I did was adopt it, then spend sixty-five commits turning a general-purpose tool into something that fits a specific pipeline — which is, almost exactly, the job of implementing a vendor system inside a business.

The underlying problem was one I recognised from work. A high-volume funnel with no reliable source coverage, no single tracker, manual triage, and no way to tell which stage was actually leaking. I have fixed that shape of problem for employers. It seemed worth fixing for myself.

What I did

• Widened the top of the funnel by writing new discovery scanners for the sources that mattered in this region and were not covered — LinkedIn, NaukriGulf, Bayt, recruitment-agency boards — plus a recurring pass over sponsorship-confirmed international roles.
• Built the source registry out to 170 verified company and portal entries, each one checked to be a live board rather than a dead link, with title filtering tightened so the funnel carries volume without carrying noise.
• Built a triage dashboard: every discovered role bucketed by verdict, one-click mark-applied and discard, automatic filing of the tailored CV and cover letter to the right record, and applied roles disappearing from the queue so the view always shows what is actually outstanding.
• Replaced a fragile mail integration. Status detection had been scraping a webmail interface's DOM, which broke whenever the UI changed; I rewrote it to read the local mail store directly, which does not.
• Built a staged outreach system with the control I would insist on at work: actions are drafted rather than sent, they sit in a veto window before execution, and there is a panel to pause, veto or send immediately. It is deliberately never fully autonomous.
• Put the approvals on my phone. A Telegram channel surfaces what the system wants to do and takes the decision back, so the pipeline keeps moving without me at a desk — and a sentinel process reports when a scheduled run fails, rather than failing quietly.
• Made the automation trustworthy: deterministic exit codes across the scheduled chain, and enforcement hooks that turn the pipeline-integrity rules from documentation into checks that actually block.

The part that is actually an operations lesson

The most valuable change was not a scanner. It was refusing to let the outreach run unattended. Every version of this tooling wants to become fully autonomous, and the pull is strong when the manual step is the boring one — but an automated action sent under my name, to a real person, on a platform with its own terms, is a risk I own and cannot recall.

So the design keeps a human in the loop at exactly one point: the send. Everything before it is automated hard. That is the same trade-off as an approval threshold in a credit process, and I would defend it the same way — the gate is not there because the system is unreliable, it is there because the consequence is asymmetric.

What I would tell you in an interview

This is the least glamorous project I have and probably the most representative. I did not build the engine. I integrated a third-party system, found where it did not fit the real process, extended it, instrumented it, and put controls around the part that could do damage — then ran my own pipeline on it for months and fixed what broke. That is implementation work, and it is most of what operations actually is.

Where this transfers

What it means for an employer: I can take a third-party system and make it reliable, auditable and safe to run unattended, rather than building from zero. Vendor and tooling implementation, straightforwardly. Every business runs systems that cover 70% of the real process, and the gap is closed either by people doing manual work forever or by someone willing to extend the tool, wire it into the surrounding systems, and own the controls around it. I would rather be the second kind.