Can You Explain It to the Customer?

The thing I weight least when I interview a Solutions Architect is how much MongoDB they already know. That surprises people — it’s a MongoDB role. But product knowledge is the one thing the job is built to teach you, and forty-five minutes is far too scarce to spend measuring the only thing I can install later. So I score for everything else — and I built a scorecard to keep myself honest about it.

I have spent a lot of the last few months on the other side of the interview table, for pre-sales SA roles — the people who sit with a customer and turn a hard technical problem into a plan they trust. The bar I hold in that forty-five minutes becomes the team I work with for years. Hiring is the highest-leverage thing I do — more than any architecture I draw or any workshop I run, because those help one customer and a good hire helps every customer that person ever touches. That is exactly why I don’t trust the warm feeling that follows a good conversation. A good conversation is easy to fake in both directions.

So instead of a gut call, I score. The scorecard runs across six distinct technical areas — Coding & Development, Databases & Distributed Systems, Software Architecture & Design Patterns, Microservices & Event-Driven Architecture, Cloud & Hyperscalers, and Search, Streaming & AI — each rated on its own rather than blurred into a single impression. Scoring one area at a time is what stops a candidate’s fluency in the thing I happened to ask about first from colouring everything after it.

The last of those areas is deliberate, and it’s the one I keep expanding. Search, streaming, event-driven systems, embeddings and vector search — I test them because that’s where the field is going, not just where it’s been. Enterprise data problems are moving toward real-time and AI-native architectures, and I’m hiring people who’ll still be useful in that world, not only in the one I interviewed them in. A scorecard is only as forward-looking as the areas you put on it, so I revisit mine as the ground shifts.

The scorecard has evolved. I kept adding types of question, because different types expose different things. Scenario questions — “a customer wants X, walk me through how you’d approach it” — show me how someone reasons when there’s no clean answer. Experience questions — “tell me about a time you had to talk a customer out of something” — show me what they’ve actually lived versus what they’ve only read. Direct questions — “what does this feature do, and when would you not use it” — show me the shape of what they know and, more usefully, how they behave at the edge of it. Each type catches something the others miss.

From those scored answers I extrapolate — weighting the areas and question types into a single indicator of whether this person is a good fit for the role. The weights are where the judgement lives, and three signals carry most of it — and none of them is a row on the grid. They’re read across it. Can you explain a hard idea in plain language, the way you’d talk to a customer? Do you bring breadth across many areas, or a single deep spike? And did you care enough to prepare? Those three cut through every technical area at once, and they carry more weight than any single score. The rest of this piece is those three signals, one at a time — plus the part nobody tells you about interviewing, which is how you keep the whole thing fair.

The whole job of a pre-sales Solutions Architect is one thing: sit between a customer’s problem and a product’s capabilities, and translate. I’ve done this role for years and hired for it for as long — so take this as settled, not aspirational. Translation is not a soft skill bolted onto the work. Translation is the work. Everything technical the role touches exists to serve that one act: making a hard idea land with the person who has to act on it.

So the first thing I listen for is not whether a candidate knows something. It is whether they can hand it to someone else.

Those are different skills, and the gap between them is wider than most engineers believe. I have watched brilliant people — genuinely deep, the kind who could redesign your storage engine over lunch — completely lose a room because every sentence needed three more sentences to hold it up. The knowledge was real. The transfer failed.

There is a name for the mechanism behind that failure. Psychologists call it the curse of knowledge: once you understand something, you lose the ability to model what it is like not to understand it — Camerer, Loewenstein & Weber, “The Curse of Knowledge in Economic Settings”, Journal of Political Economy, 1989. The more expert you are, the worse you estimate what a novice needs. Jargon is the tell — it is the expert quietly assuming everyone shares their vocabulary. In a pre-sales conversation, that assumption loses the deal, because the person holding the budget is exactly the person the jargon leaves behind.

The signal I am actually hunting for is compression. Take something you clearly understand and give it to a customer without making them feel small. The test I like most is quiet: ask a candidate to explain something they know cold — an index, a replica set, retrieval-augmented generation — as if the listener were smart, curious, and completely new to it. The ones who can do it don’t dumb it down. They find the load-bearing idea, reach for an analogy that actually carries weight, and stop. The ones who can’t just talk faster.

