Why The New Guy Can’t Code

I recently read this article: Why The New Guy Can’t Code (the article is only the top 25% of the page, the rest is comments, don't be intimidated, it's not that long)

The gist of it is that many new hires can't program (as discussed in this older article: Coding Horror: Why Can't Programmers.. Program?, again that page is mostly comments).

Both articles blame the interview process: potential employees are given riddles (3 lights, 3 switches or 3 doors, 3 doormen type stuff) instead of technical interviews, which does not actually test a programmer's ability to program, so many new hires are only hired because they knew the answers to some common riddles. So the push is to bring back the technical interview and get away from the riddle interview introduced in the 1990s by Microsoft, then perpetuated by Google.

But the first article goes a step further, and makes this statement:

Quote:

---

So what should a real interview consist of? Let me offer a humble proposal: don’t interview anyone who hasn’t accomplished anything. Ever. Certificates and degrees are not accomplishments; I mean real-world projects with real-world users. There is no excuse for software developers who don’t have a site, app, or service they can point to and say, “I did this, all by myself!” in a world where Google App Engine and Amazon Web Services have free service tiers, and it costs all of $25 to register as an Android developer and publish an app on the Android Market.

---

I'm pretty on the fence about this statement. I do believe that you shouldn't hire somebody who has no interest in programming outside of school or work, but I don't think gaining "real-world users" is as easy to do as the article makes it seem. Or am I wrong? Maybe I haven't programmed a "real" enough application in my spare time?

What do you guys think?

I've always had a negative outlook regarding those interview questions that companies such as google, facebook, etc...are known for. In my opinion they analyze an applicant less than the typical interview questions in that their answers don't address an applicants drive, experience, skill set, or willingness to learn (in my opinion the first and last of which are a lot more difficult to asses, but are very important traits). One can argue they address things like creativity, and this I won't deny, but I personally wouldn't bet on creativity alone.

I've always preferred questions which do to some degree address many factors at once - more descriptive questions that rely on an applicants past experiences, which through both verbal and emotional responses seem to evoke a much better assessment of an applicant. Some examples of these might include 'describe a problem you wished (or had) to solve, and how you solved it using programming' or 'have you ever lost sleep over a problem, and if so what was it?'

As far as not hiring someone who hasn't accomplished something, I find that a bit extreme, but will be honest and say it definitely would come into play when comparing candidates

Quote:

---

Originally Posted by copeg

I've always preferred questions which do to some degree address many factors at once - more descriptive questions that rely on an applicants past experiences, which through both verbal and emotional responses seem to evoke a much better assessment of an applicant. Some examples of these might include 'describe a problem you wished (or had) to solve, and how you solved it using programming' or 'have you ever lost sleep over a problem, and if so what was it?'

---

I like those. During the interview for my current job, I was asked what my favorite Java class (as in the API, not in school) was. I like that too.

Quote:

---

Originally Posted by copeg

As far as not hiring someone who hasn't accomplished something, I find that a bit extreme, but will be honest and say it definitely would come into play when comparing candidates

---

True. A person who wrote and maintains a program that people actually use has more credibility than a person who hasn't. But setting it as the lowest bar seems like overkill- how many entry-level programmers have written something that people actually use?

Or again, maybe I'm asking the wrong question. Maybe I should be asking, why haven't more entry-level programmers written something that people actually use? Looks like I have a new goal...

At the place I use to work at, they asked me how I go about solving problems. There were some technical points, but they were more interested in my thought process. I think the intent of the questions major software companies ask follow along this line, but since they ask the same questions (or very similar questions), the concept becomes lost.

I don't know if it's prerequisite that someone has major prior experience, but that's a definite plus (seriously, how can someone go through learning how to program with out at least some experience?). Different places have very unique setups, so you're likely going to have to go through some training anyways. Personally I like the questions which are technical in nature, but also require you to do some problem solving on your own (i.e. write some code, debug some code, etc.).