Learning Path Open Access

How to Kickstart a Research Journey

Roadmap for starting a research career from reading papers to publishing your first paper

Abstract

Almost everyone who wants to start doing research faces the same paralysing question: where do I actually begin? Online advice is often either too abstract ("read widely, think deeply") or assumes you are already enrolled in a PhD program with a built-in advisor and lab. This roadmap is written for the researcher starting from zero - a student, an engineer, or a curious practitioner with no formal supervision yet. It is honest about the timeline: six to eighteen months of consistent effort to reach a first genuine publication. It is structured, moving through seven phases from learning to read a paper properly through to submitting your first manuscript and building a sustainable research practice. And it is actionable, with concrete exercises, tools, and checkpoints at every stage.

Why This Roadmap?

Almost everyone who wants to start doing research faces the same paralysing question: where do I actually begin? Online advice is often either too abstract - "read widely, think deeply" - or assumes you are already enrolled in a PhD program with a built-in advisor, lab, and compute budget. This roadmap is written for the researcher starting from zero: a student, a working engineer, or a curious practitioner with no formal supervision yet.

This roadmap is honest about the timeline - six to eighteen months of consistent effort to reach a first genuine publication, not a weekend project. It is structured, moving through seven phases from learning to read a paper properly through to submitting your first manuscript. And it is actionable, with concrete exercises, tools, and checkpoints you can act on this week.

Who is this for? Undergraduates and master's students considering a PhD. Working engineers and data scientists who want to contribute an original idea, not just apply existing tools. Anyone who has finished the technical foundations (see our Machine Learning Roadmap if you have not) and now wants to turn that knowledge into a genuine contribution.

Phase 0: Mindset & Prerequisites (1–2 weeks)

Before anything else, recalibrate what research actually feels like day to day, so the inevitable friction ahead does not read as a sign you are doing it wrong.

What Research Actually Is

Research is not "learning a lot and then knowing things." It is the deliberate pursuit of a question to which nobody currently has a reliable answer. Most of the work is not eureka moments - it is reading carefully, running experiments that fail, and slowly narrowing a vague curiosity into a question sharp enough to be answered. Richard Hamming's classic talk "You and Your Research" is the single best short introduction to this mindset and is worth reading in full before going further.

Technical Prerequisites

You do not need to be a world expert before starting, but you do need enough fluency in your chosen area to read its papers without stopping every sentence. If you are targeting ML or AI research and have not yet built that foundation, work through our Machine Learning Roadmap or Data Science Roadmap first - trying to do original research before you can implement standard methods from scratch usually produces frustration, not progress.

Set Expectations Honestly

Most experiments will not work as hypothesised. Most first paper submissions are rejected or need major revision. Progress on a hard question is often invisible for months before a result clicks. None of this means you are unsuited to research - it is closer to the median experience than the exception.

Checkpoint: You should be able to: (1) Describe, in your own words, what separates research from advanced coursework. (2) Confirm you can implement standard methods in your area from scratch, not just call a library function. (3) Accept, genuinely, that early failure is normal rather than diagnostic of unsuitability.

Phase 1: Learning to Read Papers Properly (3–5 weeks)

Most people never learn to read a research paper efficiently, which makes every later phase slower than it needs to be. This phase fixes that first.

The Three-Pass Method

S. Keshav's "How to Read a Paper" describes the standard approach used by working researchers: a first pass reading only the title, abstract, and conclusion to decide if the paper is relevant; a second pass reading the whole paper while skipping proofs and detailed derivations, to understand the approach and evidence; and a third pass, done only for papers central to your own work, where you virtually re-implement the paper - redrawing every figure, rederiving every equation, and identifying implicit assumptions.

Note-Taking Discipline

For every paper you read past the first pass, write a short note in your own words covering: the problem, the key idea, the main result, one weakness you noticed, and one question it raises for you. Do not copy the abstract - the act of rephrasing is what builds understanding, and a library of your own summaries becomes invaluable once you start writing your own related-work section.

  • Zotero - Free reference manager with browser-based paper capture and citation export
  • Connected Papers - Visual map of related work around any paper you enter
  • Semantic Scholar - Citation graphs, TL;DR summaries, and influential-citation flags