I’ll flag the obvious counter, because it is a real one: being able to explain something simply is not proof you understand its full depth, and struggling to simplify is not proof you don’t. The popular “if you can’t explain it simply, you don’t understand it” line overstates the case — and it was never actually said by the physicist it’s usually pinned to. Depth and communication are two skills, not one. But for this role, I need both, and I can teach the product depth far more easily than I can teach someone to get out of their own vocabulary.

The second signal is breadth, and it is a deliberate choice that some people find counterintuitive: I would rather hire someone who has seen five databases shallowly than someone who has seen only MongoDB deeply.

That sounds backwards for a MongoDB role. It isn’t, and the reason is simple. The MongoDB depth is the one thing the job is built to teach you. We have onboarding, enablement, a whole field of colleagues, and real customer problems to learn on — product depth compounds fast once you’re inside. What onboarding cannot install is a wide frame of reference, the instinct for pattern-matching across domains, and the ability to explain. Those you bring with you or you don’t.

This is a bet on the future, not the present. I’m not hiring for who a candidate is on day one — I’m hiring for who they’ll be twelve months in, and those can be very different people. There’s a well-worn maxim that captures it: hire for slope, not y-intercept — Paul Buchheit, via Sam Altman. The intercept is what someone knows the day they start; the slope is how fast they climb. Over any horizon longer than a quarter, slope wins — the fast learner who started lower overtakes the polished expert who started flat. Breadth is one of the best predictors of slope I’ve found, because someone who has deliberately learned across many areas has already shown me they keep learning. Betting on slope is how I hire ahead of the curve instead of behind it.

The shape I look for has a name too: T-shaped — named by David Guest in 1995, popularised by IDEO’s Tim Brown. Broad horizontal literacy across many fields, plus one vertical spike of real depth — and crucially, that spike can be in anything. It doesn’t have to be MongoDB. A candidate who went deep on Postgres and can genuinely reason about its trade-offs has shown me they can go deep on ours.

The payoff shows up in front of the customer. An SA who has actually worked with five databases can position ours honestly — they know where it wins, and they know where it doesn’t, and they’ll say so. That honesty is what earns a technical buyer’s trust, and trust is the entire currency of pre-sales. The candidate who only knows MongoDB can only sell MongoDB. They can’t tell a customer when the answer is “don’t use us for this,” which means the customer can never fully believe them when they say “use us for that.” My own database-choice guide is an artefact of exactly that muscle — comparing engines on their merits — and I want it in the people I hire, not just on the site.

The third signal is the one that surprised me most, because it is so small and it predicts so much: did the candidate spend any time getting ready?

Not memorising trivia. I don’t care whether someone can recite our release history. I mean the basic act of curiosity — reading about what the company sells before walking in to sell it. And it is remarkable how often that hasn’t happened. People will research the salary band down to the euro, negotiate it hard, and arrive without having spent ten minutes on the product page. They know exactly what the role pays and almost nothing about what the role does.

I want to be careful here, because this is where an interviewer can slide into arrogance, and I’ve watched people do it. Preparation is a signal, not a filter. Nerves are real. Some genuinely excellent people freeze in interviews, blank on things they know cold, and interview far below their actual ability — that is noise, and penalising it would be a mistake. I am not testing whether someone can perform under interview pressure. I am reading a much narrower thing: did curiosity show up before the room, when there was no pressure at all, only a product page and twenty free minutes.

Because that is the job. A pre-sales SA who won’t research their own interview is showing me, in miniature, how they’ll walk into a prospect’s account: unprepared, improvising, hoping to wing it on charm. The customers I send people into can smell that instantly. The candidate who arrives having actually read about the product — who asks a sharp question about something they found, who says “I saw you do X, how does that hold up when…” — has just demonstrated the single most important trait in the role. Not knowledge. Ownership. The instinct to find out before being asked.

That instinct is the thing I most want and the thing I can least teach. So when it shows up unprompted in an interview, I notice — and I weight it heavily.

Everything above is what I look for. This section is about not fooling myself while I look for it — which turns out to be the harder skill, and the one where leadership actually shows.

