For students & faculty
Subject and project viva preparation: explain what you know and built
Prepare for subject and project vivas with conceptual explanation prompts, honest contribution examples and an illustrative faculty-reviewed rubric.
Practiz teamPractical guidance
Know which conversation you are preparing for
A subject viva explores understanding within an agreed curriculum scope. A project viva explores the work described in a project, including decisions, contributions and limitations. For either conversation, establish the expected topics, depth and assessment criteria. Confirm those with your faculty or institution before treating any generic checklist as authoritative.
In Practiz, subject viva practice can use selected curriculum units and Bloom levels, with question selection or a published voice paper. Optional Project Viva uses a project report to explore the work. Availability is configured by the college. Neither an interview nor a report automatically proves originality or verifies who authored a project.
Build an explanation in four moves
Choose one concept and explain it without opening your notes. State the idea plainly, give an example, connect it to a problem and identify a limit or exception. Then check the explanation against your course material. If you can only repeat the definition, change the example and see where your understanding stops.
For a database index, you might explain what it helps locate, show a query that could benefit, and discuss the extra work required when data changes. The aim is to connect mechanism and consequence, not to list vocabulary. For another branch or subject, ask faculty to select an equivalent applied example at the right depth.
- State the concept in your own words.
- Show one concrete example or small worked problem.
- Explain why it matters in that example.
- Name an assumption, tradeoff or case where it does not apply.
Make your project contribution discussable
Prepare a short account of the problem, intended users, design, your responsibility and what was actually checked. Separate implemented work from proposed features. In a team project, acknowledge shared decisions and name the part you can personally explain. Bring permitted diagrams, notes or a report that match the version of the project being discussed.
The fictional example below illustrates how to describe scope honestly. It leaves room for follow-up about design, testing and teamwork. Use your own facts; do not borrow its contribution or add a numerical improvement that you never measured.
Our prototype let students request lab equipment. I implemented the request validation and the database query for available items. Another teammate built the interface. We checked that invalid dates were rejected and that an unavailable item could not be requested in our sample data. We did not test simultaneous requests, so the next step is to examine that case and decide how to prevent conflicting bookings.
Practise follow-ups that reveal your reasoning
Ask a peer or mentor to choose a follow-up rather than always following your prepared order. Pause to reason through the question. If you do not know, explain what you would need to inspect or test. A clear boundary is more useful than a confident claim you cannot support.
| Area | Practice question | What to make clear |
|---|---|---|
| Concept | Can you explain this with a different example? | Understanding beyond a memorised definition |
| Design | Which alternative did you consider, and why? | Assumptions and tradeoffs |
| Contribution | Which part did you implement or investigate? | Your work and the team’s work |
| Testing | What could fail outside your sample data? | Checks performed and missing evidence |
| Reflection | What would you change with another week? | A reasoned next step rather than a feature wish list |
Agree on criteria before interpreting feedback
For a practice review, ask faculty to consider conceptual correctness, application, reasoning, contribution clarity and recognition of limitations. An illustrative descriptor for developing work is ‘explains the basic idea but needs a prompt to apply it.’ A stronger scoped observation is ‘applies the idea to a fresh example and explains a tradeoff.’ These illustrative descriptors need faculty review before use in an institutional rubric.
Tie each observation to a specific response. Do not equate fluent delivery with technical correctness, or a quiet answer with lack of knowledge. Check unclear audio or transcript errors before interpreting the report. The institution’s published criteria and human review govern any formal assessment; this guide cannot replace them.
After practice, choose one concept to revisit, one answer to clarify and one follow-up to attempt. Use the practice–review–retry loop and fit the work into an adjustable preparation plan. For college teams, connect the observations to faculty follow-up rather than an automatic hiring judgement.
Common questions
Should I memorise answers to viva questions?
Use prompts to test explanations, not to build a fixed script. Change the example, explain a tradeoff and ask for a follow-up to find the parts you cannot yet reason through.
Does a project viva prove project ownership?
No. It can help explore contribution claims and understanding, but an interview or automated report does not independently verify authorship or detect plagiarism. Faculty should review relevant evidence.
Can this rubric determine our college marks?
The examples are illustrative guidance. Confirm assessment criteria, permitted materials, scope and marking with your institution; formal decisions follow the institution’s process and human judgement.