GATE CS common mistakes
GATE CS · Understand the traps and how to avoid them.
Spending the full 3 hours on the 65 questions in strict numerical order, sinking 15+ minutes into one hard 2-mark question early in the paper.
The paper is not ordered by difficulty, and the first half mixes easy 1-mark items with genuinely hard 2-mark ones. Candidates anchored by the question number keep grinding because abandoning a question feels like admitting defeat, and they underestimate how much time the later NAT questions need.
What to do instead
Run three passes. Pass 1 (about 60-70 minutes): answer only questions you can resolve in under 90 seconds, marking the rest. Pass 2 (about 60 minutes): attack the marked questions, hardest last. Pass 3 (remaining time): check calculations and fill every unanswered MCQ with a reasoned guess. Before the exam, practise with a visible timer and a rule of 'leave a question after 4 minutes on the first pass'.
Getting negative marking wrong: leaving easy MCQs blank out of fear, or guessing blindly on hard MCQs where the expected value is negative.
GATE awards 1 or 2 marks for a correct MCQ and deducts one-third of that (1/3 or 2/3) for a wrong one, with no deduction on NAT questions. Many candidates do not internalise that a blind 4-option guess has positive expected value (+1/6 for a 1-mark MCQ) while a pure guess on a question where two options are already eliminated is strongly positive. Others over-apply this and guess on questions where they have no basis, or forget that NAT answers carry no penalty and so leave them blank.
What to do instead
Adopt an explicit policy: on MCQs, guess whenever you can eliminate at least one option (or, at worst, always guess on 1-mark MCQs since expected value is positive); never leave a NAT blank because there is no penalty. Drill this with mock papers and track your guess accuracy. Memorise the numbers: 1-mark MCQ wrong = -1/3, 2-mark MCQ wrong = -2/3, NAT wrong = 0.
Losing marks on NAT (numerical answer type) questions through formatting and rounding errors: entering a fraction as a decimal with too few digits, giving a negative answer where the question asked for a magnitude, or misreading 'up to two decimal places'.
NAT answers are graded against a machine-checked value with a tolerance, so 0.33 instead of 0.333 can fall outside the accepted range. Candidates also misread whether the answer should be an integer, a range, or a value in a specified unit, and some questions ask for the number of something where a fractional answer signals a modelling error.
What to do instead
Read the answer-format instruction before solving, not after. Carry exact fractions until the final step, then round only once, to the precision requested (default to at least 2-3 decimals if unspecified). Sanity-check the magnitude: if the question asks for a count, the answer must be a non-negative integer; if it asks for a probability, it must lie in [0,1]. Practise entering answers in the actual exam interface during mock tests.
Treating the syllabus as 'everything in a standard algorithms textbook' and spreading effort evenly, instead of weighting by the official GATE CS topic breakdown and past-paper frequency.
The GATE CS syllabus is broad, and candidates often over-invest in low-yield areas (e.g. deep compiler optimisation passes, extensive OS internals trivia) while under-preparing high-weight, high-frequency areas such as Discrete Mathematics, Data Structures and Algorithms, Operating Systems, DBMS, Computer Networks, and Theory of Computation. The result is good coverage but weak depth where most marks sit.
What to do instead
Build a topic-weight table from the official syllabus and several years of past papers, count marks per topic per year, and allocate study hours roughly in proportion. Reserve the last month for the top-weight topics and for revision, and cap time on peripheral subtopics. Recompute the table after each mock to see which topic is actually leaking marks.
Solving recurrence relations and asymptotic questions by pattern-matching to memorised formulas without checking which Master Theorem case applies or whether the regularity condition holds.
Candidates memorise T(n)=2T(n/2)+n => O(n log n) and then apply the same template to T(n)=2T(n/2)+n^2 or to non-standard forms like T(n)=T(n/2)+T(n/4)+n, where the standard Master Theorem does not apply. The failure is usually not algebra but misidentifying a, b, f(n) and skipping the comparison of f(n) with n^{log_b a}.
What to do instead
For every recurrence, write down a, b, and f(n) explicitly, compute n^{log_b a}, and state which of the three cases holds before writing the answer. For non-standard recurrences (unequal splits, subtract-and-conquer, floors/ceilings), fall back to the recursion tree or substitution method. Practise a mixed set of 20 recurrences where at least a third are traps that the Master Theorem cannot solve.
Making off-by-one and boundary errors in array, tree, and hashing questions: computing the number of nodes at height h, the index range in binary search, or the number of comparisons in a successful/unsuccessful search.
Conventions differ (height counted from 0 or 1, levels numbered from 1, load factor defined as n/m, average vs worst-case comparisons), and under time pressure candidates apply a memorised formula without checking which convention the question uses. Binary search loop invariants (low <= high vs low < high, mid = (low+high)/2) are a classic source of wrong comparison counts.
What to do instead
Before computing, write the convention explicitly on your rough sheet ('height of leaf = 0', 'levels start at 1', 'load factor = n/m') and derive the formula for a tiny case (n=1,2,3) to confirm it. For binary search, trace the exact loop on a 7-element array and count comparisons rather than recalling a formula. Build a one-page 'conventions' sheet and revise it before each mock.
Confusing the layers and protocols in the computer networks questions: mixing up which layer a device or protocol belongs to, or misapplying subnetting and CIDR arithmetic.
The OSI/TCP-IP mapping is taught with overlapping device lists (switch = layer 2, router = layer 3, but multilayer switches blur this), and protocols such as ARP, ICMP, and DHCP sit awkwardly across layers. Subnetting errors come from computing the number of hosts as 2^n instead of 2^n - 2, or from forgetting that the network and broadcast addresses are unusable.
What to do instead
Draw the layer stack once and annotate each protocol and device with its layer and PDU. For subnetting, always write the mask in binary, identify the host bits, and apply 2^h - 2 for usable hosts (unless the question explicitly asks for total addresses). Practise 15 subnetting problems including VLSM and supernetting, and re-derive rather than recall each answer.
Misapplying normalisation and SQL semantics in DBMS questions: assuming a relation is in 3NF/BCNF without computing all candidate keys, or misreading NULL behaviour in SQL aggregates and joins.
Normal-form questions hinge on finding every candidate key first, and candidates often find one key and stop, then wrongly declare a dependency 'non-prime' or 'partial'. In SQL, COUNT(*) vs COUNT(col), NULL in NOT IN, and three-valued logic in WHERE clauses produce answers that differ from intuition, and the exam deliberately tests these edges.
What to do instead
For every normalisation question, first list all candidate keys using the attribute closure of each determinant; only then test each functional dependency against 2NF, 3NF, and BCNF definitions. For SQL, rewrite the query with explicit NULL handling and evaluate row by row on a small sample table. Keep a short 'SQL NULL rules' note (COUNT ignores NULLs, NULL comparisons yield UNKNOWN, NOT IN with NULL yields no rows).
Losing marks in Theory of Computation and Discrete Mathematics by constructing a DFA/NFA or writing a proof without checking closure properties and without testing the construction on boundary strings.
Questions ask for the minimum number of states, whether a language is regular/context-free, or the validity of a first-order statement. Candidates build a plausible automaton, never test it on the empty string and on strings of length 1-2, and forget that operations like intersection with a regular language preserve regularity but complement/reversal arguments need care. In discrete maths, they skip checking edge cases in counting and graph problems.
What to do instead
After building any automaton, run it on epsilon, single symbols, and one string that should be rejected. State the closure property you are using explicitly before concluding regularity or context-freeness. For counting and graph questions, test the formula on the smallest non-trivial case (n=1,2,3) and check whether the question counts labelled vs unlabelled objects. Maintain a list of standard non-regular and non-context-free example languages for quick discrimination.
Under-preparing for the General Aptitude section and the numerical/verbal reasoning items, treating them as free marks, then losing 10-15 marks that would have been easy to secure.
General Aptitude carries 15 marks (10 questions), and its quantitative, data-interpretation, and verbal items reward practice with timing and reading accuracy rather than deep theory. Candidates who spend 100% of preparation on core CS often misread the question stem, run out of time on a data-interpretation set, or fall for distractors in verbal analogy and grammar items.
What to do instead
Schedule a fixed weekly slot (about 2 hours) for General Aptitude from the start of preparation, covering percentages, ratios, averages, permutations, data interpretation, and verbal reasoning. Practise reading the question stem twice and restating what is asked before computing. In mocks, do the aptitude section first or last consistently, and review every wrong aptitude answer to classify it as a reading error, a concept gap, or a calculation slip.