How to Write a Computer Science Research Paper

The research problem is the anchor of your entire paper — every subsequent decision about methodology, experiments, and writing flows from your understanding of what problem you are solving and why it matters. A good CS research problem has three properties simultaneously: it is meaningful (solving it advances knowledge or has practical value), open (existing approaches do not adequately address it), and tractable (you can make genuine progress on it with your available resources, skills, and time).

Finding such a problem requires systematic immersion in the current literature. Read recent proceedings from the top venues in your target sub-field: ACM Digital Library indexes the full proceedings of ACM conferences including SIGMOD, PLDI, ASPLOS, CCS, and STOC; IEEE Xplore covers IEEE and ACM co-sponsored conferences including ICSE, INFOCOM, S&P, and the IEEE Transactions journals. Reading the conclusions and future work sections of recently published papers is one of the most productive strategies for identifying research gaps — authors routinely identify problems they could not solve within the scope of their paper.

The specific problem statement should identify the input, the output, and the constraints of your problem with enough precision that another researcher could replicate your experimental setup from the problem description alone. Vague problem statements (“we study the performance of neural networks”) produce unfocused papers; precise ones (“we study the problem of efficient inference for large transformer models under memory-constrained edge deployment scenarios”) produce papers with clear contributions.

The literature review serves two simultaneous purposes: it informs your research (you must know what has been done to know what has not been done) and it becomes the Related Work section of your paper (demonstrating to reviewers that you are aware of the relevant prior art and can precisely articulate how your work differs). Failing to cite relevant prior work is one of the most common and most damaging mistakes in CS papers — reviewers who discover an uncited closely related paper often reject the submission outright.

Begin with a broad search using Google Scholar and the ACM/IEEE digital libraries, using keyword combinations from your problem domain. Identify the 5-10 most relevant and most-cited papers in your area. Read these carefully, then follow both backward (papers they cite) and forward (papers that cite them, via Google Scholar’s “Cited by” feature) citation chains. For ML and AI topics, arXiv is essential — most work is posted there before or simultaneously with conference submission, and arXiv preprints often contain the most recent developments in fast-moving areas.

As you read, take structured notes for each paper: the problem addressed, the approach taken, the datasets and metrics used, the key results, and the limitations explicitly or implicitly acknowledged. Organise papers into thematic clusters — by approach type, by problem variant, by performance trade-off — rather than chronologically. This thematic organisation will directly map to the structure of your Related Work section.

The contribution statement is the most important piece of writing in your paper. It appears in the Introduction — typically as a bulleted or numbered list of 3-5 specific claims — and every subsequent section of the paper exists to establish and support those claims. Reviewers use the contribution statement as the primary lens through which they evaluate whether your paper deserves acceptance.

Contributions should be specific, verifiable, and clearly distinguished from existing work. They may include: a new algorithm or system with specific properties (improved time complexity, better empirical performance, lower memory footprint); a new theoretical result (a lower bound, an approximation guarantee, a formal proof of correctness); a new empirical finding (a systematic evaluation that produces surprising or informative results); a new dataset or benchmark that enables future research; or a new framework or taxonomy that organises existing knowledge in a valuable way. Any combination of these is possible, but each claimed contribution must be individually supported by evidence in the paper.

The methodology section — variously titled “Method,” “System Design,” “Approach,” “Architecture,” or “Framework” depending on the paper type — describes what you did and why. It is the technical core of the paper, and its quality is evaluated on two dimensions: precision (can another researcher reproduce your approach from this description?) and justification (does the paper explain why each design decision was made — why this approach rather than an obvious alternative?).

Every design decision should be motivated. If you use a specific activation function, a particular regularisation strategy, a specific scheduling policy, or a novel data representation — explain why. Connect each choice to the requirements of the problem you defined in the Introduction. The reader should come away from the methodology section understanding not just what your system does but why those specific mechanisms are appropriate for the problem, and why the alternatives would be inadequate.

Use the right level of mathematical formalism for your sub-field. Algorithms papers require pseudocode and formal complexity statements. Machine learning papers require mathematical definition of the objective function, the model architecture, and the training procedure. Systems papers require system diagrams, component specifications, and interface definitions. Do not under-formalise (leaving implementation ambiguous) or over-formalise (introducing notation that adds no analytical value and obscures rather than clarifies).

