The real EPA Section 608 technician exam is four separate tests stapled together: Core, Type I, Type II and Type III, 25 questions each. Each section is graded on its own. You need 18 of 25 (72%) on a section to pass it. What certification you walk away with depends on which sections you passed, not on your overall percentage.

So a candidate can score 92 out of 100 and still not be Universal certified. Another can score 76 out of 100 and be Universal. If your practice test only shows the total, the first person thinks they're done and the second thinks they're in trouble. Both are wrong.

This post builds the scoring function I wish I'd written first: it takes a list of questions and a set of responses, and it returns per-section results plus the certification those results actually earn.

The rules we need to encode

Stripped down to what matters for code:

1. Four sections: Core, Type I, Type II, Type III.
2. A section passes at 18 correct out of 25.
3. Core is a prerequisite. Passing Type II without Core earns nothing.
4. Core + Type I = Type I certified. Core + Type II = Type II. Core + Type III = Type III. Any combination is possible.
5. Core + all three types = Universal.

Two extra cases show up in practice software that don't exist on the real exam:

• Short practice sets. Users often drill 10 or 20 questions from one section. "18 correct" doesn't make sense for a 10-question set, so the pass mark has to scale.
• Sections that weren't attempted. A Type II-only drill has zero Type I questions. That section is "not attempted," not "failed."

Data shape

Each question carries its section. Responses are a map from question id to the option the user picked.

const question = { id: 'TYPE2_015', section: 'Type II', answer: '0 inches Hg', options: [/* ... */] };

const responses = { TYPE2_015: '0 inches Hg', CORE_003: 'Two' };

Comparing by option text instead of option index matters here, and I'll come back to why at the end.

The scoring function

const SECTIONS = ['Core', 'Type I', 'Type II', 'Type III'];
const PASS_CORRECT = 18; // out of 25 per section

function scoreExam(questions, responses) {
  const bySection = Object.fromEntries(
    SECTIONS.map(s => [s, { correct: 0, total: 0, missed: [] }])
  );

  for (const q of questions) {
    const bucket = bySection[q.section];
    if (!bucket) throw new Error(`Unknown section "${q.section}" on ${q.id}`);
    bucket.total++;
    if (responses[q.id] === q.answer) bucket.correct++;
    else bucket.missed.push(q.id);
  }

  for (const s of SECTIONS) {
    const b = bySection[s];
    b.attempted = b.total > 0;
    b.passed = b.attempted && b.correct >= passMark(b.total);
  }

  return { bySection, certification: certificationFor(bySection) };
}

// 18/25 scaled for practice sets that are not exactly 25 questions
function passMark(total) {
  return Math.ceil(total * PASS_CORRECT / 25);
}

A few decisions worth calling out:

Unknown sections throw. It's tempting to silently skip a question with section: 'Type 2' or section: 'TypeII'. Don't. A typo in the data would quietly shrink a section to 24 questions and shift the pass mark. Failing loudly during development is cheaper than a wrong "PASS" shown to someone who is about to pay for the real exam.

Unanswered questions count as wrong. responses[q.id] is undefined for a skipped question, which never equals the answer. That matches the real exam: a blank is a miss.

passMark uses Math.ceil. For 25 questions it returns exactly 18. For a 10-question drill it returns 8 (7.2 rounded up), and for 20 it returns 15 (14.4 rounded up). Rounding up keeps the practice bar at or slightly above 72%, never below it. If you round to nearest, a 10-question set would pass at 7/10 = 70%, which is softer than the real thing.

Turning sections into a certification

function certificationFor(bySection) {
  if (!bySection.Core.passed) return 'None (Core not passed)';
  const types = ['Type I', 'Type II', 'Type III'].filter(t => bySection[t].passed);
  if (types.length === 3) return 'Universal';
  if (types.length === 0) return 'None yet (Core passed, no type passed)';
  return types.join(' + ');
}

The Core check comes first and short-circuits everything. That's the rule people forget most often, both test-takers and developers. I've seen practice apps that report "Type II: PASS" in green when Core failed, which is technically true for the section and completely false for the certificate.

