How to Prepare for a Data Journalism Interview (October 2026)

Learning how to prepare for a data journalism interview comes down to three things you can build this week: a portfolio you can defend line by line, working fluency in the reporting toolkit, and rehearsed answers to the questions editors actually ask.

Most newsrooms run the same three stages — an introductory call about fit and motivation, a portfolio or technical conversation, and often a take-home reporting test — so prepare for each one separately. Budget six to ten hours of prep spread across a week, then add an hour the night before to test your setup. Updated for 2026.

What You Need to Prepare for a Data Journalism Interview

You need three things: finished work you can walk through, written notes showing how you made the work, and enough knowledge of the outlet to talk about its audience in specifics. Everything else is a bonus.

The essentials apply to every candidate, whatever the role. Two or three finished projects, each with a documented story behind it. A written note for each one covering where the data came from, what you changed, and what you could not answer. A short list of the outlet’s recent data projects. And a one-page CV that leads with stories rather than software.

Beyond that, the useful extras depend on which seat you are applying for. This is what each material proves and who actually needs it:

• Two or three finished projects. Proves you can take a question from raw data to a published answer. Every candidate needs this.
• A methodology note per project. Proves you document sources and decisions, which is exactly what an editor signs off on. Every candidate needs this.
• Published links or a public repository. Proves other people have read the work, not just you. Every candidate needs this.
• A reproducible notebook or script. Proves your analysis can be re-run and checked by someone else. Reporting and analysis roles need this.
• A built piece: tracker, map, graphic or app. Proves you can finish a thing that ships, not just an analysis. Visual and interactive roles need this.
• A cleaned dataset with a source file. Proves you handle messy real-world data and version control. Developer and data roles need this.

Even unpublished work counts, but only if you present it honestly. An analyst forum thread on r/Journalism notes that people already use business tooling such as Power BI in their reporting, and that employers tend to accept it as evidence of skill rather than treating it as a knock on the door. Label it as a practice project and explain what you would publish if you had it.

Sketch specialists who have never reported should add two more items: a short written piece on something you actually found, and a story idea you would pitch. Editors hire for curiosity about the world as much as for the toolkit.

Step-by-Step Preparation Plan

1. Research the Role and the Organization

Read the job description twice and mark every noun in it. Data cleaning, GIS, graphics, FOIA, audience growth — each noun is a topic you will get asked about, and the list is your revision plan for the week.

Then read the outlet’s own work. Go back six months and read the data stories, the corrections page and any methodology notes they publish. Note what they reward: explanatory pieces, accountability investigations, live trackers, visual explainers. Check the team page so you know who you would work with and what they came from.

Turn that research into three sentences you can say out loud: what this newsroom covers, what its data work looks like, and one question you would want to answer there. You will know the research worked when your answers mention specific projects rather than general admiration for journalism.

2. Choose Two or Three Projects That Prove Your Range

Pick a small set, not a full archive. A strong set is one finished data story, one analysis or notebook, and one thing you built — a tracker, a map, a scraper, a chart that runs as a page.

Between them they should show reporting, cleaning, analysis, visualisation and collaboration. Aim for at least one project with a team, because newsroom work is rarely solo, and one where something went wrong and you changed course, because that is where the judgement conversation lives.

Leave the rest behind. An interviewer who asks to see everything sees nothing in depth, and a portfolio padded with half-finished class projects reads as a portfolio without a clear point.

3. Build a Clear Portfolio Narrative for the Room

Every project needs a seven-part story you can deliver in about ninety seconds: the question, your role, the data and how you got it, what you had to fix, the finding, the editorial calls, and what happened after publication.

Here is the difference the same project makes in two versions.

Weak: “I used pandas to merge the datasets and then ran a logistic regression to model the outcome, and I visualised the coefficients in a coefficient plot, which really brought the story to life.”

Strong: “Three agencies published arrest data with different column names and different definitions of a charge. I mapped each to a common schema, dropped about four percent of rows that had no agency attached, and flagged that in the methodology note. The merged set showed enforcement was concentrated in six precincts, which was not what anyone expected, and it became the spine of the story.”

The second version names the problem, the mess, the decision and the consequence. Practise it until you can say it without notes and without jargon.

4. Revisit the Data and Decisions Behind Your Work

Open your old files and go back to the source before the interview, not during it. For every number in your portfolio, know which file it came from, which line, and which document or dataset supports it.

Interviewers ask about the unglamorous parts on purpose. Expect questions on how you handled missing values, what happened when a definition changed mid-series, whether a small sample justifies the claim, why you chose a line chart over bars, and how you checked the chart for colour-blind readers and screen readers. Saying “I do not know, and here is how I would find out” scores better than a confident guess.

