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

211–220 of 225 posts

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

#211

Post by gaylemcd »

kaspiCZ wrote: post #179
gaylemcd wrote: post #131

Earlier quoted context omitted.

They have lots of impetus to change. It's just that they struggle to find a better system. Talking about prior experience? Flawed for the reasons you mentioned. Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment). Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here. Sit down and help me fix this bug? Flawed: 1. Huge bias based on whether they know thi…

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…

I can explain the details of Dijkstra's algorithm. Does that mean I invented it?

There is a world of difference between "created something" and "can explain it in detail."

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

#212

Post by gaylemcd »

logicallee wrote: post #161
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.)

If it's really, really not true then why do you write >will never be able to practice enough to do well on a well-conducted interview Or in other words a true scotsman interview. It sounds like you can't bring yourself to write "on an average interview at Google" because you wish they wouldn't pick common interview problems - but they do. Based on what you just wrote, I'd certainly work through books of "interview qu…

No. "On an average interview at google" is not really the same thing. It's not getting at the same point.

Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then that interview process is broken.

If you have a company with a bad implementation of whiteboard coding interviews (for example, who just pull questions out of Cracking the Coding Interview), then it's absolutely true that a bad candidate could pass this process.

This doesn't mean that whiteboard interviews are broken. It means that this company's implementation of whiteboard interviews is broken. There is a difference.

For Google specifically, their implementation is decent, but not ideal. A bad candidate would have low odds of passing an average interview at Google, but those odds are not as low as I'd like.

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

#213

Post by gaylemcd »

famil wrote: post #162
gaylemcd wrote: post #125

Earlier quoted context omitted.

I think it's well intentioned but highly flawed. 1. The time commitment issue. 2. It allows a company to give a bunch of "interviews" (assignments) even for candidates they aren't serious about. It can waste a lot of candidate time. 3. There is so much cheating on these that you really can't use it for evaluation. It can really only be a screening tool (which makes 4+ hour assignments really unfair). 4. It primarily…

#2 and #5 are issues with the company/hiring manager. #1, #4 and #7 are issues with traditional interview as well. #4 It's incredibly difficult to accurately assess potential during an interview. #1 and #7: This holds true for white-board interviewing. Most successful candidates (including myself) invested time to practice coding interview questions. I did over 150 questions on LeetCode and it dramatically increased…

#1 -- Not as true about whiteboard interviews. Homework interviews generally come in addition to in person interviews, so it's a bigger commitment.

#2 -- yes, this is about the hiring manager. But as the candidate, you don't really know what's going on. So it really is specific to the homework interviews.

#3 -- This is a really, really big deal. You're trying to assess people based on homework... that might actually have been done by their buddy.

#4 -- Less true about coding/algorithm interviews. These are focused more on intelligence/problem solving, which is getting more at potential.

#5 -- Absolutely this is about the hiring manager. But it's also very difficult for a homework project to focus on one things (like problem solving skills). The cheating + lack of discussion makes this hard.

#7 -- Time spent makes a MUCH bigger difference for projects than for whiteboard interviews. A 1 hour project vs 20 hours will look very different. A bad candidate with 200 hours of prep will still be worse than a good candidate with 0 prep.

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

#214

Post by [deleted] »

logicallee wrote: post #161
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.)

If it's really, really not true then why do you write >will never be able to practice enough to do well on a well-conducted interview Or in other words a true scotsman interview. It sounds like you can't bring yourself to write "on an average interview at Google" because you wish they wouldn't pick common interview problems - but they do. Based on what you just wrote, I'd certainly work through books of "interview qu…

[deleted]

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

#215

Post by gaylemcd »

NTDF9 wrote: post #160
gaylemcd wrote: post #140

Earlier quoted context omitted.

So what do you suggest?

I'm glad you asked. I have been following your blogs and posts about interviews and this is the first time I've seen you ask this. This is positive. I do not have a bulletproof solution but I have implemented processes in my current company that filters in better (measured by performance at work) people than the average prolific whiteboard coder. 1. First, we need to establish the goal of the interview. What is our g…

Oh, no, I've asked people their suggestions all the time. I typically do in these discussions. In fact, I have elsewhere in this comment section.

I'm sort of confused by your suggestions. You've decided a pretty typical interview process. What do you think is different here?

The biggest difference I can see is that you're saying that the coding is "a relevant problem from our codebase and now just some random skyline problem." And you're specifically calling out that it's okay to miss codebases.

Let's discuss these more. 1. It shouldn't really matter whether it's from your codebase, right? If you have two problems, ProblemA from the codebase (which is worse at identifying relevant skills) and ProblemB (which is a toy problem but better at identifying relevant skills), you should go with ProblemB, right? So really the question is to find a problem that is a good predictor of whatever you care about. If I really want to hire people who are smart, is giving them a challenging problem a good predictor? I think so.