Tests that encode the edge cases

The tests are the actual spec here. Each one is a situation a real candidate ends up in.

const assert = require('assert');
const make = (section, n) => Array.from({ length: n }, (_, i) =>
  ({ id: `${section}-${i}`, section, answer: 'ok' }));
const exam = SECTIONS.flatMap(s => make(s, 25));
const answerFirst = (section, k) => Object.fromEntries(
  exam.filter(q => q.section === section).slice(0, k).map(q => [q.id, 'ok']));

// 92 / 100 overall, but Type III only 17/25
const r1 = { ...answerFirst('Core', 25), ...answerFirst('Type I', 25),
             ...answerFirst('Type II', 25), ...answerFirst('Type III', 17) };
assert.strictEqual(scoreExam(exam, r1).certification, 'Type I + Type II');

// 76 / 100 overall, every section exactly 19
const r2 = Object.assign({}, ...SECTIONS.map(s => answerFirst(s, 19)));
assert.strictEqual(scoreExam(exam, r2).certification, 'Universal');

// Core fails at 17 -> nothing else counts
const r3 = { ...answerFirst('Core', 17), ...answerFirst('Type II', 25) };
assert.strictEqual(scoreExam(exam, r3).certification, 'None (Core not passed)');

assert.strictEqual(passMark(25), 18);
assert.strictEqual(passMark(10), 8);
assert.strictEqual(passMark(20), 15);

The first two cases are the ones from the intro. 92% overall misses Universal by a single question in Type III. 76% overall gets Universal because it clears every section. If your result screen can't express that, it's teaching the wrong lesson.

The third case is the "Core gatekeeper" rule: a perfect Type II section is worth nothing until Core passes.

Rendering the result

Once you have per-section data, the result screen almost writes itself. The one design choice I'd push for: show the margin, not just pass/fail.

function describeSection(name, b) {
  if (!b.attempted) return `${name}: not attempted`;
  const need = passMark(b.total);
  const margin = b.correct - need;
  const status = b.passed ? 'PASS' : 'FAIL';
  const note = margin === 0 ? ' (no room to spare)'
    : margin > 0 ? ` (${margin} above the line)`
    : ` (${-margin} short)`;
  return `${name}: ${b.correct}/${b.total} ${status}${note}`;
}

Core: 21/25 PASS (3 above the line)
Type I: 18/25 PASS (no room to spare)
Type II: 16/25 FAIL (2 short)
Type III: not attempted
Certification: Type I

"18/25 PASS" and "25/25 PASS" are very different states for someone deciding whether to book the exam. A candidate sitting exactly on the line passes this practice set and fails the real one on a bad day. Showing the margin makes that visible without any extra explanation.

Why responses store option text, not index

Back to the data shape. It's common to store a response as 2 ("the user picked the third option"). That breaks the moment you shuffle answer options per attempt, which you should do. Otherwise people learn that the answer to the recovery-cylinder question is "the second one" instead of learning the 80% fill rule.

If options are shuffled at render time, index 2 means something different on every attempt, and old responses in storage or analytics become meaningless. Storing the option text (or a stable option id) keeps scoring independent of display order. Compare responses[q.id] === q.answer and the shuffle can do whatever it wants.

Things this doesn't model (on purpose)

• Retakes. Certifying organizations generally let you retake only the sections you failed, but the details vary by organization and proctoring method. I keep that out of the scoring function and in the UI copy, with a pointer to the certifying organization's own rules.
• Type I open-book variants. Some organizations offer Type I under different conditions. Same answer: don't hard-code what you can't keep up to date.
• Time limits. Scoring and timing are separate concerns. A timer that expires should just stop collecting responses; this function scores whatever it receives.

Wrap-up

Everything here fits in about 50 lines, and it's the difference between an EPA 608 practice test that tells people where they really stand and one that gives them a comforting number. If you're building any exam simulator, the same pattern applies: find out how the real exam is actually graded, model that first, and treat the overall percentage as a footnote.

The full file with the tests is runnable with plain node score.js, no dependencies.

