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

What I've learned from 100s of interviews with candidates at top tech companies

observer.com

Post reply on HN
Print view View original

51–60 of 225 posts

Re: What I've learned from 100s of interviews with candidates at top tech companies

#51

Post by wayn3 »

gaylemcd wrote: post #29
meggar wrote: post #19

Earlier quoted context omitted.

CTCI is a great book. Is it acceptable to ask an interviewer for a different question? For example, if you're really bad at chess algorithms and you get the N-Queens question?

This is actually a really interesting point. (Context: In chess, a queen can move along a row, column, or diagonal to attack. The N Queens problem is to place N queens on an NxN chessboard such that no two queens can attack each other.) No one does poorly here because they are "bad at chess algorithms." They might do poorly because they think they're bad at chess algorithms. But this is not a "chess algorithm." It's…

Do you think it makes sense to ask interviewees to solve backtracking problems, given the fact that its mostly about already knowing the solution?

Someone who's never come in contact with backtracking won't be able to solve n queens "in time", unless they pull a mathematics stunt, but those who do know backtracking won't struggle much.

On a higher level - how much of an "already seen the algorithm" crapshot are tech interviews?

And given the fact that a lot of the problems in your book are trivial in higher level languages (reversing a string is only hard if you somehow don't know how to do pointers) - what's your opinion on trying to use Java on a whiteboard in 2017? Has python officially become synonymous with pseudocode?

Re: What I've learned from 100s of interviews with candidates at top tech companies

#52

Post by gaylemcd »

anjc wrote: post #34
michaelt wrote: post #18

Earlier quoted context omitted.

Unfortunately, nobody has any data on the job performance of people who failed their interview.

True but it should be possible to compare interview performance to job. I presume that interview performances for successful hires aren't uniform, and that on-the-job performances aren't uniform either. If these interview practices make sense then presumably there should be a clear correlation between the two.

That's not necessarily the case. People who are in shape have longer lifespans than those who aren't (probably true; let's assume it is). But if you look at just people who complete a marathon in under 3 hours, you might not see a correlation between their speed and their eventual lifespan. At some point, people might be "good enough" where beyond that is rapidly diminishing returns.

To complicate this: 1. The range in interview performance of those who get hired is really quite narrow. So you're looking at essentially the difference between a 3.1 and a 3.3. You'll need a lot of data to try to find a correlation there.

2. The interview score is only a partial measure of interview performance. If you and I experience an identical interview, I might call that a 3.1 and you might call that a 3.3. The hiring committee will hopefully understand that a 3.1 from me and a 3.3 from you are equally good (because they see our past scores). This makes the data on interview performance harder to correlate, and you'll need even more data. (Or you'll need to properly take this into account in the study, by looking at a score relative to that interviewer's past scores, rather than the score itself.)

3. The above point, repeated for job performance.

4. When a candidate with a lower score gets hired, they're more likely to have something that offset these lower scores. The data set of people who got hired is {people who interviewed well and had good or bad resumes} + {people who interviewed just okay but had great resumes}. When you correlate interview performance of those who got hired, the lower scores in there are skewed towards people with great resumes (or referrals or something else). That factor could totally eliminate any correlation between interview scores and job performance.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#53

Post by wayn3 »

holydude wrote: post #5
gaylemcd wrote: post #2

I'll try to stay active on this thread if anyone has any more specific questions. (Context: I'm the author of Cracking the Coding Interview)

The biggest problem I have with these companies is that they feel like a cult. And the people working there are doing a lot to keep that cult spirit alive. All of these companies want you too feel and act like they are the single best entity in the entire universe and you should be honored that they even acknowledged you. This works great for young graduates that are full of dreams and hopes but it discourages experi…

Corporate jobs dont pay nearly as much as google

Re: What I've learned from 100s of interviews with candidates at top tech companies

#54

Post by WalterSear »

gerbilly wrote: post #42

>Nine-to-5 isn’t enough. At top tech companies, extracurricular work isn’t a differentiating factor— it’s the expectation. I stopped reading at this point. How arrogant to expect you to gift your unpaid free time for the privilege of working there.

Gaylemcd is just bringing the news. It's not her fault that it's bad.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#55

Post by mabbo »

gerbilly wrote: post #42

>Nine-to-5 isn’t enough. At top tech companies, extracurricular work isn’t a differentiating factor— it’s the expectation. I stopped reading at this point. How arrogant to expect you to gift your unpaid free time for the privilege of working there.

You probably should have read what it was saying then: that the companies hope to see you've done something outside of work, like participated in meetups, or worked on a side project.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#56

Post by [deleted] »

dnackoul wrote: post #39
gaylemcd wrote: post #22

Earlier quoted context omitted.

1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…

>1. No, you don't need to know everything... It takes maybe a week for a smart developer without a CS degree to learn what they need to know for interviews. I just went through a job search and I didn't find this true. I think the bar on algorithms has raised significantly with all of the prep material (your book included) out there. I also found a few companies sent over "things to study" lists that were quite compr…

[deleted]

Re: What I've learned from 100s of interviews with candidates at top tech companies

#57

Post by 6stringmerc »

How similar are the Odds for a BS of CS graduate in 2017 in the United States to work in Silicon Valley versus the NCAA Division I Basketball Player to make it in the NBA?

Point being, this is extremely helpful batch of advice for a surprisingly narrow field. Take out the SV / Top 1% Tech Culture nuances and there's really not a lot to work with other than "Put your best foot forward, be flexible to learn new things if asked, and and to keep trying.

But, something like this just stings to me:

>Either way, it’s very common for a candidate to get rejected and then get an offer a year or two later.

It's extremely uncommon for the common person to get anywhere near that kind of follow up. Well, maybe for half the expected salary, but no, this doesn't happen to anybody I know outside of SV or Top 1% C-Suite management. The advice within should be constrained to its applicable universe, with cautions that viewing the process in other fields through this lens could actually be detrimental.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#58

Post by cloakandswagger »

dnackoul wrote: post #39
gaylemcd wrote: post #22

Earlier quoted context omitted.

1. No, you don't need to know everything. You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. (If a company is requiring this knowledge, then they're doing whiteboard interviews poorly [or they have a very specific skillset needed]. That's not a problem with whiteboard interviews. That's a problem with that company or interviewer. It takes maybe a week for a…

>1. No, you don't need to know everything... It takes maybe a week for a smart developer without a CS degree to learn what they need to know for interviews. I just went through a job search and I didn't find this true. I think the bar on algorithms has raised significantly with all of the prep material (your book included) out there. I also found a few companies sent over "things to study" lists that were quite compr…

I would estimate a reasonable amount of prep time prior to interviewing is around 100 hours. This is about how long it will take to brush up on and practice data structures, algorithms, DP, design questions, etc.

This is about 2 months of practicing an average of 2 hours a day, meaning you're still working a day job. I figure this could be reduced to 1 month of prep if you quit your job and have all day to yourself.

Re: What I've learned from 100s of interviews with candidates at top tech companies

#59

Post by drenvuk »

gaylemcd wrote: post #29
meggar wrote: post #19

Earlier quoted context omitted.

CTCI is a great book. Is it acceptable to ask an interviewer for a different question? For example, if you're really bad at chess algorithms and you get the N-Queens question?

This is actually a really interesting point. (Context: In chess, a queen can move along a row, column, or diagonal to attack. The N Queens problem is to place N queens on an NxN chessboard such that no two queens can attack each other.) No one does poorly here because they are "bad at chess algorithms." They might do poorly because they think they're bad at chess algorithms. But this is not a "chess algorithm." It's…

I have a question about the dynamic programming bit. These questions do not seem intuitive unless its one of the simple ones like, add or multiply the two previous values in the memo (fibonacci) or just check the min or max of the value and modify regarding that. Those patterns can sometimes be easy to spot.

The more difficult ones feel like you absolutely have to have seen the problem before because there is complex relationship between the sub problems that are used to solve by induction/bottom up. How is someone supposed to solve these? Throwing out tons of guesses at the start feels like it'll still end up with me getting shown out before lunch time.

Recursion and memoization is easy but dynamic programming doesn't really feel as natural. Ways to get better? Just do more?

Re: What I've learned from 100s of interviews with candidates at top tech companies

#60

Post by bit_logic »

I think the tide is turning against this type of interview. The industry is starting to notice how ineffective and stupid it is. The big tech companies don't care and will continue doing it because success hides all failures. When there's an endless flood of new college graduate applicants and near-monopoly positions bringing in billions of revenue, nobody cares if the hiring process is bad. They will care someday if those conditions change, but that's in the distant future. Most companies, especially small companies, are not in this position and should have a different process. It's becoming a competitive advantage, especially if a company is looking for senior engineers, to not have this interview process. For example, this list of companies was in a HN story a while ago: https://github.com/poteto/hiring-without-whiteboards The trend is growing and it's a good change for the industry.
Post reply on HN