Tamil Nadu HSE Second Year Computer Science common mistakes
Tamil Nadu HSE Second Year Computer Science · Understand the traps and how to avoid them.
When converting between binary, octal, decimal and hexadecimal, candidates write the digits of the decimal number in the wrong positional order, or they convert the integer part correctly but silently drop the fractional part (e.g. converting 25.625 by handling only 25).
Repeated division and repeated multiplication are two separate procedures, and candidates learn the integer routine first and then apply it to the whole number. They also read remainders top-to-bottom instead of bottom-to-top, because the division table is written downward while the answer must be read upward.
What to do instead
Always split the number at the radix point and label the two halves. For the integer part, divide repeatedly and write remainders to the right, then reverse the column before writing the answer; for the fraction, multiply repeatedly and collect the integer digits in the order produced. Verify by expanding the result back into powers of the base and confirming it equals the original value.
In Python list questions, candidates predict the output of slicing and negative indexing by counting from 1, or they assume a slice like a[2:5] includes the element at index 5, and they confuse methods that mutate a list (append, extend, insert, sort) with those that return a new object (slicing, sorted, concatenation).
Textbook diagrams often number list positions starting at 1 for readability, and the exclusive upper bound of slicing is unlike anything in ordinary mathematics. The mutation confusion arises because both patterns appear in the same chapter and the return value of append (None) is rarely emphasised.
What to do instead
Adopt one habit: draw the indices 0,1,2,... above each element and the negative indices -n,...,-1 below it, and mark the stop index as a wall the slice cannot cross. For each method, write beside it either 'changes list, returns None' or 'returns new list, original unchanged', and test both in the interpreter until the distinction is automatic.
Candidates describe a stack as FIFO or a queue as LIFO, or they give the wrong output for a sequence of push and pop operations because they apply the operations in the written order without tracking the changing top of the stack.
The two structures are taught together, and the everyday meanings of 'queue' and 'stack' pull in opposite directions from the technical definitions. Operation-trace questions also require simulation, which candidates try to do from memory rather than on paper.
What to do instead
Anchor the definitions physically: a stack of plates has one accessible end (top), a queue at a ticket counter has two (front and rear). For any trace question, draw a vertical column with a top pointer and a horizontal row with front and rear pointers, and perform each operation as a separate line, writing the structure's contents after every step before choosing an answer.
When writing a Python class, candidates omit self from the parameter list of an instance method, forget to write self.attribute when reading an attribute inside the class, or call a constructor with the wrong number of arguments because they did not count the implicit self parameter.
self is invisible at the call site, so the method signature and the call look inconsistent. Candidates also transfer procedural habits, where a variable inside a function simply refers to itself, into methods where the attribute lives on the instance.
What to do instead
Write the class skeleton first with every method's first parameter as self, then fill in bodies. Inside any method, read every attribute access aloud as 'self dot name'. When constructing an object, count the arguments in init excluding self and compare that count with the call before running the code.
In SQL, candidates write SELECT with a WHERE clause that filters on an aggregate such as COUNT(*) or AVG(marks), or they place a GROUP BY column in the SELECT list inconsistently, producing a query that would be rejected or would return meaningless rows.
WHERE and HAVING look interchangeable because both take a condition, and the rule that WHERE runs before grouping while HAVING runs after it is stated once and then forgotten. Aggregate filtering is also the first place where the logical order of query execution matters.
What to do instead
Memorise the evaluation order FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY and apply it as a checklist. Use the rule: if the condition mentions an aggregate function, it belongs in HAVING; otherwise it belongs in WHERE. Rewrite every aggregate-filter question into both clauses explicitly before answering.
Candidates confuse the roles of the primary key, candidate key, foreign key and alternate key, and they claim a table can have several primary keys or that a foreign key must be unique.
The definitions overlap, since a primary key is one chosen candidate key, and the words 'key' and 'unique' are used loosely in everyday database talk. Referential integrity is also described abstractly, so the constraint's purpose is not connected to any concrete table.
What to do instead
Build one small table on paper (for example Student with RollNo, AadhaarNo, Name, Class) and label RollNo as primary key, AadhaarNo as candidate and alternate key, and Class as a foreign key into a Class table. State the invariants next to the diagram: exactly one primary key per table, never null, candidate keys are unique, a foreign key may repeat and may be null unless declared otherwise.
When asked to identify the protocol or device at a given layer, candidates place a switch at the network layer, a router at the data link layer, or they say TCP is used for streaming video and DNS lookups without qualification, and they mix up the functions of IP, TCP and UDP.
The layers are taught as a list rather than as a division of labour, and switches and routers physically resemble each other. TCP and UDP are introduced as 'reliable' and 'unreliable' without the consequence for real applications.
What to do instead
Attach each device and protocol to a one-line job: hub repeats bits (physical), switch forwards frames by MAC address (data link), router forwards packets by IP address (network), TCP gives ordered reliable delivery with connection setup, UDP gives fast connectionless delivery. For each named application (web, email, file transfer, DNS, video), state the transport protocol and one reason for the choice.
In HTML and CSS answers, candidates use presentational tags and inline styling where structure and style should be separated, write unclosed or improperly nested tags, and misuse class versus id selectors, for example applying the same id to several elements or writing a CSS rule with a dot for an id.
Older teaching material and browser tolerance encourage sloppy markup, since pages often render despite errors. The distinction between class (reusable) and id (unique) is easy to state but easy to violate when writing quickly.
What to do instead
Follow a fixed template for every page: doctype, html with lang, head containing title and a linked stylesheet, body with semantic elements. Before submitting, check nesting by indenting the markup like code. Remember one rule: id is unique and selected with #, class is reusable and selected with ., and styling never appears in a style attribute in an exam answer unless the question demands it.
In file-handling programs, candidates open a file without specifying the mode they intend, forget to close it, or try to write to a file opened in read mode; they also confuse write mode, which truncates, with append mode, and they read a file twice without seeking back to the start.
The default mode hides the choice, the file pointer is invisible, and the difference between 'w' and 'a' produces no error message, only silently lost data. Candidates also test code once with a fresh file and never observe the truncation.
What to do instead
Always write the mode explicitly and say its effect in a comment: r read, w write and truncate, a append, and add b for binary. Use a with block so closing is automatic, and when re-reading, either reopen the file or call seek(0). Practise a three-step drill: write two lines, append one line, read all lines, and check the file contents between steps.
When asked for an algorithm or its complexity, candidates give a vague prose description with no initialisation, no loop condition and no termination, or they state that binary search is O(n) and linear search is faster on sorted data, and they omit the precondition that binary search requires a sorted array.
Algorithm questions are marked on structure, but candidates write them as explanations. Complexity is often memorised as a table of names without connecting the count of comparisons to the size of the input, and the sorting precondition is treated as a detail.
What to do instead
Write every algorithm in four labelled parts: input and precondition, initialisation, loop with an explicit condition and update, and return with a termination argument. Derive complexity by counting how the work grows: halving the range each step gives log n comparisons, scanning every element gives n. State the sorted-array precondition in the first line of any binary search answer.