Update: This got some attention, with some good discussion on this reddit thread The company where I work needs another experienced C++ developer. That means another round of technical interviews and another round of disappointing applicants.
I am sure those who I have interviewed in the recent past were good at their current jobs but none were suitable for the positions offered.
Do you want to work with me? What follows is a description of what we need from you.
We are not looking for a rockstar rather an experienced C++ programmer who knows the ropes. When interviewing, I am looking for someone with an excellent command of the basics of C++ and the sort of broad, generalized knowledge that comes with experience and curiosity.
One thing I am not looking for, surprisingly, is a 100% knowledge of the C++ language. It wouldn't hurt but don't panic if you can't rattle off the exact syntax to a perfect-forwarding templated move constructor off the top of your head. In real life you would look it up before implementing it but in an interview for a senior dev we might ask to describe the wheres, whys, and hows of such a beast in general terms.
The following is a list of the areas I like to cover when interviewing. A junior would not be expected to know everything here but I would like to think a senior could at least speak to almost everything here.
In vaguely descending order of importanceUpdate: Some comments complained that this is a fairly idiosyncratic and specific list. I disagree, it is meant to cover a wide range of topics that a commonly encountered in software development. Not everyone will have knowledge of this entire list but it is what I keep in mind when interviewing people.:
- Classes and objects. Encapsulation. RAII and why it is important. Inheritance and polymorphism, wheres and whys. A brief overview of how virtual functions work. Why virtual destructors are a good idea. Copying vs moving.
- How the stack works and how it differs from the heap. Memory management in general, in particular managing buffers. Buffer overflows.
- Exceptions and what happens when they are thrown. How stack unwinding works. Their interaction with destructors and non-exception-safe code.
- Experience with the stl and basic data structures. Experience with other popular libraries like boost. Experience with OS APIs (Win32, etc). Cross platform coding.
- When to use multiple threads. Thread safety in the face of multiple readers and writers. Locking in general. Deadlocks and how to avoid them. Thread pools. Futures and promises.
- The differences (pros and cons) between C++ and garbage collected languages like C# or Java. How those differences affect the way programs are constructed.
- Testing frameworks. Familiarity with common IDEs and platforms. Source control, branching and merging. Agile methodology, experiences, pros and cons.
- Network programing. Differences between blocking and non-blocking IO. Messaging. How TCP partitions messages (hint: it doesn't). ASIO-style asynchronous IO with callbacks. HTTP. REST. OpenSSL.
- Filesystems. Strings and encodings.
- SQL and databases, XML, Json parsers.
I am not a fan of extensive coding exercises in interviews but I usually get the applicant to write a simple Singleton implementation and then perhaps make it thread safe. It is worrying how many people get it wrong.
Here are some things that will score you negative points in a technical interview:
- Rattling off text-book definitions of terms without understanding. We are looking for street-smarts not book-smarts.
- Not resisting the urge to use emojis on your resume or cover letter - you are applying for a grown-ups job
- Bullshitting your way through a topic, I will be asking follow-up questions and the results will be embarrassing for both of us. It is OK to admit that you haven't used a feature or library; nobody knows everything.
- Bad-mouthing your current employer or the projects you have been working on. If they suck you were part of the problem.
- It is acceptable to say "I get asked this question a lot in interviews", technical interviews have some classic questions that everyone uses. But for the love of all that is good don't follow up with "I still don't know anything about that." It reveals a certain lack of gumption.
- When asked if a previous project on your resume that looks exactly like a spam engine is a piece of spamming malware, do not say "Yeah, it started off as a virus but we decided to commercialize it".
Finally, don't be shy in bringing up any private projects you have worked on even if they didn't go anywhere. All the best developers have random hobby projectsUpdate: Comments on this point were negative; I think I overstated the importance of hobby projects. Not everyone has the time to spend hours on a labor of love and I certainly don't hold it against anyone if they don't do this. What I was trying to explain was that experience in home projects is just as valid as on-the-job experience. and being able to say "Well I don't have any commercial experience in MySQL but I found when mucking about with my private cricket statistics generator that..." will earn you a secret bonus multiplier.