3 ms·

> system at FAANG by all the regular devs? dynamo, spanner ect were written by devs at FAANG . Do they have special interview channels for 'regular devs' and a

> system at FAANG by all the regular devs? dynamo, spanner ect were written by devs at FAANG . Do they have special interview channels for 'regular devs' and another for people who can write dynamo ?

taeric 4y ago
I took the point to be that maybe scale of database engine can get you passed a lot of nuance. Not much different from databases of old. Writing a good sorting algorithms feels excessive in many applications. The number of such algorithms that the planner of a database picks between is rather large.
ahh 4y ago
> Do they have special interview channels for 'regular devs' and another for people who can write dynamo ? Not special interviews, but certainly different pieces of headcount. There are Googlers and there are Googlers. Being the second is a lot more work, but a lot more interesting.
- lukeramsden 4y ago
  I’d love to know more about how one gets to be in the second group at all as a non-Googler - might make working at a FAANG worth it.
  - Jensson 4y ago
    The way I went: First get good at algorithms in some way. Then you join an unsexy infrastructure team at Google, there are tons of hard problems and potential for impact there. Then you use your accomplishments from the unsexy infrastructure team to join a sexy team, even at Google the kind of people who can actually improve the hard parts of Google are rare so that move isn't hard to make. Some people directly join sexy teams, but that probably means they have some accomplishments from before, the hard part is getting a foot in that door and the unsexy infrastructure teams are a great place to start since there are tons of problems to solve there and not much competition for that kind of work. Most people just want to work with data models or publicly visible products, not the invisible services that moves millions of requests per second, but anything that moves millions of requests per second will be easy to have impact with.
squeaky-clean 4y ago
When I interviewed for a high level engineering position at Facebook, the questions I got were were definitely harder than the ones some friends of mine got when interviewing at lower levels. I also had a "System Design Interview" which they did not have. Ironically I failed the System one because I think the interviewer didn't actually understand the algorithms or solutions and was working off a checklist of expected buzzwords. I spent about it 30 minutes working through a design with him putting down all my decisions. Halfway through he tells me I don't seem to be aware of this certain data structure which is necessary, so he'll tell it to me: A quadtree. My original choice was an R-Tree, I tried to tell him it's faster for windowed queries, more accurate when it comes to large locations. The only real downside relative to a quadtree is slower inserts and deletes [0]. He just kept looking at his second monitor and telling me "Well this says a quadtree is the most efficient method". Couldn't tell me why, just that his notes say so. [0] we had discussed at the start of the question, expectations of 1B queries/day, with an acceptable update latency of 24 hours.

> system at FAANG by all the regular devs? dynamo, spanner ect were written by devs at FAANG . Do they have special interview channels for 'regular devs' and another for people who can write dynamo ?

taeric 4y ago

I took the point to be that maybe scale of database engine can get you passed a lot of nuance. Not much different from databases of old. Writing a good sorting algorithms feels excessive in many applications. The number of such algorithms that the planner of a database picks between is rather large.

ahh 4y ago

> Do they have special interview channels for 'regular devs' and another for people who can write dynamo ? Not special interviews, but certainly different pieces of headcount. There are Googlers and there are Googlers. Being the second is a lot more work, but a lot more interesting.

lukeramsden 4y ago
I’d love to know more about how one gets to be in the second group at all as a non-Googler - might make working at a FAANG worth it.
- Jensson 4y ago
  The way I went: First get good at algorithms in some way. Then you join an unsexy infrastructure team at Google, there are tons of hard problems and potential for impact there. Then you use your accomplishments from the unsexy infrastructure team to join a sexy team, even at Google the kind of people who can actually improve the hard parts of Google are rare so that move isn't hard to make. Some people directly join sexy teams, but that probably means they have some accomplishments from before, the hard part is getting a foot in that door and the unsexy infrastructure teams are a great place to start since there are tons of problems to solve there and not much competition for that kind of work. Most people just want to work with data models or publicly visible products, not the invisible services that moves millions of requests per second, but anything that moves millions of requests per second will be easy to have impact with.

squeaky-clean 4y ago

When I interviewed for a high level engineering position at Facebook, the questions I got were were definitely harder than the ones some friends of mine got when interviewing at lower levels. I also had a "System Design Interview" which they did not have. Ironically I failed the System one because I think the interviewer didn't actually understand the algorithms or solutions and was working off a checklist of expected buzzwords. I spent about it 30 minutes working through a design with him putting down all my decisions. Halfway through he tells me I don't seem to be aware of this certain data structure which is necessary, so he'll tell it to me: A quadtree. My original choice was an R-Tree, I tried to tell him it's faster for windowed queries, more accurate when it comes to large locations. The only real downside relative to a quadtree is slower inserts and deletes [0]. He just kept looking at his second monitor and telling me "Well this says a quadtree is the most efficient method". Couldn't tell me why, just that his notes say so. [0] we had discussed at the start of the question, expectations of 1B queries/day, with an acceptable update latency of 24 hours.