C-DAC C-CAT common mistakes
C-DAC C-CAT · Understand the traps and how to avoid them.
In the English section, reading the passage once at normal speed and then answering each question by re-reading the whole passage again, so that 4–5 questions on one passage consume 8–10 minutes.
Candidates treat English as a reading test rather than a scanning task, and they have no habit of locating the line or paragraph that carries the answer. Anxiety about 'missing something' pushes them back to the top of the passage each time.
What to do instead
Practise the locate-then-verify routine: read the passage once for the main idea in about 90 seconds, then for every question find the keyword from the stem in the passage, read only the sentence before and after it, and answer. Time yourself on 5-question passages until you finish a passage set in 4 minutes. Never re-read the full passage unless two options are still tied after locating evidence.
In English vocabulary and grammar items, choosing the option that 'sounds right' instead of testing the sentence against a rule, and changing a correct answer to an incorrect one during review.
Spoken-English intuition is unreliable for prepositions, articles and subject–verb agreement, and answer-changing is driven by second-guessing under time pressure. Candidates also skip the small grammar rules (parallelism, modifier placement) that the paper repeatedly tests.
What to do instead
Before choosing, silently name the rule being tested (e.g., 'subject–verb agreement with a parenthetical phrase', 'parallel structure after and'). Only change an answer if you can state a specific rule that the original choice violates; otherwise keep the first reasoned choice. Build a one-page rule sheet and drill 20 error-spotting items daily.
In Reasoning, spending three or more minutes on a single seating-arrangement or puzzle set before deciding whether it is solvable, then rushing the easier questions at the end.
Puzzle sets look like the 'real' reasoning content, so candidates feel they must crack them. They start arranging without fixing the number of variables, so they redraw the same diagram repeatedly and lose track of constraints.
What to do instead
Adopt a 90-second triage rule: read the puzzle, write the entities and constraints in a compact grid, and if no definite placement emerges within 90 seconds, mark it and move on. Do two full passes - first all single-step items (series, coding-decoding, blood relations, syllogisms), then return to puzzles with the remaining time. Track per-set timings in a log so you learn which puzzle types you personally solve fast.
In Reasoning, answering syllogism and 'definitely true / possibly true' questions from real-world knowledge or from the meaning of the words rather than from the stated premises, and ignoring the difference between 'some' and 'all'.
Everyday plausibility overrides formal logic, and candidates do not draw the standard Venn diagram, so they miss the cases where a conclusion is only possible, not certain, or where 'some A are B' does not imply 'some B are A' in the reverse direction they assume.
What to do instead
Draw Venn diagrams for every syllogism item, testing the conclusion against the diagram that makes it false. Memorise the standard results: 'All A are B' plus 'All B are C' gives 'All A are C'; 'Some A are B' does not give 'Some B are not A'. For possibility questions, ask whether a valid diagram exists in which the conclusion fails; if yes, it is not definitely true.
In Quantitative Aptitude, setting up full algebraic equations for percentage, ratio, profit–loss and average problems instead of using fractions, options or back-substitution, which doubles the solving time per question.
School training rewards formal equation writing, and candidates distrust shortcuts because they fear errors. They also avoid substituting the answer options even when the options are clean numbers.
What to do instead
For each topic, learn one non-algebraic method and drill it: successive percentage change as multiplied factors (1.2 × 0.8), profit–loss via cost price = 100, ratio problems via a single multiplier, averages via deviation from an assumed mean. For any question with numerical options, back-substitute from the options when the equation would be quadratic or messy. Log which method you used per question for a week to build the habit.
In Quantitative Aptitude, leaving Data Interpretation sets until the end or attempting them without first scanning the axes, units and totals, leading to answers computed from the wrong row or in the wrong unit.
DI sets look long, so they are postponed until time is nearly gone, and then read in a hurry. Charts mix units (thousands vs lakhs, percentage vs absolute) and candidates compute with the first number they see.
What to do instead
Treat DI as high-yield: attempt one DI set early in the section to bank easy marks. On opening a set, spend 20 seconds writing down the unit, the base year, and whether figures are absolute or percentage, and note the total if given. Answer only the sub-questions that need one operation first; skip ones needing three-step computation until the second pass.
In Quantitative Aptitude, memorising formulas without practising the arithmetic they depend on, so that correct setups are lost to slow or wrong multiplication, division and fraction-to-percentage conversion.
Candidates assume the exam tests concepts only, but under a tight per-question budget, calculation speed determines whether a known method can be finished. Tables beyond 12 and common fraction–percentage equivalents are often shaky.
What to do instead
Run a daily 10-minute calculation drill: tables to 20, squares to 30, cubes to 15, and the fraction–percentage pairs (1/8 = 12.5%, 1/16 = 6.25%, 3/8 = 37.5%). Practise approximation to two significant figures for DI, and check whether the options are far enough apart that exact computation is unnecessary.
In Computer Fundamentals, confusing related but distinct terms - RAM vs ROM vs cache vs virtual memory, compiler vs interpreter vs assembler, primary vs secondary storage - and choosing the familiar-sounding option.
Everyday use of words like 'memory' and 'program' blurs the technical distinctions, and candidates revise from scattered sources without building a comparison table, so similar terms stay merged in memory.
What to do instead
Build comparison tables by hand for the confusable groups: (volatile/non-volatile, speed, cost per bit, typical size, purpose) for registers, cache, RAM, secondary storage; (translation timing, output, error reporting) for compiler, interpreter, assembler, linker, loader. Write each definition in one sentence without looking, then check. Test yourself on the table, not on prose notes.
In Programming, reading code and predicting output by intuition instead of tracing variable values line by line, so that loop boundaries, post-increment vs pre-increment, and integer division produce wrong answers.
Candidates read code the way they read prose, filling in the intended result rather than the executed one. Off-by-one loop limits and the difference between i++ and ++i are the classic traps, and integer division truncation is forgotten.
What to do instead
Trace on paper: a column per variable, one row per statement, and write the value after every increment and every loop iteration. For any loop, explicitly record the start value, the condition at the last iteration, and the value on exit. Drill 10 short output-prediction snippets daily covering for/while loops, nested loops, and pre/post increment.
In Programming, answering 'what does this program do / what is the error' questions by pattern-matching to a known algorithm name rather than checking the code's actual initialisation and return values, and ignoring syntax-level errors such as a missing semicolon or a misplaced brace.
Once a program 'looks like' a bubble sort or a factorial, candidates stop reading and pick the matching label, missing that the loop bound is wrong or the base case is absent. Error-spotting items are also rushed because they appear trivial.
What to do instead
For 'what does it do' items, verify three things before choosing: initial values of accumulators, the loop bound (inclusive or exclusive), and what is returned or printed. For error-spotting, scan in a fixed order - declarations, statement terminators, brackets, loop conditions, array indices - and state the error in words before looking at the options. If the code is a known algorithm, confirm the bound matches the standard form.