Hacker News new | comments | show | ask | jobs | submit login

This is an illuminating example of how different assumptions lead to different definitions of what makes good code. I'm convinced that this is one reason why there is this belief that 80% of programmers are incompetent. It's not there aren't truly incompetent devs out there, but it's also easy to assume someone is incompetent just because they were working from different constraints and experiences than you, and the way they did things just isn't immediately apparent.



Having recently lead a round of interviewing, I wish that I could be convinced that your kinder interpretation was true.

But under moderate questioning, most interviewees don't hold up well.


I have often been complemented on how well I code, but I don't think I stand up to many peoples moderate questioning all that well. I think this seems from looking for a clean solution to most problems vs. the perfect or most obvious solution. The vast majority of the time I avoid dealing with the minutia that many people feel is necessary.

For example, I once had school project where we where supposed to implement some fairly simple math function in x86 assembler. My first question in class was what instruction set could we use? (x86 Pentium I) So we can use the floating point unit? (Yep) So while everyone else was implementing floating point functions by hand I simply used the built in floating point unit. I still remember handing in 4 pages of clean code and asked why this was a major project until people started asking for more time to fix their buggy 40+ page programs even though I had told several people what I thought was an easier solution. I even told people that I finished the thing in a few hours while watching TV but they forged ahead I guess thought the sunk cost fallacy or something. I mean sure the way you do arbitrary exponentiation is a little funky, but that's better than doing it by hand.

Oven and over I see the same things. Last week someone was demoing his custom cashing solution created by hand and I was like A this does not fit our architecture and B why did you spend the time on this? Sure it's 'fun' but why bother?

At the same time in interviews I have been asked minutia about the java object system etc, and all I can think of is if this matters your doing something horribly wrong.


Hmm, I interviewed recently at a pretty well-known startup and crashed and burned because I didn't know uncommon HTTP codes and request/response headers off the top of my head. I aced most of the rest of the questions, and I think I got along with everyone pretty nicely.

I understand that the interviewer probably works with them every day and has them memorized, but really that's something I could have looked up in 10 seconds. I don't think people should be penalized for following Einstein's "never memorize what you can easily look up in a book" philosophy.


It's a pity you didn't reply to that request with:

422 Unprocessable Entity - The request was well-formed but was unable to be followed due to semantic errors.


In sport psychology, Hull's Drive Theory predicts that introverts perform poorly under pressure. The physiological response from a job interview is as about as close to the pressure of taking the last shot in a basketball game as I've ever experienced, and I've experienced both. Couple this with the fact that most programmers are introverts, and I'm always amazed at the credulity with which people accept these fizzbuzz claims. Is it more likely that 90 percent of experienced programmers can't program, or that something about the evaluation process is broken? I can say that I would never take a programming job where it was critical to do well under performance anxiety inducing conditions.


Or, it could be that 90% of people applying for programing jobs can't program.


Which does not contradict an assertion that 90% of employed programmers can program.


The evidence overwhelmingly suggests that interviews and interviewers are unsuitable for the task they are used for (i.e. selecting the best candidate). Assuming this applies to programming interviews as well, then your opinions of these programmers (both good and bad) could be just as incorrect as the Israeli army training example given by the psychologist in this article:

"Daniel Kahneman: How cognitive illusions blind us to reason" http://www.guardian.co.uk/science/2011/oct/30/daniel-kahnema...

"Because our impressions of how well each soldier had performed were generally coherent and clear, our formal predictions were just as definite. We rarely experienced doubts or formed conflicting impressions. We were quite willing to declare: "This one will never make it," "That fellow is mediocre, but he should do OK," or "He will be a star." We felt no need to question our forecasts, moderate them, or equivocate. If challenged, however, we were prepared to admit: "But of course anything could happen."

We were willing to make that admission because, despite our definite impressions about individual candidates, we knew with certainty that our forecasts were largely useless. The evidence was overwhelming. Every few months we had a feedback session in which we learned how the cadets were doing at the officer training school and could compare our assessments against the opinions of commanders who had been monitoring them for some time. The story was always the same: our ability to predict performance at the school was negligible. Our forecasts were not much better than blind guesses."

Another recent article was about the author was discussed here:

"The King of Human Error" http://www.vanityfair.com/business/features/2011/12/michael-...

http://news.ycombinator.com/item?id=3219240


Interviewing is an inherently flawed way of determining skill. This manifests itself in numerous ways; one of which is our inability to properly extrapolate information from an interview: if a good programmer needs to search online for information to solve a problem about once each 8-hour day, then during the interview, the good programmer may ask for help once. But if they do that, then the interviewer sees that they need to ask for help once every hour. Alternatively, if they don't ask for help, the interviewer might be led to believe that they don't use tools afforded to them. Because one cannot ask for help 1/8th of a time, the interviewer has a negative impression of the candidate regardless of the choice the interviewee makes. This sort of lose-lose for the interviewer due to extrapolation can happen for many different facets: anything that is necessary, but only in moderation.

Interviews are a very flawed system for identifying skill.


Maybe I'm actually a terrible coder and don't know it, but I search through documentation way more than once a day. Saves a ton of time.

I always thought a great interview would be something like "Here's a dev machine, make me an app that does this. I'll be back in an hour." (coding test), followed by a code review and "Let's go to happy hour." (personality test).


An interview where the interviewer favors people who look at documentation less often is already deeply flawed. In my experience, the best programmers spend the most time reading documentation, and the worst programmers are the ones who never read docs and never ask questions.

I would never want to hire or work with someone who read docs only once a day.


Yes, totally. Once per day is a ridiculous figure. Let's say "less than one time per interview-difficulty problem", and the numbers still hold.


Do I understand you correctly that you're now saying that multiple times per day is acceptable, but d/i times per day, where d is the length of the day and i is the length of the interview, is unacceptable?

This is still nuts. There is literally no amount of documentation checking that is too much, as long as the guy produces results.


It's a good point, and one I expect most people have heard quite a few times. However, interviewees probably either don't have a job or aren't doing well with the one they have. As such, I suspect you're likely to get a larger % of the mediocre than you might see elsewhere in the industry.


I don't know how to estimate this skew, but it's probably substantial, particularly in this industry.

I'm fairly introverted and a competent developer; I've only done two interviews in my 13-year-so-far professional career writing code.

The first was for my first job after college. I only called one company in the city where I planned to move; they seemed good, so I got a job there.

The only reason for the second interview -- last year -- was because I moved to Europe, and decided after 4 years that working on the projects & jobs I could get from my contacts in the US wasn't great, so I'd have to (ugh) meet some new people.

I suspect there are plenty of competent developers who have experiences like mine. We'd rather go work with people we already know, the folks on the hiring side would rather grab someone proven, vs. (on both sides) interviewing with strangers and hoping for the best.


> it's also easy to assume someone is incompetent just because they were working from different constraints and experiences than you, and the way they did things just isn't immediately apparent.

I don't know if it's common, but I tend to judge competence by the bottom line: does it work? is it supportable? what was the cost of getting there?

If it doesn't work, or does work but cannot be supported/modified, and cost a lot, it is a product of incompetence. Possibly the manager's, and not the tech guys.

I've never heard anyone refer to djb as incompetent. Some people dislike his coding style, but I haven't heard any criticism about it that is not about style. And yet, he's working with different constraints and experiences than everyone else. And things are often not immediately apparent.


I thought people generally assumed that 80% of programmers are incompetent because 80% of programmers can't perform a simple task like e.g. Fizz Buzz without an enormous amount of time and assistance.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: