You're right about it being engineering, not computer science, but IMO it's reasonable to expect someone applying to a programming job (assuming this is what it was) to have at least some software engineering experience.
C and C++ offer a wide variety of arithmetic types.
Double precision is not required by the standards
(except by the optional annex F of C99, covering
IEEE 754 arithmetic), but on most systems, the
double type corresponds to double precision.
However, on 32-bit x86 with extended precision
by default, some compilers may not conform to
the C standard and/or the arithmetic may suffer
from double-rounding issues.I am actually kind of sick of the people that say these details are not important to being a good programmer. They absolutely are, knowing fundamentals of the machine, language, and environment that you are developing in is essential.
Usually, I start off with some behavioral, get-to-know-them type questions. One of these is to ask them to recall the 'best software developer' that they've ever worked with. The great majority of candidates actually say themselves which is unexpected (and a little arrogant to me - weren't we all 'junior' developers once? - didn't we all once look up to someone?). But, surely one of the best would know when to use an array and when not to or know the memory and precision impacts of the variable types that they use.
Learning implementation details about a specific programming language is not what CS is supposed to be about (see the quote about astronomers and telescopes). In fact, if you use several programming languages at the time, I'd go as far as to call it a waste of my time - if I'm worried about overflow for a specific problem, I can get the range of data (in which programming language? which architecture?) in 30 seconds online.
I can see it being a valid question if you are working in a problem down to the bit level. But those are getting rarer, and ultimately it's what an Engineer excels at.
The second question does seem fair, though.