My progress
Menu

Frontend Developer · entry diagnostic

Frontend Developer: entry diagnostic

Ten questions on the core lessons this path builds on. It is for your own planning: it doesn't unlock anything, and it doesn't replace the final examination. Each explanation links to the core module to revisit if you got it wrong.

10 questions · for your own planning · it does not unlock anything and does not replace the final examination ·

1. A product card shows a photo of a 1 kg bag of rice, and next to it the text "Basmati rice, 1 kg, ₹145". What alt text suits the photo best?

Why each option is right or wrong

  • “alt="image", so the screen reader announces that a picture is there” (Incorrect): "Image" tells the listener nothing, and screen readers already announce that it is an image.
  • “The file name, such as alt="rice-1kg-front.jpg", so it matches the stored photo” (Incorrect): File names are for computers; read aloud they are noise.
  • “A long description of the bag's colours, logo and printed text, for completeness” (Incorrect): Extra detail slows the listener down and repeats what the card already says.
  • “Empty alt (alt=""), since the text beside it already says it all” is correct.

    The image adds nothing the text doesn't already say, so a screen reader can skip it instead of repeating it.

    • Rule of thumb: alt text says what the image tells someone who can't see it, in this spot on the page.
    • If the image were the only label: then it would need alt text such as "Basmati rice, 1 kg bag".

📖 Revise: Module 12: Webpage Content

2. A signup form shows "Email" as grey placeholder text inside the box, with no other label. What's the main problem?

Why each option is right or wrong

  • “Placeholder text loads more slowly than a label on mobile” (Incorrect): There's no real speed difference; the issue is what people can see and hear.
  • “Browsers refuse to submit forms whose inputs have only a placeholder” (Incorrect): Forms submit normally; the problem is for the people filling them in.
  • “Email fields must use a placeholder that contains an example address” (Incorrect): An example can help, but it doesn't replace a label.
  • “The hint vanishes on typing and may not be read as the field's name” is correct.

    Placeholders disappear as soon as typing starts, are often low contrast, and aren't a dependable accessible name.

    • Fix: a visible <label for="email"> linked to the input; keep placeholders for short examples.
    • Check: click the label text; the input should get focus.

📖 Revise: Module 13: Forms and Inputs

3. On a 360 px wide phone, a three-column product grid squeezes each card to about 100 px. Which CSS change fixes it best?

Why each option is right or wrong

  • “Set every card to width: 300px so it keeps its desktop size” (Incorrect): Fixed widths overflow small screens and cause sideways scrolling.
  • “Hide two of the three columns on phones with display: none” (Incorrect): That hides products from phone users instead of rearranging them.
  • “Shrink the font on phones so the text fits inside the narrow cards” (Incorrect): Smaller text is harder to read and doesn't fix the layout.
  • “grid-template-columns: repeat(auto-fill, minmax(160px, 1fr))” is correct.

    The grid fits as many 160 px-or-wider columns as the screen allows: one or two on a phone, more on a laptop.

    • Why it works: the layout adapts to the space without a breakpoint for every device.
    • Check: test at 320 px and at 200% zoom.

📖 Revise: Module 16: Responsive Websites

4. A list of 200 products each has its own click listener. A teammate suggests one listener on the list instead. Why does that work?

Why each option is right or wrong

  • “Browsers allow only one click listener per page” (Incorrect): Pages can have many listeners; the question is which is simpler and lighter.
  • “A single listener makes each click run 200 times faster” (Incorrect): Delegation saves memory and set-up, but clicks weren't 200 times slower to begin with.
  • “Listeners on list items stop working once the list scrolls off screen” (Incorrect): Scrolling doesn't remove listeners.
  • “Clicks bubble up to the list, which checks event.target” is correct.

    Events travel from the clicked element up through its parents. One listener on the parent handles every child, including

    • Name: this is event delegation.
    • Use closest(): event.target.closest('li') finds the product even if an inner element was clicked.

📖 Revise: Module 19: Browser Interactions

5. Two product requests start at once with Promise.all, and one of them fails. What happens?

Why each option is right or wrong

  • “The successful result is returned and the failure is silently ignored” (Incorrect): That would hide errors; Promise.all doesn't do it.
  • “Both requests are retried automatically until they succeed” (Incorrect): Nothing retries unless you write the retry.
  • “The browser waits with no end, because one of the two promises doesn't settle” (Incorrect): A failed request settles (as rejected); it doesn't hang.
  • “The whole Promise.all rejects with the first error” is correct.

    Promise.all succeeds only if every promise does. One failure rejects it, even though the other request may have finished.

    • If you want each result anyway: use Promise.allSettled and check each status.
    • Show it: catch the error and show a message, not a blank page.