The experimental evaluation section is where most CS papers are made or broken. The goal of experiments is to answer specific scientific questions about your proposed approach — primarily: does it work, and how does it compare to the best existing alternatives? Good experimental design requires answering the question “what claims do I need evidence for?” and then designing experiments that produce credible evidence for exactly those claims.

Every experimental section should explicitly state its research questions (RQs) — the specific questions the experiments are designed to answer. For example: “RQ1: Does our approach outperform state-of-the-art methods on standard benchmarks? RQ2: How does performance scale with training data size? RQ3: Which components of our method contribute most to its performance (ablation study)?” Structuring experiments around explicit RQs keeps the evaluation focused and makes it easy for reviewers to verify that you have answered the questions you set out to answer.

Baselines must be strong, fair, and well-implemented. Using weak or outdated baselines is a common reason for rejection — reviewers are experts in the field and know which methods represent the current state of the art. Always cite the papers from which baselines are drawn, use the best hyperparameters reported in those papers (or tune them properly), and run baselines under the same hardware and software conditions as your method.

Ablation studies — experiments that systematically remove or modify individual components of your proposed method to measure each component’s contribution — are expected in most empirical ML and systems papers. Ablations demonstrate that your method’s performance is genuinely attributable to the novel mechanisms you propose rather than to implementation details, hyperparameter tuning, or luck.

Most CS papers follow a recognisable structure, though the exact section names and organisation vary by sub-field, venue, and paper type. Understanding the rhetorical function of each section — not just its content — is what allows you to adapt the standard structure appropriately for your specific paper. The standard sections and their functions are:

Abstract (150–250 words): Self-contained summary of problem, approach, results, and significance. Quantitative where possible. Written last, but placed first.

Introduction (1–2 pages): Motivates the problem, explains why it is hard, introduces your key idea, states the specific contributions as a bulleted list, and provides a roadmap of the paper. The Introduction is the most important section — many reviewers make their accept/reject decision after reading only the abstract and introduction.

Background / Preliminaries (0.5–1 page, if needed): Formal definitions, notation, and established results that the reader needs to understand your contribution. Include only what is needed — do not pad this section with textbook material readers can look up themselves.

Related Work (0.5–1.5 pages): Thematic survey of related papers with explicit statements of how each relates to and differs from your work. Can be placed immediately after the Introduction or just before the Conclusion — different sub-fields have different conventions.

Method / System Design / Algorithm (2–5 pages): The technical core of your contribution. Precise, complete, justified. Use figures, pseudocode, and equations as needed.

Experiments / Evaluation (2–4 pages): Experimental setup, RQs, results, ablations, analysis. Use tables and figures effectively. Answer every RQ explicitly.

Discussion (0.5–1 page, sometimes merged with Results): Interprets the results — what do they mean? What are the limitations of your approach? What surprises did you encounter?

Conclusion (0.5–1 page): Summarises contributions, their significance, limitations, and future work. Never introduce new results here.

References: Use the citation format required by your target venue (ACM, IEEE, or custom). Every claim about existing work must be cited.

CS research writing has a specific register: precise without being verbose, formal without being impenetrable, honest about limitations without being self-defeating. The goal is maximum information per sentence — no word should be present without earning its place. Below are the principles of strong CS technical writing, organised by section type.

Writing the Abstract: Write it last. Use the template: (1) problem sentence, (2) why existing approaches are inadequate, (3) your key idea or mechanism, (4) the specific results (with numbers), (5) the significance or implication. Every sentence should be new information — no sentence should merely echo another. Avoid phrases like “In this paper, we…” as the first sentence; start with the problem or the key finding.

Writing the Introduction: The first paragraph should establish the problem’s importance. The second should explain why it is hard — what makes it a genuine open challenge. The third should introduce your key insight — the “aha” moment of your paper, explained at an intuitive level before any formalism. Then state your contributions as a bulleted list. End with a paper roadmap: “The remainder of this paper is organised as follows…”

