Your search guide.

Placement is here

A personal off-campus search workspace: a small static dashboard with GitHub-readable source lists, a role tracker, and a practical preparation plan.

!Dashboard preview

Start here

• Hiring-feed setup and sources.
• Collected job listings.
• Dashboard — company search, priorities, applications, next actions, backups.
• Company watchlist — discovery targets, not confirmed openings.
• Profile and positioning — evidence, fit, and unknowns.
• Four-week plan and weekly rhythm.
• Gmail, Notion, scheduling, and privacy.
• Publishing and development.
• Validation and remaining access requirements.

Open the dashboard

The dashboard is now a self-contained HTML file: styles, JavaScript, and company data are embedded. Download index.html and open it in your browser; no running cloud server is required. guide.html is self-contained too. Download both into the same folder to keep the guide navigation working. GitHub's file viewer shows HTML source; use Download raw file to save it, then open the saved file in a browser.

A preview that blocks JavaScript will still show the company list. Use a normal browser for the interactive tracker. If a preview blocks browser storage, the tracker runs in session-only mode and tells you to export before closing.

Run locally

Requires Python 3 and a modern browser. No package install, build, API key, or database is needed.

cd /workspace/placement_is_here

python3 -m http.server 8000 --bind 0.0.0.0

The local server is optional. It is useful during development and browser tests; it is not a published website and can stop when the cloud session ends.

One workspace, two views

templates/index.html, styles.css, and app.js are the dashboard sources; index.html is generated. data/companies.json is the company source of truth. Run python3 tools/generate.py after editing it to refresh the Markdown list. The same command regenerates the self-contained dashboard and the browser guide from Markdown. Run it after changing the UI sources too. data/profile.json contains the initial self-reported profile; keep it consistent with the profile guide when updating it.

Applications save in browser localStorage on the current origin. They do not automatically write to GitHub or Notion, and changing browser, port, domain, or private-browsing session can change what is available. Export frequently. To seed a new browser, import a backup; optionally place a sanitized application array in data/applications.json. A seed is read only when browser storage is absent. An existing empty local list still takes precedence.

Use a private repository for private job-search information. Even a private repository may publish a publicly accessible Pages site depending on your GitHub plan/settings. Keep data/applications.json empty on a public site. Never put email bodies, personal identifiers, recruiter contacts, tokens, or confidential assessment material into a public repository.

Application data

One record per role, not per company. Statuses: Researching → Ready to apply → Applied → Recruiter screen / Assessment / Interview → Offer / Rejected / Withdrawn / Closed. Referral requested is an additional stage. Silence is not rejection; set a follow-up date. Offers can still have pending actions.

{

  "id": "a-unique-id",

  "company": "Company name",

  "role": "Exact job title",

  "url": "https://example.com/careers/job-id",

  "location": "Bengaluru",

  "status": "Applied",

  "appliedDate": "2026-10-19",

  "nextAction": "Check application portal",

  "dueDate": "2026-10-26",

  "notes": "Eligibility checked against the posting."

}

Backup format: { "version": 1, "applications": [...] }. Import also accepts an array. Import replaces the browser list after confirmation; it does not merge records. Export first. Dates use the browser's local day. Count of active applications includes research, ready-to-apply, and referral stages; it excludes offers and closed outcomes.

Current integration state

A daily public-job collector and GitHub Actions refresh/deploy workflow are configured; live collection must succeed before listings appear. No mailbox, Notion database, calendar, or automatic outreach is connected. The browser app makes no third-party runtime requests; the scheduled server-side collector requests configured public ATS boards. Its official career links open external sites only when clicked. See the integration guide before enabling any automation.

Profile and positioning

Workspace · Dashboard · Plan · Integrations

Working profile

Final-year BTech student at IIT Delhi, with a minor including data structures, algorithm analysis, dynamic programming, greedy correctness, flows, and complexity. Main branch, exact graduation month/year, internship dates, and availability are still unknown; do not guess them in applications.

