During an interview for a C++ programmer position at ACME, two candidates are asked to create a program that takes asks the user to type in two integers, and then prints out their sum.
The first programmer solves the task in 10 lines of code.
The second programmer ends up with 10,000 lines of code.
This is because #2 did not go straight for the task, but started creating a huge set of infrastructure for solving it.
First of all, he created a
CObject base class, then went on to a
IInput interface class, derived a
CInputSTD class, created a library wrapping STL functionality to convert strings to numbers and vice versa. And still on he went, creating an event dispatcher system to lower coupling of each of the modules, and adding about 20 macros to his code. But that still wasn't enough, so on he went on and constructed a
CAddable derived from
CObject and finally the
CAdditionManager. To put everything together, he added
After that, there were only about 5 helper classes and a 500 line-long API header left to write. His whole code was well-documented, namespaced and cross-platform compatible.
Now to my serious questions:
- What is the best way to explain what exactly Programmer #2 did?
- What is bad about it compared to Programmer #1 's solution?
- How do you know if you spend too much time abstracting instead of writing actual functionality?
- Which programmer, in a real company and with the solution of Programmer #2 made a bit more sane (less classes, lines), is more likely to get the job? (given that they are equal in all other aspects)