Reading Volume & Pace

Aim for 2–3 papers per week at first-pass depth, and one paper per week at full third-pass depth. This feels slow compared to skimming blog summaries, but shallow reading produces a shallow understanding of the field that shows up immediately once you try to identify a genuine gap.

Checkpoint: You should be able to: (1) Summarise a paper's contribution in two sentences without re-reading the abstract. (2) Identify a paper's stated limitations and at least one unstated one. (3) Explain how two related papers in your area differ in method or assumptions.

Phase 2: Finding a Research Question (4–8 weeks)

This is usually the hardest and most anxiety-inducing phase, precisely because there is no fixed procedure - but there are reliable strategies for narrowing a vague interest into a workable question.

Where Questions Actually Come From

  • Gaps in related work sections: Papers routinely state their own limitations near the end - these are often ready-made starting points other researchers have not yet picked up
  • Reproduction attempts: Trying to reproduce a paper's result frequently surfaces an assumption that does not hold as generally as claimed, or a result that is more fragile than reported
  • Cross-pollination: A method well-established in one sub-field, applied to a different problem or domain, is one of the most common sources of a genuine contribution
  • A surprising result you cannot explain: If an experiment behaves unexpectedly and existing literature does not explain why, that confusion is often a real question in disguise

Scoping a Question You Can Actually Answer

Write your candidate question down in one sentence, then ask: what single experiment, run in a reasonable timeframe with the compute and data you actually have access to, would move you closer to an answer? If you cannot picture that experiment, the question is still too broad. Narrow it until you can.

Critical: Before committing serious time, search deliberately for prior work on your exact question across arXiv, Papers With Code, and recent conference proceedings directly (not only a general search engine). Finding your idea already published is not wasted effort - it tells you the question was a good one, and a novel angle or a rigor gap in that paper may still be your contribution.

Choosing Theory vs. Empirical Work

If your background and interest lean mathematical, a theoretical question - proving a bound, characterising a failure mode formally - may suit you better. If you enjoy building and iterating quickly, an empirical question with a clear experimental protocol is usually a more natural entry point. Most first-time researchers from an engineering background find empirical work easier to scope and iterate on.

Checkpoint: You should be able to: (1) State your research question in one sentence. (2) Describe the single experiment that would move you closer to an answer. (3) State, in advance, what result would make you conclude your hypothesis is wrong.

Phase 3: Literature Review (2–4 weeks)

Once you have a candidate question, build a thorough, organised map of what is already known before running a single experiment.

Systematic Search

Search with several different phrasings of your question, not just the first one that comes to mind. Follow the citation graph both forward (who cites this paper) and backward (what this paper cites) using Semantic Scholar or Connected Papers. Check the last two to three years of proceedings from the top venues in your area directly (NeurIPS, ICML, ICLR, ACL, CVPR, or their domain equivalent), since very recent work is not always well-indexed by search engines yet.

Organising What You Find

Group papers into clusters by approach, not by publication date - this is what will eventually become your paper's related-work section. For each cluster, note: what problem it addresses, what method it uses, and what it does not address that your question does. This organisation is what separates a research contribution from a re-invention of an existing idea.

Writing a Mini Literature Review

Before running experiments, write a one- to two-page summary of the state of the art as you understand it, ending with a clearly stated gap. Share this with anyone willing to read it - a mentor, a peer, even a knowledgeable friend - since an outside read at this stage is far cheaper than discovering a scoping problem after months of experiments.

Checkpoint: You should be able to: (1) Name the three to five papers most directly relevant to your question. (2) Explain clearly what gap your question addresses that they do not. (3) Defend, out loud to a skeptical peer, why your question is not already answered.

Phase 4: Running Rigorous Experiments (6–16 weeks)

This phase is usually the longest and the one where good habits compound the most. Rigour here is what makes your eventual result trustworthy and reproducible - including by future you.

Designing the Experiment