📖 Revise: Module 24: Asynchronous Programming

6. A function is typed function total(items: { price: number; qty: number }[]): number. Someone calls total([{ price: "45", qty: 2 }]). What happens?

Why each option is right or wrong

  • “It runs and returns 90, because TypeScript converts the string to a number” (Incorrect): TypeScript doesn't convert values; it checks them before the code runs.
  • “It crashes in the browser with a TypeScript error” (Incorrect): Type errors are reported when checking or building, not in the browser.
  • “Nothing: TypeScript only checks variables, not function arguments” (Incorrect): Arguments are checked against parameter types; that's one of the main uses.
  • “The type check reports that "45" isn't a number, before the code runs” is correct.

    The mistake is caught in the editor or tsc, so it doesn't ship.

    • Fix the caller: convert with Number() where the data comes in, and check it isn't NaN.
    • Limit: types don't check data from an API at run time; check that where it arrives.

📖 Revise: Module 27: TypeScript Foundations

7. A React counter does count = count + 1 on a plain variable when a button is clicked, but the screen keeps showing 0. Why?

Why each option is right or wrong

  • “React buttons can't change numbers, only text” (Incorrect): Buttons can update any value held in state.
  • “The click event doesn't fire inside a component that also holds a variable” (Incorrect): The click fires; the screen just doesn't update.
  • “The variable must be declared with var instead of let to be shared” (Incorrect): var doesn't make React render either.
  • “Changing a plain variable doesn't make React render again” is correct.

    React re-renders when state or props change. A plain variable is reset on each render and doesn't trigger one.

    • Fix: const [count, setCount] = useState(0) and setCount(c => c + 1).
    • Why the function form: it uses the latest value when several updates happen together.

📖 Revise: Module 33: State and Events

8. A component fetches products in useEffect with no dependency array, then saves them in state. The network panel shows the request repeating endlessly. Why?

Why each option is right or wrong

  • “The API is rate-limited and keeps asking the browser to retry” (Incorrect): A rate limit would show 429 errors, not an endless stream of successful requests.
  • “React Strict Mode makes every effect run forever in development” (Incorrect): Strict Mode runs effects twice on mount in development, not endlessly.
  • “fetch can't be used inside React components at all” (Incorrect): It can; the issue is when the effect runs.
  • “Each state update re-renders, and the effect runs after every render” is correct.

    With no dependency array the effect runs after every render. It sets state, which renders again, which runs it again.

    • Fix: useEffect(() => { ... }, []) to run once, or list the values it depends on.
    • Better still: use a data-fetching library or a server component, which handle caching and repeats.

📖 Revise: Module 34: React Hooks

9. A React checkout form shows "Enter a valid PIN code" in red as soon as the page opens, before anyone has typed. What's the better approach?

Why each option is right or wrong

  • “Remove validation so no message ever appears” (Incorrect): Then wrong PIN codes reach the order.
  • “Show the message in a pop-up alert so it's harder to miss” (Incorrect): Alerts interrupt and still appear too early.
  • “Turn the field border red without any text, to keep the form tidy” (Incorrect): Colour alone isn't enough; some people can't tell red from green.
  • “Check on blur or on submit, and link the message to the field” is correct.

    Messages should appear after someone has had a chance to type, and be tied to the field so screen readers announce them.

    • Link it: aria-describedby pointing to the message, plus aria-invalid="true".
    • On submit: move focus to the first field with an error.

📖 Revise: Module 35: Forms and Validation in React

10. Before release, which check best shows a React page works for a keyboard-only user?

Why each option is right or wrong

  • “An automated accessibility scan reporting zero issues” (Incorrect): Scans find many problems, but not whether focus order and traps actually work.
  • “Checking that every image has alt text in the source code” (Incorrect): Alt text matters for screen readers but says nothing about keyboard use.
  • “Making sure the page scores 100 for performance in Lighthouse” (Incorrect): Speed and keyboard access are different things.
  • “Completing the main task with Tab, Enter, Space and Escape only” is correct.

    Doing the real task by keyboard shows whether everything can be reached, focus is visible and dialogs can be closed.

    • Watch for: focus disappearing, a dialog you can't leave, or controls Tab skips.
    • Pair it: run an automated scan too; each finds things the other misses.

📖 Revise: Module 39: Frontend Quality

← PreviousPath guide
ProLearners Assist