Technical prose guidelines: Use the active voice (“we propose,” “our algorithm achieves”) rather than the passive voice (“a method is proposed”) wherever possible. Refer to your method by a consistent name throughout (define it once and use it consistently). Introduce notation before using it. Use present tense for established facts (“Neural networks consist of…”) and past tense for things you did (“We trained the model for 100 epochs”). Define all acronyms at first use.

The presentation of algorithms, pseudocode, and formal proofs is a distinct and important skill in CS paper writing. Unlike narrative prose, formal technical content must be unambiguous — there is no room for elegant paraphrase when specifying an algorithm, because ambiguity in specification translates directly into inability to reproduce results.

Pseudocode: Use the algorithm or algorithmic LaTeX package to format pseudocode consistently. Follow standard conventions: FUNCTION, PROCEDURE, FOR, WHILE, IF-THEN-ELSE, RETURN. Use meaningful variable names. Add line numbers for reference in the text. The pseudocode should be precise enough to implement but abstract enough to be readable — it is not source code, but a formal specification of the algorithm’s logic. Always include the algorithm’s input and output specification, and cite any sub-routines it calls.

Formal proofs: In theoretical papers, proofs must be complete and rigorous — every step must follow from the preceding step by a justified inference. In empirical papers, formal proofs are often provided for correctness claims but not for empirical results. Use the standard theorem-proof environment: define all variables, state the theorem precisely before proving it, and structure the proof as a clear sequence of logical steps. Long proofs can be moved to an appendix with a proof sketch in the main text — provide the key insight in the main body and the complete details as supplementary material.

Mathematical notation: Define all notation at first use. Use consistent notation throughout — if you define a loss function as ℒ, do not refer to it as L or J later. Follow the typographic conventions of your sub-field (e.g., boldface for matrices and vectors in ML papers). Introduce each equation with a sentence that explains what it represents before displaying it, and follow each equation with a sentence that explains what it means or how it is used.

Venue selection should be made before you begin writing, because the target venue determines the expected page length, formatting requirements, citation style, and — crucially — the framing and scope that reviewers from that community expect. Read 5-10 recently accepted papers from your target venue to calibrate your expectations of what that community values and what level of contribution warrants acceptance.

As a general principle: aim for the highest-quality venue where your work has a realistic chance of acceptance. Submitting to venues substantially above your paper’s quality level wastes cycles; submitting below your level means your work will not get the visibility and impact it deserves. Discuss venue choice with your advisor or experienced collaborators before submitting.

CS peer review is double-blind at most top venues — reviewers do not know the authors’ identities, and authors do not initially know the reviewers’ identities. Reviews are typically 3-5 per paper and address: novelty and significance of the contribution, technical correctness, quality of experimental evaluation, clarity of presentation, and adequacy of related work coverage. Acceptance rates at top venues range from 15–30% for conferences and lower for the most selective journals.

When reviews arrive: Read all reviews carefully before responding to any. Give yourself 24 hours before writing your rebuttal — initial reactions to harsh reviews are rarely productive. The rebuttal is an opportunity to correct factual errors in the reviews, address specific technical concerns with additional experiments or explanations, and clarify aspects of the paper that were misunderstood. It is not an opportunity to argue that the reviewers are wrong to have the concerns they raised.

Responding to reviews: Address every concern raised by every reviewer, numbered to match the original review structure. For experimental concerns (“the baseline comparison is unfair”), provide the additional experiments. For clarity concerns (“Figure 3 is unclear”), describe precisely how you will revise the figure. For fundamental novelty concerns, acknowledge the concern and argue carefully but modestly for why your contribution is meaningful — do not be defensive. A well-written rebuttal that takes reviewer concerns seriously, provides clear responses, and promises specific revision actions significantly improves the probability of acceptance.

After rejection: Rejection, even from a top venue, is not the end of the research lifecycle — it is feedback. Most CS papers are eventually published after one or more rejections and revisions. Read the reviews carefully, identify the core technical concerns (as opposed to misunderstandings or stylistic preferences), address them in your revision, and resubmit to an appropriate next venue. Many highly influential papers were initially rejected before finding their publication home.