Can you defend the solution that earned the interview?
Explain your code and adapt it to a changed input contract.
The question
You have a fictional college-coordinated pre-placement interview for a junior software role. The invitation asks you to explain your own solution without external code assistance during the interview. Your contest task was to report each payment once per logical ID. In this packet, retries have the same ID and amount.
| ID | Amount (INR) | |
|---|---|---|
| Arrival 1 | A | 50 |
| Arrival 2 | B | 30 |
| Arrival 3 | A | 50 |
| Arrival 4 | C | 20 |
| Arrival 5 | B | 30 |
| Arrival 6 | A | 50 |
Report a count of distinct IDs and one total amount.
“Explain your approach and show how it handles the panel’s new requirement.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: State the input contract
What would you do here? Open the move you’d make.
Count each ID once.
The strong move. Repeated arrivals represent the same payment under this contract.
Add all six arrivals for a total of ₹230.
Tempting, but it misses something. A and B arrive more than once. The contract requires one amount per logical ID.
See how a strong candidate says it
“I count one payment for each ID. A contributes ₹50, B ₹30 and C ₹20. That gives three distinct payments and a total of ₹100.”
Why it works: Repeated arrivals represent the same payment under this contract.
Step 2: Explain the approach
What would you do here? Open the move you’d make.
Explain the duplicate assumption and a test that checks it.
The strong move. The approach depends on identical amounts for repeated IDs.
Show a generated answer without explaining how it treats retries.
Tempting, but it misses something. The panel needs the input assumption and a check that repeated IDs do not add money.
See how a strong candidate says it
“I keep a set of seen IDs. With normal hash-table behavior, one pass takes expected O(n) time and stores O(u) IDs for u distinct payments. I would test identical retries and a list with all distinct IDs.”
Why it works: The approach depends on identical amounts for repeated IDs.
Step 3: Handle the revision
The panel adds revision numbers. Every original arrival was revision 1. A revision 2 for ₹65 arrives, followed by stale A revision 1 for ₹50. Report the amount at the highest revision per ID.
What would you do here? Open the move you’d make.
Keep the highest revision per ID.
The strong move. Revision order controls which amount is current.
Always replace the amount with the last arrival.
Tempting, but it misses something. The final A arrival has the older revision and would restore ₹50.
See how a strong candidate says it
“I keep the amount with the highest revision for each ID. A is now ₹65. The later stale A message cannot change it. The count stays three and the total is ₹65 plus ₹30 plus ₹20, or ₹115.”
Why it works: Revision order controls which amount is current.
Step 4: Show the next check
What would you do here? Open the move you’d make.
Test replay, out-of-order revisions and equal-revision conflicts.
The strong move. Tests need to distinguish a retry, an update and conflicting data.
Count each changed message as a separate payment.
Tempting, but it misses something. A new revision replaces the value for the same logical payment ID.
See how a strong candidate says it
“I would test exact replay, a higher revision arriving before a lower one, and a conflict where the same ID and revision carry different amounts. I would flag that conflict for reconciliation. The old set would have skipped the valid revision.”
Why it works: Tests need to distinguish a retry, an update and conflicting data.
The answer, in short
- Decision
- Use the highest revision for each ID.
- Because
- The changed contract allows an amount to change while the logical payment stays the same.
- What would change it
- A different definition of a payment ID or revision would change the implementation.
Common traps
- Counting arrival records as payments.
- Overwriting a valid revision with a stale arrival.
Check your answer
- I explained the original input contract.
- I justified the data structure.
- I handled a later revision.
- I named the conflict and replay checks.
Last reviewed Nov 10, 2026