Add Case-Insensitive Search to a Support Ticket Queue UI and Debug Its Behavior

You are given the source code of a small support ticket queue web app. The interview is open book: you may use any documentation you normally would, and you may spend the first few minutes reading the code before changing anything. The app currently has: - two tabs, Unresolved and Archived; - a ticket list that shows each ticket's priority and assignee; - a search box that does nothing yet; - an activity panel that opens on the right when you click any ticket row. The source does not name the UI framework. Assume a component-based framework such as React, and say where your answer depends on that choice. ### Clarifying Questions - Should the search apply only within the active tab, and should the query stay in place when the user switches tabs? - Does a match mean the query appears anywhere in the title or the assignee name, or only at the start of a word? - How should unassigned tickets be treated when matching on assignee name? - If the ticket whose activity panel is open no longer matches the search, should the panel stay open? - Is the ticket data already loaded in the browser, or should search call a server? - Should leading and trailing spaces in the query be ignored? ### Part 1 — Make the search box filter the list Make the search box filter the ticket list by ticket title or assignee name. Matching is case-insensitive: a ticket stays visible if its title or its assignee's name matches the query, whatever the letter case of either. ```hint What is new state, and what is derived Decide which value the search adds to the app's state, and whether the filtered list should be stored or computed from what is already stored. Think about what could go stale if it is stored. ``` ```hint Read the data shape first Before writing the comparison, check how a ticket and its assignee are represented in the existing code, including what an unassigned ticket looks like. ``` #### What This Part Should Cover - A controlled search input whose query is the only new piece of state - A filtered list derived from the tickets, the active tab and the query, matching both fields case-insensitively - Empty or whitespace-only queries, unassigned tickets and an empty result - How the search interacts with the tabs and the activity panel ### Part 2 — Debug behavior that does not work as expected Next, the interviewer points to parts of the app that do not work as expected and asks you to find and fix the causes. The source does not list the defects. For practice, treat each hypothetical symptom below as a bug report about this app. For each one, explain how you would reproduce it, how you would narrow down the cause in the code, and how you would fix it. 1. Clicking a row sometimes opens the activity panel for a different ticket than the one clicked, especially after the list has been filtered. 2. After switching from Unresolved to Archived, the activity panel still shows a ticket from the Unresolved tab. 3. The ticket list lags one keystroke behind the search box: typing "lo" shows the results for "l". ```hint Reproduce before reading For each symptom, find the shortest sequence of clicks or keystrokes that triggers it every time. That sequence usually points at the piece of state involved. ``` ```hint Identity versus position For the mismatched panel, compare how a row records which ticket it represents with how the panel looks that ticket up. ``` #### What This Part Should Cover - A systematic loop: reproduce, form a hypothesis, inspect state and props with the browser and framework developer tools, fix, retest - Root causes in ticket identity, derived state, and event or request timing, rather than patches over the symptom - An explanation of each fix, and a check that it does not break the Part 1 search ### What a Strong Answer Covers - Reading the existing code first and following its conventions - Minimal state (query, active tab, selected ticket id) with everything else derived - Selecting and rendering tickets by stable id, never by list position or a copied object - Narrating the reasoning while working open book, and using documentation deliberately - Search usability: a label, a clear empty state, and no lost focus while typing ### Follow-up Questions - The queue grows to tens of thousands of tickets. What changes in the filtering and in rendering the list? - How would you highlight the matching text in the title and the assignee name? - How would you put the query and the active tab into the URL so that a filtered view survives a reload and can be shared? - What automated tests would you write for the search and for each bug fix?