I ran it on the question bank behind our EPA 608 practice test, the one HVAC technicians use to prepare for the federal refrigerant handling certification. The result:

  A:   31  (13.7%)
  B:  134  (59.0%)
  C:   52  (22.9%)
  D:   10  (4.4%)
Chi-square vs uniform: 155.7 (df=3, 7.81 is the p=0.05 cutoff)
Correct answer is the longest option: 67.0%
"All of the above" correct: 4/4

Fifty-nine percent of correct answers were in position B. Correct answers were in position D less than one time in twenty. And in two out of three questions, the right answer was simply the longest option.

Then I ran it on our full-length mock exam file:

  A:  100  (100.0%)
  B:    0  (0.0%)
  C:    0  (0.0%)
  D:    0  (0.0%)
Chi-square vs uniform: 300.0 (df=3, 7.81 is the p=0.05 cutoff)
Correct answer is the longest option: 79.0%

Every single correct answer was option A.

This post covers the audit script, why it happened, and the fix. If you build any kind of quiz, exam prep or e-learning product, check your bank before you read the rest.

Why this happens

Nobody sat down and decided "make the answer B." Question authors have habits:

• Type the correct answer first, then come up with distractors. If nothing reorders them, the answer is always A. That's what happened to the mock exam file.
• Avoid putting the answer first because it "feels too easy," and drift toward B or C instead. That's a well-known human tendency when people try to place answers "randomly."
• Write the correct answer carefully and the distractors quickly. Correct answers come out longer, more specific and more hedged ("90% of the refrigerant or 4 inches of vacuum"), and distractors come out short ("50%").

None of this matters if the app shuffles options when it displays them. Ours shuffled the question order but rendered the options in the order they were stored. So the authors' habits went straight to the user's screen.

Why it matters for a practice test specifically

A biased practice test doesn't just leak points. It teaches the wrong skill.

A candidate who takes enough of those practice tests will, without ever noticing, learn "when in doubt, pick B" or "pick the long one." Their practice scores go up. Then they sit the real EPA 608 exam, which is written and checked by a certifying organization, and the trick stops working. Each section is pass/fail at 18 of 25, so a couple of points of fake confidence per section is exactly the margin that decides the result.

A practice score is only useful if it predicts the real score. Bias breaks that.

The audit script

The bank is a JSON array of questions. Each question has options and an answer that matches one option's text:

{ "id": "TYPE1_004", "options": ["...", "...", "...", "..."], "answer": "90% of the refrigerant or 4 inches of vacuum" }

// audit.js: node audit.js bank.json
const fs = require('fs');

const bank = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
const LETTERS = ['A', 'B', 'C', 'D'];

const positionCounts = [0, 0, 0, 0];
let longestIsCorrect = 0;
let aotaCorrect = 0, aotaTotal = 0;

for (const q of bank) {
  const idx = q.options.indexOf(q.answer);
  if (idx === -1) throw new Error(`${q.id}: answer not found in options`);
  positionCounts[idx]++;

  const lengths = q.options.map(o => o.length);
  if (q.answer.length === Math.max(...lengths)) longestIsCorrect++;

  if (q.options.some(o => /all of the above/i.test(o))) {
    aotaTotal++;
    if (/all of the above/i.test(q.answer)) aotaCorrect++;
  }
}

const n = bank.length;
const expected = n / 4;
const chiSquare = positionCounts.reduce((sum, obs) => sum + (obs - expected) ** 2 / expected, 0);

console.log(`Questions: ${n}`);
positionCounts.forEach((c, i) =>
  console.log(`  ${LETTERS[i]}: ${String(c).padStart(4)}  (${(100 * c / n).toFixed(1)}%)`));
console.log(`Chi-square vs uniform: ${chiSquare.toFixed(1)} (df=3, 7.81 is the p=0.05 cutoff)`);
console.log(`Correct answer is the longest option: ${(100 * longestIsCorrect / n).toFixed(1)}%`);
console.log(`"All of the above" correct: ${aotaCorrect}/${aotaTotal}`);

Three checks:

