Deloitte Interview Practice: Explain Evidence and Judgement

These are original preparation prompts, not released Deloitte interview questions or a map of a current Deloitte process. The Deloitte careers page, the role description, and a written application notice are the employer sources for current facts. This guide does not state a business-unit structure, a hiring volume, a compensation level, an assessment sequence, or an offer condition.

Describe a decision with its evidence

Choose a project decision you made. Start with the problem, then identify the information available at the time. Explain the options you considered, the criterion you used to choose, and the limitation of the decision. A strong answer makes the line between evidence and judgement visible.

For example, if you chose one storage approach over another, say what the expected data shape was and what test you used. Do not turn a personal preference into a universal rule. Finish by naming the evidence that would make you reconsider the choice.

Diagnose a disagreement constructively

Imagine two teammates disagree about whether a recurring error comes from user input or a service integration. Draft a response that turns the disagreement into testable questions. What log entry, sample request, or controlled reproduction would help? What should be recorded before a configuration change is made?

The goal is not to sound decisive without information. It is to make progress while protecting the system and respecting the people involved. Describe the smallest reversible step and the result that would justify the next one.

Explain a technical concept to a non-specialist

Take a concept from your own work, such as caching, validation, version control, or an API boundary. Explain it first in a sentence without jargon. Then give a small example, a likely failure mode, and one question a stakeholder could ask to check their understanding.

This exercise tests clarity. If the explanation only works for someone who already knows the term, revise it. If it needs a factual claim about a platform or a policy, keep a reliable source next to that claim.

Turn a case prompt into an action plan

Suppose a small service receives an increase in support requests after a feature change. Create a plan with a problem statement, a list of evidence to gather, a hypothesis to test, and a communication step for affected users. Avoid asserting a root cause before testing it.

Your conclusion may be conditional: “If the error appears after a particular request shape, inspect the validation boundary.” Conditional reasoning is honest when the data is incomplete.

Keep the live process outside this guide

Do not use general questions to decide what a role will ask, who can apply, or how a result will be judged. Open the current employer posting when you are considering an application and follow the instructions attached to it. If a material condition is unclear, use the official contact rather than an old forum recollection.