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

31–40 of 49 posts

Re: Why the new guy can't code

#31

Post by davetong »

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 sorts of questions only tell you one thing though, that the person you are interviewing has spent a lot of hours in front of the one programming language. I personally do not rate these types of questions for an interview because anyone can learn syntax, data structures and best ways to implement language-dependent code.

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.

Misconception 3: degrees don't tell anything

There is a lot of "show us your projects" being thrown around. While this is a fair call, one should not dismiss the degree. Simply being, that the degree is a project. It means that the candidate has had to spend three to five years juggling multiple subjects (read as 'projects'), while working part-time (read as 'projects') and managing their social life (read as 'drinking beer' and 'tuning hot people'). A degree is a testament of the students ability to see something through from start to finish... it's an example of their dedication.

Misconception 4: degrees aren't teaching students how to code, so how are they expected to code

Again, this is a fallacy. The degree is teaching students how to collaborate through group projects. How to work unsupervised and be resourceful while working unsupervised. It teaches the fundamentals so they can pick up any programming language (just another tool) and apply the fundamentals they have been taught.

I strongly agree with @marcamillion's statement about "developers being better over time". This is why I disagree with Misconception 1, as all this is doing is showing how much experience the interviewer has with the language they are quizzing someone on.

Overall, give the new coder a break. They most likely got hired because they: - fit into the work culture - possess strong problem solving abilities - can work unsupervised - can work within a team environment - have imagination

And if the new guy is asking you a question, it's because they're wanting to learn, so respect that as they're trying to be awesome like you.

Disclaimer: Sometimes people make mistakes though, and a dud ends up being 'that' coder that can't code ;)

Re: Why the new guy can't code

#32

Post by wan23 »

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.

Re: Why the new guy can't code

#33

Post by ericbrunstad »

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.

And incur a cost proportional to 1,000,000 when you could incur a cost proportional to 20? I strongly disagree.

Re: Why the new guy can't code

#34

Post by ericbrunstad »

shaggyfrog wrote: post #26
nupark2 wrote: post #18

Earlier quoted context omitted.

As a hiring manager, my 'bias' against CS degrees, such as it exists, is that they don't actually tell me much of anything. Individuals have the capability to learn "compiler construction, functional programming the theory behind OO programming, prolog, how databases actually work", et al, independently of a degree, and yet, having that degree doesn't seem to actually guarantee that a potential hire understands any o…

Then you shouldn't have a bias against CS degrees; you should simply see them as zero-information attributes. (Which, I think, is correct in a general sense: a resume should get a candidate to an interview, not earn the job on its own.)

Well, there's no way someone could get a degree in CS from Carnegie Mellon without learning quite a bit. For instance, they must take 15-213, which is an excellent systems programming course (students learn about virtual memory, UNIX programming, properties of integers that are useful for handling overflow, etc).

Re: Why the new guy can't code

#35

Post by carussell »

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.

Regarding the last bit, how hard can I say "wtf"? Writing readable code and a writing a binary search are hardly at odds; they're orthogonal.

Regarding the first bit, there are lots of situations where the algorithm needed is a binary search, but for which your generic search-a-sorted-array won't do. For almost any non-trivial need, really...

Re: Why the new guy can't code

#36

Post by [deleted] »

nupark2 wrote: post #18
tomjen3 wrote: post #14

Earlier quoted context omitted.

No you won't. Academia thought me how to be a better programmer, about compiler construction, functional programming the theory behind OO programming, prolog, how databases actually work (IE not just some random subset of the sql language) how 3D graphics work (including how to compute light and how you go from a mesh of triangles to an image on a screen), Haskell, SVN and how to work on large projects with others (i…

As a hiring manager, my 'bias' against CS degrees, such as it exists, is that they don't actually tell me much of anything. Individuals have the capability to learn "compiler construction, functional programming the theory behind OO programming, prolog, how databases actually work", et al, independently of a degree, and yet, having that degree doesn't seem to actually guarantee that a potential hire understands any o…

[deleted]

Re: Why the new guy can't code

#37

Post by xsmasher »

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…

1: I want to see if someone knows language foo, and I want to know that they can implement algorithms and data structures. In short I want to see that they've spent a lot of hours on this platform.

Of course anyone with the hacker nature can learn any language, but that doesn't mean I want them to learn it on the clock. When I want an electrician I call an electrician, not a smart friend who I think can learn it.

2: I don't ask brain teasers because someone who has heard the question before has a tremendous advantage over someone who has not. That's not what I want to test for.

RE: 3 and 4, I don't much care as long as they pass #1.

Re: Why the new guy can't code

#38

Post by Dove »

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.

I once needed to find several elements in a ~500,000 object array several times a second. And the criterion by which I could judge whether they were the objects I wanted was expensive to compute, and often complex -- involving looking at neighboring or seemingly unrelated objects, or the general program state. And in special cases, I needed to return a filtered slice of the array.

There wasn't a library function to do what I needed, and that's a pretty serious understatement. I wrote my own libraries for the job, and still wound up writing one flavor or another of tweaked binary search about once a week.

Re: Why the new guy can't code

#39

Post by billswift »

apl wrote: post #6

> Smart and Gets Things Done. (Academia is teeming with > people who are the former but not the latter. Tired stereotype. Academics at the top of their game know how to get shit done, very much so even. But it's different shit.

To the extent that there is a problem here, it's because academia optimizes for getting different things done than businesses do. It takes even smart people a little while to make the psychological switch-over, the more so since most of them, and their bosses, don't realize the need. It is just another kind of cost for new hires, like their learning your technology stack and coding conventions.

Re: Why the new guy can't code

#40

Post by jallmann »

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.

You have no idea what I was doing (or even what language I was using), so don't presume.

I benchmarked my binary search, a hand-rolled linear search, and the search function that was built into the container I was using.

  binary 0.019003 ms
  linear 3.402408 ms
  builtin 9.007484 ms
> it's usually better to do a linear search for the sake of having more readable code

For small inputs, maybe. But a binary search takes only marginally more time to test and write than a hand-rolled linear search. And anyone halfway competent should be able to recognize one when reading code. When you have more than a dozen elements or so, a linear search is simply Doing It Wrong.

Post reply on HN