Dan Luu
patreon
Algorithms interviews in practice
🕑 Added 2019-02-18 05:36:21 +0000 UTCI've spent a decent chunk of time digging around going and finding inefficiencies at the last two companies I worked.
One thing I find funny about interviews is that a lot (most?) of the inefficiencies I find when digging around are things that I think almost all of our engineers would've gotten right if they got the thing as an interview question.
If you were to look at a global profile of all of our code when I joined a certain big company, I believe the one of the hottest functions across the entire company was array resizing because our ML framework had a custom re-sizable array with O(n^2) resizing instead of the usual O(n) resizing. This is a "classic" phone screen question that's considered so basic that it will get bundled in with another basic question as a quick test, and yet no one noticed that this was one of our hottest functions. Ironically, I was one of relatively few backend folks who was hired without doing an algorithms interview (because the hiring manager for the performance team thinks those are useless) and I'm the one who found this.
This is not so different from the other big companies I've worked at, where there's also so much waste that you can easily find single functions that are standard interview questions which are mis-implemented in a way that costs the company millions of dollars a year (or sometimes much more). All of these companies have an algorithms-heavy interview as the default and people seem to think they get a lot of value out of this.
I suppose one could argue that there would be way more of this if we didn't have these interviews, but I find this to be implausible.
I know someone on the team that's analogous to mine at FB (that is, the team that goes and finds performance problems throughout the fleet) and they also have a non-standard interview process that doesn't have algorithms stuff in it because they think it's useless. So, you have people saying that we have to interview for whiteboard algorithms stuff because we have "scale" and people will go write O(n^2) stuff by accident if they don't know this stuff, but then, on the teams that actually find and fix this stuff, these interviews are considered worthless.
Comments
https://mobile.twitter.com/nitsanw
How would you select for people who are good at finding performance problems in practice? Give them a debugging problem? Go off their past experience?
