This substack is an impersonation. It is not mine (Gayle Laakmann McDowell). Reported. (I also commented on the substack but I was, of course, banned.)

(And if you have any doubt about whether this is really me, please check my twitter: http://twitter.com/gayle.)

0Thread HN

[dead] 4 years ago

Hi, ACTUALLY Gayle Laakmann McDowell here. This substack is not mine. It is an impersonation. I reported but substack hasn't deleted yet. I commented and I was, of course, banned.

(And please upvote this so people see :). Also, feel free to comment on the substack that this is an impersonation.)

0Thread HN

How to Interview Engineers 9 years ago

I agree with much of this. Some additional comments:

Ask questions as close as possible to real work: This is achieved by making interview question as similar as possible to the job you want the candidate to do (or to the skill you're trying to measure).

This "or" thing in parentheses is really important. Interviews should not be "as similar as possible to the job." They should be all about the skill you want to measure. And there's quite a difference between these.

People can be trained, assuming you have time and resources.

The point of standard algorithm interviews is to measure a particular skill: intelligence. The belief behind this is smart people will tend to solve problems well in the real world. It's okay if they don't know all the skills they need; they can learn them. (And if there's a particularly challenging skill, then maybe you need to add that into the process.)

Avoid hard questions: If a candidate solves a really hard question well, that tells you a lot about their skill. However, because the question is hard, most candidates will fail to solve it well. The expected amount of information gained from a question, then, is heavily impacted by the difficulty of the question. We find that the optimal difficulty level is significantly easier than most interviewers guess. This effect is amplified by the fact that there are two sources of signal when interviewing a candidate: whether they give the “correct” answer to a question, and their process / how easily they arrive at that answer.

You don't give examples of what qualifies as hard vs. easy, so it's a little difficult to judge this. But generally, I'd advocate for people asking harder questions.

When a question is easy, a little thing -- small point of confusion, etc -- can make a big difference in whether the candidate seems to have gotten to that answer well or not.

When a question is hard, this is when you can actually see a great differential between great vs. good vs. okay. You can offer help and see how effectively they pick up on that advice.

If your interviewers are just throwing out a question and then sitting back and seeing what happens, then yeah, candidates won't be able to tackle a hard question. But that's not what they should be doing.

To be clear here: hard does not mean "ask about some obscure data structure [skip lists, etc]." It means a challenging question involving common knowledge (hash tables, strings, arrays, maybe binary search trees).

5. Ask every candidate the same questions: [...] there is no justification for asking different questions to different candidates. If you evaluate different candidates for the same job in different ways, you are introducing noise.

I think this is overplayed a little.

If you're doing algorithm-style interviews, any question should be basically evaluating the same skill (problem solving skills). If I ask my favorite question and you ask your favorite question, but they're evaluating the same skill, then it doesn't really matter. There's nothing to make one question better than another. Why not let each interviewer ask the question that they like?

Now, if every interviewer asks a different question, you won't be able to give a well-defined metric on what good performance looks like for that problem. But that's okay. You can't really do that anyway.

When companies give well-defined metrics, they get too rigid. The candidate takes slightly longer to complete the code because the candidate thought things through more thoroughly, and now they're pushed into a lower performing bucket. And that's wrong.

These standardized metrics sound good in theory, but they don't work well in reality (for algorithm interviews, anyway).

0Thread HN

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

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

0Thread HN

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

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.

0Thread HN

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

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

0Thread HN

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

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.

0Thread HN

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

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

0Thread HN