Q&A Strategies & Defense

Boards are won or lost during Q&A. This guide covers how judges probe and challenge, response strategies, handling unknown questions, trap patterns, and when to stand firm versus when to adapt.

How Judges Probe and Challenge

Judges rely on several probing tactics:

Tactic	What It Sounds Like	What They Are Testing
Direct challenge	”Why didn’t you use Platform Events instead?”	Can you defend your decision with reasoning?
What-if scenario	”What if the data volume triples in year 2?”	Can you think about scalability and evolution?
Depth probe	”Walk me through exactly how that OAuth flow works”	Do you truly understand, or are you bluffing?
Alternative push	”Have you considered using a different approach for X?”	Do you know alternatives and can you compare?
Edge case	”What happens when the integration fails at 2 AM?”	Have you thought about failure scenarios?
Requirement shift	”What if the client adds 5 more countries next year?”	Can you adapt your architecture?
General knowledge	”Explain the difference between Skinny Tables and Custom Indexes”	Do you have deep platform knowledge?
Consulting skills	”How would you handle a stakeholder who disagrees with this approach?”	Can you operate as a trusted advisor?

Q&A Response Strategy

When a judge asks a question, this decision tree helps select the right response approach:

Figure 1. Q&A response strategy routing from knowledge confidence through challenge type to the appropriate outcome. Partial knowledge and no-knowledge paths both require demonstrating architectural reasoning rather than guessing.

The STAR-A Framework for Responding

When a judge challenges a design decision, this structured approach works well:

1. S - Situation: Restate the challenge to show you understood it
   • “You’re asking about what happens when…”
2. T - Think: Pause visibly. Evaluators want to see you think, not react
   • Take 3-5 seconds. This shows deliberation, not ignorance
3. A - Answer: Address the specific challenge with a specific answer
   • “In that scenario, I would…”
4. R - Rationale: Explain the reasoning behind your answer
   • “Because…”
5. A - Adapt: If the challenge reveals a genuine gap, update your design on the spot
   • “Given that constraint, I would revise my approach to…”

The golden mindset

Treat every challenge as a “help me understand” question, not an attack. The board is not trying to trick candidates; they are stress-testing the design for production-level reliability.

Handling Questions You Don’t Know the Answer To

Never say “I don’t know” and stop there. These strategies work better:

Strategy	When to Use	Example
Reframe with assumptions	When you know the general area but not the specific detail	”My initial design assumed X; given your challenge, I would revise it to Y because…”
Acknowledge and bridge	When you have partial knowledge	”I’m not certain of the exact API limit for that, but architecturally I would address it by implementing a governor limit monitoring framework and…”
Demonstrate reasoning	When you don’t know the feature but understand the problem	”I haven’t worked with that specific feature, but given the requirement, I would evaluate it against [criteria] and my fallback approach would be…”
State what you would do	When the question is beyond your experience	”In practice, I would investigate [specific thing] and consult with [resource]. My architectural instinct says [reasoning]…”

What kills candidates

Bluffing. Judges can sense when a candidate is bluffing and does not really understand their own solution. Honesty with intelligent reasoning always beats a confident wrong answer. Being realistic and direct about knowledge gaps is essential.

Common Trap Question Patterns

Pattern	Example	How to Handle
The false dichotomy	”So you’d use either batch or streaming?”	Recognize the spectrum: “It depends on the latency requirement. For this use case, near-real-time with a 5-minute polling interval balances…”
The scope creep	”What if they also need a mobile app for field reps?”	Assess impact: “That would change my architecture in these ways… I’d recommend a phased approach where…”
The buzzword test	”You mentioned eventual consistency - explain what that means here”	Go deep: give a specific, scenario-relevant explanation, not a textbook definition
The governor limit probe	”What happens when you hit the 50,000 record SOQL limit?”	Show you know the limits AND the workarounds: “I’d implement [specific pattern] and additionally monitor with…”
The cost challenge	”Isn’t that an expensive approach?”	Tie to business value: “The cost of middleware is offset by the reduction in custom integration maintenance and the SLA guarantee for…”
The “simpler way” challenge	”Couldn’t you just use flows for that?”	Show you evaluated it: “I considered that approach. The limitation is [specific]. For this volume and complexity, [your choice] is more appropriate because…”

---

Defending Decisions: When to Stand Firm vs. When to Adapt

This is one of the most nuanced skills the board evaluates. Getting it wrong in either direction costs points.

Figure 2. Stand firm vs adapt decision logic for judge pushback. The first branch (new information or same facts) is the critical split; misreading it causes candidates to either capitulate unnecessarily or defend a genuinely flawed design.

When to Stand Firm

Stand firm when:

• Clear reasoning ties directly to specific requirements
• The judge’s challenge introduces no new information; they are testing conviction
• The approach is well-established best practice for this specific scenario
• Specific platform capabilities or limitations support the choice

How to stand firm gracefully:

“I understand the appeal of [alternative]. In this specific scenario, I chose [my approach] because [requirement X] requires [specific capability]. The alternative would introduce [specific risk/limitation] that conflicts with [requirement Y].”

When to Adapt

Adapt when:

• The judge introduces genuinely new information or a constraint that was missed
• The challenge exposes a real gap in the design
• The original reasoning does not hold up under specific scrutiny
• The judge points out a platform limitation the candidate was unaware of

How to adapt gracefully:

“That’s a valid point. Given [new constraint], I would revise my approach to [new approach] because [reasoning]. This would require adjusting [related element] as well.”

Recovery When You Realize a Mistake

