Pseudocode Questions in Placement Tests: A Tracing Method

By Pooja Goenka · Published 2026-11-02 · Updated 2026-11-12

To solve a pseudocode question in a placement test, do not try to "see" the answer. Trace it: write every variable as a column, run the program one line at a time, and update only the column that changes. A trace table turns a guessing problem into a copying problem, and that is the whole method.

Pseudocode sections are reported in several fresher tests. One Infosys guide on Weekday describes sample items such as a loop that adds to a variable, an expression mixing modulo and integer division, and a loop that steps by 3, and it advises tracing on paper line by line (checked 2 Nov 2026). It is a third-party source, not an official Infosys document, so check the current pattern for your own drive. The method below works whatever the exact format is.

What a pseudocode question really tests

You are not asked to write code. You are shown a short program in plain, language-neutral style and asked what it prints or returns. The test is whether you can be a careful computer for two minutes.

That is why people who code well still lose marks here. They read the program like a story, skip steps they think they understand, and carry a value in their head that quietly changed three lines ago. A computer never skips a step. Neither should you.

The four-step method

Computing teachers call this a trace table, and the process is also called a dry run. The 101 Computing site describes it as a technique to "predict step by step how the computer will run the algorithm", built with one column per variable plus columns for conditions and output (101 Computing, checked 2 Nov 2026). Here is the version that suits a timed test.

1. List the variables first. Draw one column for each variable you can see, plus one for the output. Leave room, because you will add rows, not erase.
2. Write the starting values. Fill the first row from the initial assignments. Do this before reading the loop.
3. Move one line at a time. For each line, change only the variable it changes. Write the new value in a new row. Never overwrite the old one, because you may need it when you check your work.
4. Stop when the condition says stop. At the end of every loop pass, test the loop condition again, out loud in your head, with the new values. Then read what the final line prints.

The cost is a few seconds of writing per line. The saving is that you stop re-reading the code four times to double-check a number you were never sure of.

Worked example 1: a loop with modulo and integer division

x = 17
y = 0
while x > 0
    y = y + (x mod 5)
    x = x div 3
print y

Here mod is the remainder and div is division that drops the fraction.

After pass 3, x is 0, so x > 0 is false and the loop stops. The program prints 3.

Notice what the table protects you from. In pass 2, the remainder is 0, so y does not change. People who work in their heads often add something there by habit.

Worked example 2: the loop that changes its own counter

i = 1
s = 0
while i <= 10
    s = s + i
    i = i + 3
print s, i

Trace it: i is 1, s becomes 1, i becomes 4. Then s is 5, i is 7. Then s is 12, i is 10. Then s is 22, i is 13. Now 13 <= 10 is false, so the loop ends. It prints 22 13.

The trap is the final value of i. Many people print 10, because 10 was the last value that passed the check. The counter moved once more before the check failed.

Worked example 3: recursion

function f(n)
    if n <= 1 then return 1
    return n + f(n - 2)

print f(7)

For recursion, write the calls going down first, then fill in the answers coming back up.

• f(7) needs f(5)
• f(5) needs f(3)
• f(3) needs f(1)
• f(1) returns 1

Now go back up. f(3) = 3 + 1 = 4. f(5) = 5 + 4 = 9. f(7) = 7 + 9 = 16.

Note that n goes 7, 5, 3, 1 and never hits 0. A version that stopped only at n == 0 would never end for odd n. When you see a base case, check that the steps can actually land on it.

Worked example 4: update order

a = 6
b = 4
a = a + b
b = a - b
a = a - b
print a, b

Line by line: a becomes 10. Then b = 10 - 4 = 6. Then a = 10 - 6 = 4. It prints 4 6. The program swaps the two values without a third variable. You do not need to recognise the trick. A trace table gets you the answer even if you have never seen it.

Five traps that cost marks

• Integer division. When both numbers are integers, many languages drop the fraction, so 7 / 2 gives 3. This is a classic trap when tracing by hand. If the question shows a decimal anywhere, decide which kind of division applies before you continue.
• Negative numbers and modulo. Languages disagree. In C-style truncation, -7 / 2 is -3 and -7 % 2 is -1. In Python, -7 // 2 is -4 and -7 % 2 is 1. A fair test states which rule applies, so look for that note.
• Off-by-one in loops. < and <= differ by one full pass. Write the loop's last pass in the table, not just the first.
• The last value of the counter. As example 2 shows, a counter usually ends one step past the value that last passed the check.
• Output inside versus outside the loop. A print indented inside the loop prints every pass. Outside, it prints once. Check the indentation before you total up the output.

Some school materials write integer division and remainder as DIV and MOD, as in the Save My Exams guide to trace tables (Save My Exams, checked 2 Nov 2026). If your test uses / and % instead, the rule is the same, only the symbol changes.

Making it fast enough for a timed section

A trace table feels slow at first. Three habits fix that.

Shrink the table. Use only the columns that change. If a variable is set once and never touched, write it at the top and leave it out.

Spot the pattern, then check it. In example 2, you can see that i goes up in steps of 3, so s adds 1, 4, 7, 10. Use patterns to predict, but fill the first three rows of the table before you trust them.

Write the table small and neat. Most mistakes in a rushed trace are misread handwriting, not misunderstood code.

For where this section sits in a full test, see our Infosys preparation guide and the wider aptitude preparation guide. If a TCS test is your target, the TCS NQT 30-day plan shows how to fit this practice into a month.

One free thing to try

Take the LogicWiz Exams pseudocode practice set. Before you open any answer, trace each program in a table on paper. Then read the worked answer and compare it, row by row, with your own. The first time your table differs from the answer, find the exact row where you went wrong. That row is the habit to fix.

Common questions

Do I need to know a particular programming language for pseudocode questions?

Not usually. Pseudocode is written to be language-neutral. Knowing how loops, conditions, functions and the remainder operator work in any one language is enough. Read the test's own instructions for its notation.

Is a trace table allowed in the test?

Rough work on paper is generally allowed in online tests, but rules differ by company and by test centre. Check the instructions for your test. If you are not allowed paper, practise holding two or three variables in your head and write the rest as you go.

How long should I spend on one question?

There is no single answer, because test timings vary by company and change over time. Practise under the timer given in your own test's instructions. A good first target is to finish a short loop without re-reading the code.

What if the loop runs hundreds of times?

Look for the pattern after three or four passes, such as a counter that grows by a fixed step or a value that halves. Then work out where the loop stops and compute the final value directly. Confirm your pattern against the first three rows before you rely on it.

How is this different from debugging code I wrote?

When you debug, you can run the program. In a pseudocode question you are the machine. The trace table is how you do by hand what a debugger would show you.