GATE CY common mistakes
GATE CY · Understand the traps and how to avoid them.
Treating Numerical Ability items as pure arithmetic and skipping the data-interpretation and logical-reasoning sub-parts, or budgeting equal time per question so the last 5–8 GA questions are answered in a rushed final minute.
GATE General Aptitude is a fixed 15 marks (10 one-mark + 5 two-mark) but mixes quantitative aptitude, data interpretation, verbal ability and logical reasoning under the same clock as the technical paper; candidates who drill only formulas underestimate the reading load of DI tables and verbal items and allocate time by habit rather than by marks-per-minute.
What to do instead
Build a fixed GA routine: 12–15 minutes total, order = verbal/logical first (fast, low computation), then quantitative, then DI. Practise with a stopwatch on 15-question GA-only sets so the split becomes automatic, and never leave GA to the end of the paper - attempt it in the first pass so it is not sacrificed to technical-question overrun.
Solving recurrence relations and counting problems by pattern-matching from memory (e.g., writing the closed form of a recurrence without checking initial conditions), and answering generating-function or inclusion–exclusion questions with an unverified formula.
Discrete Mathematics is formula-dense and many candidates memorise results (Catalan numbers, derangement counts, Master Theorem cases) without the derivation, so a small change in the problem - non-standard base case, repeated characteristic root, restricted positions - breaks the recalled template silently.
What to do instead
For every recurrence, always derive the characteristic equation and substitute the given initial conditions back to verify the constants. For counting, re-derive with a small case (n = 2, 3) and check against the formula before marking the option. Keep a one-page sheet of derivations, not just final formulas, and re-derive each from scratch during revision.
Computing the number of states or the minimum-state DFA / minimal expression incorrectly by merging states that are distinguishable, or forgetting unreachable states when minimising a DFA or simplifying a Boolean function with don't-cares.
State minimisation and K-map grouping both reward systematic procedure, but under exam pressure candidates group by visual adjacency and stop at the first cover; don't-care terms are either ignored or over-used, and unreachable states in a DFA are retained, changing the count asked for.
What to do instead
Use the table-filling (partition refinement) method explicitly: mark all pairs distinguishable in one pass, then iterate until no new pairs are marked. For K-maps, list every prime implicant, then solve the covering problem; treat don't-cares as 1 only when they enlarge a group. For DFA minimisation, first delete states unreachable from the start state, then refine.
Mixing up latency, throughput and speedup when a pipeline or cache question asks for execution time, or applying the pipeline speedup formula without accounting for stalls, branch penalties and the number of instructions.
Computer Organization questions are usually multi-step (CPI × clock cycle × instruction count, plus stall cycles), and candidates grab a single remembered formula (k / (k + n − 1) or 1/(1 + stall)) that only holds under ideal assumptions the question has deliberately violated.
What to do instead
Write the full expression before computing: total cycles = (ideal CPI + stall CPI) × instruction count + pipeline fill, then divide by clock frequency. For cache questions, separate hit time, miss penalty and AMAT = hit time + miss rate × miss penalty, and state units. Cross-check with a limiting case (100% hit rate, zero stalls) to confirm the formula reduces correctly.
Predicting C output by intuition - assuming a specific evaluation order for function arguments, ignoring integer promotion and signed/unsigned conversion, or misjudging pointer arithmetic on arrays and strings.
C leaves argument evaluation order and several conversion rules implementation-defined or unspecified, and GATE-style questions exploit exactly these corners (i++ + ++i style expressions, sizeof on arrays vs pointers, char arithmetic). Candidates who have only written application code have never had to reason about these rules formally.
What to do instead
Memorise the small set of rules that questions actually test: array-to-pointer decay except in sizeof and &, integer promotion before arithmetic, usual arithmetic conversions for signed/unsigned, operator precedence and associativity table, and that && and || short-circuit while argument order does not. For any expression with side effects, rewrite it step by step on paper and mark each sequencing point.
Stating the asymptotic complexity of an algorithm from its name rather than from its actual loop structure, and reporting an average-case bound where worst case is asked (or vice versa) - e.g., calling quicksort O(n log n) unconditionally.
Complexity questions are graded on the precise bound requested; candidates pattern-match 'sorting = n log n' and 'hashing = O(1)' and miss that the question specifies worst case, or that the inner loop runs a number of times that depends on a second variable (giving O(nm) or O(n²) rather than O(n)).
What to do instead
For every code fragment, count the exact number of executions of the innermost statement as a function of the input sizes, then take the tightest bound. Explicitly label best/average/worst. Keep a table of algorithms with all three cases and their space complexity, and re-derive quicksort's worst case (already-sorted input, pivot at end) and hash-table worst case (all keys collide) each revision.
Answering closure and decidability questions by analogy - assuming a language is regular because it 'looks simple', or assuming a problem is undecidable because it mentions Turing machines - instead of applying a specific closure property or a reduction.
Theory of Computation is the most conceptual section and the options are designed to be plausible under intuition. Candidates also confuse closure of regular languages under operations (regular languages are closed under complement and intersection but not under infinite union) and misapply the pumping lemma direction.
What to do instead
Use a decision procedure: for regularity, try to build a DFA/NFA or a regular expression, or apply the Myhill–Nerode/pumping lemma to prove non-regularity - remember pumping lemma proves only non-regularity, never regularity. For decidability, classify by reduction direction (to prove undecidable, reduce a known undecidable problem to it). Maintain a closure-property table for regular, CFL and recursive languages.
Producing a wrong FIRST/FOLLOW set or parse table entry because of epsilon-productions and nullable non-terminals, and then answering LL(1) or SLR/LALR conflict questions from that faulty table.
Epsilon handling is the single most error-prone step in compiler-design questions: FIRST of a sequence must continue past a nullable symbol, and FOLLOW must be propagated through nullable suffixes. Candidates compute FIRST and FOLLOW in one careless pass and then draw conclusions about grammar class from incorrect sets.
What to do instead
Compute FIRST with an explicit fixed-point iteration: repeat until no set changes, and for a production A → X1X2…, add FIRST(Xi) for the first non-nullable Xi, plus ε if all are nullable. Compute FOLLOW with the standard three rules applied repeatedly, including the rule for nullable suffixes. Only then fill the LL(1) table and check for duplicate entries; check LR conflicts by constructing the item sets, not by guessing.
Confusing virtual memory with cache and answering page-fault, TLB and effective-access-time questions using cache formulas, or computing the number of page-table entries and levels without applying the correct page size and offset split.
Both are memory hierarchies with hit/miss terminology, so the formulas look interchangeable, but page faults cost disk access and are handled in software, while the TLB hit path bypasses one or more page-table walks. Candidates also forget that the offset bits are not part of the virtual page number when computing table size.
What to do instead
Write the address split explicitly: offset bits = log2(page size), VPN bits = VA bits − offset bits, and number of entries = 2^(VPN bits) per level. For EAT, draw the two paths (TLB hit vs TLB miss with page-table walk) and weight each by its probability; never reuse the cache AMAT formula. Practise multi-level paging with a concrete 32-bit example until the arithmetic is automatic.
Answering normalization, SQL and relational-algebra questions by eyeballing the schema - declaring a relation in BCNF because it 'looks fine', or writing a SQL query that silently changes semantics through NULL handling, JOIN type or GROUP BY with non-aggregated columns.
Normal-form questions require finding all candidate keys and every non-trivial functional dependency, which candidates skip; SQL questions test edge semantics (NULL comparisons in WHERE vs COUNT, INNER vs LEFT JOIN, HAVING vs WHERE) that are invisible in the small sample data given, so a plausible query returns the wrong answer on the intended data.
What to do instead
For normalization, always compute the attribute closure of each candidate key and test every FD X → Y for X being a superkey (BCNF) or Y being prime (3NF) before answering. For SQL, mentally execute on a table containing a NULL row and on a row with no match in the joined table; write the query, then check the join type and whether the predicate belongs in WHERE or HAVING.