Live data from Hacker News

Today's Coding Interview Game

shubharamani.com

21–30 of 127 posts

Re: Today's Coding Interview Game

#21

I wonder how he knows what they're downgrading him for? Most interview processes don't give the candidate any feedback - just "hire" or "no hire". From the other side, I certainly don't expect perfect code on a whiteboard, especially if they're typical mistakes that even experienced coders sometimes make.

> I wonder how he

_He_ is a she.

Re: Today's Coding Interview Game

#22

Earlier quoted context omitted.

I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?

I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple…

That's even legal syntax in C99.

Re: Today's Coding Interview Game

#23
post #4

Earlier quoted context omitted.

They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified. And then they complain that they can't hire developers. I don't think these types of interviews are well conceived. Human memory is extremely context dependent and a whiteboard/interview type situation doesn't establish the right context for someone who's accustomed to working alone wi…

I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?

Well I know that I've solved a few problems in my time: like developing a multi-threaded distributed object-oriented control system, implementing a JPEG2000 encoder, a convolutional neural net, as well as solving a number of debugging problems that escaped my colleagues.

I also know I failed miserably at a trivial coding task in an interview.

So I don't know. If I'm the only one who has that kind of problem, maybe my brain works differently from other people's.

Re: Today's Coding Interview Game

#24
post #5

Its because credentialism has permeated the software business recently. Credentialists love tests, its how they got their credentials, and if they don't keep believing in tests over real world performance, they will have to re-examine the true worth of their credentials.

It is the opposite.

Interviewers are coming to realize credentials, be they Microsoft certs or computer science degrees, are not great indicators of software engineering aptitude.

The more you believe in the accuracy of credentials, the less you would want to ask coding questions in an interview. Better to simply examine resumes for the appropriate certifications and then ask fit questions.

If on the other hand, you believe nothing but on the spot coding demonstrations can prove a candidates abilities, you would do exactly what these interviewers are doing. Perhaps these tests are not the optimal tests, but they sure beat credentialism.

Re: Today's Coding Interview Game

#25
I've interviewed a lot of programmers and I think there are many misconceptions about what an interviewer is looking for or expecting.

I don't expect you to be able to code quicksort from memory. I do expect you to be able to code quicksort given the spec for it.

Just because I point out an error doesn't mean I'm counting it against you. I'm pointing it out to see how you handle it.

I do expect you to ask questions. If you are unfamiliar with an algorithm or forget the details, ask. I may not give you the answer but I'll at least point you in the right direction.

I generally try to make this clear to candidates so that they don't get uncomfortable if I point out some problem, but a lot of interviewers don't, which can be hard on the interviewee. I doubt, however, that there are many who expect perfect code on a whiteboard.

It's as much about the process than the result.

Re: Today's Coding Interview Game

#26
I worry a lot about this. I don't think it's distrust so much as thoughtlessness.

From what I can tell, Google (and other companies) started using these kinds of questions as a way to cheaply filter sudden floods of applicants, not because this is the way to find the greatest geniuses of our time. Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact.

As the tactics of successful companies percolate through the rest of the industry, they take on a third unfortunate property: cargo-cult foolishness. Google asks binary search questions and they have great engineers. I want only the best engineers, therefore I will ask binary search questions. I don't know what else to do so I shall grade strictly on style points, because points are scientific, right?

Bleh. Put it another way: if there are a large number of productive creative people shut out by a culture of thoughtless interview checklisting, that's an opportunity for some smarter company to snap them up. Such a company would by necessity have an outlaw air about them. Who else would hire misfits? But gangs of talented misfits can be a powerful force.

Re: Today's Coding Interview Game

#27

Coding general solutions should be par for the course. I agree that some interviewers are coming up with contrived examples. But of the 6 data points I have now from hiring people, those who could code on the white board turned out to be good employees (4 of them) and those who could not turned out to be a vast waste of time (2 of them). As jconphoenix was alluding to, I would have rather ended up rejecting more of t…

This sounds like risk aversion to me. People place twice as much emphasis on avoiding loss than they place on gaining something equivalent (even though the end result is the same). If you look at it in this light, then of course the good ones weren't as good as the bad ones were bad. The end result is that you end up with employees who definitely don't suck, but aren't really great either because you spent all of your time avoiding bad programmers and not enough finding good ones.

Re: Today's Coding Interview Game

#28

Earlier quoted context omitted.

I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?

I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple…

What makes you think it was held against you? Most programmers can be kind of OCD about code and would want to point out that kind of error, whether they thought it was relevant to your abilities or not.

Re: Today's Coding Interview Game

#29
I feel bad for this lady, but there's a flaw in this logic (and with the logic of many commenters here).

Everyone assumes that the battle is between...

Person 1: -Great resume -Relevant work history -Strong sense of corporate citizenship -Can't code on white board

and Person 2: -Can code on whiteboard -Smokes crack in the bathroom

But the reality is, you're all interviewing for the same job! You're not getting the job, not because you can't whiteboard code, but because someone else has the same qualifications AND CAN whiteboard code.

Which would you choose?

Post reply on HN