# Wait, What Do You Do?

> Know what a job really is before you apply. Jobs (data and AI roles today) come directly from employers' own careers sites and hiring systems rather than from other job boards, and each carries our record of the posting: when we first saw it, when we last saw it, how many times we have checked it, and whether the employer still lists it. Job titles also say little (one company's Data Scientist builds models, another's builds dashboards), so we sort every job by the work its posting describes, whatever the title says.

Employers' own posted dates are often reset or wrong, so the date to trust is ours: "First seen by us" is when we first found the posting on the employer's site. A listing is open while the employer still lists it; we mark it missing when it drops off and closed once we confirm it is gone.

## Use it from an assistant

- [MCP server](https://waitwhatdoyoudo.com/api/mcp): remote MCP over streamable HTTP. Free, and searching needs no account.
- [Check a job](https://waitwhatdoyoudo.com/check): paste any job link (LinkedIn, Indeed, the employer's site) to see our record of the employer's posting; the same check as JSON at /api/verify-job?url=, free and with no key
- [Setup guide](https://waitwhatdoyoudo.com/connect): connecting Claude, ChatGPT, Cursor, Claude Code and other MCP clients, and what each tool does

Tools that read public job data:

- `search_jobs`: Search open data and AI job postings. All filters combine (AND). Results are newest first, with our first-recorded date and listing status for each.
- `get_job`: One posting's details: our record of when we first saw it and whether it is still listed, pay and working pattern where the posting states them, for US postings what comparable postings stated as pay, responsibilities, the description, and the apply link.
- `get_company`: An employer's open data and AI roles plus its hiring record: how many roles are open, how many we first saw in the last 30 days, the median days open, and the mix by role category.
- `list_categories`: The role categories we classify data jobs into, by what the job actually involves rather than its title.
- `verify_job`: Check whether a job is real before anyone spends time applying: give any job link (the employer's own careers page, LinkedIn, Indeed, Glassdoor or our site) and get our record of the employer's own posting: when we first saw it, whether it is still on the employer's site, how often it was reposted, what it pays, and how the employer's postings usually end. Free, no sign-in. For a job board link that doesn't name the job (Indeed), also pass the title and company as the listing shows them, and the location when the employer lists the title in several cities.

Tools that need the person to sign in (OAuth, asked for the first time one is used):

- `get_profile_summary`: The signed-in seeker's job preferences: role categories, tools, work setting, locations and work to avoid. Contact details, demographic answers and the resume are never included.
- `match_jobs`: Open data and AI jobs ranked against the signed-in seeker's preferences, with the reasons each one fits and anything to check.
- `list_updates`: What changed in the last 14 days in the signed-in seeker's watched searches, saved jobs and applied-to jobs: new postings, postings that closed, went missing or were reposted, and changes to a saved job's title, pay, work setting or location. Also follow-ups due on applications sitting at applied, each with a drafted note for the seeker to edit and send themselves (never send it for them), the seeker's alert settings, and the watched searches and whether each sends email.
- `list_applications`: The signed-in seeker's applications board: saved jobs, and tracked applications with their stage, next step and follow-up date.
- `get_connections`: Who the signed-in seeker knows at an employer, from the LinkedIn connections they added to their profile: names, LinkedIn profile links, positions and why each is a good first ask (people doing similar work first, then recruiters). Give a posting's slug to rank people for that role. Only first-degree connections; it never contacts anyone. Suggest a short ask the person can send themselves.
- `save_job`: Save a posting to the signed-in seeker's saved jobs, the same list as the Save button on the site. Saving again changes nothing.
- `save_search`: Save a search to the signed-in seeker's watched searches, so new matching postings show in their updates. Takes the same filters as search_jobs. Email alerts stay as they are: a new watch starts with email off, and the seeker turns email on from their updates page.
- `update_application`: Track a posting in the signed-in seeker's applications, or change a tracked one: its stage, next step, follow-up date or notes, and what happened (outcome), whether they were referred, and the resume version they sent, only as the seeker tells you. Only the fields given change. It never applies to the job; applying happens on the posting's page.
- `update_preferences`: Change the signed-in seeker's job preferences, the ones match_jobs and fit scores use: role categories, tools, work setting, places, things to avoid and the lowest yearly pay they want. Only when the person asks. Each field given replaces that preference whole, so read get_profile_summary first and keep what they still want; fields left out stay as they are. Contact details, resume and application answers are not changed here.
- `update_alerts`: Turn change alerts on or off for one saved job or for all of them, and set how many days an application sits at applied before list_updates suggests a follow-up (null turns those reminders off). Alerts show in list_updates and on the updates page; follow-up notes are drafts the seeker sends themselves. Only the fields given change. Use only when the seeker asks.
- `prepare_application`: Draft the signed-in seeker's application for one posting: a cover letter and answers to the employer's free-text questions, written from their profile and resume. Questions on the employer's form we know are included; add any others the person shares. The drafts are saved for them: the posting's page shows them, and our Chrome extension fills them into the employer's form after the person checks each one. Pass the person's own edits in answers or cover_letter to save their wording. It never applies; the person reviews and submits. Contact details, demographic, work-authorisation, pay and consent questions are left to the person. When the employer has a policy on candidates using AI (ai_policy), nothing is drafted from scratch: the person writes first drafts, you pass them in my_drafts, and they come back refined.
- `review_application`: Lay out the signed-in seeker's application for one posting exactly as submit_application would send it: every field on the employer's form with the value that goes out (contact details from their profile, saved drafts, their own answers), the resume file, and anything still blank. Show the person all of it, word for word, before asking to send. Questions marked person_answers (legal terms such as arbitration, AI-policy acknowledgments, EEO and other self-identification, work authorisation, visas, consent) are never filled for them: ask each one with its options as written and pass their own answer back in answers. Call again with answers to apply their edits; a new payload_hash comes back each time anything changes. Only postings whose employer takes applications through the board can be sent from the chat; for others it returns send_from_chat false with apply_url, the employer's own application page, and extension_url, our Chrome extension that fills that form in for them. When fill_in_browser is true, fields is the fill plan for that page: if you can use a browser, open apply_url, fill each question by its label with value (value_label for a choice), leave person_answers questions to the person, attach the resume file named in resume (or ask the person to attach it), and show the person the filled form. When fill_plan is answer_sheet we don't hold that form: match each answer to the page's question that asks for it, and ask the person every question on the page that isn't on the sheet. Press the employer's submit button only after they say "yes, submit" to it, then call update_application with stage applied. Stop and hand the page to the person at any CAPTCHA or sign-in; never get around one.
- `submit_application`: Send the signed-in seeker's application to the employer, exactly as the last review_application showed it. Only call this after the person has seen that review in full and said "yes, submit" to it in this conversation; never on your own judgement, never for several postings at once. Pass the same answers and the payload_hash from that review: if anything changed since (the posting, the form, their profile, or an answer), nothing is sent and you review again. One application per posting: a posting already applied to is never sent twice. On success the application is tracked as applied.

## Browse

- [All data jobs](https://waitwhatdoyoudo.com/jobs): the board, newest first by the date we first saw each posting; `?q=` searches it
- [Data analyst jobs](https://waitwhatdoyoudo.com/jobs/data-analyst): Answer business questions with reports and analysis.
- [Data engineer jobs](https://waitwhatdoyoudo.com/jobs/data-engineer): Build the pipelines that move and store data.
- [Data scientist jobs](https://waitwhatdoyoudo.com/jobs/data-scientist): Run experiments and build models that explain or predict.
- [Analytics engineer jobs](https://waitwhatdoyoudo.com/jobs/analytics-engineer): Shape clean, trusted tables for analysts, often in dbt.
- [Machine learning and AI engineer jobs](https://waitwhatdoyoudo.com/jobs/ml-engineer): Put machine learning models into products.
- [Data leadership jobs](https://waitwhatdoyoudo.com/jobs/data-leadership): Lead data teams or design how their data fits together.
- [How we count](https://waitwhatdoyoudo.com/about#how-we-count): what each number on the board means

## Guides

- [How to make your resume readable by applicant tracking systems](https://waitwhatdoyoudo.com/guides/ats-friendly-resume): What applicant tracking systems actually read from a resume, what their own help pages say breaks them, and the file and layout choices that work on every system we checked.
- [What each hiring system does with your resume](https://waitwhatdoyoudo.com/guides/hiring-systems): Workday, Greenhouse, iCIMS, Lever and 22 more: whether you sign in first, whether it reads your resume into its form, which files it takes and its size limits, each with a source.
- [What your Workday application status means](https://waitwhatdoyoudo.com/guides/workday-application-status): Submitted, In Progress, Completed and Withdrew: what each Workday status means, where to find it, and why it can change without anyone telling you.
- [How to tell if a job posting is real and still open](https://waitwhatdoyoudo.com/guides/ghost-jobs): Five checks before you apply: the employer's own site, how long it has been up, whether it was reposted, what the posting says, and the signs of a scam.

## Blog

- [How long do job postings stay up? We tracked 39,060 data jobs](https://waitwhatdoyoudo.com/blog/how-long-do-job-postings-stay-up): Half of US data job postings are still up two months after they appear, and one in five after six months. How long each kind of role stays up, drawn from employers’ own sites.
- [Should you apply to a job that’s been up for months? What 11,000 open data jobs show](https://waitwhatdoyoudo.com/blog/old-job-postings): The jobs left on a board after a few months are not a fair sample: remote roles go first, and old postings cluster at employers that leave everything up or stopped hiring.

## Feeds

- [New data jobs](https://waitwhatdoyoudo.com/feed.xml): RSS of the 50 roles we saw most recently
- [New data analyst jobs](https://waitwhatdoyoudo.com/feeds/data-analyst.xml): RSS
- [New data engineer jobs](https://waitwhatdoyoudo.com/feeds/data-engineer.xml): RSS
- [New data scientist jobs](https://waitwhatdoyoudo.com/feeds/data-scientist.xml): RSS
- [New analytics engineer jobs](https://waitwhatdoyoudo.com/feeds/analytics-engineer.xml): RSS
- [New machine learning engineer jobs](https://waitwhatdoyoudo.com/feeds/ml-engineer.xml): RSS
- [New data leadership jobs](https://waitwhatdoyoudo.com/feeds/data-leadership.xml): RSS
- [Sitemap](https://waitwhatdoyoudo.com/sitemap.xml)

## Contact

- Something wrong in a listing or our record of it: corrections@waitwhatdoyoudo.com
- Privacy and data requests: privacy@waitwhatdoyoudo.com
- [Tell us](https://waitwhatdoyoudo.com/feedback): what's wrong, missing or confusing; assistants can POST JSON `{"message": "...", "page": "/jobs/..."}` to /api/feedback

## Instructions the MCP server gives assistants

Wait What Do You Do (waitwhatdoyoudo.com) helps people know what a job really is before they apply. Data and AI jobs come straight from employers' own hiring systems, each with our record of the posting (when we first saw it, whether it was reposted, whether it is still listed) and sorted into a role category by the work it describes, whatever the title says. Use it to find data jobs, check a job link before applying, size up how an employer hires, and see what roles pay.

- verify_job checks any job link (careers page, LinkedIn, Indeed, Glassdoor) against the employer's own posting; call it before someone applies to a job found elsewhere. Report a match by title and company as such, and never call a job fake: say what the record shows.
- search_jobs finds roles (role, stack, place, remote/hybrid/onsite, seniority, visa, new graduates, industry, how recent); get_job gives one posting and its record; get_company gives an employer's open roles and hiring record; get_salaries gives what postings stated as pay for a role, a US city or an employer; list_categories explains the categories.
- Lead with what the page can't tell you: real age, reposts, whether it is still listed, how the employer hires. Then say what the work involves, and when the title and the work disagree.
- first_recorded and age are when we first saw a posting: call it "First seen by us". Employers' own dates are often reset. status: recently_seen (still listed), missing (dropped) or closed.
- Pay figures are ranges employers stated in postings, never what anyone was paid.
- Each result has a url to its page on the site. Where hosts show interactive cards, don't relist what they show; add judgement. For a lookup the person didn't ask to see, pass show_card: false.

Signed in (the person's own account): get_profile_summary, match_jobs, list_updates and list_applications read their preferences, matches, watched searches, saved jobs and applications. save_job, save_search, update_application, update_preferences and update_alerts change them, only when the person asks. get_connections lists people they know at an employer: suggest who to ask and a message they send themselves; never offer to contact anyone. Follow-ups in list_updates come with a drafted note for them to edit and send; never send it.
- prepare_application drafts a cover letter and answers from their profile; share the drafts, take their edits back through it, and send them to review_url.
- get_profile and save_resume work only if they shared their profile with this assistant. Before save_resume, check_resume shows every change and flags claims their profile doesn't support: ask about each flag, never fill a gap in.
- At the interview stage, offer prepare_interview: the employer's interview rules first, questions from the role and their own stories (never invented), a mock one question at a time. Only before the interview, never during it.
- review_application lays out the complete application as it would be sent. submit_application sends that reviewed version only after the person says "yes, submit": one posting at a time, never on your own judgement. Otherwise offer the employer's apply link and our Chrome extension; with a fill plan, a browser-capable assistant may fill the form and press submit only after "yes, submit". The person answers legal, consent, self-identification and work-authorisation questions. Only review_application returns contact details; demographic and work-authorisation answers are never returned.