[matthew3]

I like this explanation, I hadn't put it into words before but it feels intuitively correct. For most positions, your ability to communicate what you're doing to the rest of the team is way more important than your ability to write fancy code, or do something like a sample project that isn't our actual day-to-day-codebase. That communication is what's going to keep the team disciplined design wise, keep things consistent, and keep the codebase extensible. And keep morale up since everybody is capable of getting on the same page with everybody.

Dealing with ambiguous scope is the single biggest thing I want in a candidate, so if you don't like dealing with that, you're not going to like working with me anyway. But here's the thing, from my perspective: when's the last time you worked with product or business people who gave you 100% perfect information and specs up-front and then didn't change them? If you can build in a way that allows for future change based on the needs of the team/company/market, then you're very valuable.

> I've never met someone who performs exceptionally well with thinking on the spot in front of people they've never met when the grand prize is gainful employment.

I also want to know, based on this line, how many people the author has interviewed themselves. Cause I've interviewed a few (it's at least in the 100+ area) and have seen as many people do well in that sort of environment as have frozen up. Not uncommon for them to do better than I'd expect myself to do, either, algorithmically - but neither does that always translate directly to an offer, if they're bad at the communication or wrinkle-handling parts.