An Original Practice Interview

Introduction

This is lesson 4 of chapter 9 and the last lesson of the course (domain interview). You now have a method (lesson 1), data structures (lesson 2), and algorithms (lesson 3). This lesson puts them together in an original practice interview you can run on your own or with a partner, and closes with a readiness review of the whole pathway.

The official ninth course, Coding Interview Preparation, centers on interview communication, pseudocode, data structures, and algorithms (source: https://www.coursera.org/learn/coding-interview-preparation (opens in a new tab)). The problems below were written by OnLevelUp for learning. They are not real interview questions from any company, and they do not reproduce the official course's graded work. Completing the official program and its assessments on Coursera remains the only way to earn the Meta certificate; OnLevelUp practice does not grant it.

Learning objectives

By the end of this lesson you can:

1. Run a timed practice interview with a clear structure and self-assessment.
2. Solve a coding problem and a front-end component problem while explaining your reasoning.
3. Answer common behavioral and technical-communication prompts with a structured answer.
4. Discuss trade-offs, testing, accessibility, and performance for an interface solution.
5. Receive feedback gracefully and iterate on your own solution.
6. Review your readiness across the nine areas of the pathway and plan your next steps.

1. How a front-end technical interview is usually organized

Formats vary by company, so treat the following as a typical shape, not a rule:

Behavior counts as much as code: clarifying, thinking aloud, accepting hints, testing, and being honest about what you do not know.

2. Communication toolkit

Use short, repeatable phrases:

• Clarify: "Let me restate the problem to make sure I understand. Inputs are…, output is…. Is that right?"
• Plan: "My first idea is brute force, which is O(n²). I think a Map can bring it to O(n). Shall I go with that?"
• Narrate: "I'm going to keep two indexes, one per end."
• Test: "Let me trace the empty input and a one-item input."
• Reflect: "The trade-off is memory for speed. If the list were huge, I'd consider…"
• Recover: "I see a bug: the index stops one early. Fixing the loop condition."

Structured answers: STAR for behavioral questions

For "Tell me about a time…" prompts, use STAR:

1. Situation: the context in one or two sentences.
2. Task: your responsibility or the goal.
3. Action: what you did, in specific steps.
4. Result: the outcome, ideally measurable, and what you learned.

Example (original): "Describe a time you handled a disagreement in a team." S: In my capstone group, two of us wanted different filter designs. T: I owned the catalog page and had to decide with a week left. A: I wrote a short comparison of both options against the acceptance criteria, built a 30-minute prototype of each, and asked a classmate to try both. R: The URL-based filter won because testers could share links; we shipped on time, and I now compare options against criteria before arguing about taste.

3. Practice interview, part A: coding problem

Set a timer for 30 minutes. Write on paper or in a plain editor, without running code first. Follow the five steps from lesson 1.

Problem A (original)

Harbor Workshops logs each page view as an object { userId, page }, in time order. A "journey" is the sequence of pages one user visited. Write firstRepeatedPage(views, userId) that returns the first page that the given user visited for the second time, or null if there is none.

Example:

views = [
  { userId: 'u1', page: '/home' },
  { userId: 'u2', page: '/home' },
  { userId: 'u1', page: '/workshops' },
  { userId: 'u1', page: '/home' },
  { userId: 'u1', page: '/workshops' },
]
firstRepeatedPage(views, 'u1') -> '/home'

A model walk-through

Clarify. Is the log sorted by time? (Yes.) Can the same page appear in other users' entries? (Yes, ignore them.) Does "first repeated" mean the first page that becomes a repeat while scanning? Yes: /home repeats at index 3, before /workshops repeats at index 4.

Examples and edges. Unknown user → null. Empty log → null. One visit per page → null. Same page three times → still returns it at the second visit.

Plan. Scan once. Keep a Set of pages seen for that user. When a page is already in the set, return it. Brute force would, for each view, search all earlier views: O(n²).

Code.

function firstRepeatedPage(views, userId) {
  const seen = new Set();
  for (const view of views) {
    if (view.userId !== userId) continue;
    if (seen.has(view.page)) return view.page;
    seen.add(view.page);
  }
  return null;
}

Verify. Trace u1: /home added; u2 skipped; /workshops added; /home already present → return /home. Correct.

Complexity and follow-ups. O(n) time, O(p) space where p is the number of distinct pages for that user. Follow-up: "What if you must answer for many users repeatedly?" Build a Map<userId, Set> in one pass, or precompute the first repeat per user in one pass: O(n) total instead of O(n) per query. Follow-up: "What if the log is too large for memory?" Process as a stream, keeping per-user sets, and discuss storage limits or a probabilistic structure at a high level.

Common weaker alternatives. Collecting all journeys then using indexOf/lastIndexOf is O(n²). Sorting pages loses the visit order that the question depends on.

4. Practice interview, part B: front-end problem

Set another 30 minutes.

Problem B (original)

Build a SeatPicker React component. Props: seats (array of { id, label, taken }) and max (number of seats a user may select). Show each seat as a button. Taken seats are disabled. Selecting a seat toggles it. Stop the user from selecting more than max. Show "2 of 3 selected" and call onChange(selectedIds) when the selection changes. Make it accessible.

A model walk-through

Clarify. Should the selection reset if seats changes? (Assume no.) Is the component controlled or uncontrolled? (Uncontrolled with an onChange callback; mention a controlled version as an option.) Mobile touch support? (Buttons handle it.)

Design the state. The minimum state is the set of selected ids. The count, the "limit reached" flag, and the status text are derived from it, never stored separately.

Code.

import { useState } from 'react';

export function SeatPicker({ seats, max, onChange }) {
  const [selected, setSelected] = useState(() => new Set());

  function toggle(id) {
    const next = new Set(selected);
    if (next.has(id)) {
      next.delete(id);
    } else if (next.size < max) {
      next.add(id);
    } else {
      return;                                  // limit reached
    }
    setSelected(next);
    onChange?.([...next]);
  }

  const limitReached = selected.size >= max;

  return (
    <fieldset>
      <legend>Choose your seats</legend>
      <p role="status">{selected.size} of {max} selected</p>
      <ul className="seat-grid">
        {seats.map((seat) => {
          const isSelected = selected.has(seat.id);
          const blocked = seat.taken || (limitReached && !isSelected);
          return (
            <li key={seat.id}>
              <button
                type="button"
                aria-pressed={isSelected}
                disabled={blocked}
                onClick={() => toggle(seat.id)}
              >
                {seat.label}
                {seat.taken && <span className="visually-hidden"> (taken)</span>}
              </button>
            </li>
          );
        })}
      </ul>
    </fieldset>
  );
}

Verify with a test sketch.

test('limits selection to max', async () => {
  const user = userEvent.setup();
  render(<SeatPicker seats={seats} max={2} />);
  await user.click(screen.getByRole('button', { name: 'A1' }));
  await user.click(screen.getByRole('button', { name: 'A2' }));
  expect(screen.getByRole('button', { name: 'A3' })).toBeDisabled();
  expect(screen.getByRole('status')).toHaveTextContent('2 of 2 selected');
});

Talking points interviewers value.

• State minimalism: derived values are computed, not duplicated.
• Immutability: a new Set is created before setSelected, so React re-renders.
• Accessibility: real button elements (keyboard and screen reader support), aria-pressed for toggle state, a fieldset with a legend to group, a polite role="status" message, and a text alternative for "taken" rather than color alone.
• Keys: stable seat.id, not the index.
• Performance: for hundreds of seats this is fine; for thousands consider memoizing the seat button and passing a stable handler.
• Edge cases: max of 0, empty seats, a seat becoming taken after being selected (remove it from the selection in an effect or on prop change).

Weaker alternatives. A div with onClick loses keyboard access. Storing count in separate state creates inconsistency bugs. Storing selection on the seat objects mutates props.

5. Part C: technical discussion questions

Practice answering these aloud in 60–90 seconds each. Sample answers are summaries to compare against, not scripts.

6. Self-assessment rubric

After each practice round, score yourself 0–3 on each line (0 = missing, 1 = partial, 2 = good, 3 = strong). A total of at least 70% is a reasonable sign of readiness; this is an editorial threshold, not an official one.

Record what you missed and drill that one skill for a week (for example, binary search boundaries) rather than re-reading everything.

7. Readiness review of the whole pathway

Use this map to check yourself against the nine areas covered by this course. The official program has nine courses (source: https://www.coursera.org/professional-certificates/meta-front-end-developer (opens in a new tab)).

For each row, pick one concrete artifact from your own work as evidence: a repository link, a test, a design file, or a short write-up. A portfolio of three to five polished projects with clear READMEs, a clean Git history, and live demos usually communicates more than a long list of technologies.

A four-week plan after the course

• Week 1: redo problem A and two variants (different data, then a larger input). Write the complexity for each.
• Week 2: rebuild SeatPicker from memory, add tests, then add a keyboard shortcut and an accessibility audit.
• Week 3: practice 10 binary search, sorting, and recursion exercises; one behavioral STAR story per week.
• Week 4: two complete timed mock interviews (with a partner if possible), then polish your portfolio and profile.

8. Common pitfalls and exam tips

Exam tip: practice out loud. Silent practice builds code skill; spoken practice builds interview skill. Record yourself once and listen back.

Exam tip: close every answer with complexity and one test. It signals completeness.

Pitfalls:

• Memorizing solutions to published problems instead of the method.
• Jumping to the optimal solution without showing the reasoning.
• Ignoring accessibility in a UI problem.
• Over-engineering a simple component (extra state, extra libraries).
• Arguing with the interviewer instead of using hints.
• Claiming experience you do not have; say what you know and how you would learn the rest.
• Preparing only for code and not for behavioral questions.
• Treating practice scores as proof of the official credential; the certificate requires completing the official program.

9. Mini case study: debrief a failed mock interview

Situation. Priya runs a mock interview on Problem A. She starts typing after reading the prompt, builds nested loops, runs out of time with a half-working answer, and says nothing while stuck. Her partner reports: "You seemed to know the material, but I couldn't follow you."

Task. Write a debrief and an action plan using the rubric.

Solution, commented.

1. Diagnosis with the rubric. Understanding 0 (no questions), Planning 0 (no brute-force-then-improve), Correctness 1, Complexity 0 (never stated), Communication 0 (silence). The issue is process, not knowledge: she knows Set but did not think about it before coding.
2. Highest-leverage fix. Enforce the first 8 minutes: restate, two examples, one edge case, pseudocode, and only then code. A visible timer or a checklist on paper makes this habit automatic.
3. Communication drill. Practice a 60-second "plan out loud" for five different problems. Use the phrases from section 2.
4. Redo. Solve Problem A again with the method; compare against the model walk-through.
5. Measure. Rescore after two weeks. Expect Planning and Communication to move first, then Correctness.

Key terms

• STAR: Situation, Task, Action, Result structure for behavioral answers.
• Derived state: a value computed from existing state instead of stored.
• Rubric: a scoring guide used to assess an answer consistently.
• Mock interview: a practice interview run under realistic conditions.
• Portfolio: a curated set of projects that demonstrate your skills.
• Trade-off: a deliberate compromise between competing qualities.

Summary checklist

• I can run a timed practice interview with the five-step method.
• I think aloud, state complexity, and propose tests without being asked.
• I can build and explain a small accessible React component under time pressure.
• I can tell a STAR story about teamwork, conflict, and learning.
• I scored myself with the rubric and have a plan for the weakest area.
• I mapped each of the nine areas to evidence in my portfolio.
• I understand that the Meta certificate is earned only through the official Coursera program.

Sources

• Coding Interview Preparation (official ninth course): https://www.coursera.org/learn/coding-interview-preparation (opens in a new tab)
• Meta Front-End Developer Professional Certificate (official program page): https://www.coursera.org/professional-certificates/meta-front-end-developer (opens in a new tab)
• React documentation, Thinking in React: https://react.dev/learn/thinking-in-react (opens in a new tab)
• WAI-ARIA Authoring Practices (button and toggle patterns): https://www.w3.org/WAI/ARIA/apg/ (opens in a new tab)