Q&A Strategies & Defense
The Q&A is where boards are won or lost. 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 use 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, follow this decision tree to choose the right response approach:
flowchart TD
Q["Judge asks\na question"] --> K{Do you know\nthe answer?}
K -->|"Yes, confidently"| D{Is it a challenge\nor a question?}
K -->|"Partially"| P["Acknowledge gap\n+ bridge to what\nyou DO know"]
K -->|"No"| N["State what you\nWOULD do to\nfind out"]
D -->|"Direct challenge"| DEF{Does your reasoning\ntie to requirements?}
D -->|"Exploratory question"| ANS["Answer directly\n+ add trade-off"]
DEF -->|"Yes"| FIRM["Stand firm:\nrestate rationale"]
DEF -->|"No / weak"| ADAPT["Adapt: revise\nyour approach"]
P --> BRIDGE["'I would investigate X.\nArchitecturally, my\ninstinct says...'"]
N --> REASON["Demonstrate reasoning\nprocess, not guessing"]
The STAR-A Framework for Responding
When a judge challenges your design, use this structured approach:
- S — Situation: Restate the challenge to show you understood it
- “You’re asking about what happens when…”
- T — Think: Pause visibly. Evaluators want to see you think, not react
- Take 3-5 seconds. This shows deliberation, not ignorance
- A — Answer: Address the specific challenge with a specific answer
- “In that scenario, I would…”
- R — Rationale: Explain the reasoning behind your answer
- “Because…”
- 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 you — they are stress-testing your design for production-level robustness.
Handling Questions You Don’t Know the Answer To
Never say “I don’t know” and stop there. Instead, use these strategies:
| 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. The judges can sense when you are bluffing and do not really know how your solution works. Honesty with intelligent reasoning is always better than a confident wrong answer. Being realistic and brutally honest about your knowledge 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 evaluated at the board. Getting it wrong in either direction can cost you.
flowchart TD
CH["Judge pushes back\non your design"] --> NEW{New information\nor same facts?}
NEW -->|"New info / constraint"| IMP{Does it break\nyour design?}
NEW -->|"Same facts,\ntesting conviction"| JUST{Can you justify\nwith requirements?}
IMP -->|"Yes"| ADAPT["ADAPT gracefully:\n'Given that, I would\nrevise to...'"]
IMP -->|"No"| ACK["ACKNOWLEDGE + HOLD:\n'My design handles\nthis because...'"]
JUST -->|"Yes"| FIRM["STAND FIRM:\nrestate trade-off"]
JUST -->|"No"| PIVOT["PIVOT honestly:\n'On reflection,\na better approach...'"]
When to Stand Firm
Stand firm when:
- You have clear reasoning tied to specific requirements
- The judge’s challenge does not introduce new information — they are testing your conviction
- Your approach is well-established best practice for the specific scenario
- You can cite specific platform capabilities or limitations that support your 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 you missed
- You realize the challenge exposes a real gap in your design
- Your original reasoning does not hold up under the specific scrutiny
- The judge is pointing out a platform limitation you were 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
If you spot an error in your own design during the presentation or Q&A, follow this approach:
flowchart TD
SPOT["You realize a mistake\nin your design"] --> WHEN{When did you\nspot it?}
WHEN -->|"During presentation"| PRES["Correct it openly:\n'On reflection, a better\napproach would be...'"]
WHEN -->|"During Q&A\n(judge pointed it out)"| QA["Acknowledge + adapt:\n'That is a valid point.\nI would revise...'"]
WHEN -->|"During Q&A\n(you noticed yourself)"| SELF["Show maturity:\n'Having discussed this,\nI realize I should adjust...'"]
PRES --> IMPACT["Briefly state the\nimpact on related\nartifacts"]
QA --> IMPACT
SELF --> IMPACT
IMPACT --> MOVE["Move forward\nconfidently"]
Correcting mistakes scores points
Judges value candidates who can identify and correct their own errors. Sticking with a known wrong answer is worse than openly adjusting your design. The ability to adapt 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 — a red flag for a consulting architect |
| Always adapting | Looks like you have no conviction and are guessing — a red flag for a technical leader |
| Flip-flopping | Changing your answer multiple times on the same topic looks like you cannot make a decision |
| Defending emotionally | Getting visibly frustrated or defensive signals inability to handle pressure |
The real-world test
Think about it this way: in a real client engagement, would you stubbornly push your design against valid pushback, or would you demonstrate the flexibility and judgment to adapt? That is what judges want to see.
The Five Question Types Judges Use
CTA coach Praneel Pidikiti identifies five distinct question types judges use during Q&A. Recognizing the type instantly tells you what the judge is actually testing — and dictates your 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 tells you the response strategy before you even process the full question.
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. Either defend with strong rationale OR acknowledge and adapt — both can score well.
- Type 4 (Rationale Missing): Your design is fine — you just need to articulate WHY. Use the trade-off formula.
- Type 5 (Cascading): The hardest type. Requires architectural thinking across domains. Trace the dependency chain out loud.
Cascading Impact Chains
When judges ask “If you change X, what happens to Y?” they are testing whether you understand cross-domain dependencies. These are the most common cascade chains in CTA scenarios:
flowchart LR
DM["Data Model\nChange"] --> SM["Sharing Model\nImpact"]
SM --> INT["Integration\nImpact"]
INT --> REP["Reporting\nImpact"]
DM2["OWD Change"] --> RH["Role Hierarchy\nImpact"]
RH --> PS["Portal/Community\nAccess Impact"]
INT2["Integration Pattern\nChange"] --> ERR["Error Handling\nImpact"]
ERR --> MIG["Migration\nSequence Impact"]
style DM fill:#d4504c,color:#fff
style DM2 fill:#d4504c,color:#fff
style INT2 fill:#d4504c,color:#fff
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 — each follow-up builds on your previous revision. If you lose track of what you’ve already changed, your architecture becomes internally inconsistent. Mentally re-validate your full solution after any on-the-spot revision.