DO-178B and DO-178C V&V Interview Questions, with Answers
What DO-178B and DO-178C actually ask of a verification engineer, then the questions interviewers use, each with an answer you can say out loud.
If you are going for a verification and validation seat on airborne software, the interview is not a trivia round on the letters "DO-178". They want to know whether you can tell a real requirement from a wish, whether a test actually proves that requirement, and what you do when the trace matrix has a hole.
DO-178B and DO-178C are the documents that set that bar for civil airborne software. This guide explains both, then walks through the questions a V&V interviewer actually asks, with an answer and the reason the answer holds. There is a scored quiz at the end. The quiz is practice. The project copy of the standard still wins if a wording detail is in dispute.
What DO-178B and DO-178C are
DO-178C, Software Considerations in Airborne Systems and Equipment Certification, is published by RTCA together with EUROCAE, where the same text is ED-12C. RTCA approved it in December 2011. It became the document people buy and use in January 2012. It replaced DO-178B, which RTCA published in 1992 (ED-12B in Europe).
Neither document is a coding standard and neither is a test procedure you can run on Monday morning. They are a set of objectives for planning, development, verification, configuration management, quality assurance and the conversation with the certification authority. You satisfy an objective with evidence: a review record, an analysis, a test, a trace, a problem report closed for a reason.
The FAA treats DO-178C as an acceptable means of compliance through Advisory Circular 20-115D. EASA points at ED-12C. Older programmes still live on DO-178B because that is what their certification basis says. If an interviewer asks "which one", the honest answer is: the one named in the project's plans and in the certification basis, which for new work is C.
The software level is not chosen inside DO-178. System safety work, commonly guided by ARP4761, classifies failure conditions. System development, commonly guided by ARP4754A, allocates functions to hardware and software and assigns a software level. DO-178C then says which objectives apply.
Software level, from the safety effect
The level is assigned before verification planning. Coverage is what the tests must exercise, not a substitute for requirements.
Public summaries of DO-178C Annex A, including the table reproduced on the DO-178C Wikipedia page from the standard, count the objectives like this:
| Level | Failure condition the safety process is worried about | Objectives | Of which need independence |
|---|---|---|---|
| A | Catastrophic | 71 | 30 |
| B | Hazardous / severe-major | 69 | 18 |
| C | Major | 62 | 5 |
| D | Minor | 26 | 2 |
| E | No safety effect | 0 | 0 |
Memorise the order, not a party trick. Level A is not "more meetings". It is more objectives, more of them done by someone who did not write the item, MC/DC instead of stopping at decision coverage, and a harder look at what the compiler did to the object code. Level E means the software has no safety effect, so these objectives are not applied. Do not invent a failure probability such as 10^-9 and attribute it to DO-178. Those probabilities belong to the system safety assessment. DO-178 does not measure them with tests.
What C changed, in language you can use
DO-178C did not invent levels A to E. Those were already in B. C cleaned up wording, made trace data an explicit life-cycle output, and gave parameter data (configuration values that can change behaviour without a code change) a proper place in verification. Technology that B never really described was moved into supplements, which you use only when that technology is on the project:
- DO-330 for tool qualification
- DO-331 for model-based development and verification
- DO-332 for object-oriented technology
- DO-333 for formal methods
DO-248C is the companion set of clarifications. It is not a second set of objectives. If you quote it, say so.
A line that sounds experienced: "B and C ask for the same kind of evidence. C is clearer about traces, parameter data and modern methods, and the supplements stop people inventing their own rules for models and tools."
What the job actually checks
Verification in this context means showing that the software satisfies its requirements and that the requirements, design and code do not contain behaviour nobody asked for. Validation, in the sense interviewers contrast it with, sits one level up: did we specify the right system behaviour for the aircraft? You will hear both words in Indian avionics teams, often loosely. If they ask you to separate them, use that split. Then go back to their procedure names, because the offer letter will say V&V either way.
The evidence chain looks like this.
Traceability runs both ways
Every box needs a parent and, where testing applies, a test. A box with no parent is a candidate for dead code or a missing requirement.
System requirements
ARP4754A / safety assessment
High-level software requirements
What the software must do
Low-level requirements and architecture
How this build will do it
Source code
Implements the low-level requirements
Requirements-based tests
Normal range and robustness
High-level requirements say what the software must do in the system. Low-level requirements and the architecture say how this design does it. Code implements the low-level requirements. Tests are written from requirements, for the normal range and for robustness: the late message, the out-of-range sensor, the event the state machine should reject.
Traceability is two-way. From a system requirement you should reach the tests that demonstrate it. From a test, or from a piece of code, you should reach the requirement that justifies it. A requirement with no test is unverified. Code with no requirement is either a missing requirement or dead code.
Structural coverage comes after those tests, not instead of them. It answers a different question: did the requirements-based tests actually exercise the code you are about to fly?
- Level C: statement coverage
- Level B: statement and decision coverage
- Level A: statement, decision, and modified condition/decision coverage (MC/DC)
MC/DC means each condition inside a decision has been shown to affect the outcome on its own. For D = A AND (B OR C) you do not need all eight input rows. You need pairs where flipping one condition flips D. One such set is (A, B, C) = TTF, FTF, TFF, TFT. In the room, pick one pair and say which condition it isolates. Reciting the expansion is less convincing than the pair.
Independence means the person confirming the objective is not the person who produced the item, when the table says the objective needs it. At Level A that is a large share of the objectives. It is documented. It is not a feeling that the team is honest.
The plans you will be asked to name:
- PSAC, Plan for Software Aspects of Certification: how this project will meet the objectives, agreed early with the authority or the DER
- SDP, software development plan
- SVP, software verification plan
- SCMP, configuration management plan
- SQAP, quality assurance plan
- SAS, Software Accomplishment Summary: what was done, written late, including open problem reports
- SCI, Software Configuration Index: the exact build, the files, the tools, the versions
PSAC is the promise. SAS is the report card. Candidates swap them constantly.
FAA Order 8110.49 describes four typical stages of involvement. SOI 1 reviews planning once the plans and standards are largely reviewed. SOI 2 reviews development data once a representative portion exists (the order says typically at least half of requirements, design and code). SOI 3 reviews verification data on the same "representative portion" idea. SOI 4 is the final review after the final build, completed verification and a conformity review. The number and depth of reviews depend on the project. Your job in SOI 3 is not to pretend the gaps are gone. It is to show the gap, the cause, and the closure path.
How to prepare
Read your own material before you read another blog. If you have a training record, a review checklist, or even a college project, bring one story with numbers: a requirement id, what the test showed, what failed, what you changed. Interviewers in Bengaluru and Hyderabad hear the same MC/DC definition all week. They remember the person who says "the trace stopped at HLR-14 because the robustness case was never written."
Practise these out loud, in this order.
- Draw the trace chain on paper in under a minute. System requirement, high-level, low-level, code, test. Mark one broken arrow and say what you would file.
- Do one MC/DC pair by hand for a decision you invent. If you freeze, you do not know it yet.
- Explain dead code versus deactivated code with an example, not a definition. Dead code: a debug print nobody required. Deactivated code: an option the build must not enable, with a requirement that says so, and a test or analysis that it stays off.
- Know what you would open in SOI 3: verification plan, test cases and procedures, results, coverage, problem reports, and the trace matrix. Know what "not complete yet" sounds like when it is honest.
- Learn the supplement names only if you have used the technology. Claiming DO-333 experience you do not have collapses at the first follow-up.
A week is enough if you already test software. A week is not enough if Boolean logic and reading a requirement are both new. In that case spend the time on one small module end to end, not on flash cards.
Questions you should be able to answer
What does a verification engineer produce that a developer does not?
Answer. Records that the requirements were reviewed, that tests exist for them, that the tests were run on the configuration you claim, that coverage was analysed, and that problems were written down and closed or justified. Developers produce the requirements, design and code. On many teams they also execute tests. Independence decides who is allowed to be the sole reviewer when the objective demands it.
Why this holds. The interviewer is checking that you do not think V&V means "I run someone else's script and paste a screenshot." The product of the job is evidence tied to an objective.
Where does Level A come from?
Answer. From the failure condition. If unintended behaviour could be catastrophic, the system process assigns Level A, and DO-178C's Level A objectives apply. The verifier does not pick the level to make the schedule easier.
Why this holds. People who say "we decided to do Level B because MC/DC was hard" have skipped the safety assessment. You can describe a change of level only as a system decision, with the authority in the loop.
What is the difference between a review and an analysis?
Answer. A review is a qualitative look: is this requirement precise, is it testable, does it contradict its parent? An analysis computes or inspects something that a reading will not settle: timing, stack, memory, link maps, or whether object code contains decisions the source does not show.
Why this holds. Level A interviews drift here fast. If you call everything a review, you will not know where to put worst-case execution time or a compiler-output check.
Give a robustness case, not a definition.
Answer. A flight-control gain is valid from 0.2 to 2.0. The normal test uses 1.0. The robustness test feeds 2.5, or a stale sample, or a NaN if that can appear on the bus, and checks the requirement that says what the software must do: hold last value, set a fault, or command a safe gain. The pass condition is the requirement, not "it did not crash" unless the requirement says that.
Why this holds. "Robustness means negative testing" is too thin. Tie the input to a required reaction.
Coverage is 100 percent and three requirements have no tests. Are you done?
Answer. No. Coverage means the tests that exist reached every statement or decision you measured. It does not create missing tests. Those three requirements are open. If the uncovered direction had been the problem, you would add tests or justify the gap. Here the matrix is the defect.
Why this holds. This is the question that separates people who have closed a coverage report from people who have only seen the percentage.
The compiler emitted a decision the source does not show. Level A. What now?
Answer. You do not ignore it because source MC/DC was green. Level A expects you to look at object code that is not traceable to source, and to verify that extra structure. Sometimes that is more testing, sometimes analysis of what the compiler did, documented. The coding standard and compiler version belong in the configuration index so this analysis stays valid for the build you certify.
Why this holds. Candidates who stop at source coverage have learned the acronym and missed the objective behind it.
When does a coverage tool need qualification?
Answer. When you trust its output to claim an objective, and a bug in the tool could hide a failure to meet that objective. That is a verification tool. DO-178C sends you to DO-330 for the qualification level. An autocode generator is heavier: its output is in the airborne software, so it can insert an error, not only miss one. If a human reviews every coverage hole anyway, say that, because the qualification need follows from how you use the tool, not from the logo on the installer.
Why this holds. "We qualify all tools" and "we never qualify tools" are both wrong. Use decides it.
What is data coupling, in one project example?
Answer. Two units share a global mode flag. Unit A writes it. Unit B branches on it. Data coupling is that shared data. Control coupling is A changing whether B's branch runs. At the higher levels you show that some requirements-based integration test actually writes the flag and takes the branch. A unit test that stubs the flag never set it from A, so it does not close coupling.
Why this holds. Interviewers use this to see if your "100 percent coverage" was ten isolated files.
Dead code showed up in the coverage report. What do you do before SOI 4?
Answer. Confirm it is dead and not deactivated. If no requirement wants it, raise a problem report, remove it under configuration control, and repeat the tests and coverage that the change affects. If it is an intended build option, it needs requirements and evidence that this configuration cannot execute it. You do not delete it in the meeting with no record, and you do not leave it because the schedule is close.
Why this holds. SOI 4 is late for surprises. The accomplishment summary will list unresolved problems. "We will remove it after certification" is not a closure.
The model is the requirement. Do you agree?
Answer. Not automatically. Under DO-331, a model can be a requirement or a design, but only if the plans say which, and the model is reviewed with the same kind of objectives as text at that level: precision, traceability, and tests that are not just a replay of the model against itself. Simulation that only shows the model matches the model is not verification of the software.
Why this holds. Model-based teams often skip this. If you have not used models, say so, then give the principle. Do not invent a SCADE or Simulink project.
A short list of wrong answers
Do not say the software level is chosen by the test team. Do not say MC/DC means every input combination. Do not say a PSAC is written after the tests. Do not say independence means developers are not allowed to test. Do not quote 71 objectives as if you counted Annex A yourself unless you have. It is fine to say "the published annex totals are 71, 69, 62 and 26 for A through D, with none at E" and that you would confirm a disputed cell in the project's copy.
If you want the hiring context around tools and certificates more generally, the AI certifications guide is a different interview. This one is about evidence, not about a badge.
Practice quiz
Use this after you can explain the trace diagram without looking. The pool has 36 questions in three quizzes. You pick your years and how you work today, and the matching set opens first. Each finished round shows the score, every miss, the right choice, and why. You can then take the other two sets.
There are three quizzes and 36 questions in the pool. Your years and how you work today pick the set that matches. You can take the other sets after.
Sources
Objective totals and independence counts are the Annex A summary widely published from DO-178C, including the table on the DO-178C page. Confirm any single cell against the standard your employer holds. DO-178C itself is sold by RTCA and EUROCAE. This article does not reproduce it.
- FAA Advisory Circular 20-115D, acceptance of DO-178C and ED-12C
- FAA Order 8110.49, software approval guidelines, including the four stages of involvement
- RTCA DO-178C overview, dates, levels, supplements DO-330, DO-331, DO-332, DO-333
- ARP4754A and ARP4761 for system development and safety assessment, which assign the software level DO-178C then uses
Frequently Asked Questions
Both are RTCA and EUROCAE guidance for airborne software assurance. DO-178B was published in 1992. DO-178C was approved in December 2011 and is the one new projects use. C keeps software levels A to E and adds supplements for tool qualification, model-based development, object-oriented technology and formal methods.
Requirements-based tests plus statement coverage, decision coverage and modified condition/decision coverage. Level B stops at decision coverage. Level C stops at statement coverage. Coverage does not replace the tests against requirements.
The Plan for Software Aspects of Certification. It is the early agreement with the certification authority on how this project will meet the objectives. The Software Accomplishment Summary comes later and records what was actually done.
Not the verification engineer. The system safety assessment and the system development process assign the software level from the failure condition. DO-178C then sets the objectives for that level.
No. Structural coverage shows the tests reached the code. Requirements that have no tests are still open, and code that traces to nothing is a separate problem.
Writes on career readiness and AI skills for Indian students and early-career professionals. Every guide is fact-checked against primary sources before publishing.