Complete agreement. "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?"

> none of those organizations ever trained me at anything at all

They trained us repeatedly not to bribe foreign government officials, even though I had zero access to anybody like that. There was also some mandatory training against harassing coworkers. I.e. "protect the company from lawsuits" training, not "here are some ideas for how to do your job more effectively" training. They were megacorps, too.

Yeah, I had no training on being an interviewer before I started doing interviews. My manager gave me some tips, and I came up with two security bug-hunt exercises (was hiring AppSec engineers), but that was it.

Now, I wonder if I had rejected earlier candidates that I would have passed if I was a better interviewer.

Same here. I receive a training budget at some places but it goes unspent. Everything is self directed learning in my own time.

> While I agree, how much training does anyone get as an interviewer?

TL;DR: not enough training.

As a hiring manager, whenever we start a hiring period I have a conversation with my interviewer team about what qualities we're looking for and review the questions they plan to ask in order to normalize the process. Stuff like "what does a good answer look like, and why? what does a bad answer look like? is this something easy for a candidate to engage with or will you spend half the interview just explaining the background? is this coding question unreasonably hard?" and so on.

I also look at the evaluations that interviewers give relative to other interviewers. Almost every hiring cycle I've done I've had to deal with some interviewer (all over the seniority spectrum) asking unreasonably hard questions.

Sounds common to have training in big tech but I never received any training either. Sometimes we’d discuss changes we wanted to make to the interview process, which suppose could be considered adjacent to training.

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.

The point is that you’re supposed to kiss clown’s ring and do the dance.

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.

To be fair, the simple answer is not so simple within Google.

The issue is that Google achieves reliability by insisting on n+2/n+1. Globally your service is in at least 2 more data centers than is required for full load. In each region in at least 1 more data center than is required for full load.

If you're using the Google toolchain, all of the scalability and fallover problems are automatically handled by the layers that you're relying on. Which everyone expects you to use, because they are already integrated into the environment.

But if you go to use Postgres as a data storage layer, then you also need to take care of replication, failover, backup, and make sure that this is integrated with the automated systems that Google already has to detect when this is needed. Even after you've done that, people from outside of your team will need to be convinced that you've done that. Simply because you're doing things differently, you'll get extra scrutiny.

As a result, even if Postgres would have worked perfectly well, it is usually not the optimal answer for someone who is working within Google's environment. Don't think of it in terms of, "Does this do the job?" Think about it in terms of, "Can those in the broader organization easily certify that this does the job?" That certification is easier when you use standardized parts that are themselves already certified within the organization.

My guess is that your interviewer was aware of this. And was left with, "What about that question that I didn't think to ask you about?"

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.

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

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.

Apparently some combo of kissing the arse and reading the mind of the interviewer...

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.

distributed virtual abstract factory

nosql on serverless

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!

I just wish that in those cases the interviewee gives feedback and allows you to rewrite instead of just failing you. I mean in practice nobody writes library functions themselves unless absolutely necessary, but I get that for some positions you have to demonstrate that you can write lower-level code if you have to.

I think that it was probably a poorly designed question, but surely you could throw the interviewer a bone by giving a custom answer after they reject the library.

I do absolutely love the other answer!

I didn't quite mean it that way. My question is basically asking "Does this hammer know that not every problem is a nail". To give a specific answer to your question, my accounting system is excel, and "everyone" is me. There are definitely plenty of places where a database makes sense. But it's also important for database engineers to understand where databases don't make sense. It's kind of like that old problem we had where people would keep on saying "We can do X with blockchain" and the typical answer is "ok but that's worse".

> it needs a real engineer (and often more money than they can spend) to create the right solution.

Then it's the wrong solution. Period.

There are plenty of annoyances with spreadsheets, but part of what makes them so robust and powerful is that they don't take a ton of specialized knowledge, and they remain incredibly flexible.

An expensive, complicated, static, "right" solution for a small business is folly (honestly - this stays true up to medium/large business). It's a ton of time and energy focused on the absolute wrong thing. When a spreadsheet can reach the same result in a fraction of the time.

Especially given the result may not actually be that important, and they pivot to something else entirely in the very near future.

I've worked at several startups. I'd caution even software startups from assuming that custom solutions are the right approach. They usually aren't. They're a waste of time and effort that ends up saddling you with a brittle, expensive solution designed to solve problems from last year.

Argh gawd I hate this!

There are plenty of reasons that a department within a company will prefer spreadsheets. Software is not the answer to everything and also this is the same problem you get when Microsoft introduces those pesky 'Power App' developers etc or previously the Sharepoint 'web parts' etc....essentially someone who kind of feels they are the 'owner' of some information then decides to formalise the process in their own little way.

Now you have a person wasting a bit of time making their little tool but you've also got people complaining that someone's now essentially taken control of it etc. At a former employer our procurement team used spreadsheets to track basically everything but importantly everything on our PCBs - every single component and their suppliers and prices etc (various factories around China usually). This would have been a horrible thing to try and formalise in a web app just because of how often they were all changing their own conventions etc (often suppliers changing what information they gave to them, too). It would have been a wild goose chase to formalise it and more than the trouble it would be worth.

Well, you've long thought wrong.

> If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software

All interviews are contrived / artificial situations: The point is to understand the candidate's thought processes. Furthermore, we're getting Bilsbie's (op) take on the situation, there may be context that the interviewer forgot to mention or otherwise Bilsbie didn't understand / remember.

Specifically, if (the hypothetical situation) is a critical business process that they need an audit log of; or that they want to scale, this becomes an exercise in demonstrating that the candidate knows how to collect requirements and turn a manual process into a business application.

The interviewer could also be trying to probe knowledge of event processing, ect, ect, and maybe came up with a bad question. We just don't know.

Given that Bilsbie can't read their interviewer's mind, there's no way to know if that's what the interviewer wanted, or if the interviewer themselves was bad at interviewing candidates.