More than once, I have met people who have claimed to be experts in their fields and defined their fields very, very broadly: they were experts in C++, C, Java, PHP, HTML, SQL, Pascal, Delphi, ASP, .NET, you name it! If you dig a bit deeper, their “expertise” often came from “technology romanticism”, school projects, classes or having read a website on the subject.

I am not an expert in Java, PHP, HTML, SQL, Pascal, Delphi, ASP or .NET. I have touched on each of these and used Oracle, MySQL, PostGreSQL, PHP, Java, etc. etc. on occasion - but that doesn’t make me an expert. I do, however, have seven years of professional experience in software design an have spent most of those seven years designing and implementing software, learning about designing and implementing software, writing C++ code, writing specifications, reading other people’s specifications, learning, learning some more, etc. A lot of sweat has gone into this experience in software design and a lot of my work has been reviewed - and approved - by my peers. That includes peers with formal training in software design, peers who are recognized experts in software design and peers who I am flattered to be called peer of. They have declared me to be an expert in this field and, after having been declared such often enough in both formal reviews and informal discussions, I now gladly accept the term.

Formal training and enthusiasm do not an expert make - though they can help. Hard work does not an expert make - though that will help as well. Expertise does make an expert. It takes skill, knowledge, judgment, and experience in a particular area - and that judgment should include judging yourself to not be an expert in some areas.

One of the self-proclaimed experts I met was a candidate for a job opening as a C++ programmer. As team lead and chief software architect, I picked the candidates on their technical skills and their ability to fit in with the team. To check the technical skills, I had (and still have) a rather tough exam that all candidates had to take. Taking the test usually takes about an hour and a half but, as we worked under pressure a lot and I had to test the candidate’s ability to work under pressure as well, I gave them 20 minutes. I have never seen a candidate that could actually do the test in 20 minutes, so I usually go in after 20 minutes, ask them how they’re doing and tell them I’ll be back in 10 minutes more. That’s when they start rushing and sometimes making very stupid mistakes. (That’s probably why my friend in Marketing said I tortured my candidates…)

So, I came in after 20 minutes, asked him how he was doing - he said he needed some more time and was showing a wee bit of irritation at being handed an impossible assignment. I offered him another 10 minutes. He said OK, so I left. Ten minutes later, I came back and, as I always did, sat down, told him he could continue working while I started checking the first pages of the test. The first three pages of my test are code that needs to be corrected. It’s the type of code that you’d find in legacy applications, written in Hungarian style and with plenty of subtle and not-so-subtle bugs - including functions that don’t do what they’re named for, variables that don’t have the type you’d expect them to have from the Hungarian-style name, etc. 35% of the test’s points are in those first three pages, and I give points for improving the code, but subtract points for making the code worse. He’d made the code a lot worse, introducing several new bugs and only fixing one or two. So, I started making some notes on the test, and, as he’d stopped writing and was looking at what I was doing (despite the fact that I’d told him he could continue the test - most candidates do this) I asked him about some of his answers: “what do you think will happen here?”, “how do you think you could optimize this?”, etc.  When we got to some of the more open questions of the test: “What is a class invariant?” for example, he started mumbling (most people say that it’s a static constant member of a class, which is second-degree bullshit, but is at least a coherent answer). When a candidate gets an answer wrong, I usually proceed to explaining the right answer to him and asking a follow-up question, to see whether he understood the concept after explanation. For most candidates, when they get the follow-up question right (which most do) they’re relieved - especially when I make it clear that I don’t mind if they don’t know, as long as they understand when it’s explained to them and they know that they don’t know.

When I got through the design-by-contract theories and went into some of the core aspects of the C++ programming language, which included a multiple-choice question with three versions of a template function (“which do you like best and why” - most get it wrong), the candidate’s temper exploded. He started shouting, waving his hands about, saying things like “Nobody uses that stuff anyway!”, etc.

That he wasn’t an expert in my view had apparently gotten through to him. That he didn’t get the job came as no surprise.