[ap22213]

In the last two weeks I interviewed three candidates with masters of science C.S. None of the three knew the memory size in bytes of a double precision floating point variable. None of the three could explain scenarios in which they would use an array over a linked list.

[probably_wrong]

I don't think that first question proves what you think it proves.

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.

[scatters]

sizeof(double) is not specific to any one programming language or architecture; it's determined by IEEE 754, an international, cross-language, cross-platform standard. Non-IEEE floating-point implementations are exceedingly rare nowadays (although they do exist).

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.

[kirab]

Well..

  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.

[daemin]

So a reasonable answer could say - usually 8 bytes - but sometimes with extended precision it could be 10 bytes, etc...

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.

[scatters]

ap22213 (OP for this thread) was more precise than I was; they actually wrote "a double precision floating point variable" rather than writing "double", which could either be a shorthand for "double precision floating point" or be referring to a platform/language type (where that exists by that name).

[ap22213]

The particular positions that I'm hiring for require certain kinds of knowledge, unfortunately. When one is dealing with Petabytes of structured signal data, it's helpful (but not required) that someone know memory layout. But, it's not the first question I ask.

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.

[CJefferson]

The floating point I think comes from C bias.

In C you kind of have to know the size of a double -- you'll call "sizeof(double)" fairly often, you'll notice the number in your code.

In most languages, you don't have a way of knowing the size of a double -- and furthermore the size a double takes in your code won't be sizeof(double) anyway, it will be much more.