Experience reported: a technology internship at Country Delight; AI evaluation tasks through DataAnnotation including model rating and repository tasks; intermediate ML exploration through an Amazon ML learning program. Confirm exact program title before putting it on a CV. Current COV888 coursework covers distributed web data, XML/BaseX, web services, NoSQL, cloud, P2P, and blockchain.

Strengths: Linux familiarity over several years, Bash basics, breadth across full stack and ML, algorithm coursework, and regular use of Claude/Codex to build and debug. These are starting points; project quality and independently explainable contributions supply the evidence.

Self-assessed preparation, not an objective test score: OS 4/5; OOP 3/5 with revision needed; networking 1/5; DBMS/SQL 1/5. DSA is intermediate by self-report.

Role order

• Graduate / junior SWE, backend, full stack, developer tools. Broadest fit for your current evidence.
• Applied AI engineer, AI product engineer, evaluation engineer, ML tooling. Prefer roles emphasising software, evaluation, deployment, and data over research publication requirements.
• Infrastructure / platform / cloud roles selectively. Linux is a useful base; strengthen networking, debugging, observability, and service design. Check degree eligibility per posting; don't self-reject based on a general branch assumption.

Research scientist, senior MLOps, and specialist systems roles may require depth you have not demonstrated yet. Keep them as exploratory targets rather than the main application funnel.

Resume strategy

Maintain a SWE version and an applied-AI version. Both should show the internship, strongest project, relevant coursework, and clear dates. Infrastructure applications can use a tailored SWE version with Linux/service evidence.

For every experience bullet, capture: problem → your exact contribution → technical decision → measured result. Use real measurements only. For Country Delight, establish what you changed, your ownership, stack, tests, and effect. For DataAnnotation, describe evaluation work accurately; distinguish evaluation from model training and follow confidentiality obligations.

Do not lead with “I use Claude for faster deployment.” Lead with what you built, how you verified it, and which decisions you own. AI-assisted work is useful when you can explain architecture, review changes, reproduce results, and debug without blindly accepting suggestions. Never invent usage metrics, internship ownership, or employment at a company whose course you attended.

Before the first applications

• Confirm graduation date, main branch, internship dates, start date, and city preferences.
• Prepare a one-page resume and clean public project links.
• Choose one strongest existing project to improve instead of starting many new demos.
• Check every posting's required years, graduation window, degree/branch, location, employment type, and work authorization.
• For remote roles, verify the employer can hire someone residing in India; remote does not imply worldwide.
• For overseas roles, record explicit sponsorship evidence or mark it unknown.

Search plan and preparation

Workspace · Dashboard · Profile · Companies · Connections

Priorities with a practical time budget

Your search order is: large companies with India roles → startups/scaleups with India roles → remote roles abroad that hire India residents → on-site roles abroad. Company tiers reflect your preferences, not hiring probability or company quality. Apple and Netflix belong in the first watchlist, but do not wait on them: suitable India graduate engineering openings may be limited.

Start with 50% of search time on large-company India roles, 35% on startups/scaleups in India, 10% on eligible remote roles, and 5% on overseas roles. Treat these as adjustable time allocations. Search by role and eligibility, not brand alone. Review conversion after two weeks; increase effort where suitable openings and replies actually exist.

Weekly rhythm

Suggested starting budget alongside college: 90–120 minutes on weekdays, with one longer weekend block. Adjust to coursework and interviews. Aim for 8–12 well-matched applications a week as an initial planning target, not a quota that justifies poor matches.

Draft referral messages first; send only after review. Use meaningful context, a role link/ID, a short fit explanation, and an easy way to decline. Do not mass-message alumni.

Follow-up default: one polite follow-up around 7–10 business days after applying or the agreed timeline, unless the employer says otherwise. Do not assume no response means rejection. Create a due date for each unresolved action. Avoid repeated follow-ups without new information.

Four-week preparation sequence

