How to Approach a Competitive Programming Question
A structured five-step approach to competitive programming questions: from reading constraints to testing edge cases, built for placement coding rounds.
Most wrong answers in competitive programming come from misreading the problem statement, not from gaps in algorithm knowledge.
That might sound counterintuitive after months of learning data structures. But look at the submissions from any practice session: most first-attempt failures are wrong output on test cases that were correctly described in the problem. The algorithm was fine; the implementation ignored a constraint or misread the output format. The fix is not more algorithm practice. It is a methodical reading habit.
Why a method matters more than knowing more algorithms
In a typical campus placement coding round, students get two or three problems in 60 to 90 minutes. The pressure to start typing immediately is real. That pressure is exactly what causes most wrong answers.
Rushing past the problem statement introduces three categories of error that have nothing to do with algorithm knowledge:
- Missed output format: The problem says “print the minimum number of moves.” You print the list of moves. The logic is correct; the output is wrong and the judge marks it as a wrong answer.
- Missed constraint: The problem says n can reach 10,00,000. You implement O(n²) because it came to mind first. Every large test case exceeds the time limit.
- Missed edge case stated explicitly: The problem says “if no solution exists, print -1.” Your code returns 0. Correct logic, wrong sentinel value.
None of these require knowing a harder algorithm. All of them require reading the problem with attention.
How to read a competitive programming problem
Read the problem statement three times, each with a different focus.
-
First read: understand the narrative. What is the setting? What object is the problem operating on? What does a correct output mean in plain language? Do not write anything yet.
-
Second read: extract the specification. Write down the input format (how many integers per line, how many test cases), the output format (exact format, not just what to compute), and the constraints (the value of n, the range of individual elements, time limit if shown).
-
Third read: work through the examples. For each sample input and output pair, reproduce the expected output by hand, step by step. If you cannot reproduce it after the third read, you have not fully understood the problem.
This takes 10 to 15 minutes for a hard problem. It is not slow. Debugging a wrong-answer submission from a misread problem takes longer.
A useful check after the second read: can you explain the problem to a classmate in two sentences, using the input and output you wrote down? If the explanation requires more than two sentences, something in the specification is still unclear.
Constraints first: matching input size to algorithm complexity
Once you have the constraints from your second read, you know which complexity class your solution must fit. The table below maps input sizes to the maximum time complexity a standard online judge accepts with a one-second time limit:
| Input size (n) | Maximum accepted complexity |
|---|---|
| up to 100 | O(n³) |
| up to 10,000 | O(n²) |
| up to 1,00,000 | O(n log n) |
| up to 10,00,000 | O(n) or O(n log n) |
These breakpoints are approximate but consistent across Codeforces, CodeChef, and the campus placement platforms used in India. The underlying rule of thumb: treat 10^8 operations per second as the judge’s rough throughput ceiling. Before you decide on dynamic programming, greedy, binary search, or brute force, you already know which options the time limit rules out. If n is 1,00,000 and you are considering an O(n²) DP approach, it will not fit the one-second limit regardless of how cleanly you implement it.
The two-player coin game problem is a clear example of constraints shaping the algorithm choice: reading the input size first confirms that an O(n²) DP recurrence fits, and the greedy approach that skips this step produces wrong answers.
From plan to code: the three-layer approach
After confirming constraints, trace through at least two of the sample inputs by hand. Write out each transformation step. This gives you a concrete state machine to translate into code rather than an abstract algorithm you are guessing your way through.
When you start writing code, break the problem into three distinct layers and implement them in order:
Layer 1: Parse the input
Write only the input-reading code first. Run it on one sample input and confirm that your variables hold exactly what the problem statement says they should. An off-by-one in the input loop produces wrong output on every test case, which makes debugging the core logic impossible while the input itself is broken.
Layer 2: Apply the core logic
With the input confirmed correct, implement your algorithm for the simplest case first, then extend to the general case. Resist the temptation to handle every special case upfront. Get the happy path working against the sample inputs first.
Layer 3: Format the output
Check the output format from your second-read notes. Is it one result per test case on a new line? A space-separated sequence? “Yes” or “No” with exact capitalisation? Get this right before submitting.
The Noddy house-numbers problem is a worked example of a layer 3 failure: the problem asks for the pair of house numbers flanking the largest gap, and printing the gap size instead is an output-format error that no amount of algorithmic cleverness would fix.
Testing beyond the sample inputs
Sample test cases in competitive programming problems are designed to illustrate the problem, not to stress your solution. ICPC regional problems and campus placement coding rounds use hidden test sets that specifically probe edge cases your implementation may not handle.
Before submitting, design your own test cases using these six categories:
- Empty or minimum input: n = 0 or n = 1. Does your code handle zero or one element without a crash or wrong output?
- Maximum input: the largest n the problem allows. Does your solution finish within the time limit at scale?
- All elements identical: does your algorithm assume distinct values anywhere in the logic or comparisons?
- Already sorted input: if your solution involves sorting, does it still work when the input arrives pre-sorted?
- Reverse-sorted input: same question for the opposite order.
- All results the same: for problems asking for a maximum or minimum, what happens when all elements tie?
For students targeting IT fresher roles and their placement structure, placement coding rounds typically involve two to three problems in 60 minutes. The problems are usually simpler in algorithmic depth than competitive programming contests, but the hidden test sets are strict on edge cases. A solution that passes the sample inputs but fails the hidden test cases scores zero.
Carrying the approach forward
The three-layer method from the coding section (parse input, apply logic, format output) is not specific to competitive programming. It is the same structure used when building a tool on top of a language model: parse the user’s request, pass it through the model with the right structure, format the response for the interface.
Students who developed the habit of working layer by layer in competitive programming find that first LLM tool-building project recognisable rather than foreign. TinkerLLM, at ₹299, is a sandbox where you apply exactly that layered discipline to build and debug your first structured LLM call. The skill transfer is genuine; the only thing that changes is the domain.
Primary sources
Frequently asked questions
How long should I spend reading a problem before writing code?
In a two-hour contest, spend 10 to 15 minutes on full problem understanding before writing any code. Misreading costs more debug time than careful reading does upfront. For a 60-minute placement coding test with two problems, allocate 5 to 7 minutes per problem on reading and planning.
What does input size tell me about which algorithm to choose?
n up to 10,000 typically permits O(n²); n up to 1,00,000 requires O(n log n) or better; n up to 10,00,000 usually needs an O(n) solution. These are the standard competitive programming complexity breakpoints based on roughly 10^8 operations per second as the judge throughput ceiling.
Should I start with a brute-force approach?
For small n (say, n up to 1,000), yes — a correct brute force beats an optimised solution with a bug. For large n, read constraints first. If n is 1,00,000, there is no point building an O(n²) approach; the time limit rules it out before you write the first line.
What is TLE and how do I avoid it?
TLE stands for Time Limit Exceeded — your code ran too slowly for the judge. It is almost always caused by picking a time complexity class too slow for the given n. The constraints-first approach (checking n before picking an algorithm) prevents most TLE submissions.
How do I design my own test cases beyond the given samples?
Test at minimum: empty or zero input, a single element, maximum n, all elements identical, already-sorted input, and reverse-sorted input. These six categories cover the majority of edge-case failures seen in placement coding rounds.
Is competitive programming different from placement coding rounds?
Placement coding rounds in India are typically easier in algorithmic depth than Codeforces Div. 2 or ICPC regional rounds, but they are stricter on output format and edge cases. The same systematic reading and testing approach applies to both.
A self-paced playground for building with LLMs.
TinkerLLM is FACE Prep's sister property. A guided environment for shipping real LLM applications, the kind of project that earns a paragraph on your resume, not a line.
Try TinkerLLM (₹299 launch)