No, I mean it literally, as in can't do do a loop/if/assignment level operation. ("Write a function that returns the sum of the two largest numbers in an array" is the literal question I would ask that the majority of candidates -- all with years of experience doing software dev -- were unable to answer.)

They simply flat-out could not program. Full stop.

And if I did this in your interview, how would you feel about that?

    List<int> blah = new List<int> { 3, 8, 2, 1, 5, 9, 0, 12, 14 };
    // pretend I don't know the numbers :)

    blah.Sort();
    blah.Reverse();

    return blah[0] + blah[1];

Congratulations, you are now better than 2/3 of applicants I saw.

I'd follow up by asking whether there's another way you could have done this (the obvious loop and store method); if you didn't come up with it, I'd explain it to you, paying attention to how well you seemed to understand it. I'd go on to ask about what characteristics make one of those solutions better than the other, hoping you'll mention the performance characteristics of sort vs. simple iteration, and maybe also the maintainability/extensibility of the two methods.

And then I'd move on to my next question with cautious hope.

2/3 is generous. That implementation probably puts you in the top-90% of candidates that make it to a technical interview.

You mean the top 10%?

Another way to do it, assuming that the list can be mutated: find the largest number in the array, store it somewhere and remove it from the list. Do this a second time. Then add those two numbers.

It evades sorting the array, but you have to search it twice.

    a = [7, 9, 2, 8]
    
    highest = max(a)
    a.remove(highest)

    nexthighest = max(a)
    a.remove(nexthighest)

    print highest + nexthighest    

Optimisation: just scan the array once, and keep track of the two highest numbers.

    a = [7, 9, 2, 8]

    highest = None
    nexthighest = None

    for item in a:
        if not highest or item > highest:
            highest = item
        elif not nexthighest or item > nexthighest:
            nexthighest = item

    print highest + nexthighest

Fyi, there's a mistake in your second solution - consider a strictly increasing list.

Thanks for the tip!

    a = [2, 7, 8, 9]

    highest = nexthighest = None

    for item in a:
        if not highest:
            highest = item
        elif item > highest:
            nexthighest = highest    
            highest = item
        elif not nexthighest:
            nexthighest = item
        elif item > nexthighest:
            nexthighest = item

    print highest + nexthighest

And my beef is with the huge variety of interview techniques (sorry if it felt like I was calling you out there, I wasn't trying to) and that candidates have to prepare for a whole range of them. One answer gets a spectrum of responses and there is rarely any good answers for everyone. (Maybe I'm just stating the obvious here)

At least it works. Since you're able to give that in not even a minute, the interviewer has plenty of time to go further:

- Do you see any problem with your method ?

- If yes (you should say yes), how can you improve it ?

In other words: the real point of asking technical questions is not can you code but much more can you engineer a solution to a problem.

As an interviewer, I would have hoped for this:

    int sum = blah.OrderByDescending(x => x).Take(2).Sum();

Ha, that's basically what I just did with the Haskell version:

   Prelude> import Data.List
   Prelude Data.List> sum . take 2 . reverse . sort $ [1..5]
   9

I can do that in Python ;-)

    a = [7, 9, 2, 8] 
    print sum(sorted(a)[-2:])

Oh cool, slices don't return index errors:

    >>> print sum(sorted([])[-2:])
    0

Reading the original problem, "Write a function that returns the sum of the two largest numbers in an array", I took the liberty of assuming that the input list would always contain at least two items.

Clearly your Reverse() is unnecessary and inefficient when you can just do

   return blah[blah.size()-1] + blah[blah.size()-2];

I totally would not hire you. :P

No true Scotsman would question my definition of a "real programmer."

>Compiling main() with an assignment and a print is technically programming, but has extremely little to do with what is actually being developed in real products. You aren't going to give anyone a job if this is all they can do.

I do not think that is even necessary to being a programmer. It is possible that someone has always worked on projects with an already existing build system, and only knew to run "make" (or equivalent) to compile. These people could be competent at actually programming, but not know how to compile something outside of an existing build system.

You're missing one key thing - by the time we see the candidate they've given us a resume that says that they can and have programmed some actual things in some actual langauges. How do you explain their inability to then do some trivial thing (more trivial than fizzbuzz even) in the language that they've already claimed skill in?

I could be wrong, but these simple tasks seem to help distinguish "hung out on a team that did those things" or even "has been stuck in meetings 38 hours/week for the last 5 years and is startlingly good at powerpoint", when those are not what we're looking for.