I interviewed for a position (and got the job) about four years ago for a C#/Angular senior developer and I was suppose to be “speaking my architectural experience into the team”. At the time, the only way I could document 10+ years of development experience was by putting a job I had worked at for a decade doing cross platform C and C++ with a little bit of assembly.

Out of nowhere, after I thought the interview was over, one guy kept drilling me on that type of low level stuff that had nothing to do with the job just to prove how smart he was. I remembered all of it thanks to a decade of dealing with it and too much time on comp.lang.c but it was still off putting.

I’ve since cut all of that stuff off my resume.

I wasn't there, so I can't know how the interview went, but are you sure the motivation was "just to prove how smart he was" ?

If I'm already 100% sure I'll recommend a hire, it's not rare for me to go off-script and dig into random stuff in the candidate's experience, first of all because I find it interesting or fun to talk about, and second because having deep knowledge about anything is positive signal, regardless of whether it's useful for the job.

I have definitely been in this scenario and asked people who had relevant background to work out low-level performance details of their code. I hope they didn't think I was "drilling" them.

My (would be) manager who was also technical (he has since self demoted to an IC role after his kids graduated college) was already satisfied. It was one of the other devs who was sitting in.

I think he asked me something about the difference between undefined and implementation defined behavior and the an example of each. This was in 2015. I had the same question when it was relevant for an interview in 1999.

I’ve geeked out with another hiring manager at an interview about some old 8 bit coding I did but that felt different.

If I was hiring for this sort of position, I'd want them to talk about the difference between hard and soft real time. I'd want to know whether or not they were familiar with embedded software development standards and what sort of things are restricted from "normal" environments when you are working in the embedded environment.

The last thing I would want to see is lines of code on a whiteboard. I'd want to see how they'd structure their code, not whether or not they remember C/C++/Rust/language-de-jour syntax.

All of the proposals for questions that I've seen in this thread are for basic programming skills. Not whether or not the person knows the environment we are hiring for.

Hopefully. But I've heard from people who got asked leetcode style stuff in addition to those kinds of questions because it was company policy for anyone interviewing to be a "software engineer".

Best to be prepared.