Define your evaluation metric and success criterion before running anything, not after seeing early results - deciding what counts as success only after the fact is one of the most common and damaging mistakes in early research. Identify appropriate baselines: a result without a meaningful comparison point is not evidence of anything. If your work involves a controlled comparison of any kind, the same rigor that governs a well-run A/B test applies - Trustworthy Online Controlled Experiments is a useful reference even outside a product setting.

Engineering Discipline

  • Version-control every experiment with Git, including configuration files, from the very first run
  • Use an experiment tracker (Weights & Biases or MLflow) so every run's exact configuration and result are recoverable later
  • Set and fix random seeds, and run multiple seeds where feasible - a result that only appears with one lucky seed is not a result
  • Follow Andrej Karpathy's "Recipe for Training Neural Networks" if your work involves training models - a disciplined, incremental approach to debugging that saves weeks of confusion

When Experiments Fail (They Will)

Distinguish between an implementation bug and a genuine negative result - this is a skill in itself, built by careful sanity checks (can your pipeline overfit a tiny toy dataset? does a known baseline reproduce its published number?) before trusting a surprising outcome. A well-understood negative result, documented clearly, is real progress and often becomes a paragraph in your eventual paper's discussion section, not a wasted month.

Reproducibility From the Start

Treat the NeurIPS Reproducibility Checklist as a working document from day one of experiments, not a form to fill in before submission - it is far cheaper to log a hyperparameter or fix a seed now than to try to reconstruct it under submission deadline pressure later.

Checkpoint: You should be able to: (1) Reproduce your own result from a fresh checkout of your code. (2) Explain why your baseline comparison is fair. (3) Distinguish a genuine finding from noise across multiple random seeds.

Phase 5: Scientific Writing (4–6 weeks)

A brilliant result poorly communicated is far less useful than a modest result written clearly. This phase treats writing as a skill to build deliberately, not an afterthought once experiments end.

Structure of a Research Paper

Abstract (write it last, even though it appears first), introduction (motivate the problem before stating your contribution), related work (organised by approach, drawing on Phase 3), method, experiments, results, discussion (including limitations, stated honestly), and conclusion. The Craft of Research remains one of the best general guides to this structure and the reasoning behind it, well beyond any one field.

Common First-Draft Mistakes

  • Burying the contribution in the middle of the introduction instead of stating it clearly and early
  • Writing the related work section as a list of summaries rather than an argument for why your gap is real
  • Omitting limitations, which reviewers read as a lack of self-awareness rather than a stronger paper
  • Overclaiming - "solves" instead of "improves," "proves" instead of "provides evidence for"

Tools

  • Overleaf - Collaborative LaTeX editor; most venues provide a template you can start from directly
  • A dedicated conference template (NeurIPS, ICML, and ACL all publish official LaTeX style files) - use it from your very first draft, not only at submission time, since formatting constraints shape how you should structure content

Getting Feedback Before Submitting

Share drafts early and often with anyone willing to read critically, not only close collaborators - a reader unfamiliar with your specific sub-area often catches unclear motivation faster than someone deep in the same work. Expect multiple full rewrites; a first draft rarely resembles the version that gets submitted.

Checkpoint: You should be able to: (1) State your paper's contribution in one clear sentence a non-expert in your exact sub-area could follow. (2) Identify and honestly state your work's limitations. (3) Have had at least one outside reader give substantive feedback on a full draft.

Phase 6: Submission & Peer Review (2–4 weeks per cycle)

Submitting is a skill in its own right, and understanding how peer review actually works removes a great deal of unnecessary anxiety from the process.

Choosing a Venue

For a first paper, workshops attached to major conferences (NeurIPS, ICML, ICLR workshops, or the equivalent in your sub-field) are usually the most realistic target: the bar is lower than the main track, turnaround is faster, and you still receive substantive reviewer feedback and a citable record. Posting a preprint on arXiv alongside a venue submission establishes priority and visibility, but is a complement to peer review, not a substitute for it.

What Reviewers Are Actually Looking For

