How to use software engineering viva questions
A software engineering viva tests whether you can reason aloud about an engineering problem, not whether you can recite definitions. The examiner is usually listening for four things:
- whether you clarify the problem before proposing a solution;
- whether you can compare alternatives against explicit constraints;
- whether your technical claims are accurate;
- whether you can explain a decision clearly enough for another engineer to review it.
A strong answer normally follows a repeatable order:
- Clarify the goal. State who needs the system, what it must do and what is out of scope.
- Name the constraints. Include scale, latency, availability, privacy, safety, budget, team capability and delivery time where relevant.
- Offer an initial design. Explain the main components and how data or requests move between them.
- Discuss alternatives. Say what you would choose instead if a key constraint changed.
- Address failure and verification. Cover testing, monitoring, recovery and how you would know the design meets the requirement.
- State your assumptions. This prevents a reasonable answer being weakened by an unstated interpretation.
Do not answer a broad question with a list of technologies. For example, saying that you would use microservices, Docker and Kubernetes does not explain why those choices fit the problem. Start with the system behaviour and constraints, then select the simplest architecture that meets them.
The following practice setup gives a candidate a consistent examiner persona and a set of stations. In MySummaries, an examiner strip for this subject could look like this:
Use the four emphases as a self-check, not as a reason to make every answer long. A short answer with a clear assumption and a defensible trade-off is stronger than a long catalogue of tools.
A workable viva method
Before proposing a design
For a system-design station, ask two or three focused questions rather than interrogating the examiner for every detail. Useful questions include:
- Who are the users, and what is the most important user journey?
- Is the operation read-heavy, write-heavy, batch-oriented or interactive?
- What happens if the service is temporarily unavailable?
- Is data deletion, auditability or regional storage important?
- Are there existing systems or interfaces that must be retained?
Then state a working assumption. For example: I will assume that the booking service must prevent double booking, that payment is handled by an external provider, and that a short delay is preferable to confirming two customers for the same resource.
While explaining architecture
Describe one request from beginning to end. If you propose an appointment booking service, explain how the client sends a request, how the application validates it, how availability is checked, how the reservation is committed and how the user receives confirmation. This exposes missing steps more effectively than naming components in isolation.
Distinguish between consistency and availability in practical terms. If two users must not receive the same seat, the reservation operation needs a concurrency-control mechanism, such as a database transaction with a uniqueness constraint or an atomic conditional update. A retry policy must also avoid creating two bookings or two charges.
When discussing quality
Separate functional tests from other forms of evidence. Unit tests can check a pricing rule, integration tests can check the interaction between the booking service and its database, and end-to-end tests can check a critical journey. They do not replace load testing, security testing, accessibility checks, monitoring or a review of operational recovery.
A useful answer also describes a failure. If a payment succeeds but the booking confirmation is not written, explain how the system detects and reconciles the uncertain state. Depending on the design, this may involve an idempotency key, a durable status record, a queue and a reconciliation process. Do not promise exactly-once behaviour without explaining where the boundary and guarantee come from.
When the question changes direction
Viva questions often test whether you can adapt. If the examiner introduces ten times the traffic, a legal deletion requirement or a second team changing the same service, do not discard the whole answer immediately. Identify which assumption changed, which part of the design is affected and what new evidence you would collect.
Use phrases such as:
- My current assumption is…
- The main risk in that choice is…
- I would compare this with…
- I would not make that decision until I measured…
- If the requirement changed to…, I would revisit…
These phrases make your reasoning visible without padding the answer.
Station list: software engineering viva questions
The practice stations below cover common areas of a software engineering oral: requirements, architecture, concurrency, testing and delivery. Each has an opening question. The opening is deliberately broad; your first task is to narrow it with assumptions.
A station table for these questions looks like this:
Do not try to memorise a single model speech for each station. Learn the order of reasoning, then adapt it to the facts in the question. The three worked stations below show what a complete response can sound like.
Worked station 1: requirements under conflict
The first station tests whether you can turn competing requests into a prioritised, testable problem. Begin by identifying stakeholders and decisions, rather than choosing a requirements method by name.
Examiner
A hospital administration team asks for a new appointment system. Clinicians want flexible booking, while the finance team wants every change auditable. How would you elicit and prioritise the requirements?
The answer identifies patients, clinicians and finance as different stakeholders and assumes that an appointment change must be attributable to a user.
ImproveState whether clinical safety or legal retention requirements impose non-negotiable constraints before discussing lower-priority features.
The response separates must-have booking behaviour from reporting preferences and proposes prioritising by risk, value and dependency.
ImproveExplain how a conflict would be resolved when clinician flexibility makes the audit trail harder to interpret.
It proposes interviews, observation, workflow mapping and acceptance criteria, then suggests validating a prototype with real users.
ImproveInclude an example acceptance criterion, such as recording who changed an appointment, when and from which previous state.
The response moves from discovery to prioritisation and validation in a clear sequence.
ImproveEnd with the first two delivery increments so the recommendation becomes an actionable plan.
A strong answerI would begin with interviews and observation of booking, rescheduling and cancellation, involving clinicians, administrative staff, finance and an information-governance representative. I would record functional requirements separately from constraints: a booking change must show the actor, time, previous value and new value, and the record must not be silently overwritten. I would prioritise safety, legal and audit requirements first, then the smallest booking workflow that can be tested with users. For flexible scheduling, I would model the allowed changes explicitly and review them with clinicians rather than accepting an ambiguous requirement. I would validate the first increment using acceptance criteria and a workflow demonstration before adding reporting or convenience features.
Notice that the model answer does not claim that a particular requirements framework is mandatory. It gives evidence of discovery, prioritisation and validation. If asked about a technique, you can name user stories, use cases, event storming or process mapping, but connect the technique to the uncertainty it is meant to reduce.
Worked station 2: preventing duplicate bookings
This question tests concurrency, data integrity and failure handling. The essential issue is not whether you can name a lock; it is whether the check and the state change are protected as one operation.
Examiner
Two customers can request the last available appointment at almost the same time. Explain how you would prevent an inconsistent result and handle retries.
The answer defines the invariant: one appointment slot can have at most one confirmed booking, and assumes a relational database owns that invariant.
ImproveClarify whether a temporary hold is needed before payment and how long it should remain valid.
It compares a transaction with a unique constraint against an application-only availability check and explains why the latter has a race condition.
ImproveMention the user-visible response when the second transaction loses, rather than describing only the database behaviour.
The response includes an idempotency key, a transaction, a unique constraint and a reconciliation path for uncertain payment results.
ImproveSpecify that the idempotency record must be durable and associated with the operation result.
The answer follows the request path, commit path and retry path in order.
ImproveAvoid switching between payment and booking before stating the core booking invariant.
A strong answerI would make the database enforce the invariant that a slot has no more than one confirmed booking. The availability check and insert would run in one transaction, with a unique constraint on the slot identifier; if two requests race, only one can commit and the other receives an unavailable response. The client would send an idempotency key so a network retry returns the original result instead of creating another booking. If payment is involved, I would record a durable pending state and use a reconciliation process for cases where the payment provider confirms success but the application does not receive the response. A temporary hold may be added if payment takes time, but it needs an expiry and a defined release rule.
A common weak answer says, check availability and then insert the booking. That sequence is unsafe when two requests perform the check before either insert. Say where the invariant is enforced and what the losing request experiences. If you propose a distributed lock, explain its expiry, ownership and failure behaviour; otherwise a database constraint is often easier to defend for a single booking store.
Worked station 3: safe continuous delivery
The final station tests delivery design rather than deployment vocabulary. A credible answer connects automation to a controlled release, observability and rollback or roll-forward decisions.
Examiner
A team wants to deploy to production several times a day. Design a delivery approach that limits the impact of a defective release.
The response distinguishes deployment from release and assumes that the service can be monitored with meaningful health and business indicators.
ImproveState whether database changes must support two application versions during a gradual rollout.
It proposes small changes, automated checks and a gradual exposure strategy instead of treating frequent deployment as an end in itself.
ImproveExplain when a feature flag is safer than a rollback, especially for a destructive data change.
The answer includes unit, integration and smoke checks, staged exposure, logs, metrics and an alert threshold.
ImproveGive a concrete example of a release gate, such as elevated payment failures compared with the pre-release baseline.
The response describes the pipeline in sequence and keeps the focus on reducing blast radius.
ImproveFinish with ownership: identify who decides to pause, rollback or investigate the release.
A strong answerI would keep changes small and require automated unit, integration and security checks before an artefact can be promoted. Deployment would be separated from release using a feature flag or a gradual rollout, so a new version first serves a small proportion of traffic. I would monitor technical signals such as error rate and latency alongside a business signal such as failed checkout payments, with a pre-agreed threshold that pauses promotion. Database migrations would be backward compatible while both application versions are live. If the defect is isolated and the old version is safe, I would stop exposure or roll back; for an irreversible data change, I would use a compatible forward fix and a tested recovery procedure, with a named person responsible for the decision.
This answer is stronger than saying that continuous integration and continuous delivery are best practice. It explains the controls that make frequent change safe: small batches, automated evidence, limited exposure, useful signals and a recovery decision. If the examiner asks about culture, connect it to the technical process: teams need ownership of services, visible deployment health and a blameless review of failures so the same risk is not repeated.
How to improve a spoken answer
After each station, review the recording for three specific faults. First, did you answer the question asked, or did you deliver a prepared lecture on a nearby topic? Second, did you state the constraint that caused your design choice? Third, did you explain what happens when the normal path fails?
A useful marking note is more precise than too vague or add more detail. For example:
- missing invariant: state what must never happen;
- unsupported technology choice: connect the tool to a requirement;
- shallow testing answer: name the risk and the test level that provides evidence;
- incomplete operations answer: include detection, decision and recovery;
- unclear communication: give the answer in numbered stages.
For a software engineering viva, specificity often means a small number of concrete examples. Say that an idempotency key is stored with the result of a booking request. Say that a unique database constraint protects one slot. Say that a contract test checks the agreed response between two services. Say that a migration remains compatible with the previous application version. These details let the examiner assess your reasoning.
The wording from a recorded attempt can be reviewed for marks that were nearly earned:
I would first clarify the users and the main workflow, then identify the constraints before choosing an architecture. I would use microservices because they scale better. I would test it and monitor the service after release. If the requirement changed, I would revisit the design rather than defend the original choice.
I would use microservices because they scale better
The answer gives a general benefit without showing that independent scaling is the actual constraint. It also says monitor without naming a signal, threshold or response.
Say: Say which component has a different load profile, then name the evidence and action: for example, pause rollout if payment failures exceed the agreed baseline and investigate the release.Try to replace broad claims with conditional ones. Instead of microservices scale better, say that I would consider separating the catalogue search component if its traffic and release needs differ materially from the rest of the system, and I would first measure the current bottleneck. Instead of testing will catch bugs, say which risk the test addresses and what it cannot prove.
A short examiner-style debrief can also make the next attempt more focused:
You made the booking invariant explicit and handled the race with a transaction; the next improvement is to state the user-facing result when the competing request loses.
A repeatable answer template
Practise the following template until it feels natural, then adapt it rather than reciting it word for word:
- Scope: I will assume…
- Goal: The system must…
- Constraint: The most important constraint is…
- Design: I would use… because…
- Alternative: I would choose differently if…
- Failure: If … fails, the system would…
- Evidence: I would verify this with…
- Review: I would monitor or revisit…
For a requirements question, the design step may be a discovery plan rather than an architecture. For a testing question, the evidence step should distinguish test levels and production signals. For a delivery question, failure and recovery should be central. For a security question, identify the asset, threat, control and residual risk.
Finish by answering the examiner's actual question. Do not add unrelated technologies simply to demonstrate that you know them. A well-structured answer can acknowledge uncertainty: I would need the expected traffic and data-retention requirements before selecting the storage design. That is not an avoidance; it shows that the decision depends on evidence.
How MySummaries helps
MySummaries lets you build a Software Engineering revision board from your own notes, then practise oral stations generated from that board. You can record answers, review the transcript for vague or incomplete phrases, and compare each response with a structured model covering assumptions, trade-offs, evidence and communication. Flashcards and written questions can reinforce definitions such as idempotency, contract testing and continuous delivery, while the oral practice keeps the focus on explaining engineering decisions aloud.