Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the new guy can't code

techcrunch.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Why the new guy can't code

#41

Post by mnutt »

marcamillion wrote: post #29
mnutt wrote: post #28

Earlier quoted context omitted.

Bad development practices can and do kill companies, although in those cases the cause of death is usually considered "failed to innovate" or something similar. Accumulate enough technical debt and you'll be unable to move very quickly for fear of breaking things. After code starts breaking expect to add processes on top of processes, which may stop the breakage but only slow things down even further. That's not to s…

As I asked in my response, Please provide examples. Bad coding does not mean 'failed to innovate'. Digg.com innovated with the Digg button, but according to Kevin they had a bunch of 'bad coders' doing 'bad coding'.

Bad coding does not mean "failed to innovate" but bad coding will certainly lead to failure to innovate.

There are many, many companies that fall into that category but if you want a direct example of bad coding -> failure then look at Friendster:

"But the board also lost sight of the task at hand, according to Kent Lindstrom, an early investor in Friendster and one of its first employees. As Friendster became more popular, its overwhelmed Web site became slower. Things would become so bad that a Friendster Web page took as long as 40 seconds to download. Yet, from where Mr. Lindstrom sat, technical difficulties proved too pedestrian for a board of this pedigree."

http://www.nytimes.com/2006/10/15/business/yourmoney/15frien...

There is hardly ever a single reason why a company fails, but site performance and the inability/unwillingness to address it played a large part in Friendster's decline.

Re: Why the new guy can't code

#42

Post by tzs »

davetong wrote: post #31

The following are some of the main misconceptions of what's floating around between the blog, TC comments and HN comments. Misconception 1: answering programming questions tells if the developer is awesome No it doesn't. When an interviewer asks you a programming language-specific question, they are wanting to know how awesome you are at the language to see if you can hit the ground running on your first day. These s…

    Misconception 2: brain-teasers don't tell you anything

    This couldn't be more wrong... The reasons why an interviewer throws you
    a brain teaser or design question is to understand your thought logic
    and problem solving skills. While you talk through how you would solve
    your problem, they are assessing your communication skills, your process
    in solving a problem and also what knowledge you have as part of your
    experience.
The problem here is that a lot of the brain-teasers I've seen bandied about for interviews are the kind of problems where you either get them via an a-ha insight, or you don't get them at all. That's kind of what makes them good brain-teasers.

Re: Why the new guy can't code

#43

Post by marcamillion »

mnutt wrote: post #41
marcamillion wrote: post #29

Earlier quoted context omitted.

As I asked in my response, Please provide examples. Bad coding does not mean 'failed to innovate'. Digg.com innovated with the Digg button, but according to Kevin they had a bunch of 'bad coders' doing 'bad coding'.

Bad coding does not mean "failed to innovate" but bad coding will certainly lead to failure to innovate. There are many, many companies that fall into that category but if you want a direct example of bad coding -> failure then look at Friendster: "But the board also lost sight of the task at hand, according to Kent Lindstrom, an early investor in Friendster and one of its first employees. As Friendster became more p…

We really are arguing in circles here, because there could be many reasons for the slowness at Friendster. Didn't have to be bad coding. It could have been insufficient hardware. No matter how good the developers were, if their hardware can only manage X number of concurrent users with max optimizations, when growth brought in X^2, no amount of 'good development' would solve that issue.

However, I do agree with your point that there isn't just one thing that kills a company. That was my original point.

The TC article made it sound as if 'bad coders' killed companies. That is very delusional and it flatters developers too much. They are important, but not THAT important. That's my point.

Please don't flame me, as a developer myself, I am fully aware of where my expertise (and value-add) stops.

Re: Why the new guy can't code

#44

Post by lurker19 »

marcamillion wrote: post #25

I think this is one of the biggest misconceptions in our industry. Software developers, REALLLY, need to get over ourselves. Bad development practices and bad coding, has not (as far as I have ever heard) killed any company. I would like to be shown at least one example, where bad software killed the software company ? For crying out loud, Windows was 'bad' until Win 2000+. Don't forget WinME. The first version of Ne…

Capisce.

Re: Why the new guy can't code

#45

Post by spc476 »

wan23 wrote: post #32
jallmann wrote: post #12

