JobDrop

Inspiration

I got tired of checking the same company career pages over and over.

Most job boards mix together old listings, reposts, sponsored results, and jobs pulled from third-party sites. Even when a listing looks new, it is often hard to tell when the company actually posted it.

I built JobDrop to make that process simpler: one place to find fresh openings directly from company career pages and public applicant-tracking systems.

What it does

JobDrop currently collects openings from more than 1,300 company sources and makes them searchable in one place.

Users can:

Search related roles instead of relying only on exact job titles
Filter by company, industry, location, experience level, and date
See jobs ordered by the date provided by the employer
Open the original company posting and apply at the source
Save searches and receive daily email alerts
Track jobs they are interested in or have already applied to

JobDrop existed before Build Week. During the event, I focused on turning it into a more reliable Fresh Discovery & Alerts product.

I expanded the search system, improved how companies and industries are categorized, made date ordering more consistent, added safer scheduled scans, and made saved-search alerts more reliable.

How I built it

JobDrop uses Python, Flask, and PostgreSQL in production, with SQLite available for local development.

The job collection system supports several public applicant-tracking-system APIs and company career sites. Depending on the source, it uses:

Requests
Beautiful Soup
lxml
Playwright

Search runs on the server using SQL filters and groups of related occupational terms. For example, a search for software engineering can also find closely related titles that use different wording.

I also added special handling for abbreviations. A search for SWE should find software-engineering roles, but it should not accidentally match a word such as sportswear.

A major part of the Build Week work was making scans safer. The scanner now keeps persistent progress for each company and avoids closing existing jobs when a source fails, times out, or unexpectedly returns no results.

Saved-search alerts use delivery cursors so a successful email is not sent again, while a failed delivery can still be retried.

The interface is built with HTML, CSS, and JavaScript. The production application runs behind Gunicorn and Nginx.

I used Codex with GPT-5.6 Sol during the final Build Week development and verification work. It helped me:

Trace behavior across routes, SQL queries, templates, collectors, and tests
Find edge cases in search and source handling
Review the repository for submission risks
Add and verify regression tests
Verify the final release against the pre-event baseline

GPT-5.6 Sol helped me build and review JobDrop, but it is not presented as a user-facing AI feature. The product decisions, ranking rules, and source-safety boundaries remained human-directed.

Challenges I faced

The hardest part was that company career sites are inconsistent.

Some have clean public APIs. Others depend on JavaScript, use unusual pagination, switch vendors, block automated requests, or briefly return empty pages during outages.

An empty result can be especially dangerous. If the system assumes that an empty page means every job was removed, it could incorrectly close hundreds of valid openings.

I changed JobDrop so existing jobs are preserved unless an empty result has been verified as legitimate. Unexpected empty scans are now treated as warnings instead of silent success.

Freshness was another challenge. JobDrop now follows a clear ordering rule:

Use the employer-provided posting date when available.
Fall back to the date JobDrop first discovered the job.
Use the exact discovery time to order jobs that share the same date.

This keeps results predictable without hiding them behind an unexplained relevance score.

I also had to balance broad search results with accuracy, prevent duplicate alert emails, handle interrupted scans, and respect the restrictions of each source.