I'm a professional in general software and finding my passion in a future career with Nintendo, God-willing with some fairy dust included. While planning ahead with knowing what tools they use, I came across a job ad from Nintendo that reads "C/C++ with low level experience."

Does that mean..

a) HR doesn't understand the differences between the two languages, but apparently got the requirements from a supervisor?

b) The company wants to see both C and C++ products from you.

c) The company focuses on C++ but wants the programmer to have knowledge of C as well?

d) It's to maintain old, reusable C code because of the history of the company, while using 'what makes C++, C++' in other areas.

e) All above

I mean, I have a long way to go, although I understand both languages completely, hense why I think saying "C/C++" is odd. But I'm wondering, portfolio-wise, if it's best to have ~5 notable products in C, and ~5 notable products in C++? And, jokingly, maybe 5 in "C+"?

It usually means their existing code is likely "C with Classes" style C++: classes, maybe some inheritance and virtual methods here and there, maybe one or two templates, but no smart pointers, no functional style, no other modern C++ features. In other words, using C++ constructs to write C-style code.

Which means you will be expected to deal with all of the headaches that comes with that.

Okay, thanks. I guess that's how I started out.

When I've applied for jobs that say C/C++, it means experience in either language counts.

Generally, I've seen two different styles when companies look for software engineers: they either want someone skilled with a laundry list of very specific technologies, or they want someone with good computer science fundamentals and believe that a good engineer can work with a variety of languages or APIs. These companies do not seem to care very much about which specific languages you know.

Not caring too much about whether your experience is with C or C++ might mean Nintendo is in the second category, which is the one I prefer. I really doubt this has anything to do with HR not knowing the difference, or with them requiring to see both in some way. Not every job is about what you know right now. I think the answer is "none of the above".

I think the only reason they even list C/C++ instead of nothing specific is that they want a "low-level" programmer in this case, and typically low-level programming is done in one of those two languages. The only other serious option I can think of right now is just straight-up assembly language programming.

I see. Nintendo programmers have noted the interview questions were for both languages, so I assume it's what you're saying - the second category. Knowing where C ends and C++ begins.

Many people use "C/C++" to mean "idiomatic C++ but also all the ugly little low-level unsafe bits that C++ proponents want to pretend aren't there any more."

And to be frank: there's no such thing as a good C++ programmer that isn't also a competent C programmer. There may well be many _mediocre_ C++ programmers that would be utterly lost in C, but those people aren't generally the ideal candidate for a company that writes OSes and tools and code demos for custom game console hardware (or any C++-using company in my personal opinion; might as well try to hire a mechanic who doesn't know how a transmission works).

By the way, I'm curious as to which branch of Nintendo is this you're applying to? Nintendo of America is local.

Well, at the end, they are both good languages and paradigms to know on the job.

Yeah, Nintendo of America. Just something to work towards. Thanks for explaining C/C++. I guess it's subjective, but it sounds like C with Classes to be expected.

It means that the person who wrote the ad, either the HR drone or the team lead, does not understand the modern languages and is stuck about 30 years in the past. It means you will not be working with modern features of the language, and that your team lead is unlikely to allow anything beyond C89 or C++98 contents in the code.


Personally I find it annoying and a sign of ignorance. C and C++ had diverged before C's ISO standardization. Although I am against age discrimination, when programmers refuse to re-learn the languages as they evolve they are like physicians who stop learning. Just like you wouldn't want a doctor who stopped learning new treatments 30 years ago, you wouldn't want a technical lead who stopped learning 30 years ago.

During my last set of interviews when between jobs, I asked the team leads if they were using modern C++. When I got blank stares, I asked about constructs from C++11, and only one of the programmers (not the team lead) was able to speak on them. He basically told me they weren't used. I asked the team lead about C++14, and he hadn't heard of it. When I started asking more questions, I quickly learned the studio was stuck in the past, refusing to update their compilers to anything C++11, and I started to turn the tables on the interview, asking just how far behind the technology curve the company was. Turns out I'm glad I did. The entire team is likely to find themselves unemployable in the near future, which is kind of sad.

Back in the early 80's and 90's when Stroustrup wanted them to come back together, it was already too late. His big cry when it was released from the lab was that everything in the K&R C standard compiled in c++, albeit with some warnings about casts, so it should be the same language. He tried to get the features moved to C, but the committee didn't want it; the C++ changes broke too much real C code. With so many revisions to each of the languages since then, they have further diverged again and again and again.

These days the languages are dramatically diverged. Any non-trivial C program will simply not compile on a C++ compiler. Not only are there the problems with everything needing explicit casts, but huge swaths of C language features introduced in C99 and C11 have no counterpart in C++. Yes, you can write code that basically works in both languages by pretending you live back in 1979 when K&R was the fresh new standard. But you miss out on three decades of improvements to both languages. Why would you want to abandon the last 30 years of advancement?

Usually the people who say C and C++ are so similar are the ones with little serious experience with either. If you haven't reached the point where you refer to the language standards, and you haven't read the language standards, you don't know the languages. You might know ABOUT the languages, and you might be able to use them and be moderately good at it, but that isn't actually knowing the language.

If you need a C programmer, get a C programmer. If you need a C++ programmer, get a C++ programmer. When people start asking about c/c++ programmers, it shows they are stuck in the distant past and have no idea what they are really talking about. They are the kind of places where once you get laid off, you will have a very difficult job finding a new job, like the doctor who hasn't updated his skills in 30 years

Well, I'm sure you understand their delima too: their staff may not be fully up to date because their code base is old but reusable. It's an expensive route (money and time) to convert an entire system to C++11. Because by the time they do that, and ship their game out, C++(14+) is already out, and they're behind again. If I were them, I'd push out the product first, and maybe have a small team that can convert resusable parts to a more modern code base. My last job had three versions of .NET going at the same time for different products. It's not easy converting old code bases.

If you need a C programmer, get a C programmer. If you need a C++ programmer, get a C++ programmer. When people start asking about c/c++ programmers, it shows they are stuck in the distant past and have no idea what they are really talking about. They are the kind of places where once you get laid off, you will have a very difficult job finding a new job, like the doctor who hasn't updated his skills in 30 years

In my experience with interviews, the worst team leads and HR drones, IMO, were the ones with a very specific list of criteria that were used to identify engineers: have you used X language, Y compiler, Z API, W methodology, etc.? The interviewers tend to be pretty shaky with the details of each of things themselves. They ask a few easy technical questions to check if you know the syntax and then a bunch of generic interview stuff like, "What's the biggest problem you've overcome?", and that's it. The interview lasts around an hour or two.

The better companies, IMO, usually start out with, "What's your strongest language?", and then ask several actual programming questions where they let you use that language. The questions usually let you demonstrate how much you know or don't know about computer science: algorithm analysis, data structures, dynamic programming, recursion, etc. The softer questions are more along the lines of "How would you debug this?" or "How would you design this?" The interview lasts all day.

For the first type of interview, yes, they better ask for C++ programmers if that's what they need, because they probably can't teach it very well or identify who can learn it by themselves.

I'm guessing that Nintendo is somewhere between those two experiences, where they probably do know what they're doing for the most part. Maybe they don't want to try to figure out whether someone who comes in as a Python programmer is ready to do low-level C programming, but they're fairly certain they can convert a good C++ programmer to C or vice-versa.