// sample reports

See the report before you trust the prep.

This is the report Placed gives you after an interview, in all five tracks: every score, the quotes behind it, what to fix, and what to practice next. Only the interview is made up.

What Pro shows after every interview, and what every free account gets for its first one.

Performance Assessment

Session Report

Top K Frequent Elements · Medium · 24:12 elapsed

Developing

Performance level

0.0/ 10

Developing

Aggregate score

NextWrite tests before you submit

Problem Understanding8

Problem Solving7

Communication6

Code Quality7

Testing & Verification4

// The evidence

Receipts & rationale

per-criterion evidence

Asked the two questions that matter before writing anything: whether k can exceed the distinct count, and what happens on a tie at the cutoff. Used the answers to rule out edge handling rather than guessing.

Receipts

you· turn 2

“can k be larger than the number of distinct values?”

Pinned the input contract before choosing an approach.

you· turn 2

“does it matter which one I return?”

Raised the tie case, the one ambiguity in the prompt.

Moved from sorting to a size-k heap with the complexity stated at each step, and found the linear bucket approach when pushed. Chose the heap anyway, which is a fair call under time, but did not say what the bucket version would cost in space or why the heap was safer.

Receipts

you· turn 4

“I think I can do better with a heap of size k, so O(n log k).”

Improved on the first idea and named the cost.

you· turn 6

“Counts are bounded by n, so maybe bucket by count?”

Reached the optimal idea from a property of the input.

−

you· turn 6

“I will write the heap version first since I am more sure of it.”

Dropped the better approach without weighing it out loud.

Clear while planning, then went quiet while coding: one line covered the whole implementation. An interviewer could follow the plan but not the code being written, and "I think that works" ended the round instead of a walkthrough.

Receipts

−

you· turn 8

“Okay, that passes the example. I think that works.”

Called it done on one example, with no walkthrough.

you· turn 4

“I would count with a hash map first, that is O(n).”

Narrated the plan with costs, in order.

Short and idiomatic: Counter and heapq.nlargest are the right tools, and the names say what they hold. Leaning on the library hides the heap logic, so expect an interviewer to ask you to write it by hand.

Receipts

code

return heapq.nlargest(k, counts.keys(), key=counts.get)

One clear line, right standard-library call.

Ran the given example only. Named two good edge cases when asked, a single element and k equal to the distinct count, but did not run either, and never traced the heap by hand.

Receipts

−

you· turn 10

“I did not run those, sorry, I ran out of time.”

Edge cases named but never checked.

you· turn 10

“the case where k equals the number of distinct values”

Picked a boundary that would catch an off-by-one.

// Sharpen this

Run the edge cases you name. Saying "single element" earns little; running it and showing the output earns the testing score.

Talk while you type. One sentence per block of code ("now I take the k largest by count") keeps the interviewer with you.

When you find a better approach, weigh it out loud before you set it aside: "buckets are O(n) time and O(n) space; I will write the heap because I can test it faster."

Close with a walkthrough on a small input instead of "I think that works".

// Pacing

24:12 elapsed

Spent the first 9 minutes on approach, which was well used, but left about 2 minutes for testing. Writing the heap version took 6 minutes; that left room to run the two edge cases you named.

// The reference solution

The idea

Count each value, then group values by their count: bucket i holds the values that appear exactly i times. Counts never exceed n, so there are n + 1 buckets. Walk them from the highest count down and collect values until you have k.

from collections import Counter

def topKFrequent(nums: list[int], k: int) -> list[int]:
    counts = Counter(nums)
    buckets = [[] for _ in range(len(nums) + 1)]
    for value, count in counts.items():
        buckets[count].append(value)

    result = []
    for count in range(len(buckets) - 1, 0, -1):
        for value in buckets[count]:
            result.append(value)
            if len(result) == k:
                return result
    return result

Passes this problem's tests in Python 3.11.

Time

O(n): one pass to count, one pass over at most n + 1 buckets.

Space

O(n) for the counts and the buckets.

What to say while writing it

Counts are at most n, so I can index buckets by count instead of sorting. I walk from the highest count down and stop as soon as I have k values.

Where people slip

Sizing the buckets by the number of distinct values instead of n + 1, so the highest count falls off the end.
Returning after the outer loop finishes a bucket, which can return more than k values.
Sorting the whole Counter and calling it optimal: that is O(n log n).

“

You think like someone who has solved this before: the right questions, the right complexity, and the optimal idea when pushed. What holds the score down is the finish. Test what you named, and say what you are doing while you do it.

— Evaluated by Placed AI

// Ask about this score

Ask Plato why a score landed where it did, or what would have moved it. Answers come from the report and your transcript. Scores do not change.

You

Why did testing only get a 4 when I named the right edge cases?

Plato

Naming them shows you know where the bugs live, which is why it is not lower. The score is for checking: you ran only the given example and said "I did not run those". A 7 needs at least one edge case run and its output read aloud, and a hand trace of the heap on a small input would have taken under a minute.

// What's next

Your next 3 moves

Built from your weakest criterion: Testing & Verification

01Review

Re-read the testing & verification rubric

You need to TRACE through inputs and call out edge cases proactively — not just say "looks good to me".

Read the rubric

02Practice

Write tests before you submit

Verification scored lowest. Pick any problem and run through edge cases.

Start next session

03Habit

Drill the habit next session

Before claiming the solution works, hand-trace the algorithm on one happy-path input and one edge case.

Recommended nextCoding

Write tests before you submit

Verification scored lowest. Pick any problem and run through edge cases.

Start next session

sample report · the interview is made up; the layout and the level of detail are what you get

Ready to get yours?

Start an interview without an account. Sign up when you finish and your first report is the full one, free, no credit card.

Start free