Opening an email from a major company's HR department can be unnerving when it contains a link to a testβnot to assess your mastery of frameworks or SQL, but a numerical reasoning test. For many, this feels like failing before the interview process has even begun.
But let's be clear right away: numerical tests are not about checking if you can calculate square roots in your head. They test how you work with information under time constraints. And this is a skill you can train.
In this article, we'll break down how to turn the stress of a numerical test into a predictable process. No magic. Just logic, practice, and understanding what exactly they want from you.
HR doesn't want to know how well you get along with fractions. They need to understand something else: how you make decisions when there's a lot of data and very little time.
In a large corporation, every morning starts with dashboards. Charts, graphs, reports β these aren't "decoration," they're the foundation for decisions. Release or postpone? Hire another team or redistribute the workload? These questions are solved based on numbers.
A typical mistake beginners make is trying to solve a problem perfectly and precisely. But the test isn't about perfect accuracy. It's about correctly handling 15-20 tasks in 30-40 minutes. Skipping difficult questions is normal. Getting stuck on one is fatal.
Forget about school examples. Corporate tests don't have abstract "x" and "y." They feature real business situations: sales dynamics, budget allocation, project profitability.
Standard test structure:
β’ Data tables β usually 2-3 tables per group of questions. They can contain absolute numbers, percentages, and different currencies. β’ Graphs and charts β line, bar, pie charts. Often combined, where one graph shows multiple indicators. β’ Questions β calculating shares, growth rates, differences, averages.
The main thing to understand: test creators intentionally add "noise" to the data. The table always has extra rows, extra columns, extra graphs. They are not needed for the answer. The task is to cut out the excess in 10 seconds.
π‘ Advice: Before you start solving, spend 15-20 seconds reviewing the entire group of questions related to one data set. Often, the questions are linked: the answer to the first provides data for the second. By reading all three, you'll save time on re-analyzing the same table.
A numerical test is a sprint, not a marathon. But without a warm-up, you won't be able to give your all.
Two to three weeks before the test, start practicing the mechanics. Don't just "solve as many problems as possible," do it systematically.
π‘ Advice: Don't memorize formulas. The test won't ask you to "calculate the variance." There will be problems with percentages and proportions. The only formula worth remembering is how to calculate one number as a percentage of another. Everything else is logic and a calculator.
You've opened the test. The first group of tasks is in front of you.
Step 1. Identify the question type. There are 4 basic types:
β’ "What is the share of X in Y?" β pure division. β’ "By what percentage did it change?" β formula (new - old) / old * 100. β’ "What was the previous value?" β reverse calculation. β’ "Compare two indicators" β you need to find the difference, not the percentage.
Step 2. Find the necessary data. Don't read the entire table. Scan for: which column is mentioned in the question? Which row? Everything else is irrelevant.
Step 3. Assess the difficulty. If you realize the task requires 3 steps and time is running out, skip it. Mentally mark it and come back if you have time left. It's better to answer 12 out of 15 questions than to get stuck on one and miss 5 easy ones.
Step 4. Check the units of measurement. The question might be in thousands, but the table is in millions. Or in euros, but the answer is needed in dollars. This is the most common source of errors.
The average time per question is 90-120 seconds. How long it actually takes β 60-90 seconds. The rest is a buffer.
What proper timing looks like for a group of 3 questions:
β’ 10 seconds β review all three questions. β’ 60 seconds β solve the first question. β’ 60 seconds β solve the second question (if using data from the first, 40 seconds). β’ 60 seconds β solve the third question. β’ 10 seconds β check: did you mix up the units?
Total: 3 minutes per group. If the group is harder, 3.5 minutes.
π‘ Advice: If the test lasts 30 minutes and there are 20 tasks, that's 1.5 minutes per question. Aim for no more than 2 minutes each. By the 18th minute, you should have solved 12 questions. The rest is for tackling the hard ones. If there are 3 questions left by the 25th minute, just logically eliminate obviously wrong answers and guess randomly. Better that than a blank answer.
Even if you're great at calculations, there are things that trip up professionals.
The table has 5 columns. The question involves columns 2 and 4. A beginner reads columns 1, 2, 3, 4 and gets distracted by column 3, which has "interesting" numbers.
What to do: Immediately find the relevant row and columns with your eyes. The rest doesn't exist.
Question: "If January sales increased by 5%, and then fell by 3% in February, how would they change relative to December?"
Many start calculating: 105% of X, then 97% of the result. This is time-consuming.
Life hack: sequential multiplication of percentages. 1.05 * 0.97 = 1.0185. That's a 1.85% increase. Done. No need to calculate from an unknown number.
The test is running, the timer is ticking. You realize you're not going to make it. You start to rush, re-read the question three times, make mistakes in simple additions.
What to do: At the moment of panic, take a breath and skip the question. Physically click "answer randomly" and move on. Losing one question isn't losing the test. Losing focus is losing everything.
Why go through all this? Why can't you just show your projects?
In large enterprise, decisions are made based on data. When you join as a tester, you will inevitably face situations where you need to:
β’ Estimate how long a regression test will take if 15% new test cases are added. β’ Explain to business why a release will be delayed, using numbers (not "well, there are a lot of bugs," but "43% of critical bugs are not closed, average fix time is 4.2 days, deadline is Friday"). β’ Compare the effectiveness of two automation approaches (one is faster to write, the other is more stable β there are metrics, calculate the ROI).
The career path from tester to test solutions architect is a path from "I checked this test case" to "I built a process that guarantees the quality of the entire product." And at every stage of this path, you will work with numbers.
A manual tester counts how many bugs they found in a week. An automation engineer counts how many test cases their framework covers and how fast they run. A team lead calculates how many resources the team will need next quarter. An architect calculates what infrastructure to build to save 20% of time on each release.
π‘ Advice: Don't view the numerical test as a "admission ticket" you can forget after passing. Treat it as the first workout of a skill you'll use every day. The better you are at it, the easier it will be to present your work to management, justify budgets, and prove the value of your department.
Here are a few specific techniques used by people who successfully pass numerical tests at major companies.
Screenshot the condition. If the test is taken remotely, take a screenshot of the condition. This is usually not prohibited, and it saves you from switching between windows. However, some systems track activity. Check in advance.
Double-click on the number. In some computer-based tests, you can select a number by double-clicking and copy it into the calculator. This is faster than rewriting it. Check this possibility before the test starts.
Estimate the answer without calculating. If the answer options are: 2345, 3456, 7890, 12345 β and you know the result is less than 5000, immediately eliminate 7890 and 12345. You're left with 2 options β a 50% chance of guessing correctly.
Work with percentages using 1%. Instead of complex division: "What is 17% of 340?" β first find 1% (3.4), then multiply by 17. This works faster on built-in calculators.
Don't panic. Numerical tests are not a death sentence. Sometimes:
β’ You didn't get enough sleep. β’ You encountered an unfamiliar format. β’ You were too nervous.
Most large companies allow you to retake the test after 3-6 months. And many candidates who fail the first time pass successfully on the second attempt.
π‘ Advice: If you fail, write down which question you got stuck on, which type of task took the most time. A week later, open a similar test and practice that exact type. In the retake, such tasks will feel automatic.
But there is another strategy: honestly admit that numerical tests are your weak point and compensate for it in the interview. If you demonstrate a deep understanding of testing, architecture, and processes, many companies are willing to overlook a borderline test score. Especially if your experience is clearly strong.
There are many resources for preparation. But here's one secret: use tests in English, even if you'll be taking them in your native language. Translated tests often lose precision in wording, and being used to English conditions gives you an advantage.
Training plan:
β’ First 5 tests β without a timer, for understanding. Analyze every task, understand the logic. β’ Next 5 tests β with a timer, but with extra time (3 minutes per task). β’ Last 5 tests β under conditions as close to real as possible (1.5
