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

71–80 of 225 posts

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

#71

Post by strictnein »

> "One Google candidate asked his lunch interviewers where all the “hot chicks” were"

It's shocking that people are this dumb, but sometimes brains just misfire in stressful interviews. Happens with the interviewer sometimes too. I was once asked, when an interviewer noticed my wedding ring, if I planned to have any kids soon and what my wife's career was, which is a definite no-no. I assumed he was joking, but he was honestly asking the question. The other interviewer stopped the interview and basically kicked him out of the room.

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

#72

Post by 11thEarlOfMar »

We've adopted a new process for interviewing software engineers. It has three interview sessions held on subsequent dates:

1. Candidate learns about the company and the tech during a set of 2-4 interviews with our engineers. We don't tell them to learn as much as they can because we want to see how inquisitive they are. Interviewers are coached to be fairly open and talk about our products and tech. If there are no red flags, the candidate receives a take home coding assignment. We give them 6 to choose from. There is no time limit, but we are interested in how long they take and which of the assignments they choose. The assignments are all relative to the type of code we develop.

2. Candidate returns with their code. We're looking for only 50-100 lines, as we don't want to ask for a lot of their time. They start the interview by hosting a code review of their code in front of 3-4 engineers. We expect them to be able to explain their coding choices and answer questions that show that the code is more or less their own authorship and that they know what they are talking about. After the code review, they will have 1-1 interviews.

3. If it goes well to this point, we have them back for more introductions to other company management to see if anyone notices anything concerning. We might take them to lunch.

With luck, we get 2 or 3 candidates through this process and then meet to discuss which gets the offer.

It's a new process and seems to be going Ok so far, but I'm curious if anyone else has tried this type if approach and if so, what was the outcome?

EDIT: Interviews are 2 hours each step. 1-1 interviews typically 1/2 hour. The code review is usually 1/2 - 1 hour, we don't put a time on it.

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

#73

Post by sporkenfang »

myrandomcomment wrote: post #65
georgemcbay wrote: post #50

Earlier quoted context omitted.

"I would ask a single question that would take 30+ minutes to work through with no expectations that the candidate would ever get the answer" The major problem with this approach (unless you are very vocal about the process up front, but still even then I see it as problematic) is it flies in the face of most education at all levels, at least as practiced in the USA. This is fundamentally more an issue with the way w…

So I was always very upfront. I told the candidate you will not get the answer. This is so I can see how you attack a problem. All the candiates had a background in the subject matter. The question was not on subject matter not tied to the job. Overall we found that the way we did this interview was very successful. At one point we lowered the bar and hired a bunch of people and they were all gone in six months. On t…

> I told the candidate you will not get the answer.

I've had an interview like this. I said thanks for your time and walked out of the room.

I'm not interested in being told problems are unsolvable, I'd really prefer to work in a culture where there's a growth mindset. Even if a problem is unsolvable for me right this second, would it not be within the realm of possibility that with more experience or with a couple other folks on a team, I could solve it?

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

#74

Post by drenvuk »

wayn3 wrote: post #51
gaylemcd wrote: post #29

Earlier quoted context omitted.

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…

It feels like the answer to both your question and mine is to do more problems. I have no issues with backtracking but your complaint mirrors my own with respect to dynamic programming.

Back to leetcode I guess.

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

#75

Post by strictnein »

11thEarlOfMar wrote: post #72

We've adopted a new process for interviewing software engineers. It has three interview sessions held on subsequent dates: 1. Candidate learns about the company and the tech during a set of 2-4 interviews with our engineers. We don't tell them to learn as much as they can because we want to see how inquisitive they are. Interviewers are coached to be fairly open and talk about our products and tech. If there are no r…

> We give them 6 to choose from

This is a good idea that I've never seen anywhere.

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

#77

Post by theoh »

NTDF9 wrote: post #66
6stringmerc wrote: post #57

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…

>> >Either way, it’s very common for a candidate to get rejected and then get an offer a year or two later. What OP implies is that the interview process is out of candidate's control and there are many variables in play. What the OP doesn't realize is that this is the definition of a shitty process. What would you call a piece of software that cannot reliably produce the same output most of the time? vs What would y…

I don't know about SV interviews, but there are ways of quantifying this kind of unreliability:

https://en.wikipedia.org/wiki/Inter-rater_reliability

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

#78

Post by claudiulodro »

11thEarlOfMar wrote: post #72

We've adopted a new process for interviewing software engineers. It has three interview sessions held on subsequent dates: 1. Candidate learns about the company and the tech during a set of 2-4 interviews with our engineers. We don't tell them to learn as much as they can because we want to see how inquisitive they are. Interviewers are coached to be fairly open and talk about our products and tech. If there are no r…

Not to be super harsh, but this sounds awful.

- First day is 4 interviews and a take-home project.

- Second day is an interview in front of a panel followed by an indeterminate amount of further interviews.

- Third day is a "culture fit" interview.

3 separate days of interviews and a take-home assignment? What professional has time for that?!

EDIT: I guess it depends on the length of the interviews. Is the total interview time for a candidate more like one all-day interview split into multiple days, or is it substantially more than that? If it's the former, why not just do it all in one day so that candidates don't have to use up a half week of vacation?

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

#79

Post by sanjoy_das »

drenvuk wrote: post #59
gaylemcd wrote: post #29

Earlier quoted context omitted.

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…

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

Once you have the recursive solution, the DP solution should be fairly easy. Draw out the recursion tree for an example (or do it more generally), convert it to a DAG by combining redundant nodes, and then do a topological sort. That topological sort is the order in which you need to solve the subproblems to get a DP solution.

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

#80

Post by mahyarm »

yanilkr wrote: post #67

Most of it is good advice for fresh graduates who want to get into big companies. Shouldn't we be telling these young people to aim higher?. If you derive your sense of worth from a bigger brand and not your own efforts and caliber, you might be complacent for a while then life happens and you will regret not accomplishing anything meaningful in life. Before preparing for your interview and seeking validation for you…

Startups aren't that special, and I lost a lot of income by doing small startups first as an employee for 4/5 years.

Startups even in successful cases are just break even working at AFGAM. Usually you'll quickly be throwing away $100k/yr in income instead. And that $60k/yr your not putting in your stock brokerage account you could of used for whatever bootstrapped digital business or financial independence base you could of done instead. Over 8 years the difference can mean a literal million dollars in the bank.

Working at AFGAM won't make you lose your soul, and you'll learn a lot of stuff that you wouldn't learn in a startup. If you work at both types, you'll quickly realize that working at a SV startup and working at Twitter or FB is not that much different.

A lot of startups have fun, but writing bad disposable code is the standard operating procedure. Mentorship is usually non-existent. Wanting to write something quality is usually difficult to get approved because you might die tomorrow. Long hours are very typical.

I would also suggesting looking at this article: https://deardesignstudent.com/8-reasons-to-turn-down-that-st... , #4 is especially relevant.

Post reply on HN