k6 interview questions and answers

A VU is a concurrent worker running your default function in a loop; an iteration is one completed pass through that function. VUs describe concurrency, iterations describe volume of work. You can hold VUs constant and let iterations fall out of it, or drive iterations directly with a shared-iterations or per-VU-iterations executor when you care about completing a fixed amount of work rather than sustaining a fixed concurrency.

What they are really asking: Tests whether you think in terms of arrival rate or concurrency. Mentioning the constant-arrival-rate executor here is a strong signal.

Getting started with k6

A check is a per-request assertion that records a pass or fail and does *not* fail the run — useful for measuring how often something is true. A threshold is a pass criterion on a metric across the whole run, and it does set the exit code. So checks tell you what happened; thresholds decide whether the build goes red. If you want CI to fail on p95 above 800 ms, that is a threshold, not a check.

What they are really asking: A frequent source of confusion and a very good discriminator. Candidates who have only run k6 locally often do not realise checks alone never fail a pipeline.

A load test holds the expected peak and asks whether the system meets its targets there. A stress test pushes past the expected peak until something gives, to find where the limit is and how the system behaves when it is crossed — degrading politely or falling over. A soak test holds a modest, realistic load for hours, looking for the things that only appear with time: memory leaks, connection pools that never return, log volumes, database bloat. Different questions, so different durations and different pass criteria.

What they are really asking: Whether you pick a test type from the question being asked, or run "a load test" by reflex. Say what each one would *tell* you and most interviewers stop there.

The average hides the tail, and the tail is what users complain about. A run averaging 200 ms can be 95% of requests at 90 ms and 5% at 2.3 seconds — the average looks healthy and one user in twenty is having a bad time. Percentiles describe the distribution: p90, p95 and p99 tell you what the slowest slice actually experienced. Quote the percentile alongside the load it was measured at, because a p95 with no context is a number, not a result.

What they are really asking: The follow-up is usually "so which percentile should we use?" There is no universal answer, and saying p95 with confidence is a worse answer than asking what the SLA says.

Writing performance requirements that can be tested

Concurrency = throughput x response time. If you need 50 requests per second and each takes 400 ms, you need about 20 concurrent users to generate it. It is the arithmetic that connects a business target ("2,000 orders an hour") to a load model ("this many virtual users with this think time"). It also catches nonsense early: if your target throughput and your measured response time imply 4,000 concurrent users and you planned for 50, one of those numbers is wrong.

What they are really asking: Whether you can derive a load model rather than guessing a thread count. Being able to do the sum out loud is worth more than naming the law.

Free load model calculator

Think time is the pause a real user takes between actions — reading a page, filling a form. Without it, virtual users hammer the system in a tight loop and you measure something no human would ever do: far higher throughput from far fewer users. Adding realistic think time changes the concurrency you need to hit a given throughput, which is why load models built without it are usually wrong in both directions at once.

What they are really asking: A common trap question. If you say "it makes the test realistic" and stop, expect "realistic how?" — the concrete answer is that it decouples user count from throughput.

A number, a condition, and a scope. "The site must be fast" is not testable. "The checkout page returns in under 1.5 seconds at p95, with 500 concurrent users, over a 30-minute steady state" is: it names the transaction, the statistic, the threshold, the load and the duration. If any of those is missing you cannot write a pass criterion, and you will end up in a meeting arguing about whether the result was good.

What they are really asking: Really asking whether you push back on vague requirements or quietly invent your own and hope nobody notices at report time.

Questions to ask before a performance test

Start small and gate on something you trust. A short smoke-level run on every merge that fails on error rate and an obviously-wrong p95 catches the crude regressions without adding twenty minutes to every build. Keep the full load test on a schedule or a manual trigger, because it needs a stable environment and realistic data. The hard part is not running the tool in CI — it is having a threshold that fails only when something is genuinely wrong, or people will start ignoring it.

What they are really asking: They are listening for whether you have dealt with flaky gates. "We failed the build on p95 and everyone disabled it within a month" is a good, honest story to have.

Performance tests in GitHub Actions

Unique where uniqueness is enforced, realistic in shape and volume, and disposable. Reusing one login across 500 threads tests your cache, not your system. Data also has to match production distribution: a table with 100 rows behaves nothing like one with 10 million, and an index that looks fine on the small one will not be. Plan how it gets reset between runs too, because a test that only passes the first time is not a test.

What they are really asking: Follow-up is usually about production data. The correct instinct is that copying real user data into a test environment is a GDPR problem, not a convenience.

Test data for performance testing