It's both.

As a hiring manager I've had situations like this arise because there was a gap in my plan and I didn't realize it. When those come up, we thank them for their cleverness, apologize to the candidate, reframe the situation, and give them another shot.

But also sometimes I leave intentional ambiguity in the plan. Part of the goal is to see if they have a degree of common sense commensurate to their level. If they're interviewing for a high level position, I'd expect them to be able to spot silly flaws and push back that perhaps the whole problem needs rethinking. And of course, I also expect them to know the brute force solution as well. Do they only know one? Both? Let's fine out.

Postgres might have been a perfect answer, but the candidate needs to explain why and how.

The purpose of the interview is for the candidate to demonstrate their thought process and ability to communicate it. “Just use Postgres” doesn’t do that.

This would be more obvious if it was a LeetCode problem and the candidate just regurgitated an algorithm from memory without explaining anything about it. Yeah it’s technically the right answer but the interviewer can’t tell if you actually understand what you’re talking about or if you just happened to memorize and answer that works.

Interviews are about communication and demonstrating thought process.

I dont even think you need to be neurodivergent or anything to answer this question like the parent’s cofounder did.

From one side, we call ourselves problem solvers, on the other hand we are not satisfied with simple solutions to these problems. If im interviewing for a job, i should be expected to behave and solve hypothetical problems the way id do it on the job. If that screws up your script, you probably suck at hiring and communicating your expectations.

Or just add a couple zeros to all the requirements until postgres is a worse solution than whatever the interviewer envisions. Isn't that the point of stating throughput requirements?

It's probably more about your mindset, than about being neurodivergent vs. neurotypical. If you care more about maintainability and operations, there's a whole host of solutions you'd never built.

if your brain short-circuits at ambiguity, or you're completely incapable of understanding intent and you take everything literally, that is a negative hiring signal.

That was what I felt too. Why even need an interview for an acquihire when you have a direct link with the founder/CEO?

On the one hand, interviewers can suck. They can be uninterested in understanding and embrace instead the role of a trigger-happy interrogator looking not for a good response - something that may very well require effort and considering new ideas on the part of the interviewer - but an excuse to cross you off the list. The interview begins to look like a game of "Guess what I'm thinking". Interviews should simulate a colleague asking you for help.

On the other hand, interviewees can give poor answers with no explanation. The interviewer should press for an explanation in those cases, of course, but perhaps some are trying to see if the interviewee instinctively provides at least some basic rationale behind the answer without having to be prodded each time, in which case it is a matter of communication habits and skills. Communication is essential, and it is under-emphasized and under-taught in so-called 'STEM' curricula.

No, the point was to demonstrate how you’d design a complex system.

If a valid answer was “just use Postgres” then it just wasn’t a very good interview question.

In real life, the answer almost certainly would be “just use Postgres” and everyone would be happy.

It depends on the situation.

Sometimes you just have a bad interviewer who is looking for something specific from you but isn't telling you. If you're experienced in these interviews, you catch the signs and adapt by asking questions to suss out which direction the interviewer wants to take it.

Sometimes your answer is plausible but the interviewer wants to see you justify it. Sometimes your answer is wrong but the interviewer wants to see if you can reason your way through it, and maybe come up with an alternative.

If you're junior/inexperienced, it's often hard to tell and it'll feel arbitrary/unfair, and unfortunately that's just how it goes. As a more senior/experienced candidate, you can often figure out which situation you're in by asking questions to feel out the interviewer and then try to pivot during the interview, though it still takes valuable minutes out of the interview that you could have otherwise spent showing your competence.

"Postgres, because..."

They want a conversation to see how you think, not an actual answer.

Which is stupid, because they asked a question that the person didn't need to think to answer. So they didn't get to see them think.

nosql on serverless

distributed virtual abstract factory

My read of the story is that the decision to hire was already made, the interviewer goofed but was then set on the right track by his boss.

Eh, it's a good answer and shows good instincts, but they still want to know how he would design a system if one was necessary. There's no need to be ridiculous about any of this from either perspective, which is why it should never have been a "fail" without the original interviewer simply saying "That's a solid answer now tell me what you would do if you had to build something new". I mean look how much time he wasted for everyone including his own CEO by being stubborn about it.

The point is the interviewers are sometimes obtuse.

Sometimes the point of the interview is to see if the candidate knows an existing solution and "just use postgres" is the good answer. Sometimes it's to test the technical chops and pretending postgres doesn't exist is the point.

The candidate shouldn't be expected to always guess right, unless the position says "a psychic". The interviewer should notice if the candidate is solving the wrong kind of problem and nudge them in the right direction instead of punishing the candidate for the wrong guess.

The point isnt to give a simple answer, even if it's a correct answer. The point is show how much you know and how smart you are.

The question is framed to you as a way for you to show you know x, y and z and talk about x, y and z.

Even if a valid solution is just do a, that's great. But the interviewer has no idea if you actually know about x ,y and z do they ?

In an interview you need to explain your thought process and demonstrate that you’re making an informed decision with supporting evidence.

Saying “just use Postgres” and then providing no explanation for why you believe Postgres is sufficient for the job, a general explanation of what type of hardware and architecture you’d use, and other details is not answering the question.

Patrick Collison sounds like a lovely, trusting, scientifically-minded man who needs to learn the constructive power of destruction. The power of rage and contempt for bad solutions and bad communication (regardless of intent).

With a smiley face front-end, of course. Wouldn't want to seem not-nice!