Position distribution with a chi-square test. With four options, each position should hold about 25% of correct answers. The chi-square statistic measures how far the observed counts are from that. With 3 degrees of freedom, anything above 7.81 means "this would happen by chance less than 5% of the time." We were at 155.7, which is not a borderline result.

You don't need a stats library. The statistic is one reduce, and the critical value for df = 3 is a constant you can hard-code.

Longest-option rate. If length carried no information, the correct answer would be the longest option roughly a quarter of the time, a bit more once you count ties. 67% means length is a strong clue.

"All of the above." In our bank, every question that offered "All of the above" had it as the correct answer. Small sample, but candidates notice patterns like that quickly.

The fix, part 1: a real shuffle

The obvious fix is to shuffle options at render time. The obvious implementation is wrong:

options.sort(() => Math.random() - 0.5); // don't

A comparator that returns random results breaks the assumptions of the sort algorithm, and the resulting permutations aren't uniform. How biased they are depends on the engine and its sort implementation. I measured it on Node 22 by shuffling ['A','B','C','D'] 100,000 times and recording where A ended up:

sort(() => Math.random() - 0.5): 36.2%  17.0%  15.6%  31.3%
Fisher-Yates:                     25.0%  25.1%  24.9%  25.0%

With the sort trick, the first option still lands in position A more than a third of the time. On a bank where the answer was authored first, that's leaving a lot of the bias in place.

Fisher-Yates is five lines and provably uniform:

// Fisher-Yates: every permutation equally likely
function shuffle(array, rng = Math.random) {
  const a = array.slice();
  for (let i = a.length - 1; i > 0; i--) {
    const j = Math.floor(rng() * (i + 1));
    [a[i], a[j]] = [a[j], a[i]];
  }
  return a;
}

The rng parameter lets you pass a seeded generator in tests, so a shuffled exam can be reproduced exactly.

The fix, part 2: pin the options that refer to other options

You can't shuffle "All of the above" into position A. It stops making sense. Same for "Both A and B" and "None of the above." Those get pinned to the end, and only the rest are shuffled:

const PINNED = /^(all|none|both) of the above$|^(a|b) and (b|c)$|^(a|b), (b|c),? and (c|d)$/i;

function shuffleOptions(question, rng = Math.random) {
  const pinned = question.options.filter(o => PINNED.test(o.trim()));
  const free = question.options.filter(o => !PINNED.test(o.trim()));
  return { ...question, options: [...shuffle(free, rng), ...pinned] };
}

Options like "A and B" are the worst case: after a shuffle, the letters point at different options. Pinning keeps the option in place, but the letters inside it are still wrong. The real fix is to rewrite those questions so options don't refer to each other by letter. The audit is a good moment to find them.

The fix, part 3: compare answers by text

If the app records "the user picked index 2," shuffling breaks scoring. Index 2 means something different on every attempt. Our bank already stored the answer as option text, so scoring is selected === question.answer no matter what order the options appeared in. If yours stores indices, migrate to text or stable option ids before you turn on shuffling, or historical results become meaningless.

What shuffling doesn't fix

Shuffling removes position bias completely. It does nothing for the longest-answer bias or the "All of the above" pattern. Those are in the content, and only editing fixes them:

• Rewrite distractors so they're as specific as the correct answer. "50% of the refrigerant" next to "90% of the refrigerant or 4 inches of vacuum" gives it away. "80% of the refrigerant or 4 inches of vacuum" doesn't.
• Make sure "All of the above" is sometimes wrong, or remove it.
• Re-run the audit after each batch of edits and watch the longest-option rate fall toward 25 to 30%.

I'd add the audit to CI with a threshold, for example fail if the chi-square for authored positions exceeds the cutoff on newly added questions, or if the longest-option rate for a section goes above 40%. That catches regressions when someone adds a batch of new questions next quarter.

The takeaway

Shuffle the questions and the options, with a real shuffle. Then audit what shuffling can't fix. It takes an afternoon, and it's the difference between an EPA 608 practice test that measures what someone knows and one that measures how well they've learned the author's habits.

Our app was shuffling questions the whole time and still sending a 59% B / 100% A pattern straight to users. That's the scary part about this kind of bug: nobody files a bug report about getting answers right.