> If you claim to know C very well and can't knock that out in 5 minutes, and it takes you 45 minutes of prompting, well, you don't know C usefully.

I recently had an interview and a "skill test" in C. It was proctored by the interviewer in-person. I had so many questions about the questions. It was like, what is the output of "some code" and while obvious, there were some questions where specific CPU architecture mattered:

    #include <stdio.h>

    int main() {
        unsigned int x = 0x01020304;
        unsigned char *c = (unsigned char*)&x;

        printf("First byte of x: 0x%02x\n", *c);
        return 0;
    }

I was like, what architecture are we running on here? So, I answered that "it depends" and explained how it would depend on the architecture. They came back and said that I didn't know C.

Sure, whatever. Probably dodged a bullet.

What architectures would it not be 04 on?

Anything big endian.

  unsigned int x = 0x01020304;
  unsigned char *c = (unsigned char*)&x;

Assume x is stored at 0x100. On a little endian architecture (x86, most modern ARM systems, etc), it will be stored in memory as [04][03][02][01], from bytes 0x100 to 0x103. If you assign char c to the address of x (0x100), it will read one byte, which is 0x4.

However, on a big endian system, that same value would be stored in memory as [01][02][03][04] - so, reading a byte at 0x100 would return 0x1.

Older ARM systems were big endian, and there are others that run that way, though it's rarer than it used to be. One of the perks of little endian is that if you want to read a smaller version of a value, you can read from the same address. To read that value as an 8, 16, or 32 bit value, I read at the same address. On a big endian system, I'd have to do more address math to do the same thing. It mostly doesn't matter, but it is nice to be able to have a "read of 8 bits at the address of the variable" do the sane thing and return the low order 8 bits, not the high order bits.

Do you know if compilers are smart enough to return 04 even on big-endian architectures nowadays? For some reason I'm under the impression that (at least clang and gcc) are able to change this from "first byte in x" to "least significant byte in x" but don't actually know why I think that. Maybe embedded compilers typically don't?

No, and it would be wrong for it to do so, because you've given it a very explicit set of instructions about what to do: "Give me the value of the byte of memory at the start of x."

To do what you're asking, you'd do something like this:

  unsigned char c = (unsigned char)x;

That will give you the low order byte of x. But to do that, on a big endian system, when you've told it to get you the byte at the base address of x, is simply wrong behavior. At least in C. I can't speak to higher level languages since I don't work in them.

To expand slightly on Syonyk said: the compiler cannot do it, because the object is stored between addresses c and c + sizeof(unsigned int). You can use this information to, for example, copy the object to another place with memcpy, and that of course wouldn't work if c wasn't pointing to the "leftmost" byte in the memory.

Unless, I suppose, sizeof was negative :).

If you wanted to return 04 on big-endian architectures, you can use a binary mask - (int &0xFF).

Since this compiles to FF 00 00 00 in big-endian and 00 00 00 FF in little-endian, it would work on both platforms.

If you’re reading a file in binary format from disk, though, you always have to know whether the byte you are reading is little-endian or big-endian on disk.

(older) ARM (aka, big-endian) it will be 01

You'll have to be a lot more specific than "ARM" - Most newer ARM systems are little endian in practical operation, and ARM has been "flexible endian" (you can switch between big and little endian - SCTLR has the relevant bits to control the accesses on most recent ARM ISAs) for some long while now.

I just ran it on my M2 mac and got 04. Don't compilers typically take endianness into account for things like this anyway?

No, compilers don’t take endianness into account. (especially not C)

You need to use a bit mask in order to make this code endian-independent rather than a pointer alias. Like (uint8_t)(int & 0xFF), or something like that.

Why would it do that? You're asking for a raw memory address value.

IIRC several currently used architectures (e.g. ARM, Power, z/Architecture, RISC-V) can all run in big-endian mode.

And in the embedded space I think PowerPC and MIPS are still around.

You probably did dodge a bullet. The correct answer to every engineering question is "it depends". :)

There were so many other little ones, like bit-shifting signed integers, which is compiler dependent. I lol’d when they told me I didn’t know C well enough. Like bro, I learned on Borland C, then Microsoft (Visual) C, now mostly gcc/clang C. I don’t know C at all.

The interview is as much about them deciding about you as it is you deciding about them. In theory, you got the information you needed. (But yes in fact everybody got screwed because they put the wrong person in charge of interviewing. Still dodged a bullet.)

> things like fizzbuzz are still useful

I think you're right here but, to play devil's advocate... isn't there some survivorship bias going on here? I assume you've never tested the negative hypothesis and gone ahead and hired somebody who couldn't program fizzbuzz to validate your assumption.

> I assume you've never tested the negative hypothesis and gone ahead and hired somebody who couldn't program fizzbuzz to validate your assumption

A former employer of mine inadvertently did! He wasn't asked to complete FizzBuzz, but I am confident he couldn't answer it as I worked on the same team as him. He was a very charismatic individual who always "needed help" from team mates on all tasks, no matter how small. He managed to collect a salary for 6 months. Some time after he was let go, the police called my employer enquiring after him, and we learned he was a conman with outstanding arrest warrants with no prior SWE experience at all. The name we all knew him by was just one of many aliases.

You're right. When interviewing for a team that writes mostly in C and assembly (assembly for various different ISAs), we're not going to hire someone who claims to know C and fumbles through some basic problems and can't reason about hardware in the slightest.