I had to write a binary search a few weeks ago in the course of Real Work. I agree technical interviews aren't the only way of assessing a candidate's qualifications. Their open source projects, their writing on technical topics, and just having a geeky conversation with them are all good indicators of cluefulness. Jon Evans is clueless. No hire.

Collections.binarySearch() ? std::binary_search() ? Not saying I don't believe you, as there are times when it does come up but IMO even if you do have to write something search-like, it's usually better to do a linear search for the sake of having more readable code.

A project I worked on needed more than just the value (or lack of value) from a sorted array---it also needed the index where the item would have been had it been in the array. The standard binary search in the language I was using didn't return that information.

Sometimes, the requirements exceed what the standard stuff gives you.

Re: Why the new guy can't code

#46

Post by EGreg »

tomjen3 wrote: post #15
EGreg wrote: post #5

I have a completely different approach. I hire people who have worked with a particular technology or ecosystem for a while, because I think that builds the relevant experience and habits. If they are good at things similar to what we are doing, they should be able to pick it up and integrate quickly, and learn more stuff. And don't underestimate the value of good documentation. But of course, one prerequisite is abs…

>Besides interview questions, give an interview ASSIGNMENT. Meaning, before you are hired, you have to complete some task. This shows a) commitment to wanting to work here, and b) shows that you can sole the kinds of problems we had to face before. Are you hirering for Facebook? Because if not you will miss the developers who aren't desperate to work for anyone.

I'm not worried about random developers I'm going to miss. I'm worried about developers we'm going to be stuck with.

Re: Why the new guy can't code

#47

Post by FaceKicker »

tzs wrote: post #42
davetong wrote: post #31

The following are some of the main misconceptions of what's floating around between the blog, TC comments and HN comments. Misconception 1: answering programming questions tells if the developer is awesome No it doesn't. When an interviewer asks you a programming language-specific question, they are wanting to know how awesome you are at the language to see if you can hit the ground running on your first day. These s…

Misconception 2: brain-teasers don't tell you anything This couldn't be more wrong... The reasons why an interviewer throws you a brain teaser or design question is to understand your thought logic and problem solving skills. While you talk through how you would solve your problem, they are assessing your communication skills, your process in solving a problem and also what knowledge you have as part of your experien…

Yeah, I've never really understood how you can "talk through your thought process" for a question like "Why is a man-hole cover round?" It seems like you'd either come up with a reason or you wouldn't be able to come up with anything at all.

Perhaps you can say things like "Well, let's see...you need to be able to pick the man-hole cover up out of it's hole, then put it down somewhere, then maybe move it, ..." but I really think these types of ramblings are just stalling for time rather than an actual English narration of what I believe is an inexplicable thought process that would go into coming up with an actual answer to such a question.

Re: Why the new guy can't code

#48

Post by Confusion »

georgemcbay wrote: post #30

I agree with a lot of this article, but the slam on Charles Simonyi was fairly random to the point of making me wonder if the author is just ignorant of software development history or straight out trolling. I've never liked Hungarian Notation either, but that doesn't change the fact that during his years at Xerox PARC and Microsoft Simonyi exemplified "Smart and Gets Things Done".

The author also seems unaware that Joel Spolsky, who he speaks approvingly of otherwise, has explained/defended that using a sane version of Hungarian notation can make perfect sense.

Re: Why the new guy can't code

#49

Post by davetong »

FaceKicker wrote: post #47
tzs wrote: post #42

Earlier quoted context omitted.

Misconception 2: brain-teasers don't tell you anything This couldn't be more wrong... The reasons why an interviewer throws you a brain teaser or design question is to understand your thought logic and problem solving skills. While you talk through how you would solve your problem, they are assessing your communication skills, your process in solving a problem and also what knowledge you have as part of your experien…

Yeah, I've never really understood how you can "talk through your thought process" for a question like "Why is a man-hole cover round?" It seems like you'd either come up with a reason or you wouldn't be able to come up with anything at all. Perhaps you can say things like "Well, let's see...you need to be able to pick the man-hole cover up out of it's hole, then put it down somewhere, then maybe move it, ..." but I…

I'd hire you if you kept on going with your answer... you've shown the following traits already:

- ability to analyse the problem

- talk about possibilities, thus displaying communication skills

I have probably misled my comment by using the phrase "brain-teaser" when I really meant "design question".

Post reply on HN