Automating My Job Hunt
Building my own job-search platform
Work
Product Thinking
Workflow Automation
Case Study
Project
Self-initiated
Personal project
Year
2026
Tools
Python, APIs
Git Hub, Google Sheets
Turning a tiring routine into a repeatable workflow
Job hunting sounds simple until you start doing it seriously. I was searching job boards, checking company career pages, evaluating openings, and recording useful details in Google Sheets. After five days of doing this manually, I realised the hard part was not only finding jobs. It was the repetitive research and data entry around every opportunity. I started building a Python workflow to automate discovery and organisation, so I could spend more time evaluating roles and applying.
My role and responsibilities
I initiated the project to solve a problem I was experiencing myself. I researched possible approaches, evaluated data sources, built the workflow, and expanded it as I encountered technical limitations.
- Defined the problem and project scope.
- Researched automation approaches, APIs, and scraping feasibility.
- Built Python collection and filtering scripts.
- Integrated filtered job data with Google Sheets.
- Tested job boards and different company career page structures.
- Debugged and expanded the working prototype.
The problem was the work around the search
Every relevant opening meant switching between job boards, company websites, and my tracker. I had to find the vacancy, check its details, assess whether it matched my requirements, then copy and organise the information.
That created three persistent challenges:
- Repetitive research: searching across multiple sources to discover relevant openings.
- Manual data entry: copying job details into the tracker one vacancy at a time.
- Poor scalability: more sources and opportunities made the manual process harder to maintain.
I wanted to reduce the effort needed to populate the spreadsheet, rather than simply make a better spreadsheet.
Choosing a practical way to collect openings
Two approaches, with different trade-offs
I considered connecting services through a visual automation platform such as n8n. I was concerned about the cost of scaling that approach as I added sources and requirements. A custom Python solution gave me more control over collection, filtering, and spreadsheet updates, while letting me expand the system incrementally.
Working around source limitations
My first idea was to collect listings directly from LinkedIn and Naukri, but programmatic access to their job data was not straightforward. I explored sources with more accessible interfaces instead, starting with supported Greenhouse, Lever, and Ashby career listings. I also added JSearch, a third-party API that aggregates listings and provided another discovery route through its free tier.
This gave me a practical foundation without making the system depend on one source or requiring me to build every collector from scratch.
Designing the workflow
The system separates collection from filtering so I can add sources without rebuilding the whole process. The key decision was to automate discovery and organisation while keeping the final decision to apply in my hands.
The first successful run
~20
openings passed the initial filters and were added to Google Sheets in the first successful run.
~10
relevant openings are currently surfaced on average across different Indian cities in my runs.
These figures describe my prototype and current testing, not a benchmark or a guarantee of results.
Expanding coverage means adapting to messy pages
The first version worked, but it exposed the main scaling challenge: companies publish openings in different ways. Standard career platforms offer more consistent structures, while other organisations use recruitment systems or custom-built pages. Adding a source can mean writing and testing a source-specific crawler, checking how fields are presented, and accounting for changes over time.
I have been testing additional Greenhouse portals, Zoho Recruit-powered pages, and custom HTML layouts. The goal is to pass each source’s results through the same filtering and spreadsheet workflow, while recognising that not every website can be scraped reliably.
What changed in my process
The project has evolved from a manual Google Sheets tracker into a working job-discovery automation system. Multiple source types are supported, including Greenhouse, Lever, Ashby, and JSearch, with additional sources still being tested.
Google Sheets remains the central place to review openings and manage applications. The system does not decide whether a role is right for me, confirm that every vacancy is still active, or submit applications. It reduces the repetitive work before those decisions.
My workflow is now simpler: review the spreadsheet, evaluate relevant openings, and apply.
What I learned and what comes next
- Source availability shapes the architecture. Access to job data differs between platforms.
- Modularity supports expansion. Separate collection, filtering, and sheet updates make new sources easier to add.
- Real-world data is messy. Titles, locations, dates, and other fields vary across sources.
- Automation needs validation. Passing a filter does not guarantee a good fit or an active listing.
- Reducing friction matters more than volume. The goal is a search process I can manage consistently.
Next: expand career-page coverage, improve extraction across layouts, reduce duplicates, check whether vacancies remain active, refine qualification, and measure time saved against the original manual process.
A useful system that can keep improving
I started this project because I was tired of spending so much time managing my job search manually. What began as a personal workaround has become an ongoing exercise in product thinking, automation, and iterative problem-solving.
For me, building a useful product means identifying a real friction point, solving the most important part first, learning from the limitations, and improving the solution through real use.