Presenting and Defending Your Decisions

Explain how significant implementation decisions addressed customer requirements within the project's constraints. Revise those decisions when new evidence challenges the original assumptions. Retain decisions supported by evidence, and update assumptions or conclusions when new findings invalidate them.

Be prepared to explain your problem-solving approach, implementation decisions, and technical reasoning. Review the interview instructions for the required format and permitted tools.

Understanding the reviewer’s question

Consider an accounts-payable review tool developed within a four-hour time limit. The brief requires a local, read-only CSV report for a single coordinator. Each invoice ID must have one review result, and unresolved records must remain visible. The brief does not require payment processing, collaborative editing, or database storage.

The reviewer asks: “Why did you choose a CSV report instead of a database-backed application?”

The question asks you to justify the architecture against the customer's workflow and requirements. Citing the four-hour limit alone does not explain why a CSV report meets the customer's needs. Dismissing a database as unnecessary overlooks scenarios where persistent storage, concurrent access, or shared editing could justify it.

Explain the rationale for each of the following three design decisions:

• Delivery: A local CSV snapshot for one coordinator.

• Reconciliation: A rule for handling repeated invoice IDs.

• Verification: The checks used to support claims about the result.

Evidence against one choice need not invalidate the others. Keep those dependencies visible as the conversation develops.

Answering with evidence

Apply the trade-off and evidence guidance from the Documenting Trade-Offs and Limitations lesson to the reviewer's question: lead with your choice, then point to the specific artifact that supports it and state what it does not establish.

Here’s a concise answer: ... ...