I had this just the other day actually. I am in SRE and the overwhelming majority of the code I write is terraform, instructions for a Dockerfile or CI pipeline, or just some random ass bash to compile information.. I don't actually do that much coding at all and what I do end up doing is pretty rudimentary.

EVERY job interview I go on though wants to do some leetcode style code puzzle. The one I got the other day I just said to the guy, "I honestly don't know how to do this. The code I write isn't fancy or clever. It's mostly just to get things done." We worked through it together though and I understood the logic by the end but they were mostly holding my hand. What I was doing was throwing out ideas and trying to work out pros/cons with the interviewer. That was enough apparently because he green-lit me for the next round..

These type of interview questions really annoy me because they are not representative of the job in any way. In addition to work, I also have a life that does not involve computers. After putting in a 40 hour week on engineering stuff, grinding leetcode over a weekend is a hard sell.

They said "don't just say" so they mean like "I don't know but I think I've heard of that and blah" or "I'm not certain but I've worked on X which is similar so I think I could pitch in easily"

I'm sure individual interviewers have their own styles, but yeah I'm with you here. Few things are more frustrating for me during an interview than wasting 30 minutes going in circles on something because the candidate isn't being honest with me.

Our role (low level software) is going to be full of things they haven't seen before. I would rather have a candidate who can quickly identify that they don't understand something, and likewise quickly try to fill that gap so they can move on to the next thing, than have someone try to bluff their way through.

I understand that there's a level of "fake it til you make it" during interviews, but the goal of the interviewer is to get as much signal on you as a candidate as possible. Admitting you don't know something may not feel good, but then it gives the interviewer the opportunity to test you on different things that could really highlight your skills. For example, we ask questions on multithreading during our panel. If you don't know how a semaphore works, and you tell me that upfront, that gives me the opportunity to explain the concept to you and see what your process is like working through new information.

I take what they're saying as "don't just give up/refuse to answer" - it's fine to say "I don't know, but I have a guess on how I'd start/find out" and try to work through that. In a real working environment, this is more how it'd work, and if someone truly didn't know where to start, usually the co-worker would try to help, which is not always how interviews go.