How do I answer these quirky HR questions for a software engineering interview: “teach a non-technical person something technical in a few minutes” and “explain to a non-technical person how they would identify elegant code”?

You should ask the interviewer if they want a one minute, five minute, or ten minute explanation, and adjust the depth you go into accordingly.

I don't consider these quirky HR questions. They're very reasonable, especially for more senior candidates. Why? Because one of the hallmarks of a good senior engineer - in my opinion - is the ability to work with people at all points on the technology spectrum. Many decision makers are rusty in their technology, but they still need to be convinced why something is a good or bad idea. Ditto for people with funding.

Teach a non-technical person something technical in a few minutes. This identifies how good a translator you are between tech and non-tech. You can't always anticipate what someone you need to work with knows or does not know, and it will be useful for you to be able to explain. Pick something in your area of expertise, or something general which is interesting.

For me I would probably explain how a web browser loads a web page, and why it's so much more complicated than it looks. You could just as easily explain how a remote control works, how a universal remote mimics remotes, the relationship between a computer's firmware and its operating system, how a cell phone transitions between cell towers, what have you.

You should ask the interviewer if they want a one minute, five minute, or ten minute explanation, and adjust the depth you go into accordingly.

How to identify elegant code. This one is a little more contrived, but still reasonable. You need to explain what code is, what differentiates elegant code from poor code, and why that difference is significant for engineering.

You can give examples a layman can identify, such as reasonable variable and method names, consistent formatting, breaking the code into 'paragraphs' with no chunk too long or too short, and so on.

For both of these questions - and indeed for many engineering tasks - the ability to make good analogies is vital. Analogy is a way of converting something in a foreign domain to a domain your target listener understands. It can convey the shape of something to a layperson better than almost anything else. Just make sure you use it for good rather than evil.