Two applicants, two different responses, what one would be correct? [closed]

Question

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 COutputFormatter, CArithmeticOperation base, CAddable derived from CObject and finally the CAdditionManager. To put everything together, he added CModuleManager, CProgram, CProgramCalculator and CProgramAdder classes.

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)

Answer 1

What is the best way to explain what exactly Programmer #2 did?

He behaves as an Architecture Astronaut?

What is bad about it compared to Programmer #1 's solution?

Failing to focus on the fact that we programmers are there to solve real problems, and deliver value to our customers. In other words, uselessly overgeneralizing a potential solution, as opposed to implementing the simplest thing which can possibly work.

Btw this is known as a code smell, named Speculative Generality.

How do you know if you spend too much time abstracting instead of writing actual functionality?

You have no functionality to deliver, no tasks finished.

When asked about why you added this interface or that pattern, your answers start too often with "we may need this in the future, when ...".

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)

That depends a lot on the company and the persons. I can imagine there are companies which would hire Programmer #2, even if I personally most likely wouldn't.

Answer 2

More code = More bugs
More code = More testing
More code = Higher maintenance costs

Don't add code unless it's necessary to fulfill the requirements.

On the other hand, don't skimp on obvious candidates for classes, functions, extensibility points and sane architecture.

Answer 3

#1 solved a problem and #2 designed a framework in which the problem could be solved.

The second would probably never happen on a job interview which makes this purely hypothetical. The closest I've come to seeing this in an interview is when the candidate asks questions like "Do you want this to be testable?" and "Can we assume a framework?" to which I answer "No" and "Yes" because the fact that it is on their mind is all I care about for an exercise like this.

Answer 4

Programmer #2 over applied objected-oriented design. The design/structure/object-schema is more complicated then the problem that it's solving. If you have a problem that seems colossal, break it down into manageable sections or objects. If you plan on expanding the software, it's good to break it down in advance. Plan out the structure so it's clear where the expansion should go. Viewing software as design heavy is something of a judgment call, and should be done with group approval before you go streamlining it.

But this is a caricature. It's not the best way to ask a "serious" question.

Answer 5

In my experience production quality code never comes in ten line packages.

Keeping it as simple as that usually mean that the program will fall over at ANY situation not part of the perfect world in which the programmer wrote the program.

• Network outage -> Crash.
• File not found -> Crash.
• User input a bad number -> Crash.

etc.

Any long running program must be able to cope with problems in a robust way. Robustness do not come cheap.

Answer 6

The two are simply not equal in all other respects. The two methods speak volumes, not about what they did, but their entire approach to a task on several levels.

The programmer #2 who wastes time writing 10,000 (or whatever) lines of code without asking any further questions in order to better define the actual requirements, or to determine the intended scope of the deliverable needs firing not hiring. Furthermore, the inability to judge the appropriateness of a solution given the situation means they would be something of a worry to hire.

Alternatively they are taking the mickey.

For the interviewer (or whoever) it boils down to a poorly specified project, badly managed, and with zero communication on either sides. (S)he needs firing too. :-)

Programmer #1 gets my vote. Task completed, on spec, on time, on budget. Delightful!

Answer 7

What is the best way to explain what exactly Programmer #2 did?

For some people, it's a personality trait.

I know a guy like this. He keeps getting fired from jobs, and not getting contract gigs renewed, because he over-engineers everything and blows the schedules.

What is bad about it compared to Programmer #1 's solution?

Programmer #2 didn't take real-world context into account.

In a job interview, unless you're asked to do something else, you should always provide short answers that demonstrate proficiency, rather than wasting the interviewer's time. Programmer #2 either didn't know that - showing a lack of experience - or didn't care.

How do you know if you spend too much time abstracting instead of writing actual functionality?

Again, this requires experience and paying attention to context. But it's rare that an interview question should take more than a few minutes to answer, and when it does, it should be pretty obvious.

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)

If I were interviewing, and I hadn't asked for a 10,000 line program, it would be programmer #1.

The job of a software developer is to solve real-world problems by writing software, and doing so in a manner suitable to the task. Part of that involves paying attention to what "suitable" means, and asking for clarification if you're not sure.

Answer 8

Although I agree with Thorbjorn that the real-world solution is rarely a ten-liner, I think the answer to this question depends on what you're looking for in the coding test. Are you testing whether the guy knows how to code a working solution, or knows how to architect a full piece of software?

If it's the first, then in my book Programmer 1 gets the job. This is because Programmer 1 applies YAGNI, which is a VERY important principle in software design. The requirements were, prompt the user for two numbers, add them, display the result. No part of these requirements, at this time, implies a need for any abstraction of code objects.

Because the program requires numbers and so the main logic will fail spectacularly if the user types in ABC, I might give bonus points for parsing the input inside a loop that won't let the user out until they enter a valid integer for each addend. I might also give bonus points for good O-O design, provided they don't go overboard; calling a driving function of a different class from your main() (thus putting as much code as possible into objects and not statics), and possibly splitting out via separation of concerns, tells me you have a grasp of good program design. However, 10,000 lines of code to prompt for two numbers, add them and display the result tells me that you are an "ivory tower" developer who has little concept of being able to "do it light" and still "do it right".

If it's the second, then I would have devised a different problem designed to evaluate their software architecture skills based on the desired language, framework and target UX. Programmer 2 might win that contest, but he would still have to prove to me that he could get some actual working code written within a time frame.

My point is that Programmer 1 might actually be better than Programmer 2, because not only might he know as much as Programmer 2 about software design, but he knows when to be devoutly adherent to SOLID, and when to take a more relaxed approach. However, this example is too simple, and at the same time too easy to make VERY complex, to gauge P1 and P2's respective capabilities on both the small and large-scale. Were I interviewing, this would be a "small-scale" problem expected to be solved in a "small-scale" way, and I would provide other exercises meant to exercise knowledge of large-scale problems.