You are unlikely to get asked any of these things during the interview, and if you are it will be obvious that you just crammed for them (much like if just brush your teeth the day before your dental appointment and then arrive at the dentist with bleeding gums).

If JavaScript is your language then you are likely looking at front end development, in which case it will be much more useful to know about frameworks and testing strategies than CS theory.

Yes, you are unlikely to get asked any of these _specific_ questions-- however, the point of study isn't to memorize any answers. Rather, it's to familiarize yourself with the patterns of CS solutions so that you're able to replicate it in a brand new problem.

Also, JS isn't just for front-end development. Aside from Node.js, which is increasingly a larger player server-side, it's also used in a bunch of desktop apps.

Again, you aren't going to get familiar with the patterns in computer science in one week. That requires years of practice. Most likely you will just hit a Dunning-Kruger peak and try to shoehorn in a pattern where it doesn't belong.

And yes, js is used in other contexts as well, but it is primarily used in front end developer. Which is why I used the word 'likely'.

I think it's worth including a bit on disjoint sets. I've managed to pull that solution on interviewers a couple times and they end up fairly impressed when you beat their best solution which is O(n) storage O(log n) time, with one that's O(n) storage O(1) time after amortization.

can you elaborate?

Some material here: https://www.geeksforgeeks.org/union-find/

    A disjoint-set data structure is a data structure
    that keeps track of a set of elements partitioned
    into a number of disjoint (non-overlapping) subsets.
    A union-find algorithm is an algorithm that
    performs two useful operations on such a
    data structure:
    
    Find: Determine which subset a particular
    element is in. This can be used for determining
    if two elements are in the same subset.
    
    Union: Join two subsets into a single subset.

Sorry, I should have com back, but yeah, this is a good summary. When done properly both Find and Union can be done in amortized inverse-Ackerman time, which is for all intents and purposes constant. It can pop up as a solution for a surprising number of questions.

An old, common, (banned) interview question goes something like this:

> Imagine you have a grid of squares, represented however you want, describing an ocean. I'm going to give you coordinates one by one that indicate land being created. You need to tell me in total how many islands exist after each coordinate, where an island is defined as a contiguous block of land connected horizontally or vertically, but not diagonally (or include diagonals if you want; it makes some parts of the answer messier).

The disjoint-set answer to this question is that you look at the coordinate's neighbors. If there are none, this is a new island. Create the node as part of a new set where the node is the "representative" of that set. If there is one neighbor, create node but make its representative the same as the neighbor's representative. If there are more than one neighbors then you have to do a union; create your node and make its representative one of the neighbors' representatives. Then go to all of the other neighbors and find their representatives (make take a couple hops). Then make their final representatives use the first neighbor as their representative.

At this point you have kind of a directed acyclic graph where each node has exactly one edge (maybe pointing to itself). The last improvement is to update each node's representative as you travel to be the final one. This amortizes out to a single hop for each node, after enough find or union operations.

Then you can start adding more data to the representative and dealing with merging that to solve some pretty complex problems in a shockingly low runtime.

This begs the question >> if you can teach yourself any of these things in a day then why would you need to know it before working there?

Why would you want to work for a company which asks these question in the interview?

I can't speak to other companies, but I do know my [unofficial] experience interviewing (on both sides) at Google.

As an interviewee, you know that you're going to have a handful of different interviewers. What you don't know is how much of an effect each of those interviewers is going to have on the hire/no hire decision. Is one bad interviewer enough to torpedo you? Two? And you have no idea what kind of questions each interviewer will ask. So, let's say only 10% of interviewers ask these kinds of questions (I'm guessing that's low). That's a ~41% chance that you're going to have to answer this, and if one bad interviewer is all you need, then you'd be foolish not to prepare just in case.

As an interviewer, we're given surprisingly few guidelines on how to interview. You take a one day class, then shadow half a dozen interviews, and that's it. We aren't given specific questions to ask, and specific questions get banned all the time (any time they're "leaked" as a Google interview question).

Once someone is hired it's really hard to force them out, so approving someone who talks a smooth game but can't back it up is extremely costly. I've seen teams get stuck with multiple people for well over a year because it takes a long time to get them out, they won't leave willingly. Meanwhile they're taking up headcount and letting them actually touch code is dangerous. In fact, I've seen teams spend an additional engineer training them to the point where they are productive, just because that's cheaper.

So you want people to actually prove themselves with some kind of an algorithm question, but you get no real guidance on how to provide these and you constantly have to come up with new ones, but they have to be the kind of question that take less than 45 minutes to explain and solve. I have no doubt that some people fall back on these kinds of questions.

Yeah, I get that these questions suck, and I try not to be that interviewer. But as an interviewee I would consider it extremely foolish to not brush up on it, just in case.

You said it yourself "they're taking up headcount and letting them actually touch code is dangerous". My question is, how did they managed to get into Google if they apparently don't know how to write code? The only way to get into google is to go through a huge set of 45-min whiteborad crap. Not once, not twice, we're talking about 7-8 times! Going over the same stupid 45-min "technical screen" where only the original question varies. You need to know all the CS basic stuff + ability to scale (if possible). Like they all say in Silicon Valley - the only way for us to know if you're a rockstar is if you manage to crack a few meaningless problems on a whiteboard. Oh... and make sure to pick your favorite language. Your Resume tells us you have a MS in CS but we don't believe it. So we're gonna put you back into a college-like exam to make sure your degree isn't fake.

