See exactly what you get for ₹99

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.

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."

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.

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.

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.

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.

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.

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.

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.

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.