GATE DA common mistakes
GATE DA · Understand the traps and how to avoid them.
In the Probability & Statistics section, computing the answer to a conditional-probability or Bayes item from the joint P(A∩B) without dividing by the conditioning event P(B), so the final value is a joint probability reported as a conditional one.
Under time pressure the joint term is the most salient number in the problem statement, and the conditioning clause ('given that…') is easy to skim past. Candidates also confuse P(A|B) with P(B|A) when the wording reverses the order of events.
What to do instead
Before any arithmetic, write the target as a symbolic expression, e.g. P(A|B) = P(A∩B)/P(B), and explicitly label the denominator as the conditioning event. Then compute the denominator separately and check it lies in (0,1]; if the result exceeds 1, the ratio was inverted. For Bayes items, always state the prior and the likelihood before combining them.
In Linear Algebra, answering rank, nullity, or eigenvalue questions by row-reducing the matrix but then reporting the number of nonzero rows of the original matrix, or by reading eigenvalues off the diagonal of a non-triangular matrix.
Row reduction is the default reflex, and candidates stop as soon as the reduced form looks clean without re-reading what was asked. Reading diagonal entries as eigenvalues is a habit carried over from diagonal and triangular matrices, and it silently fails for general matrices.
What to do instead
Use rank–nullity explicitly: write rank(A) + nullity(A) = number of columns, and check which of the two the question asks for. For eigenvalues, set up det(A − λI) = 0 and solve the characteristic polynomial; only use the diagonal shortcut after confirming the matrix is triangular or diagonal. Sanity-check with trace = sum of eigenvalues and determinant = product of eigenvalues.
In Calculus & Optimization, finding a stationary point by setting the gradient to zero and declaring it the minimum or maximum without checking the second-order condition or the boundary of the feasible region.
Single-variable training makes 'derivative zero means extremum' feel automatic, and constrained problems in the syllabus often place the optimum on a boundary or at a non-differentiable point where the gradient test says nothing.
What to do instead
Classify every stationary point with the Hessian (positive definite = local min, negative definite = local max, indefinite = saddle). For constrained problems, list the boundary and check it separately, and treat points where the function is non-differentiable as candidates. State the classification explicitly in the answer rather than only the point's coordinates.
In Programming & Data Structures, tracing a recursive function or a loop by simulating only the first one or two iterations and then extrapolating the result, producing an off-by-one return value or a wrong base-case count.
Hand-tracing is slow, so candidates shortcut to pattern-matching against familiar code. Recursion depth, pre- versus post-increment, and whether the loop bound is strict or inclusive are exactly where the extrapolated pattern breaks.
What to do instead
Write a table with one row per call or iteration showing the argument, the local variable values, and the return value, and carry it to the base case. For recursion, draw the call tree and sum the work per level. Then re-run the trace with a tiny input (n = 0 or 1) to confirm the base case is handled.
In Algorithms, quoting the complexity of an algorithm from memory (for example calling a balanced binary search tree 'O(1) search') or giving the complexity of the wrong phase, such as the best case when the question asks for the worst case.
Complexity tables are memorized as isolated facts without the associated data-structure invariant, and question stems that ask for 'the complexity of this operation' are read as 'the complexity of this algorithm'.
What to do instead
Derive the bound from the operation: state what the structure guarantees (height O(log n), amortized doubling, hashing assumption) and count the work per operation. Underline in the stem whether it asks for best, average, worst, or amortized case, and answer that one with the qualifying phrase included.
In Machine Learning, evaluating a classifier with accuracy on a class-imbalanced dataset and concluding the model is good, or reporting a metric computed on the training set as if it were generalization performance.
Accuracy is the first metric taught and the easiest to compute, and a high training score is psychologically reassuring. Imbalanced data makes a majority-class predictor look strong, and leakage between train and test is easy to introduce when preprocessing is done before the split.
What to do instead
Report a confusion matrix and choose the metric that matches the cost structure: precision, recall, F1, or AUC for imbalanced classification, and MAE/RMSE for regression. Always state which split produced the number. Fit scalers, encoders, and imputers inside the training fold only, and use cross-validation for small datasets.
In Machine Learning, confusing overfitting with underfitting when reading a learning curve, then recommending the wrong remedy, such as adding more features or reducing regularization for a model that already memorizes the training set.
Both conditions are described in similar vocabulary ('high training error' versus 'large train–test gap'), and candidates recall the remedies without matching them to the diagnostic pattern. Regularization strength is also easy to invert mentally.
What to do instead
Diagnose with the pair (training error, validation error): low training and high validation means overfitting (more data, stronger regularization, simpler model, early stopping); high training and high validation means underfitting (more capacity, less regularization, better features). Write both numbers down before choosing a remedy, and state the direction of the change explicitly.
In AI, applying a search algorithm without tracking the frontier and visited set correctly, so the reported path or node-expansion order is wrong for BFS, DFS, or A*, or the heuristic is used in a way that breaks admissibility.
Search is taught with diagrams, and candidates reproduce the diagram's expansion order rather than simulating the open and closed lists. In A*, the distinction between admissible and consistent heuristics, and whether a node can be reopened, is often skipped.
What to do instead
Simulate with an explicit table of frontier and visited nodes, expanding one node per step and recording the priority or queue position. Check the heuristic against the goal: admissible means never overestimating the true cost; consistent means h(n) ≤ c(n,n′) + h(n′). Use a consistent heuristic with a closed set, or allow reopening otherwise, and say which assumption you used.
In AI, answering a propositional or first-order logic question by translating the English sentence into a formula with the quantifier scope wrong, for example ∀x∃y where the intended meaning is ∃y∀x, or using implication where conjunction is required.
Natural language does not mark quantifier scope, and the two readings differ only in the order of symbols. The 'all A are B' pattern is also drilled as implication, so candidates apply implication to 'some A are B', which changes the truth conditions.
What to do instead
Paraphrase the sentence into a canonical form first ('for every object, if it is an A then it is a B' versus 'there exists an object that is both A and B'). Then map: universal + implication for 'all', existential + conjunction for 'some'. Test the formula on a small domain with a counterexample object to confirm the scope matches the intended reading.
In Database Management, writing a SQL query with the wrong join type or grouping level, so rows are silently dropped by an inner join or duplicated by a join on a non-key column, and then reporting the row count as correct.
The query runs without error, so there is no signal that it is wrong. Inner joins and one-to-many joins both produce plausible-looking output, and aggregate queries hide row-level duplication until the count is checked.
What to do instead
Before writing the query, state the grain of the result ('one row per customer') and verify the join keys are unique on the appropriate side; use LEFT JOIN when unmatched rows must survive. After writing it, predict the row count and the value of one aggregate by hand, then compare with the actual output. For GROUP BY, confirm every non-aggregated selected column appears in the grouping.