Ever stared at a block of code during a technical interview or a certification exam and felt your brain just... stall? You know the feeling. On the flip side, you're looking at a function, the question asks "which of the following is true," and suddenly four different options all look correct. Or worse, they all look wrong It's one of those things that adds up..
It's a classic trap. These questions aren't actually testing if you can read code—they're testing if you can think like a compiler.
Here's the thing: most people try to guess the answer by looking for patterns they recognize. But the secret to nailing these questions isn't pattern recognition. It's a systematic way of breaking down the logic before you even glance at the multiple-choice options.
What Is "Which of the Following Is True" Analysis
When you see a question asking which statement is true about a specific function, you're essentially performing a static analysis of the code. In plain English, you're predicting how the code will behave without actually hitting the "run" button Turns out it matters..
It's like being a detective. You have a piece of evidence (the function) and a set of theories (the options). Your job is to prove three of those theories wrong so that the fourth one is true by default Most people skip this — try not to..
The Mental Sandbox
To do this well, you have to create a "mental sandbox." This is where you take a sample input—something simple, like the number 1 or an empty string—and manually trace it through every line of the function. If the function has a loop, you don't run it a thousand times in your head. You run it twice. That's usually enough to see the pattern.
The Logic Gap
The trick is that these questions usually target the "edge cases." The parts of the code where things break. They aren't asking about the 90% of the time the function works perfectly; they're asking about the 10% where it does something weird, like returning undefined or hitting an infinite loop.
Why It Matters / Why People Care
Why do we even deal with these types of questions? If you're a student or a job seeker, it's because these are the gold standard for technical screening. But beyond the interview, this skill is actually the core of being a good developer Simple, but easy to overlook..
It's the bit that actually matters in practice.
Look, anyone can write code that works. On top of that, the real pros are the ones who can look at a function and say, "Wait, if the input is null, this is going to crash the entire server. " That's exactly what these "which is true" questions are training you to do.
When you ignore this level of analysis, you end up with bugs that only appear in production. You write a function that works for your test case but fails for the user. Learning to dissect a function logically prevents those "it worked on my machine" nightmares And it works..
How to Solve "Which Is True" Function Questions
If you want to stop guessing and start knowing, you need a repeatable process. Don't just read the code and hope for the best. Use a framework Simple, but easy to overlook..
Step 1: Identify the Inputs and Outputs
Before you look at the logic, look at the signature. What is coming in? What is going out?
If the function takes an array but doesn't check if the array is empty, that's a huge red flag. If it's supposed to return a boolean but there's a path where it returns nothing, you've just found a likely candidate for the "true" statement.
Worth pausing on this one.
Step 2: Trace the Control Flow
Control flow is just a fancy way of saying "where does the code go?" Follow the path.
- Conditionals: If there's an
if/elseblock, ask yourself: "What happens if the condition is false?" - Loops: Look at the exit condition. Does the loop actually end? Or does it keep running until the memory leaks?
- Recursion: If the function calls itself, find the base case. If there is no base case, the function will cause a stack overflow. That's a very common "true" answer in these tests.
Step 3: Test the Extremes
This is where most people fail. They test the "happy path"—the input that makes the function work. To find the truth, you have to test the "sad path."
Try these inputs in your head:
- Zero or negative numbers.
On the flip side, - Empty strings or
nullvalues. - Extremely large numbers. - Arrays with one element versus arrays with a million.
Step 4: Evaluate the Options via Elimination
Now, and only now, look at the multiple-choice options. Don't let them lead you. Instead, use them as a checklist Simple, but easy to overlook. Simple as that..
If Option A says "The function returns 0 when the input is negative," go back to your mental sandbox and plug in -1. If it returns null instead, Option A is dead. Cross it out. Move to Option B.
Common Mistakes / What Most People Get Wrong
I've seen a lot of smart people fail these questions because they fall into the same few traps. Honestly, it's usually because they're rushing.
Trusting the Function Name
This is a big one. A function might be called calculateTotal(), but inside, it actually subtracts values. Never assume the function does what the name says it does. In a test environment, the name is often a distraction. Read the logic, not the label Nothing fancy..
Overlooking Scope and Hoisting
In languages like JavaScript, people often forget about where variables are declared. They see a variable being used and assume it has a value, forgetting that it might be undefined due to hoisting or block-scoping. If you see var, let, or const used in a weird spot, pay extra attention Less friction, more output..
Miscalculating Loop Off-By-One Errors
The "off-by-one" error is the oldest trick in the book. Is the loop using < or <=? Does it start at index 0 or index 1? If a function iterates through an array of length 5 but stops at index 4, it might be missing the last element. This is a classic "true" statement in these types of problems.
Practical Tips / What Actually Works
After doing this for years, I've found a few shortcuts that actually save time without sacrificing accuracy Easy to understand, harder to ignore..
First, write it down. If you're allowed a piece of scratch paper, use it. Don't try to hold the state of five different variables in your head. Here's the thing — draw a small table. But column one is the variable name, column two is the value. Update the value as you move through the lines of code. It feels slower, but it's actually faster because you don't have to restart when you lose your place.
Second, look for the "impossible" option. Sometimes an option will say "The function always returns a positive integer." The word always is a huge hint. All you have to do is find one single case where it returns a negative number or a zero, and that option is gone.
It sounds simple, but the gap is usually here.
Third, check the return statements. A common trick is to have a return inside a loop. On top of that, once that line hits, the function is over. Everything below that return is dead code. If an option describes something that happens after a return statement, it's automatically false But it adds up..
FAQ
What should I do if two options seem true?
Go back to the code and look for a tiny detail you missed. Usually, one option is "mostly true" but the other is "precisely true." Look for words like "always," "never," or "sometimes." One of those qualifiers is usually the key.
Is it better to trace the code or look at the options first?
Trace the code first. If you look at the options first, you'll start seeing patterns that aren't actually there. This is called confirmation bias. You'll try to make the code fit the answer instead of letting the code tell you the answer.
How do I handle complex recursion in these questions?
Don't try to trace the whole recursion tree. Just trace the first two calls and the base case. Once you see how the value is being passed back up the chain, you can usually figure out the final result without doing the math for every single step.
What's the fastest way to spot a trick?
Look for the weirdest line of
What's the fastest way to spot a trick?
Look for the weirdest line of code. Often, the trick is hidden in an unusual placement of a variable declaration, an unexpected mutation, or a subtle misuse of a language feature. If something looks odd, it's probably intentional. To give you an idea, a var inside a block, a return inside
