4 ms·

I regularly conduct interviews at one of the more infamous "whiteboard interview" companies. At the end of my interviews I like to take five to ten minutes to a

by jfasi 9y ago

I regularly conduct interviews at one of the more infamous "whiteboard interview" companies. At the end of my interviews I like to take five to ten minutes to answer whatever questions the candidate might have about myself, the company, the process, etc. One time I had a candidate who absolutely bombed the interview asked me a question that expressed a similar sentiment: why do you guys place such a heavy emphasis on basic data structures and algorithms when standard libraries and software packages offer easy to use, efficient implementations? To be honest, this is a fair question. For someone whose entire career has been spent coding on a single machine, with data that fits in memory, reusing pre-written O(NlogN) or faster algorithms, often with a single thread, I can see why they would ask this question. The answer is: for what we do, there is no off the shelf solution. Our datasets almost never fit on a single machine, to the point where we make jokes about five terabytes of data being so small we forgot how to count that low. Our algorithms are almost all novel: one of my favorite interview questions starts off as a trivial string manipulation problem but then branches out into easy-to-express, easy-to-understand variations that actually require some very sophisticated algorithms to solve. When it comes to pre-built software, even our internal turnkey database solutions are so sophisticated they require a solid understanding of distributed systems and operating systems to avoid common pitfalls. Honestly, not every person is up to the task of working in this environment. Our workforce skews towards people with degrees in CS from high-ranking universities not because we're snobby but because there are few places that teach this particular combination of skillsets. You can probably go your entire career without working for us or on the sorts of problems we try to solve, and you can just as well prepare for interviews by focusing on practical matters and not deeper algorithms and data structures knowledge. And that's fine, I'm sure there are plenty of positions out there for you. But if you do, don't come complaining to me that our interview process is too hard or the prep process is too impractical or that we're being unfair because none of the stuff we test for is practical in the real world. You can have an easy time prepping for my interview or a job at my company, but not both. EDIT: There is something to be said for companies that cargo cult this interview process. True, if someone can pass this interview process they’re probably pretty decent, but you have to be honest with yourself what sort of problems you’ll be solving. OP, meanwhile, expressed an feeling of blanket pointlessness without saying what kind of job he’s looking for. I hope I’ve made clear this is counterproductive for companies like Facebook, Google, Microsoft, etc.

ryandrake 9y ago
I got one of these interviewers (but not at one of the big companies that actually do things at scale), and stood my ground. How would you sort this list? "Use the standard library and move on with my life." But I want you to show me... "Use the standard library and move on with my life." But what data structure would you use? "This one, because A, B, and C. It is already provided, debugged, and tested, by my standard library." How is that data structure implemented? "Doesn't matter. It works and the time I spend not worrying about it I can spend shipping software." -- It actually worked. I think they respected the pragmatism. I actually went on to help migrate them away from a HORRIBLY BUGGY home-grown container/string library, over to, you guessed it--the library that comes with the language.
- junkscience2017 9y ago
  I often try to get my interviewer to offer comments about standard libs etc...when it is clear that they also have never read the standard sort routine, they will usually want to move the discussion elsewhere rather than accept the reality of their own acumen
- oblio 9y ago
  I'd argue that for almost any companies except for the big 10 or so, that's the correct approach. Especially for enterprise software. And even in those big 10, for projects which are not directly tied to the things they do at scale (I doubt the Hangouts Android client needs to reinvent the wheel...), it's still the right approach. I'm kind of sick and tired of companies writing their own frameworks and languages when they can't really maintain them, long term. Google, Facebook, Apple, Microsoft can, because they have a different culture and primarily because they have a different focus as well as enough profits to support it. Random Java big-shop can't. Their framework will be nice and shiny the first year and 15 years later you'll be wondering why you're working with the atrocious Struts-1 inspired undocumented internal framework.
  - jfasi 9y ago
    > I doubt the Hangouts Android client needs to reinvent the wheel... This actually touches on an interesting point. My notorious interview company is Google. I'm not familiar enough with the Hangouts Android client to tell you anything about it, but for the sake of argument let's unrealistically assume it's trivial. Imagine you have an organization where some engineers are good enough to work on the Hangouts Android client but not good enough to work on, say, the F1 distributed database. Internal transfers become crapshoots. Is this person good enough to work on my new, highly complex project? Should I reinterview them to make sure they can hack it? Imagine what this does to the social and cultural stratification. "Oh, those Hangouts guys are nice but they're not that impressive, it's not like they're working on the machine learning or anything." It'd be a nightmare both practically for management and socially for the engineers. Our philosophy is: all engineers should have the chops to quickly be able to ramp up on whatever project they like. This means rejecting a lot of people, but it also means that two engineers can look at one another across the hallway and immediately know they could swap teams and not miss more than a couple weeks of productivity. When framed this way, I think the interview process is a natural consequence. Not sure what the culture is at other places, but I hope this is a useful data point.

by jfasi 9y ago

ryandrake 9y ago

I got one of these interviewers (but not at one of the big companies that actually do things at scale), and stood my ground. How would you sort this list? "Use the standard library and move on with my life." But I want you to show me... "Use the standard library and move on with my life." But what data structure would you use? "This one, because A, B, and C. It is already provided, debugged, and tested, by my standard library." How is that data structure implemented? "Doesn't matter. It works and the time I spend not worrying about it I can spend shipping software." -- It actually worked. I think they respected the pragmatism. I actually went on to help migrate them away from a HORRIBLY BUGGY home-grown container/string library, over to, you guessed it--the library that comes with the language.

junkscience2017 9y ago
I often try to get my interviewer to offer comments about standard libs etc...when it is clear that they also have never read the standard sort routine, they will usually want to move the discussion elsewhere rather than accept the reality of their own acumen
oblio 9y ago
I'd argue that for almost any companies except for the big 10 or so, that's the correct approach. Especially for enterprise software. And even in those big 10, for projects which are not directly tied to the things they do at scale (I doubt the Hangouts Android client needs to reinvent the wheel...), it's still the right approach. I'm kind of sick and tired of companies writing their own frameworks and languages when they can't really maintain them, long term. Google, Facebook, Apple, Microsoft can, because they have a different culture and primarily because they have a different focus as well as enough profits to support it. Random Java big-shop can't. Their framework will be nice and shiny the first year and 15 years later you'll be wondering why you're working with the atrocious Struts-1 inspired undocumented internal framework.
- jfasi 9y ago
  > I doubt the Hangouts Android client needs to reinvent the wheel... This actually touches on an interesting point. My notorious interview company is Google. I'm not familiar enough with the Hangouts Android client to tell you anything about it, but for the sake of argument let's unrealistically assume it's trivial. Imagine you have an organization where some engineers are good enough to work on the Hangouts Android client but not good enough to work on, say, the F1 distributed database. Internal transfers become crapshoots. Is this person good enough to work on my new, highly complex project? Should I reinterview them to make sure they can hack it? Imagine what this does to the social and cultural stratification. "Oh, those Hangouts guys are nice but they're not that impressive, it's not like they're working on the machine learning or anything." It'd be a nightmare both practically for management and socially for the engineers. Our philosophy is: all engineers should have the chops to quickly be able to ramp up on whatever project they like. This means rejecting a lot of people, but it also means that two engineers can look at one another across the hallway and immediately know they could swap teams and not miss more than a couple weeks of productivity. When framed this way, I think the interview process is a natural consequence. Not sure what the culture is at other places, but I hope this is a useful data point.