undefined | Better HN

0 pointspcwalton7y ago0 comments

If it's true that this type of problem is relevant (I doubt it), then why not ask about a specific problem you've actually had to solve?

I don't do many interviews anymore, but I used to, and I had no short supply of problems that I actually had to solve in the course of my work that I could ask about. I don't think whiteboard interviewing is great in general, but if you're going to do it you can at least try to keep it relevant.

As a matter of fact, I did have to do memoization of graph traversals at least once for work (most programmers never have to do this), and I find that problem a lot more interesting (trait matching for Rust). I could easily give a talk about that problem. As for that interview question, though? I don't always do well with time pressure, and so I can't guarantee I'd be able to answer it to your satisfaction.

0 comments

kyralis7y ago

Setting up the same problem in terms of trait matching for Rust is quite a bit more difficult than this toy problem when you're in a limited-duration interview setting. All of the time that you spend laying out the problem is time the candidate doesn't spend solving it, and time you spend not getting a signal. The simpler the problem setup the better, in my experience.

I've done the "ask a real problem that I've solved before" thing, and I find that it usually gets hung up on details and context around the problem to the detriment of actually solving the problem at hand. That's not to say that such a conversation isn't itself very valuable, but that's a different interview conversation, at least on my team. We find it important to maintain some level of focus just to ensure that we're covering the various signals that we'd like to get from the candidate.

pcwaltonOP7y ago

I am not at all confident that I would be able to answer Knights on a Keypad to your satisfaction, due to some combination of nervousness and time pressure. I probably could if I did many hours of interviewing practice, though. Absent that, I think there would be a good chance you would reject me on the grounds that I don't know how to do memoized graph traversals, despite the fact that I'm in a small minority of programmers that have shipped memoized graph traversals to production (and in fact a few teams at Google rely on my implementation of memoized graph traversals, ironically enough).

My view is that Google's interview process seems to work because Google gets so many applicants that they can afford to randomly reject most of them. It's not because it's a good process.

blaze_run7y ago

Using an actual problem you solved can also work against the candidate because most problems we encounter in our daily jobs require a lot more time than the standard 45 minutes reserved for an interview (actually only 35 minutes out of 45 because there's 5 minutes of intro/icebreaker and 5 minutes reserved at the end to answer any of the candidate's questions).

So it isn't fair to ask the candidate to solve a real bug or implement a real feature in only 35 minutes unless they've seen something similar before.

This is why big companies like Google are limited to whiteboarding interviews because they need to have an interview process efficient enough to properly vet and filter >1 million applicants Google receives each year.

Personally, I think a better interview process is a pair-programming or work audition for a day. But that is not even close to matching the scale of Google.

Let's say out of a million applications, maybe only 25% are qualified. That is still almost 1000 candidates to interview per day (number of U.S. business days in 2019 is 261; 250,000 candidates / 261 business days = ~957 candidates per business day). Pair-programming or full day work audition will not be able to accommodate 957 candidates every day.

j / k navigate · click thread line to collapse