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

Today's Coding Interview Game

shubharamani.com

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Today's Coding Interview Game

#41

Post by mavelikara »

My theory is that many other technical fields have high barriers of entry where a newcomer has to really prove her chops, usually with a certification exam, before being allowed to practice the profession; but once she starts, fellow professionals treat her with respect and take it as understood some minimum capability.

In programming, almost anyone can start on the job - but we play out the hazing ritual throughout entire careers. Every time a programmer has to change jobs, she has to face a barrage of pointless trivia questions from megalomaniacs. Of course, many of them then grumble that they can't find competent programmers.

Also, I think that the interviewer anti-loop that Steve Yegge mentions (http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...) is real.

Well, back when I was at Amazon, we did (and they undoubtedly still do) a LOT of soul-searching about this exact problem. We eventually concluded that every single employee E at Amazon has at least one "Interview Anti-Loop": a set of other employees S who would not hire E.

Re: Today's Coding Interview Game

#42

Post by mech4bg »

timcederman wrote: post #33
aplusbi wrote: post #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.…

I feel exactly the same. Don't try to make stuff up you don't know, do ask me questions, do just TRY, rather than noodling about and not saying or doing anything.

The thing that sucks is when the interviewer doesn't care about that, but instead cares about specific answers to their particular list of questions.

It can be astonishingly random who gets through an interview. Bizarre that just a few words can tip the balance.

Re: Today's Coding Interview Game

#43

Post by hc5 »

hackinthebochs wrote: post #32
nowarninglabel wrote: post #6

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…

I don't really understand this mentality. Is is really that hard to get rid of the charlatans that slip through after the fact? Just monitor them fairly closely (but secretly) for a couple of weeks. Have some sort of object measure of performance for that time period. If they don't pass muster, get rid of them. This seems like a better method than spending 6 months to fill a couple of positions.

Training and getting someone up to speed for a few weeks, then getting rid of them (if it doesn't work out) wastes more time and money than spending several months to fill the position with the right person. Laying people off for performance is hard to quantify, not to mention I certainly wouldn't want to be working for a company who is secretly monitoring new hires' performance.

Re: Today's Coding Interview Game

#44

Post by j_baker »

Evansbee wrote: post #37
j_baker wrote: post #35

Earlier quoted context omitted.

Unless I was hiring a professional whiteboard coder, I would find another method.

I believe that /this/ is short sighted. I do interviews, I care less about the right answer than I do about the problem solving approach. I interview electrical engineers and I make them do simple transistor problems. If someone gave up and said that they couldn't do it without some sort of SPICE program, I'd cut the interview pretty short. But if the fundamentals are there, even if they don't remember something stup…

My point is that a person's inability to code on a whiteboard has little to do with the value they can provide to the business. Some people just aren't good at it, and why should they be penalized for it? There are other ways to get programmers to write code in an interview, and a simple "Do you prefer to code on the whiteboard or on a computer?" can resolve this. It's not as though that's a huge burden on the business or the interviewer.

Re: Today's Coding Interview Game

#45

Post by weaksauce »

ssp wrote: post #40
rsl7 wrote: post #7

Earlier quoted context omitted.

Code on the whiteboard is counterproductive at best. Let's hook up your laptop to the projector so I can get a glimpse of how you interact with your computer. I learn more about you by seeing your relationship with your text editor, how you look up information you can't remember, etc. Not watching you sweat with a marker in your hand.

I learn more about you by seeing your relationship with your text editor Are you sure you are not just learning whether the candidate is superficially similar to you?

well a programmer that is coding a linked list in c/c++ probably(definitely) should know the pointer semantics. If they are looking that up then they should be a pass unless you are looking for a really junior programmer. Now if you are asking them to connect to a db and update a record with a stored procedure and they looked up the syntax for a db connection to a mysql database then you know they are fairly proficient at that type of coding but just forgot the exact syntax of a db connection because it's not something done every day whereas any c programmer worth their salt should know basic pointer rules.

Re: Today's Coding Interview Game

#46

Post by Natsu »

aristus wrote: post #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.…

> Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact.

You've just described how we ended up with many of our problems in the government, military, education & private industry all in one sentence.

A single upvote doesn't seem like enough.

Re: Today's Coding Interview Game

#48

Post by wtracy »

j_baker wrote: post #27
nowarninglabel wrote: post #6

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 you…

Given how hard it can be to fire people, I don't blame managers for being risk averse.

Re: Today's Coding Interview Game

#49

Post by [deleted] »

mavelikara wrote: post #41

My theory is that many other technical fields have high barriers of entry where a newcomer has to really prove her chops, usually with a certification exam, before being allowed to practice the profession; but once she starts, fellow professionals treat her with respect and take it as understood some minimum capability. In programming, almost anyone can start on the job - but we play out the hazing ritual throughout…

[deleted]

Re: Today's Coding Interview Game

#50

Post by angelbob »

blahedo wrote: post #34
sblom wrote: post #9

If you remember what a linked list is, how pointers (or references) work, and have written more than 10k real world lines of code in your favorite programming language, I would fully expect you to be able to write, not memorize, any of the linked list functions that you mention. I certainly understand your frustration, but I really don't think either the tone or the content of this blog post is going to help land a j…

But possibly not error-free the first time at a whiteboard. Talk about unrealistic conditions.

Sure. And a good interviewer should take that into account. I ask this kind of question ("write me code to reverse this linked list, re-using the existing nodes") quite frequently. I don't expect even experienced programmers to have memorized it, and it's (a bit) more interesting than it sounds.

While I do give mental brownie points for people who can just write it in one go, I don't consider it a non-starter if you can't. But if you can't get to the point of having written it, with prompting and help, in half an hour, that's a non-starter.

Post reply on HN