If any program freezes, the WHOLE DESKTOP freezes. I get this about once a day where Firefox stops to think for 10 or so seconds. During those 10 seconds, cinnamon refuses to do ANYTHING except draw the mouse cursor.
You can't switch applications, you can't switch desktops, you can't run shell commands to try to kill the misbehaving program.
The only thing you can do is hit Ctrl+Alt+F6, and kill programs from that console. But it's not even obvious what program is causing the trouble, as it's has nothing to do with CPU utilization. It's as if cinnamon only has one thread for rendering the screen and since Firefox is (very slowly) updating the screen, then nothing else can happen in the entire system.
If you say that you don't know C++, but you know SOME language which you can discuss in a meaningful manner, that's fine too.
Regardless of the job you are applying for, I expect you to be a quick thinker and demonstrate good problem solving skills. Beyond that, if you are applying for a senior position, you better know SOME language very well.
And anyone who says that C#, Java, Python or some other toy language is "better" must never have written software where performance actually mattered. If you are writing GUIs for a phone, then use whatever language gets the job done best, but when you are writing software that has to get massive amounts of work done, on limited resources, and needs uptimes that are measured in years, then you use a language with less run-time overhead and more predictable results.
Take an X-ray machine for example. We know these can kill people (look up Therac-25). However, if we write an overall program that calls a supplied program to calculate the treatment duration, and have a routine to control the machine and which has a hard limit on the duration, then it doesn't matter if the supplied program can, in some circumstances, calculate an excessive duration, because the patient can't get that dose.
What makes you think that "hard limit" enforcing code can't have a bug in it? I assume your answer is that it's such a small program that you can do a formal proof that it has no bugs. Fine, but what about the OS it runs under? Or the memory controller? Or the actual memory? Any of those can be wrong in a way that could, in theory, cause a patient to be given an overdose. If we can make a robot that is more accurate than a human (at practically any task), we probably should (ignoring issues of liability and macroeconomics), but we have yet to make *anything* that is 100%, let alone a computer controlled robot.
The hardest part of climbing the ladder of success is getting through the crowd at the bottom.