Understand
30-second explanation
Build the interview-ready mental model before comparing implementations.
Scan once, incrementing a counter whenever `nums[i] == target`.
Interview contextWhat is testedWhere candidates slipHow to stand outExplore interview contextHide interview context
What's being tested
Whether you distinguish counting from searching (no early exit).
Where candidates slip
Breaking on the first match and returning 1.
How to stand out
Mention the frequency-map preprocessing for repeated queries and binary-search bounds for sorted data.
Choose
Compare the available approaches
Use constraints and trade-offs to select the route you can defend in an interview.
Learn & trace
Build each solution step by step
Move from the core idea to a visual trace, implementation, proof, and edge cases.
Approach 1 of 1 · Optimal
Count matches
1Hint 1Explore hintHide hint
How is this different from search? (Hint: don't return early.)
2Hint 2Explore hintHide hint
Increment a counter on every equality, scanning the whole array.
3Hint 3Explore hintHide hint
Many queries? Build a frequency map once for O(1) lookups.
A · Core idea
Count how many times a value appears by scanning once and bumping a counter on every match. The key discipline: don't stop at the first match — counting requires visiting every element.
Why no early exit. Search returns on the first hit; counting must keep going to tally all of them. Breaking early is the classic copy-from-search bug.
Why linear is optimal here. For a single one-off query on unsorted data, you must examine each element, so O(n) is the floor. If you had to answer many count queries, you'd preprocess a frequency map once (O(n)) and then answer each query in O(1).
On sorted data. If the array were sorted, the matches form a contiguous block, so two binary searches (first and last position) count them in O(log n) — worth mentioning.
B · Visual dry run
Interactive dry run
Select a frame to connect the decision with its visual state.
nums = [1, 2, 2, 3, 2], target = 21
≠ 2
count=03C · Code with teaching comments
D · Why it works and complexityO(n) timeO(1) spaceOpen the invariant and proofExplore the proofHide the proof
ComplexityO(n) time, O(1) space — every element is compared once; no early termination because all matches must be counted.
E · Edge cases and pitfalls5nums = [1, 2, 3], target = 5 — Absent → 0.Explore edge casesHide edge cases
Edge cases handled
nums = [1, 2, 3], target = 5Absent → 0.nums = [4, 4], target = 4All match → 2.nums = [], target = 1Empty → 0.
Pitfalls
- Returning a boolean (found/not) instead of a count.
- Stopping at the first match (search behaviour).
Practice
Try the solution yourself
Edit the optimal implementation, test another input, and observe the result.
Editable code previewpublic int count(int[] nums, int target) { int c = 0; for (int x : nums) { if (x == target) c++; }Explore the playgroundClose the playground
Avoid mistakes
Recognize the interview traps
Understand why common attempts fail before reviewing the corrected implementation.
- Returning a boolean (found/not found) instead of a count.
- Stopping at the first match.
Revise
Carry the pattern into the interview
Pattern to remember
Count matches
Code pattern to memorize
c=0; for x: if x==target c++; return cRules to remember
- 1Counter starts at 0.
- 2Bump on equality.
- 3Don't stop early.
Use this pattern when
- Tallying matches
Choose another pattern when
- Sorted data — binary-search the first/last index instead
Interview takeaway
Counting means visiting every element — never break early.
Continue
Transfer the pattern to another problem
Use a direct variation or pattern sibling to prove the idea is reusable.
Transferable patternA core fresher pattern: Count matches. Master it on small inputs and it transfers to harder problems.