In this mock technical interview, a candidate is asked to solve a classic array problem involving selecting two items whose sum matches a gift card amount. Watch how the developer clarifies ambiguities, performs a dry run, and walks through both brute-force and optimized approaches — just like in a real FAANG interview setting.
You’re on a high-pressure shopping game show. You’re given a list of item prices and a gift card loaded with a certain amount. Your goal is to pick exactly two different items whose prices add up to the gift card value. Return the indices of those two items.
Sounds exciting! Just a few clarifications before I proceed. First — are the prices sorted in any particular order?
No, the prices can be in any random order.
Got it. And can we use the same item twice if its price is exactly half the gift card amount?
Nope, you can’t pick the same item twice. The two items must be different.
Alright. Final check — will there always be exactly one valid pair?
Yes. You’re guaranteed a unique solution in each test case.
Thanks! To confirm my understanding:
- If prices = [10, 20, 30, 40] and gift card = 50 → [1, 2] is valid because 20 + 30 = 50.
- If prices = [25, 25, 50] and gift card = 50 → valid indices would be [0, 1] and not [0, 0].
- If prices = [1, 2, 3, 4, 5] and gift card = 9 → answer is [3, 4] since 4 + 5 = 9.
Yes, those are spot on!
Awesome. Now, let’s dry run with your example: prices = [10, 20, 35, 50], gift card = 70.
- Check 10 + 20 = 30 ❌
- 10 + 35 = 45 ❌
- 10 + 50 = 60 ❌
- 20 + 35 = 55 ❌
- 20 + 50 = 70 ✅ → indices [1, 3]
I’ll start with the brute-force approach to build my understanding of the problem. Since I need to find two different items whose prices sum up to the gift card amount, the most straightforward way is to check all possible pairs.
I can use two nested loops: the outer loop will pick the first item, and the inner loop will check every other item after it to see if the sum of the two equals the target amount. If a match is found, I’ll return their indices immediately. Since the problem says there's always exactly one solution, I don’t need to worry about handling multiple results or edge conditions here.
I can use two nested loops: the outer loop will pick the first item, and the inner loop will check every other item after it to see if the sum of the two equals the target amount. If a match is found, I’ll return their indices immediately. Since the problem says there's always exactly one solution, I don’t need to worry about handling multiple results or edge conditions here.
for (let i = 0; i < prices.length; i++) {
for (let j = i + 1; j < prices.length; j++) {
if (prices[i] + prices[j] === giftCardAmount) {
return [i, j];
}
}
}
This solution checks every possible pair exactly once. The time complexity is
O(n²), where n is the number of items. It's simple and correct, but not efficient for large input sizes — so I’ll aim to optimize it next.
This has time complexity O(n²), since we try all pairs. Works fine for small inputs, but not scalable.
Right. Can you improve it?
Yes. I’ll use a hash map to store prices I’ve already seen while iterating. For each price, I’ll check if the complement (target - current price) is in the map.
const seen = new Map();
for (let i = 0; i < prices.length; i++) {
const complement = giftCardAmount - prices[i];
if (seen.has(complement)) {
return [seen.get(complement), i];
}
seen.set(prices[i], i);
}This is O(n) time and O(n) space. We're scanning the array once, and map lookups are constant time.
Sounds great. What about tricky inputs like duplicate numbers?
Good point. Let's say prices = [25, 25, 40], giftCard = 50.
- On first 25 (index 0), I store it in the map.
- Second 25 (index 1), complement is 25 → map has it → return [0, 1].
Exactly. I like how you're anticipating edge cases and validating with examples.
Thank you! I’d also write unit tests to cover:
- Random order inputs
- Duplicates
- Negative values (if allowed — though not mentioned in this case)
📝 Interviewer Feedback
Great walkthrough. You approached the problem methodically, starting with clarifications and dry-running through the example, which showed good attention to detail. Your transition from brute-force to an optimized hash map solution was well-articulated and efficient.
One strength was your ability to anticipate edge cases, like duplicate values and index handling. Your explanation of time and space complexity was also clear and concise.
In a real interview setting, I’d encourage you to verbalize trade-offs a bit more, especially around why one solution might be preferred based on input size or constraints. But overall — very strong performance!