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

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

#221

Post by mcv » Fri, May 26, 2017, 6:54 PM UTC

sage76 wrote: post #91

I asked someone in the medical profession how he got his recent job. He said he called up someone at the hospital and asked if there was a position available. Got an interview the next day, and started the next monday. On the other hand, I asked a friend in the bay area about an engineering position he had applied for. 13 rounds, and he was finally told no.

In Amsterdam, applying for a programming position usually means a phone call from a recruiter, a single talk, and then starting as soon as possible. A second round is rare.

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

#222

Post by taysic » Sat, May 27, 2017, 4:41 AM UTC

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…

I can tell you as a candidate from a top university I never stick with interviews that are this involved! If it works for you that's good to hear but to me 1 day is enough.

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

#223

Post by anjc » Mon, May 29, 2017, 9:39 AM UTC

gaylemcd wrote: post #52

anjc wrote: post #34

Earlier quoted context omitted.

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…

Just saw this now, thanks, very informative.

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

#224

Post by wayn3 » Mon, May 29, 2017, 9:40 AM UTC

geebee wrote: post #196

gaylemcd wrote: post #120

Earlier quoted context omitted.

That is really, really not true. An unintelligent engineer will never be able to practice enough to do well on a well-conducted interview at Google. (They could in rare cases do well if all their interviewers pick common problem.)

This question may be a bit too late, but I am curious. I didn't get through at Google. However, I only asked for 3 weeks to prepare, and I have outside obligations (kids, coaching, that sort of thing). I can easily traverse a binary tree, print all permutations of a set, do DFS and BFS. But I'm not super sharp, especially at a whiteboard. My review was "not bad, good analysis, but didn't make enough coding progress".…

a math degree with some CS is a way better background to have than being a CS major.

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

#225

Post by wayn3 » Tue, May 30, 2017, 6:49 AM UTC

TulliusCicero wrote: post #198

kaspiCZ wrote: post #179

Earlier quoted context omitted.

I'd say homeworks are good. In a mix. In fact the process should be a mix. It's hard to get it right. You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. Bu…

> You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail. > Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach mor…

- The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.

I fail to see how that particular point can ever be a negative for the hiring company. If you need specific skills, you dictate the environment. If you want the candidate to bring his own skills, just tell him to pick his favourite tools.