Comment by FLUX-YOU | Hacker News Reader

Comment by FLUX-YOU | Hacker News Reader

Parent Full thread

>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];

As an interviewer, I would have hoped for this:

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

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.

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

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.

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)

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%?

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.

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.

Reply on news.ycombinator.com