ambicuity/New-Grad-Jobs

TL;DR We want to dramatically expand the job data this project surfaces, and we need your ideas. Whether you have a small tweak, a wild idea, or a full proposal — drop it in the comments. All suggestions are welcome and I will reply to every comment. Why this roadmap? New-Grad-Jobs is most useful when it captures the widest possible surface of legitimate new-grad opportunities. Today we scrape and curate from a known set of sources, but there's a long tail of companies, regions, and job types we're missing. This issue is the central place to brainstorm how we add more jobs — sources, regions, scrapers, partnerships, automation, data quality, anything. What kind of suggestions are we looking for? Pick whatever resonates — these are just prompts: Sources Specific ATS platforms we don't yet scrape (Workday tenants, Greenhouse boards, Lever, Ashby, SmartRecruiters, iCIMS, Taleo, Eightfold, Phenom, Jobvite, BrassRing, etc.) Specific companies whose new-grad pipelines we should tra

🐥 Beginner Friendly Welcome! This is a Beginner Issue — a natural next step after Good First Issues. It expects you to: Read existing code and follow its patterns Own a small implementation decision Write or extend tests Difficulty: Basic Python (reading and writing functions) required No external API experience needed Familiarity with the contribution workflow expected ImportantWe recommend completing at least one Good First Issue before attempting a Beginner Issue. You must be assigned before starting — comment /assign to claim this issue. PRs submitted without a prior assignment will be closed. 👾 Description of the Issue run_integrity_checks() in scripts/quality.py is a key guardrail for publish safety, but several important failure paths are not explicitly regression-tested end-to-end. Add targeted tests for scenarios such as: missing required artifacts (docs/jobs.json, docs/health.json) invalid JSON payloads jobs/health count mismatch detection contract validation

🧩 Intermediate Contributors This issue is intended for contributors who already have experience with this repository and the contribution workflow. You should feel comfortable: Navigating scripts/update_jobs.py, config.yml, and tests/ Understanding how filter_jobs(), deduplicate_jobs(), and categorize_job() work Following existing patterns without step-by-step guidance Writing non-trivial pytest tests with mocking ImportantYou must be assigned before starting — comment /assign to claim this issue. PRs submitted without a prior assignment will be closed. 🐞 Problem Description scripts/evaluate_jobs.py is part of the published analytics sidecar path, but it has little to no direct test coverage for: eligibility gating logic (_is_eligible) scoring heuristics (_score_job) output artifact shape and metadata consistency in main() This creates risk that silent scoring/contract regressions ship unnoticed. 💡 Expected Solution Add deterministic tests covering: _is_eligible includ

Problem Location semantics are maintained in multiple places (scripts/update_jobs.py and docs/app.js). These can drift independently, leading to inconsistent filtering UX (backend accepts values that UI cannot target, or UI filters that do not map cleanly to backend acceptance). Proposed Solution Add a contract check (test and/or generated contract artifact) that enforces location taxonomy alignment between backend and frontend: parity for supported country set (USA/Canada/India/Remote semantics) consistency checks for representative state/province token coverage CI failure on incompatible drift unless both sides are updated intentionally Alternatives Considered Rely on manual coordination between scraper and frontend changes (drift risk remains high). Keep documentation-only guidance without enforcement (not CI-protected). 🏗️ Which area does this affect? 🧪 Tests (tests/) Constraints Check This does NOT require an external database (PostgreSQL, Redis, SQLite, etc.) This

🧠 Advanced Contributors This issue is for contributors who are already very familiar with this codebase and its architectural patterns. You should feel comfortable: Modifying ThreadPoolExecutor orchestration safely Reasoning about source-level concurrency, backpressure, and failure handling Writing rigorous, deterministic tests without live network calls ImportantYou must be assigned before starting — comment /assign to claim this issue. PRs submitted without a prior assignment will be closed. 🐞 Problem Description The scraper already uses aggressive parallelism and configurable worker pools, but the orchestrator still treats concurrency as mostly static for the duration of a run. That creates a gap when sources behave very differently in real time: some sources stay healthy and can sustain more throughput some sources begin returning 403 or 429 and should be backed off quickly some sources are slow but successful and should not starve the rest of the run There is already