Live data from Hacker News

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

observer.com

191–200 of 225 posts

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

#191
post #69

Earlier quoted context omitted.

She's profiting from it

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.

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

#192

Earlier quoted context omitted.

The tide is definitely turning. The last two interviews I've been to were nice casual affairs where me and another engineer had a technical discussion on how I'd approach various problems they were having (such as deployment woes, wonky network topology etc). The best part is that I feel like I learned something as well, rather than just being shown my failure because I didn't get the interviewer's "trick" to how to…

> If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities. I agree with this. I tell companies to not ask questions from Cracking the Coding Interview. But that doesn't mean those style of interviews are fundamentally broken. It's just stupid to ask questions that candidates are likely to know.

Indeed, I don't write off whiteboard interviewing altogether - if you know exactly what you are hiring for, it can be very helpful to have e.g. a systems engineer write out some C code or go through tree problems. The issue comes in that a lot of people aren't entirely sure what they are hiring for, just that they need a warm body who can code to some arbitrary ability. That's why I always make sure to ask the interviewer what the burning problems are and what kind of action they are looking for on Day One.

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

#193

Earlier quoted context omitted.

Whiteboard interviews don't have to be ineffective. But empirical evidence suggests that companies greatly overestimate their ability to conduct them properly.

So, what's a properly-conducted whiteboard interview look like?

Mostly talking about previous experience and especially any projects they were persoanally interested in talking about.

I find there is only one thing you need to ensure a new hire can handle to avoid the major fakers. Give them a simple problem that requires a for loop. Usually it takes up like 5 minutes of the interview. I started asking it when I realized that the weakest people on my team would get stuck talking about problems that were simple iterations, they'd spend days trying to avoid a simple 'for foo in bar' coding solution. These were people who could program is the weirdest thing too. Fizzbuzz has become sort of a joke meme over the years but I've found Steve Yegge's core idea to be true, and you can see the deer in headlights with even the simplest code problem. So now it's all I do. Whiteboard coding is unnatural enough as it is, there's no reason to haze when all you care about is will they get hung up on stupid trivial things. Most code is basic CRUD there is no reason to ask about b-trees or tris, let alone implement them.

If I feel the need to raise the bar even higher, I may include a simple pointer based question, since I've come to notice that indirection another concept that weaker coworkers struggle with. But the problem here, is that pointers just aren't relevant to the majority of what devs do these days, and modern languages do well to hide their usage which means fewer candidates will even have worked in a language like C. So you're likely to get a lot more false negatives. And interviews are stupidly expensive so you really want to avoid false negatives.

For reference I work for a company with less than 1000 employees, serving web traffic that needs to handle 2000req/s peak 1000req/s sustained. There is little we do that doesn't fall under basic CRUD. Our biggest tech challenge is cache invalidation, followed by 3rd party API timeouts.

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

#195

> "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 wa…

When I had a Google interview I was told (or it was at least heavily implied) that I wouldn't be evaluated by the people I was having lunch with. I didn't really believe that, and looks like I was right not to.

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

#196

Earlier quoted context omitted.

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

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".

Maybe they were being nice. As I said in another comment, I'm not allowed to know what my scores or reviews were.

FTR, I was a math major, though I did take basic CS algorithms and data structures. So I have a background, but probably further to go than a typical CS major.

I know it will vary by individual, but how many hours, over what period of time, would you say counts as "enough practice" where you might start considering that you probably aren't going to be able to practice enough to do this. Could you ballpark it?

I'd prefer to avoid "unintelligent", but you know, a point at which you'd say, this probably isn't for you, might be time to get some new goals?

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

#197
post #85
post #77

Earlier quoted context omitted.

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

Quantifying assumes that the "raters" remain the same forever. That's not true though. Raters change. Counter intuitively, as the rater gets more and more familiar with the problem, the less tolerance they have for mistakes.

I don't know where you got the idea that quantifying something fixes it for all time. Numbers can change. Measures of inter-rater reliability can be applied to multiple ratings over time by the same person (why not?)

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

#198

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…

> 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 more than anything.

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.

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

#199

Earlier quoted context omitted.

So if whiteboard interviews are stupid and ineffective, what process do you think is better? I assure that the big tech companies absolutely do care, but they struggle to find something better.

For the most successful jobs I've had, they just looked at my resume and asked some general questions about prior work. I've also had several positions where I passed whiteboard hazings. Those didn't go as well. My theory is that selecting strongly for code jam types may correlate with not selecting carefully for people who work well together.

> For the most successful jobs I've had, they just looked at my resume and asked some general questions about prior work.

That's great for people who are good at talking. And certainly communication skills are important, but a strong bullshitter with mediocre programming abilities can probably pass such a test with flying colors.

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

#200
post #5
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…

I've worked at Amazon and Google and neither felt terribly cult-ish to me. They do each have their own culture, but that's no different from any other kind of grouping: nation-state, people who go to events for a certain hobby, etc.
Post reply on HN