>simply flat-out can't program

This phrase is seriously abused and it needs to stop because our field has anything but standardized and well-known competencies that we expect people to know before they commit anything.

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. As soon as you get out of the absolute basics (IMO, if/for/assignment/operators), your demands are simply arbitrary with what you think will indicate that someone can do the job.

You might only consider someone who can pass FizzBuzz as a 'real programmer'. Someone else might only consider someone who knows and can implement advanced patterns and quickly absorb an unfamiliar API as a 'real programmer'. Programming-Genius-32 might only think someone's a 'real programmer' when he can implement every algorithm from MIT's curriculum from scratch.

And if I had to make a wild guess, I would guess that people create their own standards of what a 'real programmer' is based on things they have already solved or things they read from someone else. Then they go make hiring decisions based on this standard. It is very likely that someone can look down on many of us and call us fake programmers because they're just so much further ahead.

Convincing someone that you are a real programmer of a certain skill level is a social exercise, not a technical one.

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.

He also make the assumption that secretly terrible people don't exist in other fields. In my experience there is a small set of people in every discipline that are just leeches who contribute almost nothing but somehow stay employed. There are plenty of crappy lawyers still practicing, for example.

I see little value value in being purposefully hostile, but I also see little value in this hand-holding, spoon-feed me approach he seems to want. We should encourage people and mentor junior team members, but I am not interested in extending "love" to some person I just met.

Where I work, we have a two-step process.

The first is called "Rob's Pairing Interview", or RPI. We go through a very simple problem. Takes 30-60 minutes. Nothing fancy is required, nobody is getting an algo pop quiz. Just a basic smoke test to see if you have, at some point in your life, programmed at all.

The second is pairing interviews. You come in and pair with us. At work. On real software.

When I got hired I kept waiting for the shoe to drop. It was just like the interview. Exactly like the interview.

The shoe never dropped. That's just ... how we work. The pairing session were a 1:1 example of daily life. And in a pairing situation there are no Secretly Terrible Engineers. And only a few Secretly Awesome Engineers, which is why we do it that way.

"can't program" is such a sweeping generalisation as to necessarily be null and void. I don't really think there is such a magic binary quality. Most everyone can learn programming and it's just a matter of patience and guidance. The only hopeless cases I've seen is folks who are poor coders but are convinced otherwise.

That's great, but if I'm hiring a person with ten years of experience whose resume is full of "senior developer" stuff, I don't think that either of us is interested in them doing an unpaid internship while we teach them the basics of programming.

I would be deeply suspicious if that person was in fact a terrible engineer. More likely than not they'd be in a wrong place, doing the wrong sort of job.

If you can't program fizzbuzz they you can't program.

Sure. Except that in real life things are rarely that clear-cut.

I've just gone through a rather prolonged search and hiring process, which involved hiring and then having to (regretfully) release some candidates (near the end, we were bringing them on as contractors so as not to create too many expectations). After dozens of interviews and resumes and a few attempts at hiring, we finally got a great candidate fit.

But here's the thing -- only a very few of those candidates actually were "flat-out" incapable of programming, and it was pretty easy to figure that out. Of the others, most of them were capable of programming, but not capable of developing, which seemed to be the dividing line.

Part of my interview consisted of data-modeling exercises (from workflow documentation) and slightly more-than-basic algorithm exercises (in which I wasn't looking for good code, so much as to understand how the candidate attacked the problems). I wasn't trying to bigfoot the candidates, but it was amazing how many couldn't work their way through relatively simple modeling or algorithm design problems at all.

And yet these were professional programmers. They had degrees, sometimes graduate degrees, from good universities; they had spent years in the field; they had solid references from good employers. I refuse to believe that so many practicing programmers could simply be incompetent and never raise any kind of concerns.

Which leads me to think that there's something wrong with our discipline. (I remember an old USENIX symposium where one of the talks was, "If computers had blood, they'd call us doctors." My reply at the time was, "If computers had blood, they'd call us serial killers.") If we built bridges, we'd assign a different engineer to each leg of the bridge, start at both sides simultaneously, never bother to check flood gauges or soil samples until halfway through the project, and try to swap out the cable suspension design two weeks after opening it to traffic.

In other words, we take perfectly capable programmers and turn them into useless cogs. Programmers who can't see the forest for the trees or the trees for the leaves. Who never are exposed to systems design problems, who use HashMap as the solution for every problem because we need that code yesterday and there's no time to discuss more elegant solutions (seriously, at least half of those candidates were obsessed with HashMap, for a problem where a hash table made no sense), who are shoved into a tiny chunk of the code of a massive enterprise monstrosity and expected to keep making changes and bugfixes until the code bears no resemblance to a reasonable solution to the problem.

Bad programmers who don't learn aren't the problem. Good programmers who don't teach are. Not brilliant programmers, not rock stars or code ninjas or whatever the fuck we're calling them this week, just good, solid programmers, the sort we say we can't find. If we don't give good programmers the time, space, and incentives to teach by praxis -- if the only way to be a good programmer is to bootstrap your way up -- what right do we have to complain?