To me, that's step zero. I still can't believe companies like Google, etc get stuck at step 0. They don't seem to care about step 1, 2, 3, 4. It doesn't matter if you have 1 year or 10 years of experience, we all go through step zero (again, even though we got an MS in CS a few years back).

So, if Google ends up in a situation where "teams get stuck with multiple people for well over a year because it takes a long time to get them out", it's because the hiring process at Google sucks. If it is that costly and painful to hire the wrong people, then why Google hasn't put more resources to actually innovate and think beyond college-like evaluations. It is OK for people with zero experience, it is not OK for people with at least one work experience (which I call step 1). Of course, if you have 10 years of experience they need to use a different language in order to interact with you. So, unless someone just graduated from college looking for a job, you can't hire someone exclusively based on step 0 because it simply doesn't tell you if a candidate knows how to write code, build features, work in a collaborative environment, deal with requirements from product team, reuse exiting code, handle code reviews and feedback from peers, create frameworks or adopt new frameworks. All it tells you is if your CS degree is fake or not...

> The only way to get into google is to go through a huge set of 45-min whiteborad crap.

This is not the only way to get into Google.

> Not once, not twice, we're talking about 7-8 times!

When I interviewed I had one 15 minute phone screen, and one round of in-person interviews. The in-person set was 5 people. Of those I think I cratered on one of them, did adequate on two, and stellar on the last two.

> Like they all say in Silicon Valley - the only way for us to know if you're a rockstar is if you manage to crack a few meaningless problems on a whiteboard.

Very few people get hired as a "rockstar", and the ones that do tend to be hired for non-coding roles.

> Oh... and make sure to pick your favorite language.

Yeah, the point is for you to answer the question and not get hung up on language semantics that you aren't comfortable with. I interviewed in C# despite ~0.1% of code at Google being C#. I had a very in depth conversation about contract differences between C# and Java that I think impressed the interviewer, despite me not knowing a single line of Java and him not knowing a single line of C#. If you pick the language and still struggle with the semantics of it, that's a huge red flag.

> Your Resume tells us you have a MS in CS but we don't believe it. So we're gonna put you back into a college-like exam to make sure your degree isn't fake.

An MS in CS doesn't, by itself, qualify you for a role at Google. I have plenty of friends who have the degree who I like very much, but I wouldn't want them on my team.

> I still can't believe companies like Google, etc get stuck at step 0. They don't seem to care about step 1, 2, 3, 4. It doesn't matter if you have 1 year or 10 years of experience

Yeah, I came in with 15 years of experience across 7 different firms. And I went through the same thing. I've also worked with people who have been in the industry for all kinds of timeframes, up to 35 years, and I've seen little to no correlation between "experience" and ability.

A higher-touch process with more "describe what you did at company X" would be nice. But it also feels easier to game. I read design docs for projects at all levels at prior roles, including rationale, alternatives, etc. If I wanted to pass one of those project off as my own through an interview I don't think it'd be very hard. I also don't see any other companies that hire at the rate that Google does (well over 100 software engineers per week) that manages to do that.

> So, if Google ends up in a situation where "teams get stuck with multiple people for well over a year because it takes a long time to get them out", it's because the hiring process at Google sucks.

So now you're arguing for a more stringent review process, but one that doesn't require actually demonstrating any abilities? Also, this is less of an issue with hiring, and more of an issue with staff management.

> you can't hire someone exclusively based on step 0

I'm not sure why you think that Google is "stuck" at step 0, or that we stop there. There is generally no feedback to a candidate about why an offer isn't extended. You're assuming that it's because of a whiteboard coding issue when it might be that your experience doesn't really mesh with what's needed.

There are a wide variety of factors that candidates are scored on, and there are plenty of them that have nothing to do with the code that's written on the board. I've had plenty of candidates that have gotten a "hire" recommendation despite not having an optimal, or even a correct answer on the board. I was confident in their abilities because they demonstrated that they recognized there was a problem, usually due to running through test cases, and that given enough time they would solve it. I've had candidates that have gotten a "no hire" because, despite have a correct and nearly optimal answer, they refused to listen when told that "result &= true;" is a no-op in Java.

Is the interview process perfect? Of course not. Perfection isn't achievable. And I'm happy to listen to suggestions on how to improve the process. But your suggestions seem to be: 1.) Don't ask whiteboard questions at all (which I have yet to be convinced of), 2.) Don't stop at asking whiteboard questions (which we don't).

Just wondering, do you mean the range of questions covered is too narrow? If "10% of interviewers" ask these kinds of questions, what would the other 90% of interviewers do. Other types of common data structures/algorithms, DS/A questions thought up by themselves, or something in entirely different directions?

> Why would you want to work for a company which asks these question in the interview?

Presumably because it is one of the big five (I didn't know there was such a thing). I suspect it looks good on your CV. You'll always be a big five alumni :-)

Seems plausible. Big five stopped to look attractive to me few years ago (Microsoft and Amazon never were, tbh) but I get that people have different opinions. What I do not get is why do big five think this kinds of interview are effective. Or are they?