5 ms·

C++ on a CV is a gift for the interviewer because it's trivial to discover if the person is bullshitting when they say that they know it. I'm not talking about

C++ on a CV is a gift for the interviewer because it's trivial to discover if the person is bullshitting when they say that they know it. I'm not talking about the esoteric corners here, I mean the absolute basics - it's amazing how many people think they can pretend to know a complex technology and are then knocked for six when the interviewer actually quizzes them on it.

zabzonk 3y ago
absolutely. my #1 interview question for c++ dev roles is "tell me about the copy constructor".
- throwaway1492 3y ago
  As someone who worked professionally on a c++ application for two years around 2010, I took c++ off my resume. C++ is the ultimate "stump the chump" language with tons of corner cases and esoteric gotchas. I hated it and I hate interviewers who do this. You all can have it. The reality is, in my area, Java enterprise development pays a lot more. I'm sure this is the case in plenty of other areas as well. Surprising but true.
  - skippyboxedhero 3y ago
    Add it back. You know that any place like this is going to be full of people who spend all their time jerking themselves about how wonderful they are. Every place that I have interviewed where interviewers have done that has been full of people who are too maladjusted to work at a place that actually succeeds in producing anything.
    - deleted 3y ago
      [deleted]
  - asveikau 3y ago
    Two years probably isn't enough time to become good at c++. And in 2010 the standard was about to change a lot.
    - zabzonk 3y ago
      probably true, but the copy constructor itself (bar when it can/must be elided) hasn't changed much over a long time.
      - asveikau 3y ago
        The "= delete;" thing was added, and move constructors are a big deal, but I agree.
  - sunsunsunsun 3y ago
    I've been writing C++ for 4 years now professionally. I don't claim to be some kind of god at it but what am I supposed to do? Leave it off my resume because I don't know every intricate detail? I've used it to get shit done and make a company money, everything else is fluff.
    - jfoutz 3y ago
      Every place that uses C++ uses some narrow fraction of the capabilities. Teams try to find an intersection of features that hopefully a majority of the team can understand. In an interview setting, keep answers contextual and tight. In my previous professional setting, we would solve the problem like this : <however>. Try to solve problems using only the subset you know. if you're pushed into a corner and they really want to overload [] or whatever, be clear that because, c++ is a large and sprawling language, for production code you'll need to check the spec, or consult with a teammate. With that understanding in place, you can take a stab at it. If you get dinged for that, you probably don't want to work there anyway.
    - digging 3y ago
      > I've used it to get shit done and make a company money, everything else is fluff. I find it so frustrating how hard this is to sell in an interview. I understand how important it is to avoid bad hires, but I'm a self-taught web developer so I just flat out don't know a lot of CS "basics". I've been a professional SWE for 5 years, have made all of my teams very happy, have accomplished some very good work, and have dug into the docs enough to get the most out of the many tools/libraries I've had to use. But, sometimes there's a coding challenge on a topic I've just never seen before, and I'm dropped. As unrealistic as it is, I wish interviews had options for demonstrating my ability to learn a new tool quickly and make use of it. I'd spend a work day taking on a mock ticket for some new security procedure I've never touched before if it showed them that I can actually get the job done.
    - BeetleB 3y ago
      I suppose it depends on the work the interviewer's company is doing, but when I last had a C++ job, knowing what a copy constructor was and the implications involved was important. I agree that asking details related to syntax are not good questions. But copying objects is a very natural thing to do in most languages, and if you don't have some idea of the implications, that's a red flag. Also: Some understanding on default copy constructors. I think it's OK not to know whether a default one is created for you or not, but just knowing that it might be is worthwhile to probe in an interview. Of course, these concepts are due to a poor language design, but what can you do? If your team uses C++, you need to deal with the poor design, and need people who understand the poor design.
  - zabzonk 3y ago
    > C++ is the ultimate "stump the chump" language with tons of corner cases and esoteric gotchas. certainly, a bad interviewer can ask bad questions (for any language), but the copy constuctor (and call by value or call by reference) is one of the basic features of c++.
- boring_twenties 3y ago
  That's not a question
  - zabzonk 3y ago
    ok, "what can you tell me about the copy constructor?"
    - boring_twenties 3y ago
      OK, that's a terrible question? Do you want to know literally everything there is to know about it? Any one random thing?
