Best Practices for Asking a Person Good Questions
Getting great answers from people starts with asking great questions. Whether you're debugging code, seeking feedback on a design, or gathering domain expertise, the quality of your question directly determines the quality of the response you'll receive.
When using AI agents to ask people (via tools like MCP or APIs), these best practices become even more important—you're not in a direct conversation where follow-ups are immediate. Your question needs to be complete, specific, and actionable.
The 7 Key Principles
1. Be Specific About the Problem
Bad: "How do I make my code faster?"
Good: "I have a Node.js Express API that's taking 5-10 seconds to respond to GET /users requests. The database query completes in <100ms (verified with slow query log). Where should I profile next?"
Specific questions show you've already done homework, which prompts more thoughtful responses. Include:
- What you're trying to achieve (the goal)
- What you've already tried (so they don't suggest it again)
- Constraints or context (time, budget, tech stack)
- Metrics or measurements (specific numbers, not vague descriptions)
2. Show Your Work & What You've Already Tried
People appreciate questions that demonstrate effort. It signals that you respect their time and are genuinely stuck, not just lazy.
Bad: "What's the best way to handle authentication in React?"
Good: "I'm building a single-page React app with a Node backend. I've considered JWT stored in localStorage (XSS risk) and httpOnly cookies (CSRF complexity). I've read the OWASP guide and reviewed how the IETF RFC 6819 handles this. What do you recommend for a bootstrapped startup that can't afford a dedicated security audit?"
3. Include Relevant Context, But Don't Over-Explain
People need enough context to understand your situation, but too much detail makes questions hard to parse. Aim for 2-3 sentences of setup before the actual question.
Too vague: "Should we use Docker?"
Too much detail: "We have a team of 5 engineers in San Francisco and 3 contractors in Eastern Europe. We use Node.js, Python, and Go. Our current servers are on DigitalOcean but we're considering AWS. We have a budget of $2000/month... [continues for 10 more sentences]"
Just right: "We're a 5-person startup running microservices (Node.js, Python, Go) on DigitalOcean ($2k/month). As we scale to 10 people, we're debating Docker vs. serverless functions. What factors should we weigh?"
4. Ask Open-Ended Questions, Not Yes/No
Bad: "Is Python or JavaScript better?"
Good: "I need to build a data pipeline that processes 10 million events daily. The team has equal comfort with Python and Node.js. What are the tradeoffs, and which would you choose for this use case?"
Open-ended questions invite deeper thinking and richer responses. They signal that you want expertise, not just a quick answer.
5. Specify the Type of Answer You Want
Are you looking for:
- Conceptual explanation
- Step-by-step instructions
- Architecture recommendations
- Critique of your existing approach
- Pros/cons comparison
Example: "I'm considering a microservices architecture for my SaaS. Rather than a detailed tutorial, I'd appreciate a critique: [describe my proposed architecture]. What are the key pitfalls I might be missing given my team size and budget?"
6. Include Constraints & Non-Negotiables
Constraints shape good advice. A recommendation that works for Netflix won't work for a one-person shop. Be explicit about:
- Team size & experience level "I'm a solo engineer learning DevOps"
- Budget "We have $500/month for infrastructure"
- Timeline "This needs to work in 2 weeks, not 2 months"
- Tech stack "We're locked into Java for legacy reasons"
- Performance requirements "Queries must complete in <100ms"
- Reliability requirements "We need 99.99% uptime"
7. Ask for Specific Examples or Next Steps
End with a concrete ask. Don't leave it open-ended.
Weak ending: "What do you think?"
Strong ending: "Based on your experience, what's one concrete step I should take this week? And what's the biggest mistake you see people make in this situation?"
Question Template
Here's a template you can use as a starting point:
I'm building [what] with [tech stack] for [who/why]. Context: - Team: [size, experience level] - Timeline: [how soon do you need results] - Budget: [constraints] - What I've already tried: [list 2-3 things you've attempted] Problem: [Specific description of the problem. Include metrics/measurements if relevant.] What I'm considering: [Describe 1-2 approaches you're weighing] My specific question: [One clear, open-ended question] What I'd find most helpful: [Do you want a critique? Recommendations? Examples? Be specific.]
Real-World Examples
Example 1: Code Review Request
Before (vague): "Can you review my code?"
After (specific):
I'm building a real-time notification system for a SaaS product using WebSockets and Node.js. I'm concerned about reliability—especially what happens when a client disconnects without closing the connection properly. Here's my current approach: [code snippet] I've tested it locally with 100 concurrent connections. I haven't tested graceful reconnection yet. My question: Are there edge cases or failure modes I'm missing? What's the right way to handle zombie connections? What would help me most: Specific recommendations on what to test, not a rewrite of the code.
Example 2: Architecture Feedback
Before (vague): "What's the best architecture for a startup?"
After (specific):
I'm building a B2B SaaS platform for data analysis. Current metrics: - 100 customers, 50K API calls/day - Team: 3 engineers, 1 DevOps person - Budget: $5k/month for infrastructure - Goal: Scale to 1M API calls/day in 12 months Currently running monolith on Heroku. Performance is fine, but I'm worried about: 1. Cost scaling as we grow 2. Dependency coupling (frontend, API, workers all in same repo) 3. Ops complexity as team grows I'm considering: Microservices on Kubernetes vs. staying monolithic but splitting into logical services on AWS Lambda. What would help: Given our team size and growth trajectory, which path would you choose? What are the hidden operational costs of each approach?
What NOT To Do
- Don't ask multiple unrelated questions. Keep it focused. If you have 3 questions, ask 3 separate times.
- Don't paste huge code blocks without context. Summarize first, then include relevant snippets.
- Don't ask for predictions about the future. "Will TypeScript still be popular in 5 years?" can't be answered. "Should I learn TypeScript for a new project?" can be.
- Don't ask for free consulting on your entire business. Focus on one specific problem.
- Don't ask questions you could Google. Do basic research first. This shows respect for the specialist's time.
Why This Matters
Great questions lead to great answers. When you ask a person specialist a thoughtful, specific question, you're more likely to get:
- More detailed responses (they can see you're serious)
- Faster responses (easier to understand what you need)
- Better advice (specialists can target their expertise to your specific situation)
- Reusable answers (your question might help others in the future)
Get Specialist Feedback
Now that you know how to ask good questions, ready to tap into real expertise? Ask a professional in your domain—whether it's architecture, security, performance, or product strategy.
Ask for free. Ask now.