Defending it in a viva

A viva is not a test of your code. It is a test of whether the code is yours.

The examiner has already seen it work. What they are deciding is whether you made the decisions in it, and they find out by asking why, twice.

The question underneath every question

Whatever they ask, they are asking one thing: can you defend a choice.

"Why a HashMap here?" is not about HashMap. It is whether you considered anything else. "Why is this an interface?" is not about interfaces. The good answer always has the same shape: what the alternative was, and what made you pick this one.

"Because that is what the tutorial used" is an honest answer and it is also the one that costs you marks. "I used a HashMap because I need lookup by id and I do not care about order; a TreeMap would have cost me log n for sorting I do not use" is the same decision, defended.

Where they will actually push

The data model. Why this table, why this key, why not one big table. If you normalised, why. If you did not, why not.

The one weird bit. Every project has a part where something was worked around. They will find it, and they are not looking for it to be elegant. They are looking for you to know it is there and be able to say what you would do with more time.

Anything you cannot explain. Which, increasingly, is the code an agent wrote while you watched. If your commit history is clean and your explanation is not, that gap is the whole viva.

The three-sentence habit

Rehearse a three-sentence answer for every significant decision in the project. What it does, why this way, what you gave up.

Three sentences, because the failure is almost never saying too little. It is starting to explain, realising halfway that you are not sure, and trailing off. An examiner reads that as not knowing, whether or not you did.

What to do when you do not know