Title: Recent Interview Experiences (and Other Gripes)

As a contract C++ developer I'm one of those who has been unfortunate enough to have borne the full brunt of the slowdown in the contractor market in recent months. In that period I have had a number of interviews, some good and some not so good but, collectively, they've revealed a diversity of interviewing styles. These range from being asked virtually nothing at all to being subjected to intense technical grilling. Now, I'm one of those who frequently gets nervous in interview situations and I often make a hash of questions I perfectly well know the answers to. However, there have been many occasions on which I've been asked what I consider to be poor questions and one occasion on which the interviewers got the answers to two of their questions wrong, while I was right.

One example of a particularly poor interview question I've been asked is this: "how frequently do you comment your code?"

Had I been bolder I would have told the interviewer that it was a stupid thing to ask. However, my response was to expand the question and, instead, describe my commenting strategy. So I said I try to provide sufficient summary comments such that someone can get a rough idea of what my code is doing just by reading the comments. I said that I comment my intention, e.g., why a particular section of code is there or why it's doing what it's doing. I also said that I attempt to minimise comments by making my code as self-documenting as I can, paying attention to the names of identifiers and routines; and also by assigning complex, or even not so complex, conditional expressions to readable Boolean variables.

This particular interview was primarily a "personnel-style" interview, even though it was for a contract position. This means that I was asked questions such as: "name five terms that your colleagues would use to describe you." Well, I was completely floored by that one! I was also asked why I decided to become a contractor. I was tempted to answer: "to minimise the occasions on which I'm subjected to personnel-style interviews!" (Which is true.)

Another interesting occasion was a very gruelling telephone interview, with two interviewers in conference call mode. Although I made a hash of several questions there were two questions which they got wrong and I got right. One of them concerned pure virtual functions. I pointed out that a pure virtual function need not be overridden in a derived class. They claimed that it must. The correct answer is that it need not be but if it isn't, then the derived class remains abstract. They also claimed that the Microsoft Foundation Classes do not contain templated collection classes. Wrong again. Afterwards, I dug up the exact page reference from Stroustrup on pure virtual functions and asked the agent to pass it on to the client. Needless to say I was not offered the position.

I have not been in the IT industry that long, having spent several years in another profession. While I was trying to break into the industry I had periodic conversations with a very experienced C++ developer friend of mine who used to comment that there was a lot of incompetence in the industry. I thought he was exaggerating at the time but now I'm not so sure. I certainly do not consider myself to be anything close to an expert. Many of the contributors to C Vu are well above my level of expertise, but I do constantly strive to improve and learn about best practices.

Other bugbears about the job-seeking process are the imprecision, and often unreasonableness, of many job specifications and the lack of knowledge demonstrated by recruitment agents. Recently, an agent presented me with a specification that read "C++, Visual C++, Visual Studio and C development using Borland C++ 5." This last requirement was a "must have." I was also asked how many years' experience I had of C, C++, Visual C++ and Visual Studio respectively. There are several things that are unsatisfactory about this scenario.

Of course, much of the unreasonableness of job specifications is for the purpose of excluding potential candidates. By specifying that Borland C++ 5 is mandatory the client can drastically cut back on the number of applicants they need to consider. This is especially so when it's an employers' market - as it is, at the moment, in the contract arena.

Which brings me to Silas Brown's question in last month's C Vu. He asks why so many recruiters insist on Visual C++ experience, rather than general C++ experience, for a Visual C++ job. Well, partly it's for the reason I stated above. However, in the case of Visual C++, most usage is likely to include Windows development and most of that uses MFC. So it's this latter knowledge that most recruiters are looking for. If you have experience of C++ under, say, Unix then one is unlikely to become proficient in Visual C++ overnight. Often, for permanent jobs this does not matter. But if there is only one vacancy, and the employer has a number of candidates to choose from, all of whom have Visual C++ experience, what chance would you expect the Unix C++ developer to have?

Suppose the Unix developer has 6 years of C++ experience while the Visual C++ developers have only eighteen months. Given that it's likely that the Unix candidate is a better C++ developer one would expect the employer to pay some attention to this fact. Not a chance! It can be frustrating but that's the way the world works. In general, employers put too much store on candidates' having specific knowledge of certain technologies rather than on their being skilled practitioners of their trade.