_gabe_ 3y ago
> I mean the absolute basics Which are...? I'm guessing, depending on the niche you work in, your basics are very different from many other niche's C++ basics. If you're working in FPGA development you'll have very different basics then a fintech. Likewise, game development is very different from backend web dev. C++ at Facebook is probably very different from C++ at Microsoft. Microsoft Kernel development C++ is probably very different from Microsoft Windows 11 adware C++. I'm glad that interviewers exist that think they can pwn the interviewee by quizzing them on the "extreme basics", because it's an immediate red flag to me that the interviewer is acting with extreme hubris to claim that such a thing exists at all. I go back to this all the time, but when the guy who has literally been writing entire books on the esoteric features of C++ for 20 years says he doesn't trust himself to evaluate potential errata[0], I highly doubt any single person is capable of understanding the voluminous pitfalls and complexities of this large, bolted, amalgamation of a language. [0]: https://scottmeyers.blogspot.com/2018/09/the-errata-evaluation-problem.html?m=1 https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...
- acedTrex 3y ago
  I mean i'd assume absolute basic things like "what is a pointer vs a reference." Or "what is the stack."
- yeputons 3y ago
  > Which are...? I guess they're different for different interviewers. The one I would use is something about undefined behavior. I mean, the fact that it exists and consequences. For example: "this program works, but if I add this line of code at the very end, the program crashes. Can be I sure that it crashed because of that line or some incorrect inputs to that line?" In (almost) all other languages the answer is "Yes". Not in C++ or C. You may have a faulty program in the first place that just happen to not crash. All other quirks and syntax can be picked up when needed. You can play around and investigate. But undefined behavior requires one to think and debug in a very different mindset. One cannot assume that a program that does not crash and gives a correct answer will do that if extended.
  - krona 3y ago
booleandilemma 3y ago
The reaction I've seen from some clueless managers has verged on: "Wow he knows C++! He must be a genius!" It's surprisingly easy to fool people with just words. I think this is why we have so many incompetent people working in tech. Most people don't know how to qualify people.
grumpy_coder 3y ago
The problem with that statement is you have to in a very small time period pick enough corners to find what they know and not the many parts you think are not esoteric but are unused by many people. What isn't esoteric? Shared pointers, move semantics, atomics, inline assembler, CRTP... If you quiz someone on your particular known C++ language details you can far too easily think everyone is pretending.

zabzonk 3y ago

absolutely. my #1 interview question for c++ dev roles is "tell me about the copy constructor".

throwaway1492 3y ago
As someone who worked professionally on a c++ application for two years around 2010, I took c++ off my resume. C++ is the ultimate "stump the chump" language with tons of corner cases and esoteric gotchas. I hated it and I hate interviewers who do this. You all can have it. The reality is, in my area, Java enterprise development pays a lot more. I'm sure this is the case in plenty of other areas as well. Surprising but true.
- skippyboxedhero 3y ago
  Add it back. You know that any place like this is going to be full of people who spend all their time jerking themselves about how wonderful they are. Every place that I have interviewed where interviewers have done that has been full of people who are too maladjusted to work at a place that actually succeeds in producing anything.
  - deleted 3y ago
    [deleted]
- asveikau 3y ago
  Two years probably isn't enough time to become good at c++. And in 2010 the standard was about to change a lot.
  - zabzonk 3y ago
    probably true, but the copy constructor itself (bar when it can/must be elided) hasn't changed much over a long time.
    - asveikau 3y ago
      The "= delete;" thing was added, and move constructors are a big deal, but I agree.
