A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.
How to answer
The vagueness is the exercise: what’s on show is which answers you go looking for. A good question is one whose answer changes the code. Ask those, and state an assumption for everything else.
- Write the signature with holes in it. “Something like
merge_contacts(rows) -> ?. I don’t yet know what makes two rows the same, or what the caller needs back.” That turns vagueness into a short list of unknowns you can point at. - Tie each question to the line it decides. “Case-insensitive or not is the
.lower()in the key function; skip or fail on bad rows is one branch.” For a data feature, look for five such lines: identity, conflict, bad input, size and the output contract. If you can’t name the line a question decides, don’t ask it. - Stop asking and start building. A handful of questions, then code. When the answer is “your call”, pick, give the reason in a sentence, and move on.
- Write the answers at the top of the file. A numbered comment block the interviewer can read and correct while you type.
- Give each answer one home. Identity goes in one function, the conflict rule in one expression, and rejects in one list. When the interviewer changes an answer mid-round, one place changes.
- Test one example per decision. The case-insensitive email, the empty field, the rejected row.
The trap runs both ways. Coding straight away builds the wrong thing well, and a checklist of generic questions spends the time and shows no judgment. The skill on show is telling the two kinds of question apart.
Follow-ups
What the interviewer may ask next, once your first answer is on the table.
- Now two rows with the same phone number are the same person too, even with different emails. What changes in your code?
- The file is far too big for memory. What do you keep, and what do you sort?
- I said “your call” on bad rows. Defend the choice you made.
- Support now says the phone number from the CRM always wins over an upload, whatever the dates. Show me the one place that changes.
Where answers go wrong
- Asking a long list of questions whose answers would not change a line of code, which reads as stalling.
- Asking the right questions, then writing code that ignores one of the answers.
- Keeping assumptions in your head instead of saying them and writing them at the top of the code, where the interviewer can correct them.
Answer this in two minutes
Write the answer you would say out loud. The clock starts with your first word.
Model answer
The interviewer says: “Customers upload contact lists, and they’re full of duplicates. Build the merge.”