Three real slices of Module 1: the revision notes, the explained Q&A, and the rapid-fire mock. Tap an option on any question — every lesson works like this.
Interviewers do not give you options — they ask a question and listen to how you answer it. So every question in this pack is written the way it is actually asked, and every answer gives you the words to say, the follow-up that comes next, and the thing that loses candidates the round. Try the two below; this is exactly how every lesson behaves.
Q1 What does this print, and why? 📣 Reported in: TCS, Infosys, Wipro, Cognizant JS rounds
console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");Output: A D C B
Why: JavaScript runs one synchronous call stack, so A and D print first. Everything asynchronous is queued, and there are two queues with different priority: the microtask queue holds promise callbacks, and the macrotask queue holds timers and events. Once the stack empties, the event loop drains the entire microtask queue before taking a single macrotask — so the promise callback C beats the zero-millisecond timer B.
Follow-up: "Does setTimeout(fn, 0) run immediately?" → No. Zero is a minimum delay, not a promise — it runs after the current stack and all pending microtasks.
Don’t say: "A B C D", assuming timers and promises share one queue. That is the exact trap this question exists for.
Q2 Why does React need a key on lists, and why is the array index a bad key? 📣 Reported in: Wipro, Cognizant, Accenture, startup screenings
Say this: The key is how React identifies which item is which between renders. Without it, React falls back to matching by position, so it cannot tell an item that moved from an item whose content changed. Using the index is precisely that failure case — delete the first item and every remaining index shifts by one, so React reuses the wrong DOM node. The visible symptom is per-item state landing on the wrong row: a checked checkbox or a typed input value jumping to a different item. So I use a stable unique id from the data; the index is only acceptable for a static list that is never reordered and has no per-item state.
Follow-up: "Can I use Math.random()?" → No — it changes every render, so React unmounts and remounts every item, destroying state and performance.
Don’t say: "The key is just to remove the console warning."
The full pack has in-depth 📖 full notes + a ⚡ quick-revision cheat sheet for every technology, plus 150 explained interview questions like these across HTML, CSS, JavaScript, React, Node & Express and SQL/MongoDB, 52 mock-interview questions, 50 DSA problems with JavaScript solutions and the follow-ups, and a company-wise module covering what TCS, Infosys, Wipro, Cognizant, Accenture, Capgemini, HCL, product companies and startups actually ask — with every answer written out. No multiple choice anywhere, because no interviewer gives you options.
Every tech module gives you two study lessons: a 📖 full-notes lesson that teaches the topic in depth, and a ⚡ cheat sheet like this one for quick revision before the Q&A. Here are the first 3 sections of the HTML cheat sheet from Module 1 (Core web — HTML/CSS/JS).
⚡ Cheat sheet · quick revision before the Q&AInterviewers do not ask "what is HTML". They ask the things that show whether you understand how a browser thinks: semantics, the document structure, forms, and the handful of attributes that affect loading and accessibility. Read this in 15 minutes, then attempt the Q&A set.
<!DOCTYPE html> ← tells the browser "modern HTML5, standards mode"
<html lang="en">
<head> ← metadata: NOT shown on the page
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Shown in the tab</title>
<link rel="stylesheet" href="style.css">
</head>
<body> ← everything the user sees
...
<script src="app.js" defer></script>
</body>
</html>Interview line: "Without DOCTYPE the browser falls into quirks mode and emulates old IE layout bugs — so DOCTYPE is not decoration, it changes rendering."
The browser parses this text into the DOM (Document Object Model) — a tree of nodes that JavaScript can read and change. HTML is the blueprint; the DOM is the living building.
A <div> says "a box". A <nav> says "a box that contains navigation". Same pixels, different meaning — and meaning is what screen readers, search engines and other developers use.
| Tag | Use it for |
|---|---|
<header> / <footer> | top/bottom of a page or of an article |
<nav> | main navigation links |
<main> | the one primary content area (only one per page) |
<section> | a thematic group, usually with a heading |
<article> | self-contained content that makes sense alone (blog post, product card) |
<aside> | tangential content — sidebar, related links |
<figure> + <figcaption> | image/diagram with a caption |
Three reasons to give when asked "why semantic HTML?": accessibility (screen readers navigate by landmarks), SEO (search engines weigh structure), maintainability (code reads like an outline).
div, p, h1–h6, ul, section, form.span, a, strong, em, img, input. Width/height and vertical margins are ignored on inline elements.Classic trick question: "Can you put a <div> inside a <p>?" — No. A paragraph can only contain inline (phrasing) content; the browser will silently close the <p> and your layout breaks.
🔒 4 more sections in the full cheat sheet:
+ 2 quick-check interview questions at the end of every study lesson, a ⚡ cheat sheet like this in every module — and a 📖 full-notes lesson that teaches the whole topic in depth before you revise.
After the notes comes the Q&A lesson — 25 questions asked the way an interviewer asks them, each with a model answer, the follow-up probe and what not to say. Answer aloud first, then open the answer. Here are the first 5 from Module 1.
Q1 What does <!DOCTYPE html> do, and what breaks if you remove it? 🏢 TCS, Infosys, Capgemini
Say this: It is not a tag — it is an instruction to the browser saying "render this page in standards mode". If I remove it, the browser falls back to quirks mode, where it emulates old non-standard behaviour from the 1990s. The page still loads and JavaScript still runs, but layout silently breaks — the most famous case is the box model, where in quirks mode width includes padding and border, so every fixed-width element comes out a different size than I designed.
Follow-up: "Why is HTML5's doctype so short compared to the old HTML4 one?" → HTML5 is not based on SGML, so it does not need a DTD reference. <!DOCTYPE html> is the shortest string that still triggers standards mode.
Don’t say: "The page won't load" or "JavaScript stops working" — both are false, and interviewers use exactly those as trap options.
Q2 What goes in <head> versus <body>, and why does the distinction matter? 🏢 TCS, Wipro
Say this: The head holds information about the page that the user never sees rendered — <title>, <meta> for charset and viewport and description, <link> to stylesheets and the favicon, and scripts. The body holds everything that is actually painted on screen. It matters because the browser reads the head before rendering: charset must be declared there or text can be decoded wrongly, and the viewport meta must be there or the whole page renders as if it were desktop-width on a phone.
Follow-up: "Where should the CSS link go and where should the script go?" → CSS in the head so the page does not flash unstyled content; scripts either at the end of the body or in the head with defer.
Don’t say: "It doesn't matter, browsers fix it" — browsers do auto-correct some misplaced tags, but relying on that is exactly what the question is testing.
Q3 Why use semantic tags like <header>, <nav>, <main>, <article> instead of <div> everywhere? 🏢 Infosys, Accenture, Cognizant
Say this: Because a <div> tells nobody anything — it is a generic box. Semantic tags describe meaning, and I get three concrete benefits. Accessibility — a screen-reader user can jump straight to the <nav> or skip to <main>; with divs there is nothing to jump to. SEO — search engines understand which part of the page is the actual article versus the sidebar. Maintainability — anyone opening my HTML sees the page structure without reading class names. In my project I used header/nav/main/footer for the shell and <article> for each card, and kept divs only for pure layout wrappers.
Follow-up: "Is using a div ever correct then?" → Yes — when you need a grouping box purely for styling or layout and no semantic tag fits, a div is the right choice. Semantic-washing (using <section> just to avoid divs) is also wrong.
Follow-up: "Difference between <section> and <article>?" → An article makes sense standing alone and being syndicated — a blog post, a product card; a section is a thematic grouping inside a document and normally has a heading.
Don’t say: "Semantic tags make the page load faster" — they do not. The benefits are accessibility, SEO and readability.
Q4 What is the difference between <div> and <span>? 🏢 TCS, Wipro, Capgemini
Say this: Both are generic containers with no meaning of their own. The difference is display: a div is block-level — it starts on a new line and takes the full available width — while a span is inline, it flows inside a line of text and takes only as much width as its content. So I use a div to wrap a card or a section, and a span to style a few words inside a sentence, like highlighting a price.
Follow-up: "Can you put a div inside a span?" → It is invalid HTML, because a span may only contain phrasing content. The browser may still render something, but the DOM you get is not the one you wrote — the parser can move nodes around.
Don’t say: "Div is for CSS and span is for JavaScript" — both are used by both. And note block vs inline is only the default; CSS display can change either.
Q5 When would you use an id and when a class? 🏢 Infosys, Cognizant
Say this: An id identifies exactly one element on the page and must be unique — I use it when something needs to be addressed individually: a URL fragment like #pricing, a <label for> pointing at an input, or a getElementById lookup. A class can be reused on any number of elements and is what I use for styling, because styling is almost always "all elements of this kind". One element can carry several classes, like class="card card-featured".
Follow-up: "Which wins in CSS if both apply?" → The id. Specificity order is inline style > id > class/attribute/pseudo-class > element. That is also why teams prefer classes for styling — ids are hard to override later.
Follow-up: "What happens if two elements share an id?" → The HTML is invalid; getElementById returns only the first one, and bugs from that are very hard to spot.
Don’t say: "Ids are faster so use them for styling" — the performance difference is irrelevant today and the maintenance cost is real.
🔒 20 more explained questions in this lesson — and a 25-question Q&A lesson like this in every tech module, plus the company-wise module with every answer written out.
Every module ends with a mock interview — answer each aloud in 30–60 seconds, then check the key points. First 3 of the 12-question Module 1 mock:
Q1 What happens to a page if you delete the doctype declaration?
Good answer hits: the browser switches to quirks mode · the page still loads and JS still runs · layout breaks silently, classically the box model · doctype is an instruction, not a tag.
One-liner: It drops into quirks mode — the page works but the layout maths changes underneath you.
Q2 Give me three reasons to use semantic HTML instead of divs.
Good answer hits: accessibility — screen readers can navigate to nav and main · SEO — search engines understand the structure · readability and maintenance for the next developer · a div is still correct when no semantic tag fits.
One-liner: Accessibility, SEO and readability — divs tell nobody anything about the content.
Q3 localStorage, sessionStorage or a cookie — where would you keep a login token, and why?
Good answer hits: an httpOnly Secure SameSite cookie is the safer default, because JavaScript cannot read it so XSS cannot steal it · localStorage is readable by any script on the origin · cookies go to the server on every request, which is their purpose · cookies need CSRF protection.
One-liner: httpOnly cookie plus CSRF protection — localStorage is convenient but any injected script can read it.
🔒 9 more mock questions in this lesson, and a mock at the end of every module.
Full course
6 modules · 35 lessons · lifetime access
Every module: notes → 25 explained Q&A → mock. Plus the practical round and the company-wise module (TCS, Infosys, Wipro, Cognizant…). 7-day money-back guarantee.