The code snippet shows a bug, p is an uninitialized pointer. The behavior is undefined. Theoretically it could point to some valid memory, but saying that it points to dynamically allocated memory definitely implies a misunderstanding.
char *p = ...;
I would react to stories like this with skepticism, whether told by the interviewee or interviewer, especially when accompanied with a pretentious attitude ("Get out"), because the most fallible part is likely to be human communication.
In fact, it will generate a compiler warning (with -Wall).
The conversation (which OP said was condensed) clearly demonstrates that the interviewee does not understand that the pointer is uninitialized.
To suggest that the interviewee confused it with
char *p = ...;
*p = 'c';
Also it would still matter what ... is here.
For example if it was a constant initializer like "string", then the memory would be statically allocated and write-protected.
If on the other hand it was a call like malloc(1), then you would expect some error checking to see if malloc failed.
It's actually a pretty neat little snippet.
Regarding pointers, though, you have a point that char * is commonly used for statically allocated strings. I concede that it's fair to criticize the interviewee for saying the memory was dynamically allocated (by the compiler??), though I don't know if that rises to the level of "Get out."
Then you would just write it as a function like this:
void foo(char *p) {
*p = 'a';
}This is why people advocate for alternatives like Rust where the compiler can be precise on your behalf. But as long as C is still in use, its practitioners need to be exceptionally pedantic with their code.
Though it might be a good thing to say "well, p is uninitialized," it might also come across as obnoxious if that wasn't what the interviewer intended. So it comes down to guessing which response the interviewer is looking for.
The final answer that the memory was dynamically allocated by the compiler is as wrong as it can be.
If I saw this code then my first reaction was that this code probably will produce a segmentation fault in the best case scenario. Well, that was after I verified that this is not some pointer usage question, as I am not an experienced C developer.
It's C code. Your interpretation is not the one used by the compiler.
The point was to catch trivial bugs in code. In this case, the interview didn't.
Do you know how to read? Apparently not. I said explicitly that he conversations are a bit longer that that.
My comment was described as a short summary to illustrate a point. Instead of taking it at face value, you've read all kinds of nefarious emotions into it, and read magical interpretations into the technical portion, too.
This is called "projection".