How to practise programming fundamentals viva questions
A viva answer needs more than the right term. You need to explain what happens, support it with a small example, and respond clearly when the examiner changes a detail. This guide uses three common programming fundamentals topics to practise that sequence: parameter passing, loop boundaries and recursion.
There is no single international programming fundamentals viva format. Your course may specify particular languages, topics, marking rules or timings; check your course materials and ask your instructor what applies. The examples below use language-neutral pseudocode where possible. If your assessment expects a particular language, answer in that language and be precise about its behaviour.
For each station, practise this order:
- Answer the question directly. Give the definition or result first.
- Explain the mechanism. Describe what the program does, step by step.
- Give a small example. Use values that make the idea visible.
- Check the boundary or assumption. Say what changes if an input, language rule or condition changes.
- Stop when the question is answered. Add detail when it helps, not to fill silence.
A practice examiner persona can keep the feedback consistent. The emphases below are MySummaries practice criteria, not claims about any particular institution’s viva rubric.
The examiner strip for this subject might look like this:
Build a board from your own course notes
Before practising aloud, collect the definitions, syntax rules and examples your course actually teaches. Make separate sections for variables and types, selection and iteration, functions, arrays or collections, and testing or debugging. Add the language’s rules where they matter: for example, whether an array access is checked at runtime or what a function returns when no return statement is reached. Do not treat pseudocode conventions as a substitute for a language rule your course examines.
Keep each section small enough to speak from. A useful note records a rule, a worked example and one likely mistake. For instance, a loop note should show its initial value, condition, update and final value—not simply say “loops repeat code”. Mark sections for revision when you cannot explain them without reading.
A board on this topic ends up looking like this:
- A parameter is named in a function definition; an argument is supplied at a call.
- A local variable is available within its declared scope.
- Whether a call can change caller-visible state depends on the language and the value being passed.
- A recursive function calls itself, directly or indirectly.
- A base case stops further recursive calls.
- Each recursive step must make progress towards a base case.
For i = 0; i < 4; i = i + 1, the body runs with i equal to 0, 1, 2 and 3. At i = 4 the condition is false.
Choose normal inputs, boundary inputs and inputs that should be rejected. Compare actual results with expected results.
- For a zero-based array of length n, valid indexes are 0 through n − 1.
- An access at index n is outside that range; the result depends on the language’s rules.
Station 1: explain parameter passing
The first station tests whether you can distinguish a function’s local parameter from a variable in its caller, and whether you avoid making a language-specific claim without naming the language. Read the prompt as if the examiner has just asked it. Give your answer aloud before looking at the feedback below the mock-up.
A strong answer starts by saying what the shown pseudocode does, then explains why the caller’s variable remains unchanged. It should also distinguish this example from a function that mutates a shared object or returns a value that the caller assigns.
Examiner
In this pseudocode, what is the value of x after the call, and why? Explain what would need to change for the caller to receive the updated value. function change(n) n = n + 1 x = 4 change(x)
Correctly says x remains 4 in the stated pseudocode, but initially calls n a reference without a language rule to support that claim.
ImproveState the behaviour of this pseudocode first; qualify any pass-by-reference comparison by naming the language or convention.
Explains that n is assigned 5 inside the function, but does not clearly separate the local name from x.
ImproveSay that the function’s parameter n receives the argument value and the assignment changes n, not the caller’s x.
Uses the supplied values, which makes the result checkable.
ImproveAdd one contrast: return n and assign the result to x, if the pseudocode language supports that form.
Recognises that behaviour can differ between languages, but does not explain what assumption the answer uses.
ImproveIdentify the snippet as value-copying pseudocode and say that object mutation and language-specific reference rules are separate cases.
A strong answerIn this pseudocode, x is still 4 after the call. The argument’s value is used to initialise the parameter n, and the assignment n = n + 1 changes that parameter to 5. It does not assign a new value to the caller’s variable x. To update x in this example, the function could return 5 and the caller could assign that result to x. Actual parameter and reference behaviour depends on the language, so I would name the language before making a broader claim.
That is a MySummaries station, filled with programming fundamentals material. Yours is written from your own notes. Start free
Notice the useful qualification: the question supplies pseudocode, so the answer can state the assumed behaviour for that snippet. If an examiner asks about a language such as Java, Python or C, do not automatically reuse the pseudocode explanation. Give the rule taught for that language, and distinguish rebinding a parameter from mutating an object when relevant.
The transcript view helps you revise the exact phrase that lost precision. It is more useful to replace an unsupported generalisation than to memorise a longer answer.
A marked phrase from that response might appear like this:
x stays 4 because the function changes the value it received. It is pass-by-reference in every language. If I need the caller to get 5, I can return the result and assign it to x.
It is pass-by-reference in every language.
The snippet does not establish a rule for every programming language, and the claim is incorrect as a universal statement.
Say: For this pseudocode, n is a separate parameter initialised from x. The exact parameter-passing behaviour depends on the language.Station 2: trace a loop and find the boundary
This station tests tracing as well as explanation. State the values taken by the loop variable, how many times the body runs, and what is printed. Then identify the boundary condition that prevents an extra iteration. If you spot an error, explain what it does before proposing a fix.
A common weak answer says only “four times”. That may be right, but it does not show whether you traced the condition or guessed from the number in the code.
Examiner
Trace the loop and give the exact output. How would the output change if the condition were i <= 4? for i = 0; i < 4; i = i + 1 print(i)
Gives the correct output for the supplied loop and correctly predicts the effect of changing the comparison.
ImproveMake the distinction between the final value of i and the values printed explicit.
Traces the increment and stopping condition, but skips the failed condition check at i = 4.
ImproveExplain that the body does not run when i = 4 because 4 < 4 is false.
Uses the actual values from the question and identifies the extra printed value for the changed condition.
ImproveState the output in order rather than describing it only as a range.
Recognises that <= changes the boundary but does not mention that the loop’s update is applied after each body execution.
ImproveTrack the update after printing 3; with <=, the body then also runs at i = 4.
A strong answerThe output is 0, then 1, then 2, then 3. The body runs when i is 0, 1, 2 and 3, and the update increases i by one after each run. At i = 4, the condition 4 < 4 is false, so the body does not run again. If the condition is changed to i <= 4, the body also runs at i = 4, so the output becomes 0, 1, 2, 3, 4. The final value of the loop variable and the values printed are not the same thing.
Practise the same explanation with a different starting value and condition. For example, trace a loop that starts at 1 and continues while the counter is less than 5. Do not rely on “the loop runs n times” unless you have checked the initial value, comparison and update. For debugging questions, suggest a correction only after explaining the observed behaviour; changing < to <= is not always the right fix.
Station 3: explain recursion and its stopping condition
This station checks whether you can identify both the base case and the progress towards it. Give the result for a small input, then describe what would happen if the base case were removed. Avoid saying merely that recursion “keeps calling itself”: the examiner needs to hear what ends the calls.
Examiner
What does this function return for countDown(3)? Identify the base case and explain what can happen if it is removed. function countDown(n) if n == 0 return 0 return 1 + countDown(n - 1)
Correctly works out that countDown(3) returns 3, but describes the function as returning the sequence rather than a single value.
ImproveSay that this function returns the integer 3; it does not output the intermediate calls.
Follows the calls down to zero, but does not clearly show how the returned values combine on the way back.
ImproveTrace 1 + countDown(2), then 1 + 2, then 3.
Uses the requested input and names the base case.
ImproveGive the complete call chain: countDown(3), countDown(2), countDown(1), countDown(0).
Notes that removing the base case is unsafe, but does not account for the input reaching zero.
ImproveExplain that calls continue without a stopping condition and may exhaust the available call stack; behaviour depends on the runtime.
A strong answercountDown(3) returns 3. The calls reach countDown(2), countDown(1) and then countDown(0), where the base case returns 0. As the calls return, the values are 1 + 0, then 1 + 1, then 1 + 2, giving 3. The base case stops the recursion. Without a reachable stopping condition, calls may continue until the runtime runs out of call-stack space or otherwise fails; the exact outcome depends on the language and runtime.
To improve this answer, practise two follow-up questions: what does the function return for zero, and what happens for a negative input? In this exact code, zero returns zero. A negative input keeps decreasing and never reaches the n == 0 base case, so it may recurse until a runtime failure. That observation is more precise than saying that every recursive function must fail on negative input: the behaviour depends on its condition and implementation.
Turn a practice answer into a better one
After each attempt, record only the points that would change your answer: a wrong result, a missing step, an unsupported language claim or a boundary case you overlooked. Then retry the same question in a shorter, clearer form. A useful self-check is whether someone could reproduce the result from your explanation without seeing you run the code.
You can also make a small question set from your course board. Ask for a definition, a trace, a comparison and a bug explanation for each topic. For functions, compare a parameter with an argument; trace a return value; explain scope; and discuss how the language handles a relevant object or reference. For iteration, trace a boundary and identify an off-by-one error. For recursion, state the base case, follow a small call chain and explain what input might not reach the base case.
When feedback is incomplete, revise the source note rather than learning a polished model answer word for word. A model is a check on the reasoning, not a script that will fit every version of the question. Keep examples small enough to calculate aloud and say your assumptions before applying language-specific rules.
How MySummaries helps
MySummaries can turn your PDFs, slides and photographed notes into a revision board, then use that material to create recorded oral practice and examiner-style feedback. For this task, build a board from your course’s actual programming rules, practise questions aloud, and use the feedback to revisit precise gaps such as loop boundaries or parameter behaviour. You can start at MySummaries.