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

81–90 of 144 posts

Re: How to Crack the Toughest Coding Interviews

#81

Post by jhartmann »

haberman wrote: post #75
jhartmann wrote: post #38

Earlier quoted context omitted.

Just my two cents, Well hash tables might be O(1), but depending on the circumstance they are used in, how they handle collisions, implementation details and the quality of the hashing algorithm they can see real world performance that is not O(1). Inserting into a hash table can cause the hash table to expand, if the hash table is too small you will get collisions, etc. etc. Some choices of hash functions are actual…

> Some choices of hash functions are actual O(n) instead of O(1) I think you're getting your n's confused. O(n) in the context of a collection applies to the size of the collection, not the size of the keys. Nearly all hash functions for strings are O(n) in the size of the string. This doesn't mean the hash table is O(n) for lookups.

My point is the whole process needs to be taken into consideration when talking about performance and runtime complexity. If you just use the address of an object for the hash, that has a implication to performance. If you choose a cryptographic function, that has another implication. If you use something like cityhash, that has yet another.

If you use rehashing or a linked list to handle collisions that has another impact on the performance depending on what is going on.

If you choose to auto grow the hash table upon a certain number of collisions, this is another thing you have to worry about.

The process of lookup might use a precalculated cache of the hash code calculation if it is expensive and sacrifice some memory for this storage.

My point of all these examples is that the simple runtime of the collection isn't the whole story and lots of crap can happen under the covers. We stand on the shoulders of giants, but we have to know what weaknesses and strengths we are exploiting. While just picking the right data (or wrong) structure makes a huge impact, you need a lifetime of experience to really know what matters, and what the trade off of one or another is in a given scenario. Hard to test for that intuition and I always like people that interview with me that start talking about these sorts of issues.

Re: How to Crack the Toughest Coding Interviews

#82

Post by [deleted] »

jsnk wrote: post #49
glaak wrote: post #21

Earlier quoted context omitted.

Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?

I am not saying that programmers should not be validated. Interview questions that are like IQ tests that depend heavily on single spark of inspiration are poor validators of determining productive programmers.

[deleted]

Re: How to Crack the Toughest Coding Interviews

#83

Post by drivebyacct2 »

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. ;…

You weren't just asked 30 questions. You were asked 30 questions and evaluated on dozens of other non-answer based factors.

Imagine: I walk in, get 27/30 and then proceed to be a sexist bigot who says I refuse to work on a team with gays or women and I decide to start claiming that you have to get 100% to get hired.

I'm not saying you did something like that, but you're just automatically assuming that that question was the pinnacle of your rejection and not the other things listed.

I mean, unless you've been implicitly implying that you're a perfect interviewer minus the 3/30 you missed...

Re: How to Crack the Toughest Coding Interviews

#84

Post by jasonlotito »

glaak wrote: post #21
jsnk wrote: post #13

I feel like developer interviews are a cover for conducting an IQ test in a manner that is politically passable. And only people like developers would put up with being tested like lab mice in this manner for a job.

Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?

Of the 4, only one is asked to do what they do during the interview. Event writers submit existing copy. Or at the very least, prepare it ahead of time before submitting it. Actors auditioning know what they are auditioning for before hand. They can prepare.

Programmers, however, must take a test. It's not an interview, it's a test. Pass or fail (regardless of what people say), it's a test. It's a test of which you have little preparation for. You hope that what they are looking for is what you can provide. What they are asking for is what they will test for (this is fairly often not the case).

Re: How to Crack the Toughest Coding Interviews

#85

Post by wting »

I'm kind of surprised at some of the negative comments people have towards these styles of interviews.

I'm a current student still going through the interview process with Seattle / SV / Austin companies (big and small).

Every interview is the same:

- review resume

- 0-2 behavioral questions

- 1-3 technical questions covering design, data structures, algorithms, sometimes language specific (usually pointers)

Here are two recent questions asked of me this past week:

1. How would you detect the largest sub array (i.e. max sum of adjacent numbers) given an example array:

[ -1, 5, 2, -4, 6, 3, 9]

2. Given N cubes painted 1-6 sides (duplicate colors on a single cube is possible), what's the largest stack you can build such that all faces on each side are the same color? The stack is 1 cube wide and deep, solve for height.

Maybe wherever you're employed / looking for a job doesn't ask these type of questions. Congrats. However it doesn't change the fact that these questions are the norm for top tier US tech companies, and a quick glance at GlassDoor.com will corroborate.

Their effectiveness (or lack thereof) is up to the hiring companies to decide. Seriously, hot companies get flooded with applications (I believe Google gets >100k annually). They don't have time to sit down with you and pair program for an entire day, especially as a 1st or 2nd round screening.

Re: How to Crack the Toughest Coding Interviews

#86

Post by DannyBee »

incision wrote: post #44
DannyBee wrote: post #25

Earlier quoted context omitted.

I'm on 3 of our hiring committees, and i've been at google for over 6 years. It hasn't been invite only for as long i've been here, AFAIK. Either that, or I was secretly invited! It is irrelevant whether it's an honor, but as to whether it gives you insight, you are generally right but you did miss an important point: The vast majority of people who are "members" of a given hiring committee often don't show up every…

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.

Re: How to Crack the Toughest Coding Interviews

#87

Post by robrenaud »

nandemo wrote: post #18

I got that book. While the questions and answers are useful, in my experience this book alone is nowhere near enough to get prepared for a Google interview (not that the author claims that). I studied CLRS's Introduction to Algorithms and a couple of other books for about 2 months. Even then I could not answer the hardest questions during the onsite interview. And if you cannot come up with an optimal algorithm for a…

I interview for Google.

I gave my question to an algorithms professor and he didn't get the optimal answer.

Needless to say, I don't expect candidates to get the optimal answer.

Re: How to Crack the Toughest Coding Interviews

#88

Post by haberman »

jhartmann wrote: post #81
haberman wrote: post #75

Earlier quoted context omitted.

> Some choices of hash functions are actual O(n) instead of O(1) I think you're getting your n's confused. O(n) in the context of a collection applies to the size of the collection, not the size of the keys. Nearly all hash functions for strings are O(n) in the size of the string. This doesn't mean the hash table is O(n) for lookups.

My point is the whole process needs to be taken into consideration when talking about performance and runtime complexity. If you just use the address of an object for the hash, that has a implication to performance. If you choose a cryptographic function, that has another implication. If you use something like cityhash, that has yet another. If you use rehashing or a linked list to handle collisions that has another…

I understand and agree with your point. I was just making one small correction.

Re: How to Crack the Toughest Coding Interviews

#89

Post by joezydeco »

ionwake wrote: post #19

Am in the only 30 year old coder here, who earns around £300 a day coding, but would fucking die in one of these interviews?

Not by a long shot. I'd love to work at a place like Google and would probably do just fine, but I'm 100% certain I'd never make it through the gauntlet. And I've been coding 25 years longer than the kids doing the interviewing.

Re: How to Crack the Toughest Coding Interviews

#90

Post by tjdetwiler »

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…

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 moment I really felt like the (relatively young) interviewer way trying to lead me in the wrong direction, and then when I realized I needed to make no assumptions, criticized me for trying to clarify other parts of the problem.

I didn't get that job, but after that experience I was hardly disappointed.

Post reply on HN