Keep DSA warm throughout: a few focused sessions each week, revisiting errors rather than only counting solved problems. For ML roles, add train/validation/test separation, leakage, evaluation metrics, baselines, and model failure analysis. For infrastructure, add processes, permissions, ports, logs, resource constraints, and one reproducible service deployment.

One project that supports multiple lanes

Improve your strongest existing project. A small service with persistent data, a tested API, structured logs, and reproducible deployment supports SWE and infrastructure applications. If it already uses AI, add an evaluation dataset you have rights to use, a baseline, failure cases, and measured latency/cost. An AI feature is optional; complexity without evidence does not improve the signal.

Deliverables: a README that someone else can run, a clear architecture diagram, tests for meaningful failures, and a short explanation of your own decisions. Keep tool-generated output only after review. Explain the code and rebuild a critical path without relying on generated answers.

Review every week

Track applications by role: date, source, location, eligibility, stage, outcome, next step, due date. Count applications, human replies, assessments, interviews, offers, rejections, and pending responses separately. Exclude automated acknowledgements from positive replies. Compare cohorts with similar time since applying; fresh applications should not make a lane look ineffective.

If there are few replies after a reasonable wait, review resume clarity, role fit, proof of work, and sourcing. If assessments fail, focus on DSA or the assessed skill. If interviews stall, practice explanations and inspect topic-specific gaps. Change one major lever at a time.

Connections, scheduling, and privacy

Workspace · Dashboard · Plan · Profile

What works now

The dashboard and GitHub lists share data/companies.json. Application edits live in this browser and can be exported/imported. Gmail, Notion, Calendar, and repository writes are not connected. No mail is read or sent, no calendar events are created, and no application is submitted by this app.

Choose a single application source of truth before adding sync. Until then, the browser tracker plus private exported backups is the default. Notion can become the source of truth later; avoid independently editing the same applications in several places without a reconciliation strategy.

Connect services

Connect Gmail and Notion through the service integrations available in your assistant/product. No usable Gmail or Notion tools are available in the current workspace. If you want calendar scheduling, connect Google Calendar too. Do not paste credentials, mailbox exports, or sensitive messages into this repository. A connection must be tested before automation is claimed.

Once connected, provide the intended Notion database/page reference and choose a mailbox scope. A safe first pass is to inspect a small user-selected set of job-related messages, propose matches and status updates, then review ambiguous ones. Reading a mailbox for tracking does not authorize sending email or applying for jobs.

Gmail workflow

