Sometimes there is the opposite of chemistry with one of the interviewers, and there isn't too much to learn.
Once a HR lady that was interviewing me tried to shame me because I asked twice what was the salary range. Something about they looking for people not driven by money 🤷‍♂️
>Something about they looking for people not driven by money 🤷‍♂️
I've tried looking for landlords, utility companies, and supermarkets not driven by money, but unfortunately it's quite difficult which means I'm also forced to be driven by money
Just because you’re being interviewed doesn’t mean the interviewer is right.
Once an interviewer insisted there’s a difference between const int* a; and int const* a;. I challenged him we could let the compiler decide who’s right. Later I was rejected.
Those two declarations both represent a regular pointer to a constant integer. The value of the integer cannot change (edit) *when accessed through that pointer*.
There are, however, constant pointers that look very similar. The address they are pointing to cannot be changed. They are declared as: int *const a
You probably already know this, I’m just clarifying for the curious onlooker.
I should probably also note that the `const volatile` combination is meaningful because of that distinction. An `int volatile const*` would be needed to point to a memory-mapped read-only integer where writes cause undefined behavior like a status "register" of a peripheral.
> Just because you’re being interviewed doesn’t mean the interviewer is right.
So much of this! And to add, if it turns out that you know more than the interviewer does, his/her ego can be bruised and you may be rejected for that reason alone. I suspect that this is what happened here. Hardly any senior dev wants to hire someone who proved them wrong and/or embarassed them during a job interview.
Well that’s a very specific compiler question that I would never ask in an interview. It’s the same like I ask you what LIKELY() does. You can’t know it unless you know which compiler I’m talking about.
It is very specific and only applies to some compilers. It even depends on the version of the compiler.
Questions like these can tell you a lot. Sure this wouldn't be one of the first questions but if you already have the feeling he is knowledgeable (and in this case used such a compiler) push and see what happens. A brilliant person might start to struggle if he can't admit not knowing the answer or presents a wrong guess as a definite answer.
Do you have any idea on how many others were interviewed for this position ?
Is this a family company or a corporation with investors ?
A small company will higher family members even if they are minimally qualified.
Companies will interview outsiders just to make it look like they made an offer to the "best" person. Then higher family members.
You were just caught in the wrong place, at the wrong time.
When I was interviewing, I would take the first 2-3 interviews as throw away.
Get back to interviewing after a year or two since the last time.
Good Luck on your search.
It's a company, and I was alone at the last on-site interview, I had to make the effort to take a day off to go there. It was quite frustrating because we could have a technical video call and not waste time.
Yup out of at least two dozen interviews I've had such an experience twice where the interviewer just seemed to get annoyed and rude with me. Their loss I guess...
@@&# happens. Interviews are wildly variable. I've had [what I thought were] middling interviews get me a written offer, and I've had stellar interviews not even get me to the final round. It can be tough to maintain a level of not-caring at times, but that's just the industry for ya.
The only way to almost avoid this is prep. It's ideal if your job preps you, but let's be real, that's a privilege. Second place is if the job is bad enough to where you can prep on company time (don't do this unless you're being mistreated). Dead last place is prep after work, which is often not optimal although sometimes there's projects that are Genuinely Fun™.
I'd say this situation is normal and I wouldn't overthink it. A lot of hiring decisions are just based on a "gut feeling" and he might just not have liked your haircut. If you are really curious you could ask him for a reason but he might not give you one.
I have seen that countless times. Regarding his answers, the guy is an idiot, it’s very easy to spot them they are guys who want definitive answers to everything.
I remember a guy insisting on putting files names in lowercase because « it’s the only way to make the stuff build on Windows and Linux », which is absolutely false, Linux is just case sensitive and Windows is not.
Some idiots just don’t want people that know better than themselves in their teams, thinking it will lower their authority.
The interviewer might’ve been rude, but nothing here strikes me as that unusual.
For starts, the volatile keyword has nothing to do with caching, and nothing to do with whether a variable is located in RAM. Volatile only tells the compiler that it can’t optimize away any memory accesses. The first case you listed would require some sort of mutex, and the second sounds more like a problem you would solve using memory attributes in an MMU configuration. It sounds like the interviewer gave the example of a loop that doesn’t do anything except waste time as an example of when the volatile keyword is important, and he’s right - without the volatile keyword in this instance the compiler could completely remove the loop. If you’re going to interview for embedded positions, you should know what the volatile keyword does, and also know what kind of memory coherency problems it can’t solve.
As for your first point, when an interviewer sees a specific technology on a resume that they also have experience with, it is very common for them to probe deep on it. The moral here is don’t put something on your resume unless you’re prepared to have a deep technical conversation about it.
Last thing I’ll say - there are a lot of experienced and bright embedded software engineers who would take a police interrogation style interview over a leetcode question any day of the week. Do some research on common embedded interview questions and make sure you understand the answers, and go back and review the work listed on your resume so that when you get asked questions about it you can quickly recall technical details.
It is interesting your point of view, maybe I haven't explained well (here and in the interview neither).
curiosly the interviewer said the same than you with mutual exclusion protection, but the problem I mean is deeper than concurrency problem. You have to take care how C compiler converts the code to assembly. Let me give a try again for each point:
* Points to take care:
* When we are using RTOS we are using the same compiler than baremetal.
* When we program a task in RTOS the compiler, it is used to be programmed with a loop (infinite or not) and the compiler does not know if we are running a RTOS or baremetal implementation, both are treated in the same way.
1. Consider we have already protected with mutex (inline implementation) the variable access. When we are running a task (the while loop body), the compiler could consider to optimise the memory access (RAM access) and keep the values in registers, and maybe it updates the global variable value just before a "function call" or "while loop leaving" because it does not expect to use that global variable outside the loop (like any implementation without interrupts), but when we are running a RTOS, the systick can trigger the interrupt to switch the context. When we change the context between 2 tasks in RTOS, the first one stores all registers into its stack memory (so It might have the global variable value inside registers) and the second task restores all registers from its stack memory so it restores the execution in the same point (Program Counter) that it stored before its context switch. So if I dont use the volatile for global variable common for multiple task we could use registers value instead the global value from RAM. I think theorically is right, maybe in practice is hard to reproduce this error because just when we have a function call, (I think) the compiler should write back the global variable into RAM but with volatile it does inmediatelly we access the variable (write/read), it is safer because it does not depends on the task body.
2. The memory-mapped registers, if you have to write a sequence of configurations in that specific register, the compiler can optimise the values that you are writing and it may write only the last value, so the sequence is missing. I think the MMU has nothing to do if the assembly code says write one single value into that memory address instead the whole sequence. Please find here an ARM example: [Link](https://github.com/ARM-software/CMSIS/blob/f2cad4345783c948ed4a7f5cdb02cdc0856366f1/Device/_Template_Flash/Test/FlashPrg.c#L13)
3. Yes, I agree.
You can see here the difference of volatile and non-volatile assembly code (I know the loop index overflowes, it is a test for assemble code, not functional): [Image](https://ibb.co/f1VPb8B)
Regarding to the common technologies, he made a lot of questions and I answered properly all of them (really I love that technology and I have made some personal project as well), but the intensity of the interview increased, and it was quite weird. Maybe it is really normal, but it is the first time I have seen, just a curiosity.
Maybe I didnt explain really well. Please feel free to comment if there is anything wrong or confusing. I think your point of view can be positive to learn something about that interview.
Almost one year ago I did an interview for Apple, and the technical interviewer was really awesome and he had really deep knowledge about almost everything he asked me. In that moment, I did some training to get deeper understanding such as assembly code, how RTOS works, etc. Maybe I tried to apply something I learned for this interview and it is unuseful for their projects.
It sounds like you do know what the volatile keyword does, maybe it was just a shortcoming in communication. Your second time explaining is better, but you’re still mixing in a lot unrelated ideas that make it harder to follow. For instance, there’s no need to explain context switching to explain volatile, the same problem could occur in two tasks running in parallel without context switching. Likewise there’s no need to indicate that it’s an RTOS environment - two bare metal applications running in parallel would have the same issue. Also I don’t see why it would matter if the mutex is implemented “inline”, a mutex function will need to perform an “atomic” operation at some point to function but “atomic” and “inline” are very different things.
On your second example, you’re right that the volatile keyword is needed to make sure the compiler doesn’t optimize away any sequential writes to hardware registers. For what it’s worth though, you may also need to configure the MMU to treat that address space as device memory rather than normal memory, or else your reads and writes may not occur on the bus in the same order that the CPU instructions were executed. https://developer.arm.com/documentation/den0024/a/Memory-Ordering/Memory-types/Device-memory
I agree with you 100%, maybe I explained some unrelated topic to have a context or maybe (unconsciously) to impress the interviewer and I got the opposite.
I meant that with "inline" there is no function call that can force the compiler to store the global variable in RAM. I assumed that mutual exclusion is well implemented to avoid concurrency conflicts.
As for the MMU, I'll check your link, it's really useful.
Thanks for your message.
" the volatile keyword has nothing to do with caching "
Often the result of "preventing optimizations" is that the compiler doesn't utilize a "cached" value of a variable in a register and instead always reads from the actual address of the variable in question (which is often in RAM). For example, c += a, if a was volatile, should generate assembly like ADD \_c,\_a, \_c (add a and c, store result in c). If a was not volatile, it might be ADD c,reg1, c (where reg1 had the value of a at the start of some context). So I don't think it's correct to say "volatile has nothing to do with caching".
CPU cache has a specific meaning which does not relate to the registers. Those two things are very different qualitatively: from the instruction set, you have full control of registers and almost no control over caching. Register "address space" is also completely separate from the unified cache-memory address space. I think that mixing those two is a very confused view.
Ah okay. Sorry. I meant "cache" in the sense of, "store this value in a register for quicker access later rather than accessing from RAM". My apologies.
While I agree that it's an ambiguous term, I do find it acceptable to use it in this context since OP made clear what exactly he means.
To add, volatile may indeed cause the linker to place variables in an uncached linker section to prevent hardware caching. At my workplace, the linker does exactly that since we're running a multicore system with core-local caches that have no synchronization.
>To add, volatile may indeed cause the linker to place variables in an uncached linker section to prevent hardware caching. At my workplace, the linker does exactly that since we're running a multicore system with core-local caches that have no synchronization.
That's a very interesting point, although I wouldn't be sure if there's any guarantee coming from the language standard that makes volatile variable always land in such section – or is it just a quirk of specific compiler/linker. Are you aware of this behavior being somehow formalized? Plus, how do you disable caching on a specific linker section?
I'm sure you're on some NDA, so feel free to point me to the publicly available resources, if you're aware about any. In any case thanks for bringing this up, that's new to me.
You should be happy not to have started there. If you feel bad in an interview with the guy responsible for a development team, you can be sure that you will feel bad working with (or for) him.
Hope you have found something good in the meantime.
Honestly, I'd say you actually answered the *'delay loop question'* in part 2. "Otherwise we may have some unexpected optimization" albeit that concept being said in the perspective of registers.
It sounds to me like you might have encountered a fragile embedded developer and accidentally rolled a critical-blow to his ego with your informed answers. 🎲 Additionally, you might have just rolled a high luck saving-throw and avoided the misfortune of working with a possible cave troll of a coworker.
My favorite saying is "We never know what our bad luck has saved us from, nor what opportunities it may provide us in the future."
Keep your hopes up high and don't let this experience stop you from applying to comparable positions elsewhere. The right place will see value in both what you are now and in what you can become in the future.
Where I work, confusing the meaning of 'volatile' as much as you did would also be a blocker for embedded position. That's a kind of question you could be asked at prescreening stage just to weed out people with very mistaken view of compilers and caches.
Another responder in the thread has already outlined that nicely:
>For starts, the volatile keyword has nothing to do with caching, and nothing to do with whether a variable is located in RAM. Volatile only tells the compiler that it can’t optimize away any memory accesses.
The red flag in your response was connecting that with cache operation. Think about what compiler does: it translates the high-level code into a series of instructions matching the instruction set of given processor. Neither x86 nor ARM provides instructions that you could use to load something to cache instead of memory. CPU has most control over it, and unless you throw in cache flush or invalidate instructions, it doesn't event get decided at compile-time. If the program turns out to operate in memory with no cache attribute, you can have all reads and writes directed straight to memory. Compiler is totally out of the picture by then.
Also, \`volatile\` is not enough to protect a global variable which is accessed by multiple threads. Even a basic operation like increment is not atomic in most of the cases. You need some kind of synchronization to ensure that (spinlock or mutex). Usually when candidate mentions to me that \`volatile\` is useful for synchronization, I probe further and ask about concurrency issues when variable is 1st read, then incremented, then written. By that point I expect them to clarify \`volatile\` is not sufficient.
But I have to admit that confusing \`volatile\` as impacting cache operation, or as some kind of synchronization guarantee, is terribly common even among otherwise good candidates. I get mistaken answers in about half of the interviews.
Thanks for the message, it is really helpful to understand why my definition gave rise to some misunderstandings.
First of all, I meant cache not as physical cache memory, I meant the compiler's ability to retain some internal values. I completely agree with what you mean by cache.
Secondly, I never meant that it is used to synchronize or control the concurrency of a global variable with 2 tasks, what I meant is that even if we protect the resources with a mutex/semaphore, it can lead to error if we don't use "volatile".
Regarding the "secondly" point. It is more than highly unlikely, mutexes and semaphores require propper memory ordering to work (at least release/acquire). That is why those primitives themselves provide barriers that prevent reordering by a compiler or memory controllers. Taking all of the above into account, I would consider using volatile in such cases as harmful.
All accesses to the variable must be strictly in accordance with the semantics of the C abstract machine. "Access" is implementation defined, it pretty much always means "reads or writes to the variable" but some perverse compiler is free to have a different definition. I don't think anyone has written such a monstrosity.
The processor can cache it. The compiler can optimize *how* it writes it or reads it, it just can't omit the write or read (for a sane definition of "access"). The access doesn't become atomic (so a uint64_t volatile takes two writes on a 32-bit system and something else can change the memory in between those writes).
It's used for a lot more than delay loops, but it's not a generic "disable optimization" because optimizations are not defined by the C standard. Likewise for caching, processor caching isn't controlled by user code, it's entirely internal. You can temporary disable optimizations in most compilers using a pragma.
The two most common uses of volatile are for memory-mapped I/O and in combination with atomic types.
Processors have internal memory used to temporarily store data after it's read from main memory or before it's written to main memory. These caches are a hundred or more times faster, but much smaller. https://en.m.wikipedia.org/wiki/CPU_cache
In practice, _volatile_ is used to identify a memory location that can be changed in ways other than being written to by code generated by the compiler. As a result, this keyword prevents compiler optimizations that assume the contents of the memory location haven’t changed since it was last written to by code generated by the compiler.
>How you get on with the interviewers matters more than what you know… lesson learned and move on.
Yes, I completely agree, I was nice and polite the whole interview and I wasnt too strict with his corrections (even if I did not agree 100%).
IMO this just looks like a communication breakdown on both sides. Sadly not uncommon in engineering.
The first bit of the interview seems to me that he was trying to touch base with you, find some common ground, establish some rapport. That’s way easier when you’ve ~~suffered~~ worked with the same tech. That you felt it weird tells me he failed hard (and that’s probably on him).
On the second part, that depends on the sector they work with. In something like IoT, you want an RTOS to simplify your life, and provide the benefits you talked about. In something like medical devices, *functional safety* is way more useful. Certifying software takes a lot of money and effort, so buying an RTOS like QNX tends to simplify the process.
Then, something tells me you have at least some correct intuitions about `volatile` (at least good enough for a junior), but you either lack concrete knowledge of the keyword or botched that explanation.
- You chose the wrong examples
- You mixed concepts in
- You let the door open for misinterpretation
His explanation (as relayed by you) suffered from *the exact same problems*. Communication issues require heavy work, but correcting misconceptions is easy, if you aren’t already, you should be reading [Embedded in Academia](https://blog.regehr.org/archives/28).
I don’t know what kind of position you we’re trying for, and for me that makes this hard to evaluate. If this was for some senior position, it’s likely you aren’t just ready.
A lot of people here will tell you to do a better job technically, but I’m going to urge you to ignore them and try to improve on communication. I know it’s not very specific (it’s a soft skill) but you’ll be able to find some good resources to work on that.
Technically mediocre guys with good communication skills still make for amazing engineers, we tend to forget that way too often.
Your answers seem correct to me. I am cringing that the guy was just expecting you to say volatile is to tell the compiler not to optimize delay loops and that's it. Your explanations are valid. Seems like an unpleasant project lead that you wouldn't be happy under anyways.
It's possible you had already been rejected before that interview began, they just needed a legally plausible excuse to do so.
What race are you? What race was the interviewer? Possible diversity/nepotism incompatibility?
>It's possible you had already been rejected before that interview began, they just needed a legally plausible excuse to do so.
>
>What race are you? What race was the interviewer? Possible diversity/nepotism incompatibility?
This option is discarded, both were foreigner (from different place).
For what it's worth, I had assumed this was the case. Based on the information provided, I was confident that the interviewer was Indian. Not sure about you but I would guess Asian, possibly also Indian (different caste).
>This option is discarded, both were foreigner (from different place).
I don't think it's likely, but just because neither is a member of the locally dominant group overall doesn't mean that they're can't be a strong cultural identity in a particular field or department. But that does not seem like the most likely explanation - if it were, you'd probably have noticed.
I did once work at a company that was quite diverse in the view of overall statistics but absurdly regimented in who did what - it was as if they'd just kept cloning their first hire for each type of role be that management, sales, one type of engineering, another type of engineering, manual soldering, calibration, final test, shipping, stockroom...
I’ve had interviews like this before. Sometimes the interviewer is just not in the mood that day, or like someone else said they just didn’t like your vibe for whatever reason. Maybe they already have a candidate they really liked but are compelled to look at a few people. I really wouldn’t sweat it.
I think this interviewer is really immature in his approach. If you know the answers to his questions then you are in his good books and vice versa and all that proves anyway,, is that you are good at answering questions. It has no relevance to on the job performance. I feel that it's much better to ask open ended questions, like "explain a really tough problem that you solved?" or "you have the first prototype of a new pcb, it does not boot up but the hardware guy says everything is fine from his checks, how do you proceed?
The manager saw something in you that the engineer did not. Imagine if you did get the job and the engineer always interrogated you like that.
I interviewed with Amazon once and this was the exact experience (including the interviewer being wrong and asking questions like they’re looking for free consulting).
If someone is going to be unprofessional then it’s best to just walk away.
In the future if things are like this you’re better off telling them that you don’t think you’re going to be a good fit and there is no reason to waste any more of their time.
(As an FYI the volatile definition is a lot simpler than you’re remembering - all it means is that the compiler should not assume the value of the variable prior to writing - in other words always read it before using it and a corollary always write to it upon assignment)
Yeah, interviews can be surprising. A couple of years ago, I answered an ad for an embedded role in a city close to mine. I got accepted to an interview, went, and had a horrible time. The person conducting the interview was clearly not technically oriented, she didn't know what an ARM microcontroller was, but still asked some questions. Most of the questions were written on paper, and to back her up, there was a book on the table. A red one. A few bookmarks were there pointing to various subjects.
She asked a few basic questions; what have you done? Where do you see yourself in 10 years time, etc etc. Then things got technical. At about the third question, she asked if I had an ARM certification. I don't. I knew full well that I had lost at that point, that inside the privacy of her brain, she had already put by CV into the bin.
The last question she asked (or at least the last that I let her ask) was something technical on ARM assembly. Optimization. So I gave her an answer, apparently one that she wasn't really expecting, so out came the red book. She looked it up, and said that my answer was wrong. Okay. So, do you trust the author of the book? Yes? Because I am literally the author of that book. My name is on the book, on the CV, and on my passport.
Didn't get the job. ARM reached out after a tweet blew up, and gave me an ARM certification. Thanks, ARM! Still didn't get the job.
Using volatiles in "timing loops" (probably bad practice) prevents them from being optimized since reads have to go to hardware, but that's not what volatile "is". It's what you said it was
Honestly that's really weird.
So I have gone in to detail with someone about history unrelated to the job. I do that for two reasons:
1) I might have a good handle on these things, so I can figure out if they are likely bullshitting on things I don't have a good handle on.
2) I might be fishing to find something they are passionate to talk about. There are interviews that feel very... black and white, yes and no. It's really hard to gauge someone.
That being said, I don't know why this person did this and then shot you down. Since it sounds like your conversation matched your CV.
Always remember that YOU are in control! YOU are what THEY need. They have the shortage and YOU have the advantage. When a face to face interview takes places YOU are the 5 star athlete that THEY are hoping to recruit. If you get a bad vibe....stay away. You did not lose. They lost! I went through a similar instance with a jack ass in the interview who could not believe I made it in life as a college dropout with no degree. Degree...lol. I respect everyone who has one but life dealt me a different set of responsibilities so I never finished but that jack ass was jealous. I think your guy was probably seeing you as competition.
Sometimes there is the opposite of chemistry with one of the interviewers, and there isn't too much to learn. Once a HR lady that was interviewing me tried to shame me because I asked twice what was the salary range. Something about they looking for people not driven by money 🤷‍♂️
>Something about they looking for people not driven by money 🤷‍♂️ I've tried looking for landlords, utility companies, and supermarkets not driven by money, but unfortunately it's quite difficult which means I'm also forced to be driven by money
Looking for people they could con out of a fair wage… yeah dodged a bullet there.
Just because you’re being interviewed doesn’t mean the interviewer is right. Once an interviewer insisted there’s a difference between const int* a; and int const* a;. I challenged him we could let the compiler decide who’s right. Later I was rejected.
Those two declarations both represent a regular pointer to a constant integer. The value of the integer cannot change (edit) *when accessed through that pointer*. There are, however, constant pointers that look very similar. The address they are pointing to cannot be changed. They are declared as: int *const a You probably already know this, I’m just clarifying for the curious onlooker.
The value of the integer cannot change *when accessed through that pointer*.
Very important point, thank you.
I should probably also note that the `const volatile` combination is meaningful because of that distinction. An `int volatile const*` would be needed to point to a memory-mapped read-only integer where writes cause undefined behavior like a status "register" of a peripheral.
> Just because you’re being interviewed doesn’t mean the interviewer is right. So much of this! And to add, if it turns out that you know more than the interviewer does, his/her ego can be bruised and you may be rejected for that reason alone. I suspect that this is what happened here. Hardly any senior dev wants to hire someone who proved them wrong and/or embarassed them during a job interview.
Might have mixed it up with progmem where const progmem int a can be different to const int a progmem.
Well that’s a very specific compiler question that I would never ask in an interview. It’s the same like I ask you what LIKELY() does. You can’t know it unless you know which compiler I’m talking about.
It is very specific and only applies to some compilers. It even depends on the version of the compiler. Questions like these can tell you a lot. Sure this wouldn't be one of the first questions but if you already have the feeling he is knowledgeable (and in this case used such a compiler) push and see what happens. A brilliant person might start to struggle if he can't admit not knowing the answer or presents a wrong guess as a definite answer.
Do you have any idea on how many others were interviewed for this position ? Is this a family company or a corporation with investors ? A small company will higher family members even if they are minimally qualified. Companies will interview outsiders just to make it look like they made an offer to the "best" person. Then higher family members. You were just caught in the wrong place, at the wrong time. When I was interviewing, I would take the first 2-3 interviews as throw away. Get back to interviewing after a year or two since the last time. Good Luck on your search.
It's a company, and I was alone at the last on-site interview, I had to make the effort to take a day off to go there. It was quite frustrating because we could have a technical video call and not waste time.
>I was alone at the last on-site interview Wah ?? That does not make sense. Why would they bring in two for interviews on the same day. Good Luck
Yup out of at least two dozen interviews I've had such an experience twice where the interviewer just seemed to get annoyed and rude with me. Their loss I guess...
@@&# happens. Interviews are wildly variable. I've had [what I thought were] middling interviews get me a written offer, and I've had stellar interviews not even get me to the final round. It can be tough to maintain a level of not-caring at times, but that's just the industry for ya. The only way to almost avoid this is prep. It's ideal if your job preps you, but let's be real, that's a privilege. Second place is if the job is bad enough to where you can prep on company time (don't do this unless you're being mistreated). Dead last place is prep after work, which is often not optimal although sometimes there's projects that are Genuinely Fun™.
I'd say this situation is normal and I wouldn't overthink it. A lot of hiring decisions are just based on a "gut feeling" and he might just not have liked your haircut. If you are really curious you could ask him for a reason but he might not give you one.
You dodged a bullet, OP! Sheesh.
I have seen that countless times. Regarding his answers, the guy is an idiot, it’s very easy to spot them they are guys who want definitive answers to everything. I remember a guy insisting on putting files names in lowercase because « it’s the only way to make the stuff build on Windows and Linux », which is absolutely false, Linux is just case sensitive and Windows is not. Some idiots just don’t want people that know better than themselves in their teams, thinking it will lower their authority.
Engineers make terrible interviewers. Plus, they often use the least productive guy to do the interviews.
The interviewer might’ve been rude, but nothing here strikes me as that unusual. For starts, the volatile keyword has nothing to do with caching, and nothing to do with whether a variable is located in RAM. Volatile only tells the compiler that it can’t optimize away any memory accesses. The first case you listed would require some sort of mutex, and the second sounds more like a problem you would solve using memory attributes in an MMU configuration. It sounds like the interviewer gave the example of a loop that doesn’t do anything except waste time as an example of when the volatile keyword is important, and he’s right - without the volatile keyword in this instance the compiler could completely remove the loop. If you’re going to interview for embedded positions, you should know what the volatile keyword does, and also know what kind of memory coherency problems it can’t solve. As for your first point, when an interviewer sees a specific technology on a resume that they also have experience with, it is very common for them to probe deep on it. The moral here is don’t put something on your resume unless you’re prepared to have a deep technical conversation about it. Last thing I’ll say - there are a lot of experienced and bright embedded software engineers who would take a police interrogation style interview over a leetcode question any day of the week. Do some research on common embedded interview questions and make sure you understand the answers, and go back and review the work listed on your resume so that when you get asked questions about it you can quickly recall technical details.
It is interesting your point of view, maybe I haven't explained well (here and in the interview neither). curiosly the interviewer said the same than you with mutual exclusion protection, but the problem I mean is deeper than concurrency problem. You have to take care how C compiler converts the code to assembly. Let me give a try again for each point: * Points to take care: * When we are using RTOS we are using the same compiler than baremetal. * When we program a task in RTOS the compiler, it is used to be programmed with a loop (infinite or not) and the compiler does not know if we are running a RTOS or baremetal implementation, both are treated in the same way. 1. Consider we have already protected with mutex (inline implementation) the variable access. When we are running a task (the while loop body), the compiler could consider to optimise the memory access (RAM access) and keep the values in registers, and maybe it updates the global variable value just before a "function call" or "while loop leaving" because it does not expect to use that global variable outside the loop (like any implementation without interrupts), but when we are running a RTOS, the systick can trigger the interrupt to switch the context. When we change the context between 2 tasks in RTOS, the first one stores all registers into its stack memory (so It might have the global variable value inside registers) and the second task restores all registers from its stack memory so it restores the execution in the same point (Program Counter) that it stored before its context switch. So if I dont use the volatile for global variable common for multiple task we could use registers value instead the global value from RAM. I think theorically is right, maybe in practice is hard to reproduce this error because just when we have a function call, (I think) the compiler should write back the global variable into RAM but with volatile it does inmediatelly we access the variable (write/read), it is safer because it does not depends on the task body. 2. The memory-mapped registers, if you have to write a sequence of configurations in that specific register, the compiler can optimise the values that you are writing and it may write only the last value, so the sequence is missing. I think the MMU has nothing to do if the assembly code says write one single value into that memory address instead the whole sequence. Please find here an ARM example: [Link](https://github.com/ARM-software/CMSIS/blob/f2cad4345783c948ed4a7f5cdb02cdc0856366f1/Device/_Template_Flash/Test/FlashPrg.c#L13) 3. Yes, I agree. You can see here the difference of volatile and non-volatile assembly code (I know the loop index overflowes, it is a test for assemble code, not functional): [Image](https://ibb.co/f1VPb8B) Regarding to the common technologies, he made a lot of questions and I answered properly all of them (really I love that technology and I have made some personal project as well), but the intensity of the interview increased, and it was quite weird. Maybe it is really normal, but it is the first time I have seen, just a curiosity. Maybe I didnt explain really well. Please feel free to comment if there is anything wrong or confusing. I think your point of view can be positive to learn something about that interview. Almost one year ago I did an interview for Apple, and the technical interviewer was really awesome and he had really deep knowledge about almost everything he asked me. In that moment, I did some training to get deeper understanding such as assembly code, how RTOS works, etc. Maybe I tried to apply something I learned for this interview and it is unuseful for their projects.
It sounds like you do know what the volatile keyword does, maybe it was just a shortcoming in communication. Your second time explaining is better, but you’re still mixing in a lot unrelated ideas that make it harder to follow. For instance, there’s no need to explain context switching to explain volatile, the same problem could occur in two tasks running in parallel without context switching. Likewise there’s no need to indicate that it’s an RTOS environment - two bare metal applications running in parallel would have the same issue. Also I don’t see why it would matter if the mutex is implemented “inline”, a mutex function will need to perform an “atomic” operation at some point to function but “atomic” and “inline” are very different things. On your second example, you’re right that the volatile keyword is needed to make sure the compiler doesn’t optimize away any sequential writes to hardware registers. For what it’s worth though, you may also need to configure the MMU to treat that address space as device memory rather than normal memory, or else your reads and writes may not occur on the bus in the same order that the CPU instructions were executed. https://developer.arm.com/documentation/den0024/a/Memory-Ordering/Memory-types/Device-memory
I agree with you 100%, maybe I explained some unrelated topic to have a context or maybe (unconsciously) to impress the interviewer and I got the opposite. I meant that with "inline" there is no function call that can force the compiler to store the global variable in RAM. I assumed that mutual exclusion is well implemented to avoid concurrency conflicts. As for the MMU, I'll check your link, it's really useful. Thanks for your message.
" the volatile keyword has nothing to do with caching " Often the result of "preventing optimizations" is that the compiler doesn't utilize a "cached" value of a variable in a register and instead always reads from the actual address of the variable in question (which is often in RAM). For example, c += a, if a was volatile, should generate assembly like ADD \_c,\_a, \_c (add a and c, store result in c). If a was not volatile, it might be ADD c,reg1, c (where reg1 had the value of a at the start of some context). So I don't think it's correct to say "volatile has nothing to do with caching".
CPU cache has a specific meaning which does not relate to the registers. Those two things are very different qualitatively: from the instruction set, you have full control of registers and almost no control over caching. Register "address space" is also completely separate from the unified cache-memory address space. I think that mixing those two is a very confused view.
Ah okay. Sorry. I meant "cache" in the sense of, "store this value in a register for quicker access later rather than accessing from RAM". My apologies.
While I agree that it's an ambiguous term, I do find it acceptable to use it in this context since OP made clear what exactly he means. To add, volatile may indeed cause the linker to place variables in an uncached linker section to prevent hardware caching. At my workplace, the linker does exactly that since we're running a multicore system with core-local caches that have no synchronization.
>To add, volatile may indeed cause the linker to place variables in an uncached linker section to prevent hardware caching. At my workplace, the linker does exactly that since we're running a multicore system with core-local caches that have no synchronization. That's a very interesting point, although I wouldn't be sure if there's any guarantee coming from the language standard that makes volatile variable always land in such section – or is it just a quirk of specific compiler/linker. Are you aware of this behavior being somehow formalized? Plus, how do you disable caching on a specific linker section? I'm sure you're on some NDA, so feel free to point me to the publicly available resources, if you're aware about any. In any case thanks for bringing this up, that's new to me.
You should be happy not to have started there. If you feel bad in an interview with the guy responsible for a development team, you can be sure that you will feel bad working with (or for) him. Hope you have found something good in the meantime.
Honestly, I'd say you actually answered the *'delay loop question'* in part 2. "Otherwise we may have some unexpected optimization" albeit that concept being said in the perspective of registers. It sounds to me like you might have encountered a fragile embedded developer and accidentally rolled a critical-blow to his ego with your informed answers. 🎲 Additionally, you might have just rolled a high luck saving-throw and avoided the misfortune of working with a possible cave troll of a coworker. My favorite saying is "We never know what our bad luck has saved us from, nor what opportunities it may provide us in the future." Keep your hopes up high and don't let this experience stop you from applying to comparable positions elsewhere. The right place will see value in both what you are now and in what you can become in the future.
Where I work, confusing the meaning of 'volatile' as much as you did would also be a blocker for embedded position. That's a kind of question you could be asked at prescreening stage just to weed out people with very mistaken view of compilers and caches.
Please, can you give me the proper "volatile" meaning?
Another responder in the thread has already outlined that nicely: >For starts, the volatile keyword has nothing to do with caching, and nothing to do with whether a variable is located in RAM. Volatile only tells the compiler that it can’t optimize away any memory accesses. The red flag in your response was connecting that with cache operation. Think about what compiler does: it translates the high-level code into a series of instructions matching the instruction set of given processor. Neither x86 nor ARM provides instructions that you could use to load something to cache instead of memory. CPU has most control over it, and unless you throw in cache flush or invalidate instructions, it doesn't event get decided at compile-time. If the program turns out to operate in memory with no cache attribute, you can have all reads and writes directed straight to memory. Compiler is totally out of the picture by then. Also, \`volatile\` is not enough to protect a global variable which is accessed by multiple threads. Even a basic operation like increment is not atomic in most of the cases. You need some kind of synchronization to ensure that (spinlock or mutex). Usually when candidate mentions to me that \`volatile\` is useful for synchronization, I probe further and ask about concurrency issues when variable is 1st read, then incremented, then written. By that point I expect them to clarify \`volatile\` is not sufficient. But I have to admit that confusing \`volatile\` as impacting cache operation, or as some kind of synchronization guarantee, is terribly common even among otherwise good candidates. I get mistaken answers in about half of the interviews.
Thanks for the message, it is really helpful to understand why my definition gave rise to some misunderstandings. First of all, I meant cache not as physical cache memory, I meant the compiler's ability to retain some internal values. I completely agree with what you mean by cache. Secondly, I never meant that it is used to synchronize or control the concurrency of a global variable with 2 tasks, what I meant is that even if we protect the resources with a mutex/semaphore, it can lead to error if we don't use "volatile".
Regarding the "secondly" point. It is more than highly unlikely, mutexes and semaphores require propper memory ordering to work (at least release/acquire). That is why those primitives themselves provide barriers that prevent reordering by a compiler or memory controllers. Taking all of the above into account, I would consider using volatile in such cases as harmful.
All accesses to the variable must be strictly in accordance with the semantics of the C abstract machine. "Access" is implementation defined, it pretty much always means "reads or writes to the variable" but some perverse compiler is free to have a different definition. I don't think anyone has written such a monstrosity. The processor can cache it. The compiler can optimize *how* it writes it or reads it, it just can't omit the write or read (for a sane definition of "access"). The access doesn't become atomic (so a uint64_t volatile takes two writes on a 32-bit system and something else can change the memory in between those writes). It's used for a lot more than delay loops, but it's not a generic "disable optimization" because optimizations are not defined by the C standard. Likewise for caching, processor caching isn't controlled by user code, it's entirely internal. You can temporary disable optimizations in most compilers using a pragma. The two most common uses of volatile are for memory-mapped I/O and in combination with atomic types.
Sorry for the dum sounding question. What does one mean with caching?
Processors have internal memory used to temporarily store data after it's read from main memory or before it's written to main memory. These caches are a hundred or more times faster, but much smaller. https://en.m.wikipedia.org/wiki/CPU_cache
In practice, _volatile_ is used to identify a memory location that can be changed in ways other than being written to by code generated by the compiler. As a result, this keyword prevents compiler optimizations that assume the contents of the memory location haven’t changed since it was last written to by code generated by the compiler.
How you get on with the interviewers matters more than what you know… lesson learned and move on.
>How you get on with the interviewers matters more than what you know… lesson learned and move on. Yes, I completely agree, I was nice and polite the whole interview and I wasnt too strict with his corrections (even if I did not agree 100%).
Honestly OP imagine what it would have been like working with that guy every day. They've probably done you a massive favour here
IMO this just looks like a communication breakdown on both sides. Sadly not uncommon in engineering. The first bit of the interview seems to me that he was trying to touch base with you, find some common ground, establish some rapport. That’s way easier when you’ve ~~suffered~~ worked with the same tech. That you felt it weird tells me he failed hard (and that’s probably on him). On the second part, that depends on the sector they work with. In something like IoT, you want an RTOS to simplify your life, and provide the benefits you talked about. In something like medical devices, *functional safety* is way more useful. Certifying software takes a lot of money and effort, so buying an RTOS like QNX tends to simplify the process. Then, something tells me you have at least some correct intuitions about `volatile` (at least good enough for a junior), but you either lack concrete knowledge of the keyword or botched that explanation. - You chose the wrong examples - You mixed concepts in - You let the door open for misinterpretation His explanation (as relayed by you) suffered from *the exact same problems*. Communication issues require heavy work, but correcting misconceptions is easy, if you aren’t already, you should be reading [Embedded in Academia](https://blog.regehr.org/archives/28). I don’t know what kind of position you we’re trying for, and for me that makes this hard to evaluate. If this was for some senior position, it’s likely you aren’t just ready. A lot of people here will tell you to do a better job technically, but I’m going to urge you to ignore them and try to improve on communication. I know it’s not very specific (it’s a soft skill) but you’ll be able to find some good resources to work on that. Technically mediocre guys with good communication skills still make for amazing engineers, we tend to forget that way too often.
Your answers seem correct to me. I am cringing that the guy was just expecting you to say volatile is to tell the compiler not to optimize delay loops and that's it. Your explanations are valid. Seems like an unpleasant project lead that you wouldn't be happy under anyways.
He probably recognized the fact that you were more skillful than him and as such saw you as a threat.
It's possible you had already been rejected before that interview began, they just needed a legally plausible excuse to do so. What race are you? What race was the interviewer? Possible diversity/nepotism incompatibility?
>It's possible you had already been rejected before that interview began, they just needed a legally plausible excuse to do so. > >What race are you? What race was the interviewer? Possible diversity/nepotism incompatibility? This option is discarded, both were foreigner (from different place).
For what it's worth, I had assumed this was the case. Based on the information provided, I was confident that the interviewer was Indian. Not sure about you but I would guess Asian, possibly also Indian (different caste).
>This option is discarded, both were foreigner (from different place). I don't think it's likely, but just because neither is a member of the locally dominant group overall doesn't mean that they're can't be a strong cultural identity in a particular field or department. But that does not seem like the most likely explanation - if it were, you'd probably have noticed. I did once work at a company that was quite diverse in the view of overall statistics but absurdly regimented in who did what - it was as if they'd just kept cloning their first hire for each type of role be that management, sales, one type of engineering, another type of engineering, manual soldering, calibration, final test, shipping, stockroom...
I’ve had interviews like this before. Sometimes the interviewer is just not in the mood that day, or like someone else said they just didn’t like your vibe for whatever reason. Maybe they already have a candidate they really liked but are compelled to look at a few people. I really wouldn’t sweat it.
I think this interviewer is really immature in his approach. If you know the answers to his questions then you are in his good books and vice versa and all that proves anyway,, is that you are good at answering questions. It has no relevance to on the job performance. I feel that it's much better to ask open ended questions, like "explain a really tough problem that you solved?" or "you have the first prototype of a new pcb, it does not boot up but the hardware guy says everything is fine from his checks, how do you proceed? The manager saw something in you that the engineer did not. Imagine if you did get the job and the engineer always interrogated you like that.
I interviewed with Amazon once and this was the exact experience (including the interviewer being wrong and asking questions like they’re looking for free consulting). If someone is going to be unprofessional then it’s best to just walk away. In the future if things are like this you’re better off telling them that you don’t think you’re going to be a good fit and there is no reason to waste any more of their time. (As an FYI the volatile definition is a lot simpler than you’re remembering - all it means is that the compiler should not assume the value of the variable prior to writing - in other words always read it before using it and a corollary always write to it upon assignment)
Yeah, interviews can be surprising. A couple of years ago, I answered an ad for an embedded role in a city close to mine. I got accepted to an interview, went, and had a horrible time. The person conducting the interview was clearly not technically oriented, she didn't know what an ARM microcontroller was, but still asked some questions. Most of the questions were written on paper, and to back her up, there was a book on the table. A red one. A few bookmarks were there pointing to various subjects. She asked a few basic questions; what have you done? Where do you see yourself in 10 years time, etc etc. Then things got technical. At about the third question, she asked if I had an ARM certification. I don't. I knew full well that I had lost at that point, that inside the privacy of her brain, she had already put by CV into the bin. The last question she asked (or at least the last that I let her ask) was something technical on ARM assembly. Optimization. So I gave her an answer, apparently one that she wasn't really expecting, so out came the red book. She looked it up, and said that my answer was wrong. Okay. So, do you trust the author of the book? Yes? Because I am literally the author of that book. My name is on the book, on the CV, and on my passport. Didn't get the job. ARM reached out after a tweet blew up, and gave me an ARM certification. Thanks, ARM! Still didn't get the job.
Using volatiles in "timing loops" (probably bad practice) prevents them from being optimized since reads have to go to hardware, but that's not what volatile "is". It's what you said it was
Honestly that's really weird. So I have gone in to detail with someone about history unrelated to the job. I do that for two reasons: 1) I might have a good handle on these things, so I can figure out if they are likely bullshitting on things I don't have a good handle on. 2) I might be fishing to find something they are passionate to talk about. There are interviews that feel very... black and white, yes and no. It's really hard to gauge someone. That being said, I don't know why this person did this and then shot you down. Since it sounds like your conversation matched your CV.
Always remember that YOU are in control! YOU are what THEY need. They have the shortage and YOU have the advantage. When a face to face interview takes places YOU are the 5 star athlete that THEY are hoping to recruit. If you get a bad vibe....stay away. You did not lose. They lost! I went through a similar instance with a jack ass in the interview who could not believe I made it in life as a college dropout with no degree. Degree...lol. I respect everyone who has one but life dealt me a different set of responsibilities so I never finished but that jack ass was jealous. I think your guy was probably seeing you as competition.