Defense and Submission

Two kinds of work here: administrative, which is boring and can destroy your timeline, and rhetorical, which is the defense itself.

Administration, handled in month one

Do this in Phase 0, not Phase 5. Nothing here is intellectually demanding and all of it has lead times you do not control.

Find and read your program's formal requirements. Get the official template or the formatting specification — margins, font, line spacing, required front matter, page numbering, whether a declaration of originality or a specific title page is required. If a LaTeX template exists, use it from day one rather than porting your document into it at the end.

Establish the dates and put every one in a calendar with a two-week-early reminder: the submission deadline, the intent-to-submit or defense-scheduling deadline, which is often earlier and easier to miss, how far in advance the committee must receive the document, and the defense window itself.

Confirm the process details. How many committee members, who selects them, and does your advisor need to arrange anything with a lead time. Whether a plagiarism check is mandatory and who runs it. Whether the thesis is published, whether an embargo is available, and whether your funding source or an industrial collaborator has IP restrictions on what you may publish — this last one occasionally forces real changes to a document and you want to know early.

Ask your advisor two questions this month: what a passing thesis looks like in this program, and who is likely to be on your committee. Both change how you write. If you know a committee member's specialty, you know which chapter will be read hardest.

Two weeks before submission

Formatting and completeness, mechanically.

Check the document against the template requirements line by line: margins, spacing, page numbering, title page, declaration, abstract length limits. Confirm the table of contents, list of figures, and list of tables are auto-generated and current. Verify the PDF has fonts embedded and that figures are vector where they should be — a thesis with a rasterized, blurry architecture diagram makes a poor impression for no reason.

Then the content sweep. No \todo{} or [?] markers anywhere. Every citation resolves. Every figure and table referenced from the text. Numbers in the abstract, introduction, and evaluation chapter agreeing with each other, which is the error most likely to have crept in after a late rerun.

Then archive your artifacts: code committed and tagged, raw results backed up somewhere that is not your laptop, and a repository README that lets someone reproduce your main result. Do this before the defense, both because you may be asked and because the machine you did everything on will eventually be reimaged.

Print the whole thing once and read it on paper. You will catch things you have looked past on screen for two months.

The defense talk

Typically 20 to 30 minutes plus questions; confirm your program's format. Aim for roughly one slide per minute, which means about 20 to 25 content slides.

A structure that works, with approximate timing for a 25-minute talk:

Spend the first four to five minutes on motivation and problem — the longest single block, and correctly so. Your committee has read the thesis but has not been living inside it for a year, and a talk that starts fast at a technical level loses the room in the first two minutes. Make the problem concrete, ideally with a measurement of your own.

Then about two minutes on why it is hard and why existing approaches fall short, then a single slide with your key insight — the one thing you want remembered. Then five to seven minutes of design, being much more selective than in the thesis: one architecture slide and your two or three most important mechanisms, not all of them. Then six to eight minutes of results, again selective: the headline result, the overhead, and one interesting or surprising finding. Then a minute or two on limitations and future work, which is worth including deliberately — raising your own limitations frames the discussion on your terms and demonstrates command of your work. Then a summary slide restating your contributions.

Keep backup slides after the summary for the questions you expect: detailed methodology, additional experiments, an ablation table, hardware specification. Being able to say "yes, I have that" and jump to a slide is one of the more impressive things that happens in a defense.

Slide craft: one point per slide, minimal text, figures reused from the thesis for consistency, and no slide you would need to apologize for the font size of. Never read your slides aloud.

Rehearsal

Rehearse three times. Once alone with a timer, and expect to be over — cut rather than talking faster. Once for labmates, asking them to interrupt with questions. Once as a mock defense with your advisor, ideally with someone who has not followed the work, roughly a week before the real thing so you have time to act on what it reveals.

Separately, reread your ten to fifteen core papers in the last week. You need to be able to say what each one did, how yours differs, and why you did not do it their way. A committee member asking about a paper you cited and cannot discuss is one of the worse moments available in a defense, and it is entirely preventable.

Questions you will be asked

These recur. Prepare an answer, with a backup slide where relevant, for each one.

Why didn't you compare against X? Either you did and can point to it, or you have a reason — the artifact was unavailable, it targets a different regime, it requires hardware you lack. Never answer this with a vague dismissal of X.

Does this generalize beyond your benchmarks? Answer with your workload-level held-out results and your sensitivity sweep, and state the boundary honestly.

What is the overhead? You have a section on this. Know the numbers cold, including the tail.

What happens when the workload changes? Your distribution-shift experiment. If you do not have one, expect to be pushed on this.

Is this actually novel relative to paper Y? Be specific and fair about the difference. Do not overclaim, particularly since Y's author may be present.

Why did you choose these particular benchmarks? Your methodology section answers this. One sentence per workload.

How sensitive is this to hyperparameters? Your sensitivity sweep.

Would a simpler approach work as well? You should have tested this — see the simple-model comparison in guide/06-evaluation-playbook.md. Having tested it and found the answer is a strong position either way.

What is the weakest part of your work? Answer this genuinely. A prepared honest answer is impressive; a deflection is not, and the committee already knows the answer.

What would you do with another six months? Your future work section, made concrete.

Could this be deployed in production? What would break? Maintainability, debuggability, and the difficulty of reasoning about a learned policy during an incident. Systems people care a great deal about this and a thoughtful answer signals maturity.

Answering well

Listen to the whole question. Do not begin answering the question you expected.

Pause before answering. Two seconds of silence reads as consideration, not uncertainty.

If you do not understand the question, ask for clarification, or restate it as you understood it and confirm. Answering a misunderstood question wastes the exchange and looks worse than asking.

Answer directly first, then support. "No, we did not test that. The reason is..." is much better than three sentences of context arriving at an implicit no.

Bound your claims rather than defending more than you showed. "Within the range we tested, yes; beyond that I would expect X, but we did not measure it" is a strong answer.

Never bluff. "I don't know" followed by "here is how I would find out" is a perfectly good answer and your committee has heard enough bluffing to recognize it instantly. Attempting to talk past a gap converts a small weakness into a credibility problem.

When a committee member is right about a flaw, concede it and say what it would take to address. Defending an indefensible point is the worst-scoring behavior in a defense. The committee is evaluating whether you understand your own work, including its limits — conceding accurately is evidence that you do.

After

You will likely receive required corrections. Log every one, address each explicitly, and return a change list alongside the revised document so reviewers can see their comments were handled rather than rereading the thesis.

Then finish the archiving: tag the final code, deposit the thesis wherever your institution requires, and consider whether a paper is extractable — a well-executed MSc thesis is often one focused workshop paper, and that decision is much easier while everything is still fresh.