GitHub Actions Matrix Strategy - Test Across Versions

A CI pipeline that tests three Node versions sequentially can take 45 minutes when it should take a fraction of that. Interviewers bring up GitHub Actions matrix strategy because it's a quick way to check if you actually optimize build times or just let pipelines run slow.

The answer interviewers want

Matrix strategy runs the same job across different combinations of variables in parallel instead of sequentially. If you're testing Node 16, 18, and 20 one after another, that's three full job runs stacked up. With a matrix, all three run at the same time on separate runners.

In your workflow YAML, you define a matrix under strategy with a node-version array, something like:

strategy:
  matrix:
    node-version: [16, 18, 20]

GitHub Actions automatically spins up a separate runner for each value in that array. You can extend this beyond language versions. Add an os array with values like ubuntu-latest and windows-latest to get cross-platform testing, and the matrix expands to cover every combination of the two dimensions.

Two details matter here that people skip. First, set fail-fast: false. By default, GitHub Actions cancels all other matrix jobs the moment one of them fails, which defeats the purpose if you want to see results across every version. Second, use exclude to remove specific combinations that don't make sense for your project, for example if a given Node version doesn't need to be tested on Windows at all.

Why interviewers ask this

This question separates people who've only run single-job pipelines from people who've actually had to speed up a slow CI setup under pressure. It's also a proxy for whether you think about pipeline cost and signal quality, not just getting tests to pass eventually.

Follow-ups to expect

What happens if you don't set fail-fast: false? By default, the first failing combination cancels every other job in the matrix, so you lose visibility into whether the failure is version-specific or a real cross-cutting bug.

How do you handle a combination that doesn't apply to your project? Use exclude in the matrix definition to drop that specific combination rather than letting it run and fail or skip unnecessarily.

How does adding an os array change the matrix? It multiplies out every OS value against every existing dimension like node-version, so you get a runner for each full combination, which is also why unnecessary combinations should be excluded to control runner count.

The common wrong answer

Most candidates describe the matrix as just "a way to run tests on multiple versions" without mentioning that it parallelizes them, and that's the whole point interviewers are listening for. The other common gap is not knowing about fail-fast: false. Candidates who've only read the docs once tend to assume the matrix always runs every job to completion, and get caught off guard when asked why their pipeline stopped reporting results for some versions after one failed.