You've built and evaluated your contribution — what's left for a PhD in computer science is publication and viva preparation, and both work meaningfully differently in CS than they do in most other academic disciplines. Get the venue choice wrong and a genuinely strong paper can be quietly undervalued by evaluators who don't know CS's unusual publication norms. Get viva preparation wrong — treating it like any other oral defense rather than one that may need to include a live, working demonstration — and you can find yourself less convincing than your actual results deserve. This guide walks through exactly what to get right at both stages.
Why CS Publication Culture Is Genuinely Different
If you're coming into a PhD in computer science from a background in another field, or working with a supervisor or committee more familiar with traditional journal-first disciplines, it's worth understanding early that CS publication norms are a genuine outlier. Roughly 60 to 65% of computer science research output is published in conference proceedings rather than journals — a far higher share than in almost any other field — and, unlike biology, chemistry, or the humanities, peer-reviewed conference papers in CS are treated as equal to, and often more prestigious than, journal publications. This isn't a shortcut or a lesser standard; it's the opposite. Leading CS conferences typically have acceptance rates between 10% and 20%, compared to conference acceptance rates often around 80% in many other scientific fields, meaning a CS conference paper has already survived a genuinely competitive review process by the time it's accepted.
Understanding this distinction matters practically: if your department or committee defaults to evaluating you primarily on journal output, you may need to actively explain why your strong conference publications carry equal or greater weight, rather than assuming this is universally understood.
Conferences vs Journals: What Actually Carries Weight
In CS specifically, the general rule most working computer scientists apply is straightforward: peer-reviewed conference publications are the most important and relevant measure of a computer scientist's accomplishments, on par with — and in many subfields more valued than — journal articles. The best conferences in most CS subfields are typically organized by ACM or IEEE, and the strength of a specific conference (rather than just "is it a conference or a journal") is what actually determines how much weight a given paper carries.
This has a direct, practical implication for your publication strategy: rather than defaulting to "which journal should I submit to," the more useful question for most CS scholars is "which conference, in my specific subfield, carries the most weight for the kind of contribution I've made" — and only secondarily whether a journal extension of that work makes sense afterward.
Understanding CORE Rankings
The CORE Conference and Journal Ranking system is the dominant, widely used tool for assessing CS venue quality, classifying conferences and journals into four tiers — A*, A, B, and C — based on a combination of citation impact, competitiveness (acceptance rates), and the track record of the conference's program committee. As a practical rule of thumb: publications in CORE A* or A conferences are generally considered stronger contributions than publications in lower-tier journals, even though this can run counter to the instincts of evaluators trained in journal-first disciplines. If your university's evaluation committee defaults to counting only journal publications, it's worth proactively pointing to your paper's CORE ranking as objective, third-party evidence of its actual standing in the field, rather than assuming the distinction will be obvious.
Before submitting anywhere, it's worth checking your target venue's current CORE ranking directly, since rankings are periodically updated and a venue's standing can shift between cycles.
Where Preprints Fit Into a CS Publication Strategy
Posting a preprint — most commonly via arXiv — ahead of or alongside a formal peer-reviewed submission has become a widely accepted, field-specific norm in computer science, used to establish priority for an idea and gather early feedback from the community before formal review concludes. This is worth understanding as distinct from problematic duplicate publication: posting a preprint and then publishing a peer-reviewed version of the same work is standard, accepted CS practice, not a plagiarism or originality concern, provided you follow your target venue's specific policy on prior preprint disclosure (most major CS venues have clear, published policies on this that are worth checking directly before submission).
Choosing the Right Target Venue for Your Contribution
Matching your specific contribution to the right venue tier matters more than simply aiming as high as possible every time. A genuinely novel, rigorously evaluated contribution with strong experimental results is a reasonable fit for an A*/A conference in your subfield. A solid, useful, but more incremental contribution may be better suited to a well-regarded B-tier venue or a specialized workshop tied to a major conference, where it will actually get read and cited by the right audience rather than getting lost in an extremely competitive top-tier review process. Submitting consistently above your work's actual maturity level tends to produce a string of rejections that cost months of resubmission cycles; submitting appropriately tends to produce a faster, more productive publication record.
If you'd like guidance identifying the right target venues for your specific subfield and contribution, our PhD thesis assistance service works with computer science scholars specifically at this publication-strategy stage.
It's also worth planning your submission timing around conference cycles rather than treating publication as something to slot in whenever convenient. Most major CS conferences run on fixed annual or biannual submission deadlines, often many months before the actual conference date, and review cycles can run several months from submission to final decision, sometimes with a rebuttal or revision phase in between. Working backward from your intended thesis submission date, and mapping out which conference deadlines realistically fall within your remaining timeline, tends to produce a far less stressful publication strategy than reacting to whichever deadline happens to be nearest when your results are ready.
Getting Your Manuscript's Framing Right
A detail worth getting right regardless of venue: avoid using words like "novel" or "new" in your paper's title. This is explicit guidance from IEEE's own author resources, on the basis that claiming novelty in the title is somewhat redundant — reviewers expect your paper's actual content and evaluation to demonstrate novelty, not the title to assert it upfront. A title that lets your contribution speak for itself through precise, specific language tends to read as more confident and more professional than one that oversells itself before a reviewer has read a single page.
Don't Overlook Reproducibility Expectations at Submission
Most major CS conferences now run a formal artifact evaluation process alongside standard peer review, awarding specific badges — Artifacts Available, Artifacts Evaluated (Functional or the higher Reusable tier), and Results Reproduced or Replicated — to papers whose code, data, and experimental setup meet defined reproducibility standards. Even where artifact evaluation is optional rather than mandatory at your target venue, submitting a clean, well-documented, runnable version of your code alongside your paper has become an increasingly strong, sometimes decisive, signal of quality to reviewers. If you built your methodology with reproducibility in mind from early in your PhD, this stage becomes a matter of packaging what you already have rather than a last-minute scramble to reconstruct a presentable artifact from scattered scripts and undocumented dependencies.
Viva Preparation: What's Different for a CS Thesis
A CS PhD viva follows the same underlying structure as a viva in any discipline — an oral examination where examiners confirm you understand your research deeply enough to defend it independently — but it carries one meaningful difference for systems-oriented and applied CS theses specifically: the expectation, in many cases, of an actual working demonstration of your system, not just a description of it. Where your contribution includes an implemented system, tool, or pipeline, current guidance consistently recommends running a genuine live demo during your defense, since examiners tend to find a working demonstration considerably more convincing than a verbal or slide-based explanation alone.
Preparing and Rehearsing Your Live Demo
If your thesis includes a system component, treat your demo with the same rigor as your written defense. Run it end-to-end multiple times in the exact environment you'll use on the day, not just on your development machine, since environment mismatches are one of the most common sources of live-demo failure. Prepare a pre-recorded backup video of the same demo in case of a live technical failure — network issues, hardware problems, or an unexpected dependency conflict can happen to anyone, and having a backup ready signals preparedness rather than covering for a mistake. Keep your demo focused on the specific claims your thesis makes; a flashy but tangential feature demonstration can actually distract from your core contribution rather than strengthening it.
Practically, this means testing your demo on the actual hardware and network connection you'll use for the viva itself, at least once, rather than assuming your development setup will translate identically. If your system depends on external services, cloud resources, or specific hardware that might not be reliably available on the day, build a clearly labeled fallback path into your demo script — a pre-recorded segment you can switch to seamlessly rather than awkwardly apologizing and improvising. It's also worth timing your demo precisely during rehearsal, since a live demonstration that runs long can eat into the time available for the broader Q&A that follows, and examiners tend to notice when a candidate hasn't accounted for this.
A Practical Pre-Viva Routine
In the days before your viva, reread your entire thesis closely rather than cramming new material — the goal is to re-internalize your own arguments and decisions, not to learn anything new at this stage. Prepare a tightly rehearsed one-sentence summary and a slightly longer one-paragraph summary of your whole thesis, since a request to summarize your work is consistently one of the very first things asked. Spend real time thinking broadly about how your work fits into the wider field, what you'd do differently in hindsight, and where the field or your own research agenda might go next — examiners consistently report valuing this kind of reflective, big-picture thinking as much as, or more than, granular recall of specific numbers from your results tables.
It's also worth genuinely internalizing that you are not expected to have perfect recall of everything you've read or written. Asking an examiner to repeat or clarify a question, or taking a moment to think before answering, is normal, expected behavior — not a sign of weakness. If an examiner becomes more confrontational than the rest of the panel, a calm, thoughtful, non-defensive response tends to rebalance the discussion far more effectively than matching their tone.
Common Question Categories to Rehearse
Beyond the near-universal opening request to summarize your thesis, CS vivas tend to probe a recognizable set of categories: your core contribution and what specifically is new about it; your choice of methodology and why you chose it over alternatives (a category that deserves particularly thorough preparation, since examiners consistently probe design decisions more than any other single area); your evaluation design, including why you chose your specific baselines and metrics; the limitations and generalizability of your results; and, for systems work specifically, questions probing the actual engineering decisions behind your implementation — why you chose a specific architecture, library, or algorithmic approach over alternatives, and what tradeoffs that choice involved. Rehearsing spoken, not just written, answers to a handful of concrete versions of each of these categories is one of the highest-value uses of your final preparation time.
A few specific, worth-rehearsing-aloud versions: "In one sentence, what is the core contribution of this thesis?" (a near-universal opener); "Why did you choose this baseline for comparison, and what would change if you'd chosen a different one?" (tests whether your evaluation design was genuinely deliberate); "If you had another year, what would you change or extend?" (a limitations question that rewards honest, specific self-assessment far more than vague optimism); and, for implementation-heavy theses specifically, "Walk me through what happens when your system fails or receives unexpected input" (tests whether you understand your own system's edge cases, not just its happy path). Practicing these aloud, ideally with someone pushing back on your first answer rather than accepting it immediately, surfaces gaps in your reasoning far faster than silent reflection.
A Real Example: Undervaluing a Strong Conference Paper
A scholar whose department's evaluation norms had historically prioritized journal publications initially treated their own A*-ranked conference paper as a secondary accomplishment compared to a lower-tier journal submission still under review, simply because "journal" sounded more prestigious by the conventions they were used to. A conversation with a more CS-native mentor clarified the actual standing of the work: the A*-ranked conference paper, having survived a sub-15% acceptance rate at one of the field's most competitive venues, was objectively the stronger publication by any standard measure the field itself uses, including citation impact and program-committee rigor. Reframing the department's evaluation conversation around the paper's CORE ranking — rather than assuming the conference-versus-journal distinction was self-evident — meaningfully changed how the work was received internally. The broader lesson: in computer science specifically, know your own field's actual standards well enough to advocate for your work accurately, rather than assuming a generic academic-prestige hierarchy applies unchanged.
FAQs
What does publication and viva preparation for a PhD in computer science actually involve?
Publication involves understanding CS's conference-first publication culture and targeting appropriately CORE-ranked venues for your specific contribution, rather than defaulting to a journal-only strategy; viva preparation involves the usual thesis-defense fundamentals plus, for systems-oriented work, preparing and rehearsing an actual live demonstration of your implemented system.
Why does this stage matter so much for a CS PhD specifically?
Because computer science's publication norms — conference papers weighted equal to or above journals, CORE rankings as the key quality signal — are genuinely different from most other academic fields, and misunderstanding this can lead to a strong publication record being undervalued by evaluators unfamiliar with CS-specific conventions.
How does this stage affect a PhD thesis in computer science?
A well-targeted publication strengthens your case for original contribution in terms the field actually recognizes, while a well-prepared, demo-ready viva turns an oral defense into a confident, convincing conversation rather than an abstract description of work examiners can't directly see functioning.
How long does it take to complete a PhD thesis using this approach?
Under UGC norms, a PhD runs three to six years including coursework; once submitted, the examination process including the viva is required to be completed within six months, so the publication-and-viva stage itself typically adds months rather than years when approached with proper preparation.
Is professional help available for publication and viva preparation in a PhD in computer science?
Yes. Experienced research mentors can help identify appropriately ranked target conferences and journals for your specific subfield, review manuscript framing, and support structured, demo-ready viva preparation — this is a core part of what services like ThesisLikho's PhD thesis assistance provide.
Getting the final stretch right means your work gets evaluated on its actual merit, in the terms your own field genuinely uses. If you'd like support choosing target venues or preparing for your viva, Book a PhD Research Consultation →