Run a simple self-audit: for each published claim, write the source, the date you pulled it and the transformation that produced it. Anything you cannot complete on paper is a weak spot, and better to find it three days before than in the meeting.

5. Practice Explaining Technical Work to Non-Technical Audiences

Editors are not testing your syntax. They are checking whether a reader who does not write code will understand the finding and trust it.

Do three things when you explain a project. Name the human problem before the method. Quantify the effect in units the audience already uses — dollars, days, people, miles. Close by saying what the reader should take away, in one sentence.

A live screen-share can help or hurt. It helps when the project is small and you can narrate it end to end in three minutes. It hurts when you start scrolling a notebook, hunting for the cell you meant to open. Either way, rehearse the route: open the file in advance, hide the noise, enlarge the font, and know your own output numbers cold in case the connection fails.

6. Rehearse Likely Interview Questions

Interviewers ask about storytelling, collaboration, ethics, accuracy, design judgement, deadlines and what you do with incomplete information. Rehearse the technical and the behavioural side separately.

On the technical side, be ready to talk through pivot tables and spreadsheet cleaning, how you would structure a SQL query against a public database, when Python or R beats a spreadsheet, how you document a scrape responsibly, and how you verify a number with the agency that published it. You are not being examined on syntax. You are being examined on whether you know which tool fits and why.

On the behavioural side, use a fixed structure: situation, task, action, result. Every answer should name the constraint you were under, the choice you made, and what the choice cost. Cut anything about tools you used but did not decide with.

Record two or three answers on your phone and play them back. Count how many times you say “basically” or “kind of”, and cut every filler phrase. Interviewers are generous with silence and impatient with padding.

7. Prepare Questions for the Interviewer

Ask about the work, not the perks. Questions that signal real curiosity: how a data story moves from idea to publication, who signs off on accuracy before it runs, whether you write your own methodology notes, what the biggest failed project of the last year taught the team, how the group is structured between reporters, developers and designers, and how the newsroom decides whether a data project succeeded.

One question about contract type and salary range is normal and not rude, particularly for freelance or contract work. Ask where it falls in the process, and let them go first if they prefer.

These questions work for you too. If the answer to “who signs off on accuracy” is a shrug, that tells you something real about how the desk works, and you learned it in the interview rather than after you accepted.

Common Mistakes That Sink Data Journalism Candidates

Most candidates lose rounds on small habits rather than missing skills. Each mistake below has a direct fix you can apply the same day.

Showing unfinished work. A half-built tracker with a promising readme still reads as unfinished. Present what shipped, and describe the abandoned version as a lesson in scope instead.

Claiming every part of a project. If four people built it, say so and name your slice. Editors have seen the repo. Overclaiming costs you the whole conversation.

Hiding uncertainty. Sweeping claims without caveats invite the question you least want. Name the limits yourself, early, and it stops sounding like a weakness.

Overexplaining tools. Five minutes on your stack and none on your finding is a bad trade. Cap tool talk at a sentence and spend the time on the story.

Bashing former colleagues. The interview panel will be your colleagues. Talk about constraints and what you learned, not about people.

Ignoring accessibility. Ask how you colour a chart and whether it works in grayscale. It is a real newsroom problem and a real skill.

Never connecting the data to readers. If you cannot say why the finding matters to someone outside the newsroom, you have not finished the analysis yet.

Spending a week on the take-home test. Forum consensus treats the reporting test as the main gate, and candidates rightly worry about unpaid hours. Ask for a time box, ask whether a small cleaned dataset with one chart and two paragraphs is enough, and if the scope is open-ended, propose a scope in writing before you start.

Quick Preparation Tips

The day before, test the link and the sharing permissions on your portfolio, and open every project on the device you plan to use. Interviewers have clicked dead links. Have a PDF or printed copy as backup so the meeting does not die with the wifi.

The morning of, print your one-page story notes and your questions. Rehearse your opening ninety seconds out loud once, standing up. Silence your notifications and check the time zone if the call is cross-border. On nerves, most editors tell candidates the same thing: a little nerves means you care, and nobody expects a performance.

Frequently Asked Questions

Start With the Portfolio, Not the Toolkit

If you do one thing this week, pick your strongest project, write its seven-part narrative, and say it out loud three times until it takes ninety seconds. Everything else in this guide hangs off that answer, because it is the one thing every version of the interview will come back to.

Then work backwards from there: find the gaps in the story, close them before the meeting, and go in knowing exactly what you built and why it mattered.