Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)
share|improve this question

closed as not a real question by Jarrod Roberson, Macneil, Robert Harvey, kevin cline, ChrisF Aug 1 '11 at 17:37

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

8  
So Programmer 2 went the route that would have added hundreds of hours to development time vs Programmer 1 day and half development time ( which includes full regression testing ). Please don't tell me this is a "what if" situation. Based on what you describe it sounds like programmer B would waste money doing stuff already supported. –  Ramhound Aug 1 '11 at 15:57
9  
This smells like a anti-oop stealth rant. –  Gary Willoughby Aug 1 '11 at 15:57
3  
what's the difference between 10 lines and 10.000 lines? –  Casey Patton Aug 1 '11 at 16:06
5  
@Casy Patton, one is implicitly cast as a floating point amount of work. Handy for contractors and consultants. –  Philip Aug 1 '11 at 16:09
3  
They both should have refused to accept the job because this could have been done in a spreadsheet instead of wasting precious developer time. –  JeffO Aug 1 '11 at 17:41
show 9 more comments

8 Answers

#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.

share|improve this answer
1  
I have had architecture astronauts in job interviews. Asked to write "code to x", they write "a function to do a more general problem" and sometimes forget to write code to call that function. Hint: if you can't fit it on the whiteboard, you're writing way more than I expected you to. –  Kate Gregory Aug 1 '11 at 20:43
add comment

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.

share|improve this answer
1  
Normally yes, but in an interview candidates may do things to demonstrate their abilities and knowledge - things that they wouldn't do in real life. In an interview, we clearly aren't there to solve real problems, we're there to sell ourselves to a potential employer. A lot depends on what the candidate thinks you're likely to be looking for. "Why are you asking a trivial question?" may lead to "to test if I'm an architecture astronaut", or "to give me a simple platform to demonstrate my wider skill-set". –  Steve314 Aug 1 '11 at 16:23
1  
@Steve314, what better way to demonstrate our abilities and knowledge, and to sell ourselves to a potential employer, than to solve the problems thrown at us, in the most concise and elegant way possible? Just my 2c. –  Péter Török Aug 1 '11 at 16:28
    
@Steve: I agree with Peter's comment. And if during an interview you are concerned that they want more, why not suggest possible pros and cons of the approach, and how you would do it differently with different requirements? –  Jeremy Heiler Aug 1 '11 at 16:50
1  
@Péter Török, if I were given a FizzBuzz type of problem, during an interview, I would get quite bored and discouraged. I would reply "Oh man, instead of 1...100, can I do it for numbers 1 through 60 instead, because that is what the headhunter prepared me for?". If this joke is not appreciated, then the interviewers are square code monkeys and have failed my test. I would also like to generate a 10-lines long BASIC program that looks like this: "10 Print "1"; 20 Print "2"; 30 Print "Fizz"; 40 Print "4" ... Then I would want to see them convince me that the loop-ed version is better. –  Job Aug 2 '11 at 2:41
1  
@Job, I understand your sentiments. This reminds me of the Barometer question :-) –  Péter Török Aug 2 '11 at 8:30
show 1 more comment

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.

share|improve this answer
    
+1 for basically saying don't revent the damn wheel. –  Ramhound Aug 1 '11 at 17:28
add comment

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.

share|improve this answer
    
This is true, but before creating code to handle those situations, there must be specifications (tests) for those situations. I wouldn't be happy if a developer spent thousands of dollars on insurance that I don't want and can't afford. Sometimes a crash and stack trace is sufficient. –  kevin cline Aug 1 '11 at 16:30
    
@Thorbjørn Ravn Andersen - The only requirement was to parse user input. So your examples do not apply. –  Ramhound Aug 1 '11 at 17:27
    
@Ramhound, example is contrived and unrealistic. –  user1249 Aug 1 '11 at 18:40
1  
Also anyone who can't add two numbers in 1 line of code should definitely not be hired. –  Kevin Aug 1 '11 at 22:43
add comment
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.

share|improve this answer
add comment

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!

share|improve this answer
    
I'm still surprised it took him 10 lines to add two numbers. –  Kevin Aug 1 '11 at 22:42
add comment

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.

share|improve this answer
    
And I'd be very leery of a C++ developer who used atoi() in such a way. That would suggest a C guy who knew some C++, not a C++ guy. –  David Thornley Aug 1 '11 at 17:03
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.