OP doesn't say whether it was a SQL database, but Go's sql.DB automatically uses a connection pool. Naively using goroutines for every sql.DB operation is a good way to run into connection, deadlock, and other problems, so I think OP's approach of not using goroutines unless/until there's a demonstrated need (e.g., through profiling) is sound, and that interviewer might want to pump the brakes on the blanket prescriptions.

I'm gonna say this with all the respect in the world for the technical view —I'm a nerd and I agree with you guys 100%, a huge upvote for the whole thread— but experience taught me something along those lines:

There are such situations (people and places) that command one to put their mindset in "agreement mode", not because of logical reasons¹, but absent or even contrary to those, because of a need to reduce friction². In this meta-knowledge space³ lies the solution space⁴ for all your problems in a human environment.

When you approach things like that, you tend to see where "tech" fits in a wider landscape, and it tells me when to speak and when to shut my big nerdy mouth (whenever it's counterproductive, e.g. premature abstraction⁵ is just as bad as premature optimization). It tells me which lines in the code are "political", "organizational", "structural" not to the tech but to the humans around; and by elimination, which lines are left for us nerds to think about deeply.

It's a dance, really, there's no right/wrong/perfect, but there's a certain way to rise above these human contingencies and actually facilitate the path to market while having a blast — just set your expectations right as to what you can and can't touch, at least for now, reassess on a need-to basis.

So when you see a dark "anti" pattern (OP's case), sure you naively ask 'why', but then if you see org/pol structure, if you see this rigid wall of "this is how we do it, this is who we are", you know it's not about tech anymore. It's personal. Don't hit there. People (especially when insecure, so all of us at times) tend to protect their knowledge like it's a judgment on themselves, like it's proof of their worth, and it's very hard but doable to notice when you're entering such territory with someone.

____

[1]: you might be smarter than your boss, you may be "right" technically

[2]: "friction" in the economic sense, which includes overhead in your code as well as overhead from meetings. What stands between idea and productive execution.

[3]: literally, larger than the technical, including all aspects of engineering, organization and market forces.

[4]: the product that which you seek to make, i.e. that people use. The "internal" side of the product is the organization and codes that make it, that support its continued existence.

[5]: in this case, we "abstract prematurely" when we presume to know a system better than their maintainers, or that our "outside looking in" "fresh" pair of eyes has all the answers already. There is often much more than the technical to consider.

That’s too bad because I’d personally want to hire someone that could demonstrate they knew something I didn’t in an interview.

Well then you're probably the kind of person who would instinctively give signs that someone like me can open their big nerdy mouth, that this is safe territory because we're all engineers trying (this thing with error in the cycle, you know). You're probably someone in the "having a blast" part of my perspective — the kind of people I can actually work with best. The others, we "manage" kinda, with empathy if we can, like they manage us too.

Slight tangent. You know this idea of "feeling comfortable being wrong" in front of someone, that it's OK to say dumb stuff in front of people we trust. I think it enables us to just try, up to our limits (where we must fail a lot by definition, and also the only place where we make actual progress).

When you can build the kind of team that can transparently fail (thus collectively improve...), within that 'safe' tech space of 'engineers', where we know it's everybody just trying and the ethos is aligned with that (nerds may speak, fail, laugh, etc.), I think you've got a solid basis for any project, any company.

You sound like someone who builds that kind of environment. I wouldn't worry in that case; again, nerds will pick up the signs if you just speak your mind — hints like you saying "So I didn't know X, and then blablabla", or simply asking bluntly "what do you think of our choice to do X?" instead of defending it like OP's interviewer. ;-) In general, people who ask questions have to be prepared to hear the answer, that's how I operate personally. I would just temper the response based on what I actually do know of the situation.

I personally don't spend one minute thinking about mind games if the other person seems direct, transparent, honest, especially problem-solving mission-driven kinda mindset.