Imagine two different software engineers in job interviews. Both are asked for an algorithm that solves some programming puzzle, such as "identify all palindromes in a string of characters."

The first candidate, Alice, reflexively enters problem-solving mode upon hearing the problem. She pauses for a few seconds as she internalizes the problem, and then quickly thinks up a very inefficient algorithm that finds the answer by brute force. She decides to sketch this algorithm first (as a warm up) and then turn her mind to finding a more efficient path to the answer.

The second candidate, Bob, responds very differently to the same problem. He reflexively predicts that he won't be able to solve the problem. He struggles to quiet that voice in his head while he waits for a solution to present itself, but no solution is forthcoming. He struggles to focus as the seconds pass, until a part of his brain points out that he's been quiet for an uncomfortably long time, and the interviewer probably already thinks he's stupid. From then on, his thoughts are stuck on the situation, despite his attempts to wrest them back to the task at hand.

Part of what makes the difference between Alice and Bob might be skill: Alice might have more experience that lets her solve programming puzzles with less concerted effort, which helps her get to a solution before self-doubt creeps in. Self-confidence may also be a factor: perhaps Alice is simply less prone to self-doubt, and therefore less prone to this type of self-sabotage.

A third difference between Alice and Bob is their response pattern. Bob begins by waiting blankly for a solution to present itself; Alice begins by checking whether she can solve a simple version of the problem ("can I solve it by brute force?"). Bob is more liable to panic when no answer comes ("I have been quiet for too long"), Alice is more liable to break the problem down further if no solution presents itself ("Can I divide and conquer?").

This difference is also explained in part by experience: a more seasoned software engineer is more likely to reflexively notice that a problem can be solved with a simple recursion, and know which data structures to apply where. I don't think it's only experience, though. Imagine Alice and Bob both faced with a second problem, outside their usual comfort zone — say, a friend asks them for advice about how to handle a major life-changing event. It's easy to imagine Alice attempting to understand the situation better and asking clarifying questions that help her understand how her friend is thinking about the question. It's similarly easy to imagine Bob feeling profoundly uncomfortable, while he tries to give neutral advice and worries about the fact that he might give bad advice that ruins his friend's life.

One might call what Alice is doing "confidence," but that doesn't tell us how it's working. And 'confidence' also comes with connotations that may not apply to Alice — she may well decide that she isn't in a position to give good advice, she may be working from a shaky understanding and thus doubt her own conclusions, even as she turns her thoughts to understanding the obstacle before her.

One of the big differences, as I see it, is the difference in the response pattern between Alice and Bob. Alice justs gets down to addressing the obstacle before her, Bob spends mental cycles floundering. Managing response patterns is something of an art: when confronted with an obstacle, does your brain switch into problem-solving gear or do you start to flail?

Note that the art of response is not about immediately solving any problem placed before you. Sometimes, the best automatic response is to find some way to disengage or dodge. You aren't obligated to solve every problem placed before you. The goal of having appropriate response patterns is to avoid flailing and avoid staring blankly. The goal is to have your mind shift into the problem-solving gear.

Having effective responses prepared isn't necessarily a general skill. I'm a computer programmer at heart, and a few years ago I switched paths to math research. If I'm faced with a programming problem that I want to solve, I quickly and easily slip into effective-response-mode; I can often find solutions to problems reflexively, and when I can't, I reflexively examine the problem from many different viewpoints and start breaking it down. Yet, if you confront me with a math problem I want solved, there are still times when my reflexive response is to sit back and wait for someone else to solve it for me. (It doesn't help that I'm surrounded by brilliant mathematicians who can do so successfully.) That reflexive response — the one of blanking my mind, curious while I wait for someone else to find the answer — is not a very effective response.

Effective responses aren't about answering quickly, either. When paired with expertise and familiarity an effective response to an obstacle will often lead to a fast answer, but oftentimes the most effective response is to pause and think. Plenty of people have very ineffective response patterns that involve opening their mouths the moment you ask them to help you confront an obstacle. Some people reflexively start solving the wrong problem, others reflexively start making excuses for themselves, still others reflexively share personal anecdotes that paint them in a positive light. Effective response patterns are not about answering fast, they're about answering well.

The most competent people that I know are, almost universally, people who have very effective response patterns to obstacles in their areas of expertise. The good programmers I meet reflexively start breaking a problem down the moment they decide to solve it. The stellar mathematicians I know reflexively start prodding at problems with various techniques, or reflexively identify parts of the problem that they don't yet understand. The best businesspeople among my advisors are people who listen to me describe the choice before me, and reflexively describe the costs, constraints, and opportunities they observe. Each has acquired a highly effective response pattern to problems that fall within their area of expertise. This response pattern allows them to hit an obstacle and start taking it apart, with an Alice-like mindset, rather than flailing and doubting themselves as per Bob.

Confidence, practice, and talent all help develop these specific response patterns quite a bit. That said, you can often learn someone's response patterns with much less effort than it takes to learn their skills: you can start thinking in terms of incentives, opportunity costs, and markets long before you become a master economist (though reading a microeconomics textbook surely doesn't hurt). Competence isn't just about believing in your capabilities; it's also about having a pattern prepared that takes you directly to the "break down the problem and gnaw on the parts" stage without ever dumping you into the "worry about how you've been silent for a long time and reflect on the fact that the interviewer probably thinks you're dumb" zone.

Having an explicit pattern, such as a checklist, can help you switch from one pattern to the other. For example, imagine Bob in the example above had a checklist which read as follows:

If I start dwelling on how likely I am to fail, I will do the following. (1) Say "hmm, let me think for a few minutes" aloud. (2) Verify that I understand the problem, and ask clarifying questions if I don't. (3) Check whether I could easily solve the problem by brute force. (3) Come up with a few simplifications of the problem. (4) Find a way to break off only one part of the problem or one of its simplified variants.

then he may well be able to manually switch from a flailing response pattern to an effective one. This sort of manual switching is a good way to instill a new response pattern. The ultimate goal, though, is for efficient response patterns to become reflexive.

In fact, I think many people could benefit from developing efficient "fallback" response patterns, to handle new or surprising situations. Response patterns like "verify that your observations were correct" or "find more data" or "generate more than one plausible explanation for the surprise" and so on. As far as I can tell, there is a general skill of being able to smoothly handle surprising new situations and think on your feet, and I suspect this can be attained by developing good response patterns designed for surprising new situations.

This advice is not new, of course. Lots of self-help advice will tell you to break down the problems before you into smaller parts, and to infuse your actions with intentionality, and to reflexively do the obvious things, and so on. So I won't say much more on how to attain the Alice-like mindstate as opposed to the Bob-like mindstate. The important takeaway is that sometimes people respond to obstacles by breaking them down and other times they respond by flailing, and one way or another, it's useful to develop reflexive responses that put you into the former mindstate.

The way that I do it is by monitoring the ways that I respond to new obstacles placed before me. I watch myself facing various situations and observe which ones lead be to reflexively get defensive, or to reflexively blank my mind and wait for someone else to answer, or to reflexively freeze in shock and act dumbfounded. Then I practice building better response patterns for those situations, by figuring out what the checklists to run are, and I do my best to replace those patterns with reflexive inquiry, curiosity, requests for clarification, and impulses to take initiative. Polished response patterns have proven useful to me, and I attribute much of my skill at math, programming, and running nonprofits to having sane responses to new obstacles.

Regardless of where you get your response patterns from, I suspect that honing them will do you well.