When an error is spotted mid-presentation or during Q&A, this approach works:

Figure 3. Mistake recovery protocol for errors spotted during the presentation or Q&A. All three discovery paths converge on stating the cross-artifact impact before moving forward, which demonstrates cross-domain architectural awareness rather than isolated thinking.

Correcting mistakes scores points

Judges value candidates who identify and correct their own errors. Sticking with a known wrong answer is worse than openly adjusting the design. Adapting under pressure is a core CTA skill.

The Danger Zones

Danger Zone	Why It Fails
Always standing firm	Looks rigid and unable to incorporate feedback. Red flag for a consulting architect
Always adapting	Looks like there is no conviction and the candidate is guessing. Red flag for a technical leader
Flip-flopping	Changing the answer multiple times on the same topic signals indecision
Defending emotionally	Visible frustration or defensiveness signals inability to handle pressure

The real-world test

In a real client engagement, an architect who stubbornly pushes a design against valid pushback loses trust. Judges want to see the flexibility and judgment to adapt when warranted.

The Five Question Types Judges Use

CTA coach Praneel Pidikiti identifies five distinct question types judges use during Q&A. Recognizing the type instantly reveals what the judge is actually testing and dictates the response strategy.

#	Type	What the Judge Says	What They Are Testing	Response Strategy
1	Invalid - your solution has a flaw	”That won’t work because…” / “Are you sure that’s possible with…” / “That API doesn’t support…”	Can you recognize a genuine error and correct on the spot?	Acknowledge the flaw immediately. Do NOT defend a broken approach. Say: “You’re right - that won’t work because [reason]. I would correct this by [fix].” Then assess cascading impact.
2	Missed - you skipped a requirement	”What about requirement X?” / “I don’t see how you’ve addressed…” / “You haven’t mentioned…”	Did you cover all stated requirements?	Do NOT panic. Say: “That requirement is addressed by [solution element]” if you covered it implicitly. If genuinely missed, say: “I should have addressed that explicitly. I would handle it by [approach].“
3	Suboptimal - your solution works but isn’t the best choice	”Have you considered using X instead?” / “Why not use Y for this?” / “Is there a simpler approach?”	Can you evaluate alternatives and defend or improve your choice?	Either defend with rationale (“I considered X but chose Y because [specific reason tied to requirements]”) OR acknowledge the better option (“That’s a better fit because [reason] - I would revise to use X”).
4	Rationale Missing - your solution is correct but you didn’t explain WHY	”WHY did you choose X?” / “What’s the reasoning behind…?” / “Walk me through your decision process”	Do you understand your own design, or did you just pick something familiar?	Explain your reasoning using the trade-off formula: “I chose [approach] because [requirement]. I considered [alternative] but rejected it because [limitation]. The trade-off is [what you give up].“
5	Cascading - changing one answer invalidates others	”If you change X to Y, what happens to your sharing model?” / “You just revised your integration - does your migration still work?”	Can you see cross-domain dependencies in your architecture?	Pause. Trace the impact chain: the changed component → what depends on it → what depends on THAT. Say: “Changing X means I also need to revise [Y] because [dependency], and verify that [Z] still works because [connection].”

How to recognize the type instantly

Listen for the verb: “won’t work” = Invalid. “What about…” = Missed. “Have you considered…” = Suboptimal. “Why did you…” = Rationale. “If you change…” = Cascading. The verb reveals the response strategy before the full question is even processed.

Responding to Each Type - The Key Difference

• Types 1-2 (Invalid, Missed): The judge has found a real gap. Correct or address it. Do not defend.
• Type 3 (Suboptimal): Judgment call. Defend with strong rationale or acknowledge and adapt; both can score well.
• Type 4 (Rationale Missing): The design is fine; articulate WHY using the trade-off formula.
• Type 5 (Cascading): The hardest type. Requires cross-domain architectural thinking. Trace the dependency chain out loud.

Cascading Impact Chains

When judges ask “If you change X, what happens to Y?” they test understanding of cross-domain dependencies. These are the most common cascade chains in CTA scenarios:

Figure 4. Cross-domain cascading impact chains for the three most common judge cascade questions. Tracing these chains out loud during Q&A demonstrates the cross-domain architectural thinking that distinguishes passing candidates.

Common chains to trace:

If You Change…	Check Impact On…	Why
Data model (add/remove objects)	Sharing rules, integration mappings, reports, migration scripts	Objects ripple through every layer
OWD settings	Role hierarchy access, portal visibility, Apex sharing logic	OWD is the foundation of the sharing pyramid
Integration pattern (sync → async)	Error handling, data consistency, user experience, reporting timeliness	Async changes when data is available downstream
Identity provider	Portal access, API authentication, mobile SSO, external user provisioning	Auth is a cross-cutting concern
License type	Available features, object access, sharing model options, portal capabilities	Licenses gate what’s architecturally possible

The cascade trap

Judges often ask cascading questions in sequence, with each follow-up building on the previous revision. Losing track of what has already changed makes the architecture internally inconsistent. Mentally re-validate the full solution after any on-the-spot revision.

Related Topics

• Presentation Structure: how to structure the presentation that precedes Q&A
• Common Mistakes & Mock Boards: common Q&A failures and hostile Q&A practice drills
• Sharing Model: most commonly probed domain during Q&A; prepare deep sharing knowledge
• Integration Patterns: judges frequently probe error handling and failure scenarios for integrations
• Large Data Volumes: judges probe LDV strategy including indexing, skinny tables, and archival
• Data Modeling: judges test relationship type decisions and their cascading impact on sharing