Create a label such as Job Search. Label relevant application threads manually first, then add narrow filters for confirmed sender domains or known company/ATS threads. Avoid labelling your entire inbox with broad keywords. Useful Gmail searches (paste into Gmail's search bar):

• label:"Job Search" newer_than:30d
• label:"Job Search" {interview assessment recruiter}
• label:"Job Search" {"not moving forward" "unfortunately" "regret"}

These queries are review aids, not reliable outcome classifiers. Read context and distinguish auto-acknowledgement, positive interest, assessment invitation, interview, rejection, and offer. A rejected application at one role does not close every application at that company.

Match by job ID, exact role, company, existing thread, and sender. Store thread/message IDs for deduplication in a future private sync store. Mark uncertain matches for review, and never infer acceptance or rejection from sentiment alone. Retain only a short non-sensitive summary and private reference link, not full email bodies.

Notion database design

Use one record per application. Suggested properties:

Views: actions due, interview preparation, active applications by priority, closed outcomes, and eligibility still unknown. Put profile, preparation plan, and company radar links on the parent page. Keep resume variants and private job details appropriately restricted.

A future sync service needs least-privilege OAuth, secure token storage outside GitHub, pagination, retries, stable IDs, idempotent updates, and conflict handling. A scheduled GitHub Action is possible but is not a permanently running backend. Do not expose OAuth refresh tokens in static JavaScript. No automation is installed yet.

Calendar

For now, create your own recurring search/preparation blocks from the weekly plan, and use application due dates for reminders. Interview events should record the employer-confirmed time zone, meeting link, preparation block, and application reference. Calendar invitations and changes require an actual integration and explicit scheduling instructions. No events have been created.

Publication boundary

A static site is suitable for non-sensitive UI, company discovery, and a local private tracker. A shared, authenticated, cross-device application database requires a backend or a properly authorized Notion integration. Do not treat an obscure Pages URL as access control. Export files and browser storage can contain personal data; protect them accordingly.

Run, maintain, and publish

Workspace · Dashboard · Integrations

Open without a server

Download index.html and open it in a normal browser. It embeds its CSS, JavaScript, company list, and empty application seed, so it does not fetch adjacent files. Download guide.html into the same folder for the linked guide. GitHub's HTML source viewer is not a live website. Preview viewers may block scripts or storage; the company list stays readable without scripts, and blocked storage uses an explicitly labelled session-only mode.

Development

Use the existing checkout; no worktree is necessary. Python 3 serves the static files:

cd /workspace/placement_is_here

python3 tools/generate.py

python3 -m http.server 8000 --bind 0.0.0.0

There are no runtime dependencies. node --check app.js validates JavaScript syntax. A browser test script is in tools/smoke.cjs; it uses Playwright if available in the development environment and exercises filtering, persistence, next-action updates, import/export, and malicious text handling. Run it against a server started above with node tools/smoke.cjs.

Update data/companies.json for company changes. Each company has an ID, name, priority, official careers URL, target roles, caution, opening status, and verification date. Check exact job postings separately. Don't label a vacancy verified merely because its careers homepage loads. Run the generator to update Markdown and the browser-readable guide. Keep private application backups outside the checkout. Edit templates/index.html, styles.css, and app.js; regenerate index.html rather than editing it directly.

GitHub Pages

A deployment workflow is provided at .github/workflows/pages.yml. It uploads only public UI assets and data, not the whole checkout. It runs on pushes to main or a manual workflow dispatch. Pages must already be enabled with GitHub Actions as the source in repository settings. The workflow uses the standard GITHUB_TOKEN to deploy to an existing Pages site; it does not attempt to enable Pages automatically. GitHub’s configure-pages action documents that automatic enablement requires a different, admin-capable token. No extra token is needed for this setup when Pages is enabled manually.

• Decide whether the repository and site may be public. The current profile includes university, experience, and skill self-assessments. Remove details you do not want published from both Markdown and JSON, then regenerate the browser guide. Keep application seed data empty unless intentionally public.
• Commit the reviewed files and push a main branch to lakshay-lg/placement_is_here. A successful push adds repository files; only a successful Pages deployment establishes a live website.
• In repository Settings → Pages, select GitHub Actions as the source. Availability and visibility depend on your GitHub plan and organization policy.
• Run the Deploy dashboard workflow (or push to main) and inspect its result. Use only the URL returned by a successful Pages deployment.
• Check company loading, guide links, adding a disposable record, persistence after refresh, and import/export on the published origin. Local browser data does not transfer to that new origin automatically.

The workflow uses relative links so it works under a repository Pages subpath. The site has no authentication, mail integration, or server-side database. Hosting is continuous after a successful deployment, but live processes from a development environment do not persist with the site.

Deployment errors

• Configure existing Pages site / Get Pages site failed / Not Found: open repository Pages settings and select GitHub Actions as the source. If Pages settings require a plan upgrade, private-repository Pages is unavailable on the current plan; choose an eligible hosting option rather than making the repository public automatically.
• Create Pages site failed / Resource not accessible by integration: older runs attempted automatic enablement with the default workflow token. Enable Pages manually and run the latest workflow on main; re-running an old failed job can retain the old workflow definition.
• Deployment protection or waiting for approval: review the github-pages environment’s allowed branches and any required approvals. The deploy branch is main.
• Validate generated site: run python3 tools/generate.py, commit the regenerated files, and push. The workflow deliberately fails when checked-in outputs differ from their sources.
• Another error: inspect the failed step and capture its exact message. Do not infer a successful deployment from a successful push or a locally passing build.

After saving Pages settings, start a fresh Deploy dashboard run on main. A successful deployment reports the actual website URL in the github-pages environment.

Company watchlist

Discovery targets, not verified live openings. Check location, eligibility, and the specific job posting before applying. Priority reflects search preference, not hiring probability.

Validation and remaining setup

Workspace · Development

Verified in the current environment

• JavaScript syntax; local asset and guide paths.
• Browser tests with Playwright and system Chromium: 29 company records, priority filtering/search, form prefill, application persistence after reload, status/due counts, export/import, unsafe URL rejection, safe literal text, deletion, guide anchors, mobile width, and recovery from corrupted local storage.
• Standalone HTML works over HTTP with all other network requests blocked, and in a sandbox-style document. Direct file-URL navigation could not be tested because this environment’s managed Chromium policy blocks file URLs. No third-party runtime dependency or adjacent asset fetch is required.
• Blocked browser storage supports session-only tracking with explicit export reminders; JavaScript-disabled viewers retain a static list of all companies.

Hiring-feed checks

• Fourteen collector tests cover all three provider adapters, persistent first-seen identity, successful empty boards, failed/malformed responses, partial failures, duplicate records, reopened listings, disabled sources, and remote-country caution.
• Live board requests returned network proxy 403 even after an escalated retry. Candidate sources have not been live-verified. The setup snapshot contained error status and no listings; consult the current feed source-health panel for subsequent results.
• Daily refresh/deployment workflow is configured; its remote execution and output must be checked independently.

Not verified / not active

• Employer career pages all returned network proxy 403 during this run. The list remains unverified; no specific live role is claimed.
• GitHub API read returned Forbidden. Native Git and API permissions are separate; verify push results and Pages deployments independently.
• Gmail / Notion / Calendar are not connected. Integration installation did not expose usable tools.
• New-task restoration and deployed-origin behaviour have not been tested.

Saved environment draft

Startup instructions and the following custom network destinations were saved for review; package-manager presets were preserved. Saving did not apply runtime settings or publish the environment. Review and save in environment settings, then publish the environment. After propagation, retry blocked reads before concluding authentication is missing.

• about.gitlab.com
• api.github.com
• automattic.com
• canonical.com
• careers.adobe.com
• careers.microsoft.com
• careers.oracle.com
• careers.salesforce.com
• careers.servicenow.com
• grafana.com
• groww.in
• jobs.apple.com
• jobs.netflix.com
• optiver.com
• razorpay.com
• stripe.com
• www.amazon.jobs
• www.atlassian.com
• www.bloomberg.com
• www.browserstack.com
• www.cloudflare.com
• www.databricks.com
• www.google.com
• www.meesho.io
• www.nvidia.com
• www.observe.ai
• www.postman.com
• www.rippling.com
• www.sarvam.ai
• www.uber.com

Daily hiring feed

Workspace · Dashboard · Collected listings · Companies

Where to find openings

For Apple, Netflix, Google, Microsoft, and Amazon, use their official career search/alerts until a supported collector is added. The feed does not cover every watchlist company. Avoid scraping logged-in job aggregators, bypassing CAPTCHAs, or treating reposted listings as confirmed openings.

What is implemented

The dashboard has a Hiring feed before the company radar. It filters by India-mentioned locations, remote roles requiring country checks, other/unclear locations, experience-title signals, first-seen age, and search text. It hides obvious senior-title signals by default, shows 30 matches at a time, and can prefill the application tracker with an exact role and posting link.

Source configuration lives in data/job-sources.json. The initial eight candidate boards are Databricks, Stripe, Postman, Canonical, Grafana Labs, GitLab, Meesho, and Sarvam AI. Their API requests were blocked by the cloud network policy during setup, including an escalated retry. At setup, board identifiers and live coverage were pending a successful source check. Consult the feed’s current source-health panel for subsequent results. No live openings have been invented to fill the feed. A migrated or invalid board will show an error until its provider/board ID is corrected against the employer’s current career-page link.

The output is data/jobs.json, embedded into index.html; a GitHub-readable summary appears in docs/openings.md. Application records remain private browser data and are not sent to these APIs or committed by the refresh workflow.

Daily update

.github/workflows/refresh-jobs.yml runs around 9:00 AM India time every day (03:30 UTC), on a manual dispatch, and when collector/source configuration changes on main. GitHub schedules are best effort and may be delayed; this is not a continuously running scraper.

The job fetches public JSON, checks its structure, normalizes engineering-title matches, saves the feed to GitHub, regenerates the static page, then calls the Pages deployment workflow explicitly. This explicit call matters: commits made by GITHUB_TOKEN do not normally trigger another push workflow.

Pages still needs to be enabled with GitHub Actions as its source. The refresh job also needs permission to push ordinary commits to main. If branch protection rejects bot writes, the workflow fails rather than rewriting history or bypassing protection; use a PR-based refresh workflow or explicitly approved repository policy. No PAT is required by the collector.

A failed Pages deployment does not roll back an already saved feed snapshot. A feed failure does not mean there are no jobs.

Freshness and matching limits

• First seen: when this collector first discovered a role. Initial collection can include old jobs. It is not “posted today.”
• Source published date: shown only when the provider supplies a publication field; Greenhouse update timestamps and Lever creation timestamps are not relabelled as publication dates.
• Last seen: last successful response containing that role. Failed sources retain previous records and display stale warnings.
• No longer listed: used only when a successful, structurally valid board response omits a previously seen job. This is not a confirmed rejection or proof that a vacancy is filled. Roles that remain on the board but move outside the engineering-title filter are recorded separately, not marked closed.
• Source health: every attempt records which boards succeeded, failed, or have never succeeded. If every source fails, the workflow saves status but marks the refresh job failed. Partial failures remain visible while other sources update.
• Eligibility: title/location heuristics only. Experience years, degree/branch, graduation date, work authorization, sponsorship, and India payroll eligibility are not verified. “Remote” is not “worldwide.” Senior-title filters are a convenience, not a suitability decision.
• Coverage: engineering-like titles, including ML and infrastructure; not every employer or role. The GitHub list displays up to 100 listings, while JSON retains the collected records.
• Snapshot: a downloaded HTML file never silently updates itself. Download again or use the successfully deployed site for new snapshots. Browser application tracking is separate.

Run or extend it

cd /workspace/placement_is_here

python3 -m unittest discover -s tests -v

python3 tools/fetch_jobs.py

python3 tools/generate.py

The collector uses Python’s standard library with TLS verification, bounded response sizes, one board request at a time, and a limited retry for rate-limit/server errors. It does not fetch every job detail page. No credentials are needed for the public APIs.

To add a source, inspect its official career-page application links to find the actual provider/board token, add one entry to data/job-sources.json, then run a successful check. Do not guess success from a company name. Test unknown schema changes before accepting them as a complete snapshot.

Provider references: Greenhouse Job Board API, Lever postings API, Ashby public Job Posting API.

Collected job listings

Listings from configured public ATS boards. First seen is discovery time, not employer publication time. Check source health and original eligibility requirements. This view shows up to 100 listings; data/jobs.json retains all collected records.

Last successful collection: 2026-10-20T22:44:14+00:00

Source health

• Databricks: ok; last success: 2026-10-20T22:44:14+00:00
• Stripe: ok; last success: 2026-10-20T22:44:14+00:00
• Postman: error; last success: Never
• Canonical: ok; last success: 2026-10-20T22:44:14+00:00
• Grafana Labs: ok; last success: 2026-10-20T22:44:14+00:00
• GitLab: ok; last success: 2026-10-20T22:44:14+00:00
• Meesho: ok; last success: 2026-10-20T22:44:14+00:00
• Sarvam AI: ok; last success: 2026-10-20T22:44:14+00:00