Lecturer or PhD to data scientist: what research training covers

Mistake 1: submitting the thesis as the portfolio

The thesis is the evidence you are most proud of, and it is the hardest one for a hiring manager to assess. It is long, domain-specific and written for examiners. A reviewer with twenty minutes will not find the part that proves you can build a model.

Fix: keep the thesis as one line on the CV and build a separate project of two to four pages that uses the same kind of reasoning on a problem with a decision attached. If your research was on crop yields, build a model that decides which plots to inspect first. If it was on student outcomes, predict which students need an early intervention. The domain can stay; the output must become a decision.

Mistake 2: reporting a fit statistic instead of a held-out result

Research papers often report how well a model explains the data it was fitted on, with a significance test. Data science roles care about how the model performs on data it has not seen. The two can disagree sharply, and the easiest way to show you understand this is to demonstrate the gap yourself.

Here is a minimal demonstration on synthetic data. A threshold rule is tuned on training records, then checked on held-out records. Only the standard library is used.

import random

random.seed(7)

def make_record():
    # Synthetic: a noisy score where positives tend to score higher
    label = 1 if random.random() < 0.3 else 0
    score = random.gauss(62 if label else 50, 10)
    return score, label

data = [make_record() for _ in range(400)]
train, test = data[:300], data[300:]

def accuracy(rows, cut):
    return sum((s >= cut) == bool(y) for s, y in rows) / len(rows)

# Tune the cut-off on training data only
cuts = [c / 2 for c in range(80, 150)]
best_cut = max(cuts, key=lambda c: accuracy(train, c))

print("best cut-off:", best_cut)
print("train accuracy:", round(accuracy(train, best_cut), 3))
print("test accuracy: ", round(accuracy(test, best_cut), 3))
print("always-predict-0 on test:", round(accuracy(test, 1e9), 3))

With seed 7 it prints:

best cut-off: 58.5
train accuracy: 0.76
test accuracy:  0.71
always-predict-0 on test: 0.61

Those are three numbers worth writing about: the training accuracy, the held-out accuracy (usually lower, because the cut-off was chosen to fit the training noise), and the baseline of predicting the majority class every time. With imbalanced labels, a model can look impressive and barely beat that baseline. Put all three in your write-up, with one paragraph on what the gap means.

Fix: every model in your portfolio reports a baseline, a held-out score and the metric chosen for a stated reason. The Data Science programme spends real time on validation for this reason; it is where research instincts need the most adjustment.

Mistake 3: code that only runs on your laptop

Research code is often a sequence of scripts run in a remembered order, with paths to a personal folder. A reviewer who clones your repository and gets an error on line three stops reading.

Fix:

• One entry point (python run.py or a notebook that runs top to bottom).
• A requirements.txt with versions.
• A synthetic or public dataset included or downloaded by the script, never a private path.
• A fixed random seed, so your reported numbers reproduce.

Test it by running the project in a fresh folder, the way a reviewer would.

Mistake 4: explaining the method before the problem

Academic writing earns the right to a conclusion by building up the method. A business reader wants the conclusion first. The first paragraph of your project README should say what was decided and why, in two sentences, before any method appears.

Compare:

(Both openings describe a hypothetical project; the figures are illustrative.) The second opening states a decision, a comparison with doing nothing clever, and a promise to show limits. Your research training gives you the honesty about limits; put it in the first screen, not the appendix.

Mistake 5: hiding the uncertainty you would have reported in a paper

The opposite error also happens. Some researchers, told that business readers want simple answers, strip out every caveat. Then an interviewer asks how confident you are and there is nothing in the project to point to.

Fix: report a range where it matters (a bootstrap interval on the held-out metric is enough), name the one assumption most likely to be wrong, and state what data would change your recommendation. That is the research habit that transfers most directly, and it is rarer than it should be.

What to call yourself when you apply

Titles like data scientist at a product company, research data scientist, applied scientist or decision scientist suit an academic background better than ML engineer, which leans on production software. Read the posting for whether the day involves experiments and analysis or mostly deploying and maintaining systems; choose the former first.

If you are still deciding between these directions, the comparison of data science and data analytics is a useful first read, and how to become a data scientist in India covers the wider route.

An answer to "why industry, and why now?"

In research I spent most of my time designing studies and defending methods, and I enjoy that. What I missed was seeing a result change a decision within weeks rather than years. When I built my first portfolio project, the thing that surprised me was how much lower my held-out accuracy was than my training accuracy — my research habit was to report fit, and I hadn't separated tuning from testing. I rebuilt it with a proper split and a majority-class baseline, and now I report both. I'd like a role where the question is "should we act on this?", because that's where I think careful methods matter most.

That answer admits a real mistake and shows the correction, which is more persuasive to an interviewer than a publication count.