How to determine the actual level of development in a shop, e.g. C++ vs. C?

Question

I imagine most of you know what I am getting at. You start a new job and within the first week or so of scanning through the code you realize you are in yet another C shop that throws in the occasional stream or hapless user defined class here and there. You quickly realize that not only aren't you going to learn anything new but it is just a matter of time before you are asked not use certain things because no one else understands them and won't be able to maintain your work.

How often do you see some new technique on say, StackOverflow, only to realize that if you ever used it at work you would be met with bewilderment or annoyance at best?

In your experience are these places the norm or the exception?

How do (or would) you try to determine a group's level of sophistication and commitment to C++ in the interview setting? For instance I have tried asking questions about the company's use of things like STL, Boost, 3rd party libs, etc., but that only seems to get incrementally closer to the reality of situation you'll find once in it. Thoughts?

Answer 1

I've worked for long periods of time in three C++ shops. In all cases, they were real C++ shops, using C++ as it was intended to be used, and staying fairly up-to-date, given the times I worked at them.

Answer 2

The places I've worked at weren't necessarily using C soley. They weren't cranking out new programs one after another...they were usually building something big and maintaining it. In my experience it becomes harder to keep implementing new an exciting features of a language into an older piece of software that keeps growing and the main job is to maintain/update it.

I think asking in the interview about those cool new features would help a lot...you should at least be able to weed out the obvious ones. Another thing would be to ask if you could talk to some of the people that actually write the code. Most interviews are with manager types...and they aren't always the people involved with using the latest features of a language.

Answer 3

If you read between the lines, you'll probably find a heck of a lot of information buried in their questions, both in terms of what they want you for and their level of sophistication.

You may also want to return their questions not only with answers, but with harder questions requiring clarification on ambiguities in their questions.

Just don't come off as an arrogant jerk when you do it. ;-)

Answer 4

It's really all across the board. On one end of the spectrum, I've worked in one place where the code was recently rewritten in C. Recently being 10 years ago. Everyone was highly skeptical of this new-fangled technology.

Slightly farther down the spectrum, you'll find C programmers who happen to have compilers with C++ features enabled. They'll dabble in the "class" keyword. But other than that, they are practically writing in C.

Next down the line I think you'll find those who just groked inheritance and polymorphism. These are the kind of guys and gals that would swoon over an MFC or wxWidgets program, thinking it was the greatest.

You'll go a little farther and find the folks who just read Meyer. They are all about figuring out how to use STL efficiently. They've got a basic notion of templates that equates mostly to the way STL uses them.

Then you've got the Modern C++ Template Metaprogramming geeks. Many of us these days use their work in the form of boost and all its goodness. Few actually dork around with template metaprogramming. That's probably a good thing.

I have seen perfectly good code written at each level.

The cool thing I always liked about C++ is that at each level of added complexity, the cost could be conceptualized in terms of "how this new abstraction might be implemented in C". So I can conceptualize that inheritance and polymorphism is adding the cost of a function pointer lookup. Since I have seen this and written this in C, I know what I'm in for. I also have a sense of how templates work in part because of how the preprocessor works in C. This applies to most features in the C++ and C world.

Since it's easy to map concepts to how they are implemented in C, I can easily visualize how the underlying architecture runs my code.

Answer 5

Interestingly, I consider the level of advancement pretty much the opposite of your preferences. Therefore this response might not be directly useful, but I hope it's at least somewhat informative.

---

First, any environment that encourages "cleverness" is suspect. If I see a lot of Boost, a lot of template metaprogramming, and especially any use of C++'s "functional" features, it's a big red warning sign. It means the developers have some idea of what correct programming is, but are constrained by either lack of imagination or politics to using a decrepit junk language such as C++. C is boring and tedious to work with, but "advanced" C++ goes out of its way to interfere with development.

Second, check whether a particular technology or concept is treated as a buzzword. If the prospective employer uses XML, there's an easy check you can do -- do they use a real parser/serializer (either SAX or DOM is fine), or do they parse it with regexes and serialize it with raw character streams? If the latter, it shows they don't understand why XML is useful, and they're just using it to have another three-letter acronym on the project description.

Third, figure out what language the developers wish they were using and why. Every good developer has a favorite obscure language -- it doesn't matter whether it's Python, Ruby, Smalltalk, Haskell, or Factor -- and a reason for preferring it. If everybody is content to work in C++, it's another warning sign that they've not got much curiosity about programming in general.