Clarity of the stated contribution, a fair comparison against real baselines, honest treatment of limitations, and enough detail to reproduce the core result. Reviewers are not looking for a flawless paper with no weaknesses - they are looking for a paper that is honest about the weaknesses it does have.

Handling Rejection and Revision

Rejection at this stage is closer to the norm than the exception, even for researchers with long track records - read reviews after giving yourself a day or two of distance, then extract the specific, actionable points buried in even harshly worded feedback. A rebuttal or revision that directly addresses reviewers' stated concerns, point by point, is far more effective than a general defence of the paper's overall value.

Checkpoint: You should be able to: (1) Identify an appropriate first venue for your specific result. (2) Read a critical review and extract the actionable concern underneath the tone. (3) Revise a draft in direct response to specific reviewer feedback.

Phase 7: Building a Research Career (Ongoing)

A first publication is a beginning, not an end point. This phase covers what turns one paper into a sustainable research practice.

Finding and Working With Mentors

Reach out to researchers whose work is closely adjacent to yours with a specific, well-reasoned question rather than a general request for mentorship - PhD students and postdocs are often more responsive and closer to hands-on work than senior professors with limited bandwidth. Once a working relationship exists, come to every conversation with a clear, specific question or update rather than an open-ended "what should I do next?"

Community & Visibility

  • Attend conference workshops virtually if in-person attendance is not feasible - workshop discussions are often where the field's next ideas are being tested
  • Present your work wherever a venue exists - a lab meeting, a local reading group, a poster session - practising the explanation out loud sharpens the written version too
  • Follow 10–15 active researchers in your sub-area on X (Twitter) or Bluesky - a genuinely effective way to track what the field is currently discussing
  • Contribute to open-source research code - reproducing and extending others' released implementations builds both skill and visible track record

Deciding Whether to Pursue a PhD

A completed first publication is one of the strongest signals in a PhD application, stronger than a long list of finished online courses. If you are uncertain whether a PhD is right for you, applying while continuing independent research in parallel is often clarifying in itself - the application process forces you to articulate a research agenda you may not have written down otherwise.

Next steps: Keep a running list of research questions you encounter but are not ready to pursue yet - today's tangent is often next year's project. If you are also building toward an applied ML career alongside research, our ML Interview Guide covers the technical interview process for research-adjacent roles.

Timeline & Realistic Pace

PeriodPhaseWeekly HoursFocus
Weeks 1–2Phase 0: Mindset & Prerequisites8–10 hrs/weekRecalibrate expectations. Confirm technical foundations are solid.
Weeks 2–7Phase 1: Learning to Read Papers10–12 hrs/weekThree-pass method, note-taking discipline, build reading volume.
Weeks 7–15Phase 2: Finding a Research Question12–15 hrs/weekExplore gaps, attempt reproductions, narrow to one scoped question.
Weeks 15–19Phase 3: Literature Review12–15 hrs/weekSystematic search, organise by approach, write a mini review.
Weeks 19–35Phase 4: Running Experiments15–20 hrs/weekDesign, run, debug, and document experiments with discipline.
Weeks 35–41Phase 5: Scientific Writing12–15 hrs/weekDraft, get feedback, and rewrite the manuscript multiple times.
Weeks 41–45+Phase 6: Submission & Review5–10 hrs/weekSubmit, respond to reviews, revise. May repeat across cycles.
OngoingPhase 7: Research CareerVariableMentorship, community, deciding on next questions or a PhD.

Total commitment: ~6–12 months to a first workshop-quality result at 10–20 hours/week, extending to 12–18 months for a full conference paper. This timeline compresses significantly with a responsive mentor and full-time focus, and extends for a genuinely novel, ambitious question. Treat every estimate here as a plan to revise, not a deadline to enforce rigidly against your specific question.

Learning Tips

  • ✓ Start before you feel ready - the feeling of being ready rarely arrives on schedule
  • ✓ Write a note in your own words for every paper you read past a first pass
  • ✓ Decide your success criterion before running the experiment, never after
  • ✓ Track negative results as carefully as positive ones - future you will need them
  • ✓ Share drafts early with anyone willing to read critically, not only close collaborators
  • ✓ Reach out to PhD students and postdocs, not only senior professors, for feedback
  • ✓ Treat rejection as the norm, not the exception, and extract the actionable feedback inside it

