WBCHSE HS Vocational IT & ITeS common mistakes
WBCHSE HS Vocational IT & ITeS · Understand the traps and how to avoid them.
In the spreadsheet practical, typing a formula such as =SUM(A1:A5) but leaving the cell formatted as Text, so the formula shows as literal characters instead of a result.
Candidates paste or type data into cells that were pre-formatted as Text (common when importing roll numbers or phone numbers) and then write formulas in the same column; the cell's Text format overrides calculation, and the candidate does not notice because the displayed string looks like the formula they typed.
What to do instead
Before writing formulas, select the target range, open Format Cells, set the category to General or Number, then re-enter the formula by pressing F2 and Enter (editing the cell forces recalculation). As a habit, enter one test formula first and confirm a numeric result appears before filling the rest of the sheet.
Using relative cell references (e.g. B2*C2) in a formula that must be copied down, then reporting wrong totals because the reference drifts, or freezing the wrong part by typing $B$2*$C$2 everywhere and breaking the fill-down.
Candidates memorise the $ symbol without understanding which coordinate must stay fixed; in mark-sheet or bill-type tasks the rate or tax cell must be absolute while the row values stay relative, and this mixed referencing is rarely practised.
What to do instead
State the rule aloud before writing: lock the part that must not move. Build one formula with a mixed reference such as =B2*$F$1, copy it down two rows, and verify the results by hand; only then fill the whole column. Practise five mixed-reference exercises (percentage, tax, discount) until the pattern is automatic.
In the database section, writing a query or filter that returns rows but answering the question with the wrong aggregate, e.g. counting all records instead of counting DISTINCT customers, or grouping by the wrong field so the summary is meaningless.
Candidates learn SELECT, WHERE and COUNT as separate syntax items and never connect them to the business question; they also confuse COUNT(*) with COUNT(column), which ignores NULLs, so results silently differ.
What to do instead
Before writing SQL, underline the noun in the question (how many customers, how many orders) and decide whether duplicates should collapse. Write the query, then run a manual check on a small sample of rows to see whether the count matches. Practise COUNT(*) versus COUNT(column) versus COUNT(DISTINCT column) on the same table.
Describing hardware or OS concepts only by definition (e.g. 'RAM is temporary memory') without linking them to observable behaviour, so answers to application questions such as why a machine slows down or loses unsaved work are marked incomplete.
Candidates revise from definition lists and never practise the 'explain what happens when' style of question; the exam often asks for consequences and comparisons (RAM vs ROM, volatile vs non-volatile, cold boot vs warm boot) rather than pure definitions.
What to do instead
For each component, prepare a three-line card: what it is, what happens if it fails or is too small, and one everyday example. Rehearse comparisons in a two-column table (volatile/non-volatile, primary/secondary storage) and answer past-style questions in full sentences that include the consequence.
Answering internet and web-technology questions by mixing up the protocol layers and services: calling HTTP a mail protocol, confusing URL with domain name, or stating that email is delivered directly to the recipient's computer.
Candidates use browsers and email daily but never see the underlying model, so terms like protocol, server, DNS and URL are learned as isolated words; under exam pressure they attach a familiar word to the wrong function.
What to do instead
Draw a one-page map: application protocols (HTTP/HTTPS for web, SMTP for sending mail, POP3/IMAP for retrieving), then DNS resolving a name to an IP, then the browser requesting a page from a server. Label each arrow with the protocol and re-draw it from memory before the exam.
In the BPO/KPO and customer-service questions, giving a generic answer such as 'be polite to the customer' instead of naming the process step, SLA element, or escalation action the scenario requires.
Soft-skill topics feel obvious, so candidates do not prepare structured vocabulary (first-call resolution, escalation matrix, turnaround time, service level, quality audit); they then write vague sentences that earn partial marks at best.
What to do instead
Build a scenario-response template: acknowledge, clarify, act within scope, escalate with the required information, confirm and close. Learn five BPO terms with a one-line definition and one example each, and practise writing answers that name the step and the responsible role rather than describing a friendly attitude.
Treating cyber-safety and data-privacy questions as general awareness and writing 'use a strong password and don't share it', missing the specific mechanism asked for (phishing indicators, OTP fraud, two-factor authentication, data minimisation, consent, secure disposal of devices).
Candidates revise safety from posters and slogans rather than from scenario reasoning, so they cannot identify which control applies to which threat, and they omit the legal or ethical dimension of handling personal data.
What to do instead
Prepare a threat-to-control table: phishing, malware, weak credentials, shoulder surfing, insecure Wi-Fi, data leakage. For each, list the warning sign, the preventive control and the correct response. Add three privacy principles (collect only what is needed, take consent, delete when no longer required) with a workplace example of each.
Losing marks in data entry tasks by entering values that look right but break validation: dates in mixed formats, leading zeros dropped from codes, extra spaces, or one field shifted so every subsequent column is wrong.
Candidates type at speed without checking the first row against the source, and spreadsheets silently convert entries such as 01/02 into a date or strip leading zeros, so the error is invisible unless the candidate compares field by field.
What to do instead
Adopt a check-first routine: enter one complete record, compare it to the source field by field, then continue. Format code and phone fields as Text before typing, use data validation for date and list fields, and finish with a spot check of the first, middle and last records plus a count of records entered against the source.
In the project and viva, being unable to explain the candidate's own submitted work: unable to say which tool created a table, why a particular formula or query was used, or what a screenshot in the report demonstrates.
Projects are often assembled from copied templates or completed in a hurry, so the candidate has output but no memory of decisions; viva questions target exactly this gap and expose work that was not done independently.
What to do instead
Keep a one-page project log written as you work: date, task, tool used, the exact formula/query/command, and the problem solved. Before the viva, rehearse a two-minute walkthrough of the project and a one-sentence justification for each major element, and be ready to reproduce one formula or query live.
In the communication-skills section, writing letters or emails with the correct content but wrong structure: no subject line, missing salutation or complimentary close, informal contractions in a formal message, or a single unparagraphed block of text.
Candidates draft the way they message friends, and the marking scheme rewards format and tone as much as content; they also confuse formal, semi-formal and informal registers and apply one style everywhere.
What to do instead
Memorise the skeleton for each format: email (subject, salutation, purpose paragraph, details, action, close, signature) and formal letter (sender, date, receiver, subject, salutation, body paragraphs, complimentary close). Practise rewriting one informal message into formal register, and check tone, spelling and paragraphing as a separate final pass.