- sunsunsunsun 3y ago
  I've been writing C++ for 4 years now professionally. I don't claim to be some kind of god at it but what am I supposed to do? Leave it off my resume because I don't know every intricate detail? I've used it to get shit done and make a company money, everything else is fluff.
  - jfoutz 3y ago
    Every place that uses C++ uses some narrow fraction of the capabilities. Teams try to find an intersection of features that hopefully a majority of the team can understand. In an interview setting, keep answers contextual and tight. In my previous professional setting, we would solve the problem like this : <however>. Try to solve problems using only the subset you know. if you're pushed into a corner and they really want to overload [] or whatever, be clear that because, c++ is a large and sprawling language, for production code you'll need to check the spec, or consult with a teammate. With that understanding in place, you can take a stab at it. If you get dinged for that, you probably don't want to work there anyway.
  - digging 3y ago
    > I've used it to get shit done and make a company money, everything else is fluff. I find it so frustrating how hard this is to sell in an interview. I understand how important it is to avoid bad hires, but I'm a self-taught web developer so I just flat out don't know a lot of CS "basics". I've been a professional SWE for 5 years, have made all of my teams very happy, have accomplished some very good work, and have dug into the docs enough to get the most out of the many tools/libraries I've had to use. But, sometimes there's a coding challenge on a topic I've just never seen before, and I'm dropped. As unrealistic as it is, I wish interviews had options for demonstrating my ability to learn a new tool quickly and make use of it. I'd spend a work day taking on a mock ticket for some new security procedure I've never touched before if it showed them that I can actually get the job done.
  - BeetleB 3y ago
    I suppose it depends on the work the interviewer's company is doing, but when I last had a C++ job, knowing what a copy constructor was and the implications involved was important. I agree that asking details related to syntax are not good questions. But copying objects is a very natural thing to do in most languages, and if you don't have some idea of the implications, that's a red flag. Also: Some understanding on default copy constructors. I think it's OK not to know whether a default one is created for you or not, but just knowing that it might be is worthwhile to probe in an interview. Of course, these concepts are due to a poor language design, but what can you do? If your team uses C++, you need to deal with the poor design, and need people who understand the poor design.
- zabzonk 3y ago
  > C++ is the ultimate "stump the chump" language with tons of corner cases and esoteric gotchas. certainly, a bad interviewer can ask bad questions (for any language), but the copy constuctor (and call by value or call by reference) is one of the basic features of c++.
boring_twenties 3y ago
That's not a question
- zabzonk 3y ago
  ok, "what can you tell me about the copy constructor?"
  - boring_twenties 3y ago
    OK, that's a terrible question? Do you want to know literally everything there is to know about it? Any one random thing?

_gabe_ 3y ago

> I mean the absolute basics Which are...? I'm guessing, depending on the niche you work in, your basics are very different from many other niche's C++ basics. If you're working in FPGA development you'll have very different basics then a fintech. Likewise, game development is very different from backend web dev. C++ at Facebook is probably very different from C++ at Microsoft. Microsoft Kernel development C++ is probably very different from Microsoft Windows 11 adware C++. I'm glad that interviewers exist that think they can pwn the interviewee by quizzing them on the "extreme basics", because it's an immediate red flag to me that the interviewer is acting with extreme hubris to claim that such a thing exists at all. I go back to this all the time, but when the guy who has literally been writing entire books on the esoteric features of C++ for 20 years says he doesn't trust himself to evaluate potential errata[0], I highly doubt any single person is capable of understanding the voluminous pitfalls and complexities of this large, bolted, amalgamation of a language. [0]: https://scottmeyers.blogspot.com/2018/09/the-errata-evaluation-problem.html?m=1 https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...

acedTrex 3y ago
I mean i'd assume absolute basic things like "what is a pointer vs a reference." Or "what is the stack."
yeputons 3y ago
> Which are...? I guess they're different for different interviewers. The one I would use is something about undefined behavior. I mean, the fact that it exists and consequences. For example: "this program works, but if I add this line of code at the very end, the program crashes. Can be I sure that it crashed because of that line or some incorrect inputs to that line?" In (almost) all other languages the answer is "Yes". Not in C++ or C. You may have a faulty program in the first place that just happen to not crash. All other quirks and syntax can be picked up when needed. You can play around and investigate. But undefined behavior requires one to think and debug in a very different mindset. One cannot assume that a program that does not crash and gives a correct answer will do that if extended.
- krona 3y ago

booleandilemma 3y ago

The reaction I've seen from some clueless managers has verged on: "Wow he knows C++! He must be a genius!" It's surprisingly easy to fool people with just words. I think this is why we have so many incompetent people working in tech. Most people don't know how to qualify people.

grumpy_coder 3y ago

The problem with that statement is you have to in a very small time period pick enough corners to find what they know and not the many parts you think are not esoteric but are unused by many people. What isn't esoteric? Shared pointers, move semantics, atomics, inline assembler, CRTP... If you quiz someone on your particular known C++ language details you can far too easily think everyone is pretending.