Frequently Asked Questions

  • No. A surprising amount of meaningful research - reproducing a paper, extending an idea, contributing to an open-source research project, running a well-designed empirical study - can be started independently, as an undergraduate, or while working full-time. What a PhD program provides is structured supervision, funded compute and time, and a built-in community of collaborators, all of which make research faster and less lonely, not possible in the first place. Many strong publications begin as independent projects that later attract an advisor's attention or get folded into a lab's agenda. Start before you have permission; ask for supervision once you have something worth discussing.
  • Start narrow and specific rather than broad and vague. Read three to five papers in a sub-area that genuinely interests you, form an opinion about a gap or a question the authors did not address, and email the corresponding author with that specific observation rather than a generic "I am interested in your work" message. Professors and researchers respond far more often to a concrete, well-reasoned question than to a request for mentorship in the abstract. Reaching out to PhD students and postdocs, not only senior professors, is often more productive - they have more time, are closer to hands-on work, and are frequently looking for collaborators on a specific sub-problem.
  • There is no fixed number, but a reasonable milestone is being able to explain, without notes, the three to five most influential papers in your chosen sub-area, plus five to ten more recent papers that build on them - enough to describe the current state of the art and identify where the open questions are. This typically takes four to eight weeks of focused reading. Do not wait until you feel you have "read enough"; that feeling rarely arrives. Start drafting a research question once you can articulate what is currently unknown or unresolved, even if your reading list feels incomplete.
  • A good research question is specific enough to be answered with an experiment you can actually run, and its answer is not obviously predictable in advance - if you already know what the result will be, it is not research, it is confirmation. A bad research question is usually one of three things: too broad to design a single experiment around ("how can AI help healthcare?"), already answered clearly in the literature you have not fully read, or unfalsifiable in a way that no experiment could challenge it. A useful test: write down, before running anything, what result would make you conclude your hypothesis is wrong. If you cannot state that, the question needs sharpening.
  • Search deliberately before falling in love with an idea: query arXiv and Papers With Code with several different phrasings of your question, check the "related work" and citation graph of the two or three closest papers you find (using Semantic Scholar's citation graph), and search recent conference proceedings (NeurIPS, ICML, ICLR) directly rather than relying on search engines alone, since very recent work is not always well-indexed yet. If you find the exact idea already published, that is not necessarily a dead end - a novel angle, a different dataset, or a rigor gap in the original paper can still be a contribution. If your idea is genuinely close to unpublished ongoing work, an honest, apologetic email to the authors is the right move, not silent abandonment.
  • Choose based on your mathematical background and what kind of questions excite you, not on which path seems more prestigious. Theoretical research demands comfort with proof-based reasoning and can be pursued with less compute, but progress is often slower and harder to course-correct once you are deep into a proof attempt. Empirical research demands engineering discipline and access to compute, but offers faster feedback loops and more visible, incremental progress. Most practitioners entering research from an engineering background find empirical work a more natural entry point, with theory added later once a specific empirical puzzle motivates it.
  • Expect a high failure rate as the default, not the exception: most experiments do not work as hypothesised, and most first-submitted papers are rejected somewhere before being accepted. Track a negative result as carefully as a positive one - a well-understood failure is genuine progress, and future-you will thank present-you for the documentation. Imposter syndrome is close to universal among early-career researchers, including those who go on to have distinguished careers; it is not reliable evidence about your actual ability. Build a peer group of other early-stage researchers going through the same thing - isolation makes every setback feel more significant than it is.
  • Zotero or Paperpile for reference management and citation formatting. A structured note-taking system (Notion, Obsidian, or even a disciplined folder of markdown files) with one note per paper, written in your own words, not copied abstracts. Weights & Biases or MLflow for experiment tracking once you are running empirical work - a surprising number of promising results are lost simply because no one recorded which exact configuration produced them. Git for every piece of code, from day one, even for a "quick" exploratory script.
  • Workshops attached to major conferences (NeurIPS, ICML, ICLR workshops) are the most realistic and valuable first venue: the bar is lower than the main conference track, the turnaround is faster, and you still get real reviewer feedback and a citable record. arXiv preprints alone establish priority and get real readership but carry less credibility without peer review, so treat a preprint as a complement to a venue submission, not a substitute. Avoid predatory or pay-to-publish venues entirely - a checkable rule of thumb is that any venue asking for a substantial publication fee before review, with reviewers who leave no substantive comments, is not worth your first paper.
  • For someone starting from solid technical fundamentals but no prior research experience, six to twelve months of consistent, serious effort is a realistic range to reach a workshop-paper-quality result, and twelve to eighteen months for a full conference paper - assuming 10–15 hours a week alongside other commitments, faster with full-time focus. The variance is large and depends heavily on how quickly you find a well-scoped question and whether you have a mentor giving feedback along the way; a good mentor can cut this timeline substantially by preventing months of wandering.
  • For PhD applications, the strongest signal is one or two pieces of genuine research output - a workshop paper, a solid preprint, or even a well-documented negative result you can discuss with depth - rather than a long list of completed online courses. Reach out to potential advisors months in advance with a specific, well-reasoned research interest, not a generic interest statement. For research engineer or applied scientist interviews, be ready to walk through a project end-to-end: motivation, related work, method, what failed, what you learned, and what you would do differently. Our ML Interview Guide covers the broader technical interview process that overlaps with research-track roles.

Comprehensive Resource List

Search & Discovery Tools

ResourceUse For
arXiv (cs.LG, cs.AI, cs.CL)Latest research preprints across ML and AI sub-fields
Papers With CodeState-of-the-art results with linked implementations
Semantic ScholarCitation graphs, TL;DR summaries, influential-citation flags
Connected PapersVisual map of related work around any single paper

Reading & Writing Guides

ResourceWhy It Matters
How to Read a Paper - S. Keshav (PDF)The standard three-pass method for reading efficiently
The Craft of Research - Booth, Colomb, WilliamsTimeless, field-agnostic guide to research reasoning and writing
You and Your Research - Richard HammingThe definitive essay on research mindset and choosing important problems
A Recipe for Training Neural Networks - KarpathyDisciplined, incremental approach to debugging empirical ML work

Tools for Managing Research

ToolUse For
ZoteroReference management and citation export
OverleafCollaborative LaTeX writing with conference templates
Weights & BiasesExperiment tracking, model versioning, collaboration
NeurIPS Reproducibility ChecklistEnsuring experiments stay reproducible from day one

Conclusion: Your Research Journey Starts Now

Research is less mysterious than it looks from the outside, and more effortful than most people expect once they are in it. This roadmap provides a structured path from reading your first paper carefully to submitting your own. But no roadmap replaces sitting down and reading the next paper today.

Start today. Pick one sub-area, read three papers this week using the three-pass method, and write a note on each in your own words. The question you eventually pursue will not arrive from waiting - it will arrive from reading, noticing a gap, and being willing to sit with the discomfort of not yet knowing if it is any good.

The timeline is six to eighteen months to a first publication. This is longer than an ambitious junior researcher usually hopes, and it is also honest - rushing past the reading and literature review phases to reach experiments faster is the most common reason early research stalls.

Finally: hold onto why you wanted to do this in the first place. Research is one of the few activities where genuine curiosity is not just tolerated but is the entire point. Protect that curiosity through the inevitable failed experiments and rejected drafts - it is what will carry you to the next question after this one.

Next Steps

  • Pick one narrow sub-area and commit to reading three papers this week
  • Set up Zotero (or a note-taking system) before your reading pile gets unmanageable
  • Identify one researcher whose recent work interests you and read their three most-cited papers
  • Join a reading group, Discord server, or local meetup for accountability and feedback
  • Write down every "I wonder why..." moment - one of them is probably your research question