During the PhD · Build your proof

Reverse-engineer job postings

The labor market publishes its requirements every day. Read them like data, and let them tell you what to build.

3 min read · By Marc Sleiman

Most students start their job search by applying. I ask them to start by reading. Every day, employers publish exactly what they want in plain language: the skills, the software, the years of experience and the kind of problems you will solve. Very few PhD students read those postings carefully until it is too late to act on them.

The exercise

During Year 2, or as early as you can, collect ten to fifteen job postings that look interesting to you. Do not apply to any of them. You are not ready yet, and that is the point. You are collecting data.

Save each posting in full, because postings disappear once the role is filled. Then build a simple spreadsheet with one row per posting and these columns: the employer, the title, the sector, the skills listed as required, the skills listed as preferred, the software named, the years of experience requested, and the kind of problem the role works on. It takes an evening.

What to look for

Once you have fifteen rows, patterns appear quickly. Ask four questions of the spreadsheet.

Which skills recur?

If eleven of fifteen postings mention SQL and three mention Stata, that tells you something your coursework will not. Count the mentions. The skills near the top of your count are your learning plan.

What experience do they expect?

Notice how many postings ask for “two or more years of industry experience” even for PhD-level roles. That is not a reason to give up on them. It is a reason to build applied experience during the program so you can show the equivalent. The experience page explains how.

What software keeps appearing?

Python, R, SQL, Git, Tableau or Power BI, cloud platforms, and sometimes specific tools for experimentation. Separate the ones that appear in almost every posting from the ones that appear once. Learn the first group properly. Ignore the second until you target that specific employer.

What would you have to show?

This is the most important question. For each skill, ask what evidence would convince a stranger that you have it. “Familiar with Python” on a resume is not evidence. A cleaned dataset, a documented analysis and a dashboard on GitHub are. Write down the evidence you would need, and that becomes your list of things to build.

Reading between the lines

Postings are written by busy people, often by copying older postings, so read them with some skepticism. A long list of “required” skills is often a wish list; if you meet most of the core ones, you are a candidate. Look for the verbs. A role that says “design and analyze experiments” and “partner with product managers” is a product data science role regardless of its title. A role that says “estimate damages” and “support expert testimony” is consulting. A role that says “build and maintain forecasting models in production” wants more engineering than most economists have.

Also look at who wrote it. Search the company and the team on LinkedIn, find people with that title, and look at their backgrounds. If most of them have economics PhDs, the team values your training. If none of them do, you will need to work harder to explain why your training fits.

Repeat it every year

Do the exercise again in Year 3 and Year 4 with fresh postings. The market changes, your interests narrow, and you will start to see which skills you now have and which are still missing. By Year 5 the spreadsheet becomes your target list, and the employers in it become the people you reach out to before the postings even appear.