Ansh Bhalala

< all notes

I research every company before I apply. Here is the system.

, 3 min read. Ansh Bhalala, co-written with AI from my own repos, notes, and session logs.

I graduate in December 2026, so I'm job hunting during my last semester. I would rather send fewer applications that each say something true about why I fit than spray a hundred. That means knowing what a team actually builds before I write to them. Claude Code does the reading and organizing. The decisions, and every word that goes out under my name, stay with me.

One tracker

Every role I'm considering lives in one CSV: company, role, location, status, the link to the posting, notes, and the next step. Claude can read it, sort it, and tell me what's stale, but it can't add a role without a working link, and it can't report on a role that isn't in the file. That rule exists because a model asked to "find me jobs" will happily describe jobs that don't exist.

I keep a small dashboard for flipping statuses during the day, and a daily step writes those changes back into the CSV and commits it. One source of truth, the same rule I use for ORRN's data.

A morning feed of new roles

A short Python script runs on a small server every morning. It reads public new grad listings, mostly the SimplifyJobs feed, plus company career pages on Ashby, Greenhouse, and Lever. It keeps roles that match what I've actually built: backend and full-stack work, applied AI, developer tools, and anything that touches hardware or operations. It dedups against the tracker and leaves a short list for me to read with coffee.

A brief before every application

This is the part I care about. For each role on the short list, I ask for a research brief: what the company ships, who the team is, what they've written or open sourced, and where my work honestly overlaps. Sometimes there's a real overlap, like a company that prints labels or runs a warehouse. Often the brief shows me how much I'd have to learn, which is useful to know going in. Sometimes it tells me the role isn't a fit, and I skip it.

The brief also shapes what I write. If a team just shipped something on Cloudflare Workers, I mention D.O.R.I.S.. If they build for operators, I talk about ORRN. Every claim has to point at something real on this site.

Referrals at big companies

If a company has more than 500 employees, the tracker flags it for a referral first, with a reminder a few days out. At that size a warm introduction matters most, and I'd rather talk to someone on the team before my resume lands in a queue.

Rules I keep

  • Nothing is sent or submitted under my name until I've read it.
  • Never invent a claim about my experience. If it isn't in a repo or on this site, it doesn't go in.
  • Every role in the tracker has a working link.
  • Personal data stays out of git.
  • All writing goes through a plain-language ruleset: no em dashes, no filler, no buzzwords.

Why bother

It's the same habit I bring to engineering work: understand the problem before writing code, keep one source of truth, and check the output against something real. If you're hiring and you got a message from me, it's because I read about what your team builds and thought I could help.

More notes