class CreditTracker:
Part 1 — Credits with expiry, spent earliest-expiring first
Perplexity's credit tracker, from one first-hand report (August 2025). The post body does not name the round; only its title says phone screen. It gives no outcome. This is everything it says about the problem:
Design a CreditTracker class with 3 methods: 1. def add_credit(start_time, end_time, credit) 2. def subtract_credit(time, credit) 3. def check_credit(time) When you subtract credit, you want to subtract the one with earliest expiration time. There is no guarantee that the time in add_credit and subtract_credit will be in increasing order.
Where the other rules come from. A commenter on the only Perplexity report asked whether this is the same as OpenAI's GPU-credit question; the rules below follow the OpenAI reports — confirm with your interviewer. We have many first-hand reports of the OpenAI question; nobody in them mentions Perplexity, and the Perplexity post itself does not say it is the same question.
Implement CreditTracker() with:
add_credit(start_time, end_time, credit): grant credit usable from start_time until end_time.subtract_credit(time, credit): spend credit at time. The tests ignore what it returns.check_credit(time): return the credit usable at time, as an int; 0 when nothing is usable.Graded rules:
add_credit and subtract_credit can arrive in any order.check_credit(time) counts only the spends that have happened by time. A query earlier than a spend is not reduced by it.Not graded: the OpenAI reports disagree, so ask your interviewer
end_time? Most OpenAI reports say no; one says yes. The tests never query or spend exactly at a start or end time.Our setup — ask your interviewer
Integer times; check_credit returns 0 when nothing is valid; two grants that expire at the same time may be drained in either order (the tests' answers do not depend on it). Our reference counts a grant valid for start_time <= t < end_time and returns None after a spend it cannot cover, but neither choice is graded.
Standard explanation — no candidate report records what the interviewer accepted here.
Record every call and replay the spends in time order at query time, so a grant valid at the spend's time can still pay for it.
Standard explanation — no candidate report records what the interviewer accepted here.
Keep the valid grants in a min-heap on expiration during one sorted sweep; caching state between queries needs invalidation whenever an earlier call arrives.
Standard explanation — no candidate report records what the interviewer accepted here.
Ask. OpenAI reports variously return None from then on, throw an exception, or say the tests never overspend.
From one first-hand Perplexity report, August 2025. The post body does not name the round; only its title says phone screen. The post records no outcome, no follow-up and no test cases. It gives the class, the three method signatures and two rules: spend the credit with the earliest expiration first, and do not assume the times arrive in increasing order. Its only captured reply is a commenter asking whether this is the same as OpenAI's question; nobody answers in the captured replies.
Everything beyond those two rules on this page follows the OpenAI GPU-credit reports, not Perplexity. Those candidates describe the same three operations under other names. The points they return to most: calls arrive out of order, so recording the calls and computing at query time works where settling each spend as it arrives does not; the earliest-expiring rule sometimes only shows up in the last test cases; an expired grant cannot pay; and they disagree about the window end and about what happens when a spend cannot be covered. Several OpenAI candidates say the interviewer gave them the test cases; one found that the last two carried a requirement nobody had mentioned, and reading every test case before designing is advice they give. Whether Perplexity's version runs the same way is not reported.
Part 1 — Credits with expiry, spent earliest-expiring first
Perplexity's credit tracker, from one first-hand report (August 2025). The post body does not name the round; only its title says phone screen. It gives no outcome. This is everything it says about the problem:
Design a CreditTracker class with 3 methods: 1. def
add_credit(start_time, end_time, credit)2. defsubtract_credit(time, credit)3. defcheck_credit(time)When you subtract credit, you want to subtract the one with earliest expiration time. There is no guarantee that the time in add_credit and subtract_credit will be in increasing order.
Where the other rules come from. A commenter on the only Perplexity report asked whether this is the same as OpenAI's GPU-credit question; the rules below follow the OpenAI reports — confirm with your interviewer. We have many first-hand reports of the OpenAI question; nobody in them mentions Perplexity, and the Perplexity post itself does not say it is the same question.
Implement CreditTracker() with:
add_credit(start_time, end_time, credit): grant credit usable from start_time until end_time.subtract_credit(time, credit): spend credit at time. The tests ignore what it returns.check_credit(time): return the credit usable at time, as an int; 0 when nothing is usable.Graded rules:
add_credit and subtract_credit can arrive in any order.check_credit(time) counts only the spends that have happened by time. A query earlier than a spend is not reduced by it.Not graded: the OpenAI reports disagree, so ask your interviewer
end_time? Most OpenAI reports say no; one says yes. The tests never query or spend exactly at a start or end time.Our setup — ask your interviewer
Integer times; check_credit returns 0 when nothing is valid; two grants that expire at the same time may be drained in either order (the tests' answers do not depend on it). Our reference counts a grant valid for start_time <= t < end_time and returns None after a spend it cannot cover, but neither choice is graded.
Which grant does a spend draw from first?
What if a grant arrives after a spend at a later time?
Is a grant usable at exactly end_time, and what happens when a spend needs more than is valid?
How would you avoid replaying every call on each check_credit?
What the one Perplexity report says: one class with three methods; a spend takes from the credit with the earliest expiration time first; the times in add_credit and subtract_credit are not guaranteed to arrive in increasing order. The post records no outcome, test cases or follow-ups. The post body does not name the round; only its title says phone screen.
From the OpenAI GPU-credit reports (a commenter on the Perplexity report asked whether this is the same question; confirm with your interviewer): candidates who assumed the calls arrive in time order struggled, and recording the calls and computing at query time works; an expired grant cannot pay for a spend; one candidate found the earliest-expiring rule only in the last two test cases, as a requirement nobody had mentioned; candidates advise reading every test case before designing.
Ask: whether a grant is usable at exactly its end_time, and what happens when a spend needs more credit than is valid at its time. The OpenAI reports disagree on both.