2. The edge case thing. You seem very fixated on this. Why? What interviewers should be thinking about is the signal that the candidate sends. Certainly, in many cases, missing an edge case is just a "I haven't written in certain details yet." In some cases, missing an edge case (particularly after a conversation) might actually signal a much bigger issue. For example, imagine someone didn't write in a check to see if an array is sorted. No big deal, probably. But if there's a repeated issue with this and they can't write this code correctly, then we have an issue. Saying that edge cases don't matter is too broad. They might, and they might not. I encourage interviewers to focus on the signal and not on some binary rule.

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

#216

Post by gaylemcd »

eli_gottlieb wrote: post #191
gaylemcd wrote: post #139

Earlier quoted context omitted.

And? By your logic, if a lawyer tells you how to handle some unfair legal situation, that lawyer is doing something wrong. Because they're profiting from something that's unfair. When I talk to a company about how to create a hiring process, I tell them that it's unfair to expect side projects from candidates.

There's a reason people dislike lawyers.

Right. And it has nothing to do with their offering advice to get out of bad legal situations.

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

#217

Post by tentakull »

People saying that she's just delivering news/trying to help. Nah, she is propagating toxicity that comes when there's lots of money to be had in a certain profession. Blend in, rank and file, do well on your homework and standardized tests and maybe you too can go to an Ivy League company. It's absolutely mind numbing that the homebrew creator Max Howell was turned down by google. But, it's because of this toxicity. I'm a piece of shit and studied for interviews like 90% of the dev workforce and got a job at a Big 4 company. I feel dirty.

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

#218

Post by logicallee »

gaylemcd wrote: post #212
logicallee wrote: post #161

Earlier quoted context omitted.

If it's really, really not true then why do you write >will never be able to practice enough to do well on a well-conducted interview Or in other words a true scotsman interview. It sounds like you can't bring yourself to write "on an average interview at Google" because you wish they wouldn't pick common interview problems - but they do. Based on what you just wrote, I'd certainly work through books of "interview qu…

No. "On an average interview at google" is not really the same thing. It's not getting at the same point. Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then that interview process is broken. If you have a company with a bad implementation of whiteboard coding interviews (for example, who just pull questions out of Cracking the Coding Interview), then it's absolutely…

uh, you're willfully ignoring that we don't care about the company's side of things. In this thread where someone wrote:

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

>I'd say it is mostly that. Just do thirty to fifty leetcode medium problems (some of them on pen and paper), and you're good to go.

Nobody in this thread cares if the reason this advice actually (in actual practice) often works is that the interview process is broken.

nobody cares if the reason we get the job is because we exploited a flaw, and we "shouldn't have" done it that way. Basically, where you just wrote,

>Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then that interview process is broken.

you should have written:

>Taking a step back: If preparation can give a bad candidate a good shot at passing the interview, then I have to admit, if you strictly want to increase your chances of getting a job, then you can do so by preparing -- but I grit my teeth while saying that, because that interview process is broken.

that would have been honest and matches the reason others had for the above thread! anyway, thanks for the responses.

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

#219

Post by deong »

TulliusCicero wrote: post #201
deong wrote: post #117

Earlier quoted context omitted.

I make roughly 85% of that 200k figure (give-or-take, depending on stock option values), and my house cost $90 per square foot. If you're a good senior level engineer, you can make good money in far more than five or six companies in the world.

200k is mid-level at Google. Senior engineers make significantly more, and staff engineers make a LOT more. Now if you want a big house, then most of the cities that Google is in are terrible for that. But there's more to life than having a big house, and the expensive metros have their own pros. It's pretty hard to beat Silicon Valley weather, and for what amounts to a giant suburb the restaurant scene is quite good…

Well sure. I'm not arguing otherwise. I'm just responding to a comment vaguely asserting that you can't make Google money in a boring corporate job. He wasn't arguing that the city was nicer. He just said, basically, "where else are you doing to get 200-300k". Well, if what you care about is how much of that you get to keep, lots of places.

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

#220

Post by mcv »

kaspiCZ wrote: post #179
gaylemcd wrote: post #131

Earlier quoted context omitted.

They have lots of impetus to change. It's just that they struggle to find a better system. Talking about prior experience? Flawed for the reasons you mentioned. Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment). Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here. Sit down and help me fix this bug? Flawed: 1. Huge bias based on whether they know thi…

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…

What I always prefer is a take-home programming assignment, and then present the results to a group of developers. You need to be able to explain what you did and answer questions about it.
Post reply on HN