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

How to Crack the Toughest Coding Interviews

gklst.tumblr.com

Post reply on HN
Print view View original

131–140 of 144 posts

Re: How to Crack the Toughest Coding Interviews

#131

Post by Evbn »

mrbgty wrote: post #50

Personally, I don't really get this type of interview. For one it sounds like they've pretty much standardized it for all developers with little insight into how a new candidate might fit into an existing team best. Also, it simply does not reflect in anyway what it will be like to work there or what it will be like to work with that person. One key reason is that the interviewer asks questions they already have the…

Actually at most big company jobs the programming tasks have well known solutions but need people to grind them out.

Re: How to Crack the Toughest Coding Interviews

#132

Post by Evbn »

barbs wrote: post #68

Has anyone read the book put out by the blog post author? I thought the post was well written, and would like to know if the book is worth getting as well...

Yegge's blog post and CLR textbook are all you need. For a more social version go read the Reddit subrddit on interview problems or read glassdoor.

Re: How to Crack the Toughest Coding Interviews

#133

Post by haberman »

seiko55 wrote: post #107
haberman wrote: post #17

> Given a cube with sides length n, write code to print all possible paths from the center to the surface. What is a path through a cube? This seems like some weird combination of graph theory and geometry.

you are a googler, right? i think we've seen your posts.

Yes (I don't keep this a secret, it's right on my userinfo page). How does that pertain to this thread?

Re: How to Crack the Toughest Coding Interviews

#134

Post by stcredzero »

dbecker wrote: post #113
stcredzero wrote: post #37

I think I've been a victim of ageism here in the SF bay area. One member of a group met me in person, and we had a positive experience during the coding interview. (I look young for my age.) I gave him some Python code that solved his problem, as well as a version optimized for common prefixes and another that gave the same tally by user as well as the total aggregate. Note I am not primarily a Python coder, and it's…

You say you are a victim of ageism, but I don't see much in this story to support that conclusion. The interviewer apparently thought you were cheating... or at the very least he was incompetent to recognize the quality of your code. But those are totally different from discriminating against you because of your age.

> You say you are a victim of ageism, but I don't see much in this story to support that conclusion.

There's a lot of information in tones of voice.

Re: How to Crack the Toughest Coding Interviews

#135

Post by theootz »

Evbn wrote: post #126
dspeyer wrote: post #115

Earlier quoted context omitted.

At Google, at least, we try to make up new questions frequently and retire old ones.

There aren't enough problem in the world for that to be possible, ignoring extremely superficial differences. It always comes down to exercises from CLR lightly dressed up.

Sorry, but what's CLR?

Re: How to Crack the Toughest Coding Interviews

#136

Post by Someone »

pjscott wrote: post #108
Someone wrote: post #72

Earlier quoted context omitted.

"I vaguely recall counting lattice paths in 3-space being a wickedly hard problem with no known polynomial time solution." I think you can easily write the recursion: p(x,y,z) = p(x-1,y,z) + p(x,y-1,z) + p(x,y,z-1) Leave out the term with x-1, y-1, or z-1 for the edge cases for x, y, and/or z equal to zero. With that in hand, it is easy to compute all values bottom up, starting with those where x+y+z = 0, 1, 2, etc.…

You're assuming that all movement must be in one of three directions, but in general, you can go in six directions -- forward or backward along the x, y, and z axes. Your cubic-time DP algorithm doesn't solve the self-avoiding walk problem, which I think is what jsolson vagely recalls. http://en.wikipedia.org/wiki/Self-avoiding_walk

I wasn't assuming, I was following what the OP wrote: "by going only up or right one point with each move (that is, each move is either (0,1) or (1,0)))" for 3D.

Counting self-avoiding walks is hard in 2D, too (http://oeis.org/A007764)

Re: How to Crack the Toughest Coding Interviews

#137

Post by cagey »

theootz wrote: post #135
Evbn wrote: post #126

Earlier quoted context omitted.

There aren't enough problem in the world for that to be possible, ignoring extremely superficial differences. It always comes down to exercises from CLR lightly dressed up.

Sorry, but what's CLR?

http://en.wikipedia.org/wiki/Introduction_to_Algorithms

Re: How to Crack the Toughest Coding Interviews

#138

Post by glaak »

DannyBee wrote: post #86
incision wrote: post #44

Earlier quoted context omitted.

That doesn't seem to be a point missed so much as one that's obvious and generally unnecessary to state fully qualified descriptions of everything in casual conversation.

Except that when you are using it as marketing in a book, there are very important distinctions. Lies of omission and all that.

A lie of omission would apply if you state a selection of true facts and ignore other ones so as to make yourself look better than you are.

In this case, I'm stating that I was a hiring committee member and not saying that I attended regularly, when I in fact did. This is not a lie of omission. At worst, you could accuse me of not offering additional qualifications.

Re: How to Crack the Toughest Coding Interviews

#139

Post by planckscnst »

monksy wrote: post #111
tjdetwiler wrote: post #90

Earlier quoted context omitted.

I've been in interviews where I felt like the interviewer went a little power-hungry with the situation. For example: Interviewer: "How you implement this calculator program?" Me: "Well I would try to read a number...." Interviewer: "HA! You cannot assume the type of input" Me "Okay, fair enough... does the input reflect a valid math expression?" Interviewer: "Of course, why would you ask such a question." In the mom…

I've been on interviews like that. Its a double edged sword. if you assume the worst about the input in the first place you're screwed. If you don't they'll bring it up later.

Sounds like a good solution would be to think about it while you create your solution, and when the bring it up, say somethint to the effect of "Yeah, I thought of that while I was working on it; you'd just do x and it's fixed."

Re: How to Crack the Toughest Coding Interviews

#140

Post by glaak »

nandemo wrote: post #71
glaak wrote: post #62

Earlier quoted context omitted.

You also did not wear a pink and blue striped hat, and did not get an offer. And yet, you seem to not connect your failure to wear a pink and blue striped hat with your failure to get an offer. I'd suggest you read the section in the article about how you're evaluated. Yes, how optimal your solution is matters -- of course it does. This doesn't mean that you have to get an optimal answer though. You have to do better…

> You also did not wear a pink and blue striped hat, and did not get an offer. I don't understand the point of this quibbling. Say I was asked 30 questions; I missed 3 of them and didn't get hired. It's a reasonable to assume that these 3 questions were considered important in the general assessment. > You have to do better than the majority of candidates (maybe ~80% of candidates). I know, I said I read your book. ;…

"Say I was asked 30 questions; I missed 3 of them and didn't get hired. It's a reasonable to assume that these 3 questions were considered important in the general assessment."

That would be true if those answers were assess on a strictly correct / incorrect basis AND those were the only things you were assessed on. Neither of those are true though in this case.

It's very possible that the questions where you didn't get an optimal answer you actually did very well on. And that there are other questions where you got the optimal answer, but it took you too long or you made too many mistakes in coding. Or you just came off as arrogant. Who knows?

I've seen many many candidates make similar assumptions to yours -- thinking they bombed specific interviews, when in fact they did very well on those. You might be correct about why you got rejected. But it's even more likely that you're wrong.

But this is absolutely true: getting the optimal solution in all interviews is not a necessary and sufficient condition.

Post reply on HN