Question 1
Difficulty: medium
How do you determine the right performance testing strategy for a new application or feature?
Sample answer
I start by understanding the business goal behind the release, because that usually tells me what “good performance” means in context. For example, a checkout flow needs low latency and high reliability, while a reporting tool may care more about throughput and data consistency. I work with product, engineering, and operations to identify critical user journeys, expected traffic patterns, peak load, and any non-functional requirements. From there, I define the test types we need, such as baseline, load, stress, spike, soak, or scalability testing. I also make sure the environment, test data, and monitoring are realistic enough to produce usable results. If the application is new, I usually start with a smaller baseline and then build a risk-based plan that focuses on the most business-critical components first. My goal is always to find issues early and provide clear, actionable results rather than just numbers.
Question 2
Difficulty: medium
Describe your process for creating a realistic performance test script.
Sample answer
When I build a performance test script, I focus on realism first and convenience second. I begin by studying actual user journeys, API contracts, and production or staging logs if they are available. That helps me model the sequence of requests, think times, parameterization needs, and data dependencies accurately. I avoid hardcoding values and instead use correlation, dynamic data, and reusable functions so the script behaves like real traffic. I also validate that the script is clean and stable under low load before scaling it up, because a broken script can hide real bottlenecks. If the application has different user types, I create separate flows for each one rather than forcing everything into a single generic script. Once the script is ready, I check that the response validations are meaningful, not overly strict, so the test catches real failures without creating noise. A good script should reflect how people actually use the system, not just how the tool can execute requests.
Question 3
Difficulty: easy
What metrics do you pay closest attention to during a load test, and why?
Sample answer
I look at metrics in layers. On the user side, I focus on response time percentiles, throughput, error rate, and concurrency because those tell me whether the system is meeting the experience expectations. I pay special attention to p95 and p99 latency instead of only averages, since averages can hide serious tail-latency issues. On the infrastructure side, I watch CPU, memory, disk I/O, network usage, thread pools, garbage collection, database connections, and queue depth, depending on the architecture. I also look for saturation points and whether metrics change gradually or suddenly, because that often indicates different classes of bottlenecks. For example, a steady rise in latency with stable throughput may suggest resource contention, while a sudden spike in errors might point to connection limits or rate limiting. I always compare the metrics to the user journey being tested so I can connect the numbers to business impact. The goal is not just to collect data, but to understand what is driving performance behavior.
Question 4
Difficulty: medium
Tell me about a time you found a performance bottleneck. How did you identify and resolve it?
Sample answer
In one project, we saw acceptable average response times during early testing, but the p95 latency climbed sharply as we approached expected peak traffic. I started by breaking down the transaction timing and correlating it with application and database metrics. That showed the application tier was not the primary issue; the database connection pool was being exhausted during bursts, which forced requests to wait. I worked with the developers to review connection usage, and we found a few queries were holding connections longer than necessary because of inefficient transaction handling. We also discovered the pool size was configured too conservatively for the actual workload. After the team optimized the query flow and adjusted the pool settings, we reran the test and saw much more stable latency under load. What I learned from that experience is that the bottleneck is often not where the symptom appears first. A structured approach and good observability are essential for finding the real cause rather than guessing.
Question 5
Difficulty: medium
How do you handle a situation where development says the performance issue is caused by the test environment, but you believe the application is the problem?
Sample answer
I handle that by staying factual and collaborative, not defensive. First, I verify the environment as thoroughly as possible: infrastructure sizing, configuration differences, data volume, network conditions, monitoring gaps, and whether the test setup mirrors production closely enough. If the environment checks out, I present evidence in a clear way, such as comparisons between baseline and stressed runs, resource saturation graphs, and request-level timing breakdowns. I also try to reproduce the issue with smaller experiments, because that often helps isolate whether the bottleneck is environmental or code-related. If there is still disagreement, I suggest a joint review with developers, ops, and myself looking at the same data together. I have found that most disagreements disappear once the team sees objective evidence. My priority is not to “win” the argument; it is to identify the real constraint and help the team fix it quickly. That mindset keeps the conversation productive and focused on the end user.
Question 6
Difficulty: easy
Which performance testing tools have you used, and how do you choose the right one for a project?
Sample answer
I have worked with tools such as JMeter, Gatling, and LoadRunner, and I have also used monitoring and log analysis tools alongside them. I choose a tool based on the system architecture, team skills, reporting needs, and how complex the test flows are. For example, if the project needs fast scripting, good code-based maintainability, and a lot of automated execution, I may prefer a tool like Gatling. If the team already knows JMeter and needs broad protocol support and flexible plugins, that can be the better choice. For enterprise environments with strong reporting and protocol coverage needs, LoadRunner can still be very useful. I also consider integration with CI/CD, version control, and observability platforms, because the test tool should fit into the delivery process rather than sit outside it. In practice, I try to recommend the simplest tool that can meet the requirements reliably and be maintained by the team over time.
Question 7
Difficulty: medium
How do you decide when a performance test result is good enough to sign off a release?
Sample answer
I do not look at a result in isolation; I compare it against the agreed acceptance criteria, baseline performance, and business risk. If the release meets response time, throughput, and error-rate targets under realistic load, that is a strong sign. But I also check whether the system behaves consistently, whether resource usage remains stable, and whether there are signs of approaching saturation that could cause trouble as traffic grows. If the test reveals a problem in a non-critical area, I weigh the user impact and whether there is a viable mitigation plan. I also consider whether the workload used in testing reflects actual usage, because passing an unrealistic test is not meaningful. When I recommend sign-off, I explain the evidence clearly, the assumptions behind it, and any known limitations. I want stakeholders to understand the level of confidence they are getting. In my view, sign-off is not about pretending risk is zero; it is about showing the system is ready for the expected demand with known and acceptable risk.
Question 8
Difficulty: hard
How do you approach performance testing in a CI/CD pipeline?
Sample answer
I approach CI/CD performance testing by keeping the feedback loop fast and meaningful. Not every performance test belongs in every pipeline stage, so I separate lightweight checks from heavier load tests. For example, I like to run basic response-time thresholds, API smoke performance checks, and regression indicators early in the pipeline to catch obvious issues quickly. Then, for larger load or endurance tests, I schedule them in nightly runs or pre-release gates where longer execution time is acceptable. I also make sure test scripts are versioned with the application code and that the results are easy to interpret automatically, ideally with trend tracking over time. Another important piece is test data and environment stability, because a flaky pipeline can waste everyone’s time. I work with DevOps and developers to define alert thresholds that catch real regressions without creating too much noise. The overall aim is to make performance a regular part of delivery, not a last-minute validation step.
Question 9
Difficulty: easy
Describe a time when you had to explain complex performance findings to non-technical stakeholders.
Sample answer
I once had to present test results to product and business leaders after a new feature slowed down a key customer workflow. Rather than starting with graphs and jargon, I framed the issue in terms of user impact: how many extra seconds customers would wait, where they would feel the delay, and what business risk that created during peak periods. Then I showed a simple visual comparing the baseline and new release, highlighting the points where latency increased and where the system began to saturate. I kept the technical detail in the backup so I could answer questions without overwhelming the room. I also explained the options in practical terms: optimize the feature now, reduce scope, or accept the risk temporarily with monitoring and a fix plan. That approach helped the stakeholders make a decision quickly because they understood both the evidence and the tradeoffs. I have learned that good communication in performance testing is about translating technical results into decisions people can act on confidently.
Question 10
Difficulty: hard
What would you do if a performance test failed the night before a release is scheduled?
Sample answer
I would first confirm the failure is real and not caused by a broken environment, data issue, or script defect. If the failure is valid, I would triage quickly to understand whether it is a regression, a capacity problem, or a known issue that has worsened. Then I would assess the scope: is the issue affecting a critical user path or only a limited scenario? I would share a concise summary with engineering, product, and release stakeholders as soon as I had enough evidence to be useful. My recommendation would depend on the severity and the release risk. If it is a major issue on a core flow, I would strongly advise against releasing until there is a mitigation or fix. If the issue is contained and there is a safe workaround, I would document the risk clearly and suggest additional monitoring or a rollback plan. In a situation like that, calm communication and fast, evidence-based triage matter more than trying to be perfect on the first pass.