An interview is mostly noise. A candidate is nervous, or over-caffeinated, or has a rehearsed answer that sounds impressive and says nothing. Someone name-drops the right technologies in the right order and it feels like competence. Someone else stumbles over their words and it feels like weakness. Both feelings are usually wrong. The interviewer’s whole job is to separate the signal — how this person reasons, explains, and handles the edge of their own knowledge — from the noise wrapped around it.

The best moment in any technical interview is when a candidate hits “I don’t know.” What they do next is almost pure signal. Do they bluff, or do they reason out loud toward an answer, or do they simply say “I don’t know, here’s how I’d find out”? That last one is what a customer gets on a hard day, and it tells me more than any correct answer to an easy question.

The way I fight the noise is structure — the scorecard from the start of this piece is exactly that discipline pointed at the whole interview. Same areas, comparable questions, consistent scoring, every candidate held to the same bar. My instinct is not the instrument; the structure is. That isn’t only my preference — the research backs it hard, and I lean on it because a leader who ignores what’s known about their own craft is just guessing with confidence. Structured interviews far outpredict free-flowing conversation (Schmidt & Hunter, Psychological Bulletin, 1998), and the most careful recent re-analysis ranks them the single strongest predictor of job performance, above raw cognitive-ability testing — Sackett, Zhang, Berry & Lievens, Journal of Applied Psychology, 2022. What separates a structured interview from the “let’s just chat and see” version everyone’s gut prefers is nothing but the format — same interviewer, same candidate, same forty-five minutes. The uncomfortable implication: the more you trust the warm conversation, the less you should.

But structure is a floor, not a script. The discipline is holding the same bar for every candidate — asking comparable questions, scoring against the same rubric, writing down what I actually observed rather than the halo of a confident voice — while still reading the human in front of me. It means giving the frozen candidate a second door into a question instead of moving on. It means discounting the smooth talker who filled four minutes and answered nothing. Fairness and rigour are the same act here: the structure protects the nervous-but-excellent candidate from my gut exactly as much as it protects the team from a polished hire who can’t actually do the work.

This is the part of leadership nobody applauds — building a system that overrides your own worst instincts and holds even when you’re tired, biased, or charmed. It’s unglamorous, and it’s the difference between the team you meant to build and the team your gut would have handed you. Anyone can run an interview. Running the same fair, rigorous interview for the tenth candidate as for the first is the actual job.

Let me make the ideal concrete. Two candidates — both invented, illustrative composites, not real people, assembled from patterns I’ve seen many times over.

Composite A looks perfect on paper. Years on MongoDB, every feature at their fingertips, can talk sharding topology and index selectivity without pausing for breath. Ask them to explain it to a customer and the room fogs over — every answer is longer than the question, thick with vocabulary that assumes you already know the answer. Ask what they’d do when MongoDB is the wrong tool and they can’t get there; they’ve only ever known one hammer. They didn’t look at anything before the interview because they figured their depth would carry it. On a scorecard that only measures product knowledge, they win easily.

Composite B knows less MongoDB — noticeably less. But they’ve worked across three databases, shipped on two clouds, and picked up enough AI to be dangerous, and when you ask them to explain any of it they find the one idea that matters and hand it to you clean. When you push into what they don’t know, they say so, and then reason toward an answer instead of bluffing. They’d read about the product before arriving and opened with a sharp question about something they’d found. They will be more useful to a customer in month three than Composite A is today.

I hire Composite B every time, and it isn’t close.

Not because product knowledge doesn’t matter — it does, and B will build it fast, because building it fast is exactly the trait they already showed me. I hire B because the things B brought are the things I can’t install: the breadth, the compression, the ownership, the honesty at the edge of their knowledge. The MongoDB depth is the most teachable thing in the whole role. Everything that makes B trustworthy in front of a customer is the least teachable, and they already have it.

So the two takeaways, one for each side of the table. If you interview: structure the room, test the translation and not just the recall, and bet on slope. If you’re the candidate: read the website — not to pass a quiz, but because the curiosity that makes you read it is the whole job, and we can tell within minutes whether you brought it.

The best hire is rarely the person who knows the most on the day. It’s the person a customer will trust in a hard conversation and the team will learn from in an easy one — because both of those compound, and the product knowledge shows up on its own. That’s what the scorecard is built to find. Everything else, I can teach.