Haryana BSEH Senior Secondary NSQF IT-ITeS common mistakes
Haryana BSEH Senior Secondary NSQF IT-ITeS · Understand the traps and how to avoid them.
In a spreadsheet task, the candidate types =B2*C2 (a rate or tax cell such as a fixed GST/percentage cell) and fills it down the column; the copied cells then multiply by blank cells or by the wrong row and return 0, #VALUE! or absurd totals, and the candidate submits the sheet without checking the formula bar of the copied cells.
Relative referencing is learnt first and drilled with simple column sums, while mixed and absolute references are practised only once and rarely appear in class tests, so under exam pressure the candidate never thinks of locking the fixed cell.
What to do instead
Before the exam, practise the 'rate cell' pattern at least five times: put the rate in one cell, write =B2*$C$1, press F4 to toggle $C$1 → C$1 → $C1 → C1 so the toggling is automatic, then fill down. In the exam, click three or four of the filled cells and read the formula bar to confirm the rate cell stayed fixed, and re-total the column with a calculator to see whether the answer is plausible.
The candidate completes a mail merge but the printed output is either the main document with «AddressBlock» / «Name» placeholders intact, or 40 identical letters, or only the first record; sometimes only the main document is saved and the merged document is never created.
Mail merge has six sequential steps and candidates rush from 'Insert Merge Field' straight to Print, skipping 'Preview Results' and 'Finish & Merge → Edit Individual Documents' because these buttons are not needed for the marks in a written answer, only in the practical.
What to do instead
Drill the fixed sequence: create data source → link → insert fields → Preview Results (check record 1,2 and last) → Finish & Merge → Edit Individual Documents → save as a separate file. In the practical, tick off 'previewed at least three records' before printing, and save both the main document and the merged letters with clear file names.
During the typing and data-entry test the candidate looks at the keyboard, types digits on the top row with the wrong finger, uses the left Shift for right-hand letters (or Caps Lock instead of Shift), and hits the spacebar with the thumb of the wrong hand, so speed may be acceptable but errors and backspacing push net speed down.
Practice time is spent typing free text for fun rather than doing home-row and reach drills, the school keyboards have worn or blank legends, and the candidate has never measured gross versus net speed, so the error penalty in the marking scheme is invisible to them.
What to do instead
Run 10-minute daily drills: home-row asdf jkl; first, then top-row digits with the correct finger, then a mixed paragraph, always with hands covered by a cloth or cardboard. Practise Left Shift for letters typed by the right hand and vice versa. Track gross words per minute and accuracy separately, and target 95%+ accuracy before pushing speed.
In a loop or array question the candidate writes for i in range(len(a)): and then accesses a[i+1], or uses <= instead of <, and the program crashes with IndexError/ArrayIndexOutOfBounds; or they set the sum/initial value to 1, and the trace output is wrong even though the code 'looks right'.
Candidates memorise syntax patterns rather than tracing execution, and under time pressure they translate a natural-language statement like 'compare each element with the next' directly into code without checking what happens at the last element.
What to do instead
Before writing code, draw the array with its index numbers above it and hand-execute the loop for the first and last iteration on paper (a small trace table with columns i, value, running total). Then code using range(len(a)-1) for neighbour comparisons, and test the program with an empty list, a one-element list and the actual sample data.
The candidate calls the unique identifier a 'foreign key', defines a foreign key as 'a key from another country/table' without naming the referenced primary key, and writes query criteria for a numeric field with quotes ('WHERE Marks > "60"') or leaves the criteria row empty so the query returns every record.
Keys are taught as definitions to be memorised from a list rather than built and broken in a live two-table relationship, so the candidate has never seen what happens when a foreign key value has no matching parent record and cannot connect the concept to the actual field names in the query grid.
What to do instead
Build a two-table practice database (Students, Marks) and tick Enforce Referential Integrity, then try to enter a Marks row for a non-existent StudentID and read the error. In queries, drag the field, type the criteria without quotes for numbers and with quotes for text, and run a blank-criteria query once to see the difference.
HTML answers and practical files show unclosed tags (<p> without </p>), crossed nesting (<b><i>text</b></i>), attributes written without quotes (align=center with spaces), and a file saved as 'page.txt' or from a word processor, so the browser shows raw markup or the page does not open at all.
Candidates write HTML in an editor that never shows the source and have no habit of validating; browsers silently repair many errors, so the candidate never receives feedback that nesting is wrong, and Windows hides file extensions so '.html' is guessed.
What to do instead
Type in Notepad/VS Code, save with 'Save as type: All files' and a literal name.html, and turn on file-name extensions in Explorer. After writing, run the page through the W3C validator or read the source view in the browser, and check every opening tag against a closing tag by indenting the nested lines.
For green IT and workplace-safety questions the candidate writes one-line generic statements such as 'green IT means using computers less' or 'keep the workplace safe', with no mention of power-management settings, e-waste/handover to authorised recyclers, duplex/ink-saving printing, virtualisation or server consolidation, and no mention of ergonomics, cable management, fire-exit or electrical-safety rules.
This domain is treated as filler that can be revised the night before, so the candidate answers from common sense and never learns the specific practices and vocabulary that carry the marks.
What to do instead
Build a one-page keyword bank per topic: Green IT (power management, Energy Star, virtualisation, telecommuting, duplex printing, e-waste, refurbishment, responsible disposal) and Safety (ergonomic chair/monitor height, 20-20-20 eye rule, no food near hardware, anti-static precautions, fire extinguisher class, electrical hazard reporting). Answer in points, each naming one practice and its benefit.
Asked about the IT-ITeS industry, the candidate describes it only as 'computers and software', cannot name the sub-sectors (IT services, business process management/BPO, software products and engineering R&D, hardware, IT-enabled services such as e-commerce, animation and gaming, and domestic services), and lists job roles in random order instead of the entry → executive → team lead → manager pathway with the qualification and experience for each step.
The first chapter is revised as a list of headings without a structure, and the candidate has no mental map connecting sub-sector to example employer to job role, so recall collapses under exam phrasing that asks for examples.
What to do instead
Make a three-column table for each sub-sector: sub-sector | example work/employer | two entry-level job roles. Then draw one vertical career ladder for a role you know (e.g., data-entry operator → verification executive → team lead → process manager) with the years of experience and the skill needed at each step, and memorise that ladder rather than a list of disconnected titles.
The practical file/portfolio contains screenshots or printouts with no name, date, aim or steps; the candidate cannot open their own submitted file when asked, and in the viva answers 'I did not make that part' or 'my friend helped' when asked to explain a formula, a query or a block of their own code.
The project is assembled the week before submission from borrowed files, and the candidate treats the viva as a formality, so they have never rehearsed explaining their own output and cannot connect a line in the report to a decision they made.
What to do instead
Keep a lab journal from day one: for each practical write aim, tools used, steps, output printout with name and date, and one line on an error faced and how it was fixed. Before the viva, pick three items (a formula, an SQL query, a loop) and explain each aloud in 60 seconds to a peer who then asks 'why this and not the alternative'.
Before printing, the candidate hits Ctrl+P without checking the preview: in a spreadsheet the last two columns spill onto a separate page or show ####, in a Word table the right margin is cut off, and in a slide handout the notes are printed dark or orientation is wrong.
Candidates test only on screen, never look at the Print Preview, and do not know that page orientation, margins, scaling/print area and column width are separate settings that must be set deliberately.
What to do instead
Always open Print Preview first and fix issues there: set Orientation and Margins, in a spreadsheet select the range and use Print Area → Set Print Area with 'Fit to 1 page wide', and widen columns showing ####. In Word use the table's AutoFit to Window and check page breaks with the Layout view before printing.