Getting the information you need from experts

Whether you're learning a new codebase from a teammate or digging into an unfamiliar technology, asking questions is a core engineering skill. You can improve your odds of getting a useful answer by deliberately shaping how you ask, and by steering the conversation when it drifts off course.

Why vague questions fail

An underspecified question often triggers one of these responses:

  • The person starts by explaining fundamentals you already know.
  • They share information that's new to you but irrelevant to the actual problem.
  • They provide a relevant explanation, but load it with terminology you don't understand.

All of these outcomes waste time and can feel condescending, even when the person answering had no way of knowing what you already know. To avoid them, you can use a few specific tactics.

Ask yes/no questions

The single most effective technique is to phrase your question so it can be answered with "yes" or "no." This sharply limits how far an answerer can wander from the topic. Even on complicated subjects, you can break down your curiosity into these small, targeted queries. Real examples of such questions about databases include:

  • How often do you expect db failovers to happen? Like every week?
  • Do you need to scale up by hand?
  • Are FB/Dropbox both using MySQL?
  • Is orchestrator a proxy?
  • Do you route queries to a shard based on the id you're searching for?

Answers to yes/no questions rarely stop at a single word; the person will almost always elaborate, and that elaboration tends to be useful. Because they're easy to answer quickly, they also produce faster results.

State your understanding

A close relative of the yes/no question is the "check my understanding" approach. Lay out what you believe about the system, including any guesses about its rationale, and explicitly ask whether it's correct. A well-formed understanding statement should cover your goal, what you know about how the relevant systems work, and where you're speculating.

For example, instead of asking "Why is rkt's storage designed differently from Docker's?", you can summarize what you know about how each one lays out images on disk, propose a hypothesis about the architectural trade-offs, and close by asking whether your reasoning holds. This kind of question gives the answerer something concrete to react to, and it often surfaces details you'd never have thought to ask about. For instance, a response might point out a fundamental difference between the two formats—like that the ACI format is a DAG instead of a linked list—that completely reframes the design decision.

Writing down your understanding also clarifies your own thinking; sometimes you'll answer your own question in the process. At best, this is a form of yes/no question that lets someone correct the parts that are wrong and confirm the parts that are right.

Steer the conversation

If an explanation is going off on a long tangent, interrupt with a more specific question. This feels rude, but it's ultimately more efficient for both sides; continuing down an irrelevant path is a waste of everyone's time. A more targeted question is the natural way to interrupt, since an irrelevant tangent usually stems from a question that was too vague.

Similarly, don't let a statement that fails to answer your question end the exchange. Keep pushing, but do so constructively: ask an even more pointed question in the direction you actually care about, or ask the person to define a term you didn't understand. When you receive surprising new information, take a moment to process it. In a real-time conversation it's fine to say something like "that's surprising to me, let me think for a minute" before asking your next question.

These techniques require a small amount of confidence. It can be tempting to assume a confusing explanation is excellent and that you're simply not smart enough to follow it. But many knowledgeable people simply aren't clear communicators, and most genuinely want to help. Remember that if you walk away with just one new piece of information—even the answer to a single yes/no question—that's a victory. Avoid advice that frames experts as perfect and question-askers as a burden; your coworkers are usually trying to help, even when their first answer misses the mark.

Being a better answerer

There's a counterpart to these techniques: making yourself easier to extract information from. When you are explaining something, pause periodically and check in with the other person. A simple "does that make sense?" helps, though it's not infallible. Be especially vigilant about checking in when you're explaining a concept you've never described before, or when you don't know the person you're talking to well—both are situations where your initial explanation is likely to miss the mark.

The ability to draw knowledge out of people is an underrated engineering skill. Some developers know far more than they can explain well. Rather than being frustrated by that, you can simply get better at asking the kinds of questions that produce the answers you need. This widens the pool of people you can learn from: instead of needing someone who gives crisp explanations on the first try, you need someone who has the information you want, and you can use targeted questions to extract it. Most people are genuinely happy to be useful, and with practice, a series of well-aimed questions gets you where you need to go quickly—a good use of everyone's time.