That's completely false, and anyone who says that is completely ignorant of Bayesian logic.

Here are some simple numbers.

Suppose that a "good" candidate is a 1-in-100 find. Suppose that a "bad" candidate has a 1% chance of tricking you into hiring them anyway.

Every time you pass on a "good" candidate, that is greater opportunity for a "bad" candidate to trick you into hiring them!

Counterintuitively, if you pass on too many of the "good" candidates, in your overzealousness to reject bad candidates, you're actually INCREASING THE ODDS OF A BAD HIRE.

This is management porn. "It's better to reject a good candidate than hire a bad candidate." It makes the manager feel good. "Wow! That candidate seemed smart, but I rejected him anyway! I'm such a great leader! I make the tough decisions!"

tl;dr summary

Because "good" candidates are rare, every time you pass on a good candidate that increases your odds of making a bad hire! This is simple Bayesian reasoning!

I personally have worked with several awesome people that have interviewed with Google, and none of them got hired. They all said the interview process was flat out insulting.

Interestingly enough, most of them ended up at Facebook.

Not sure if you have ever been a manager, because firing someone is NEVER easy. It hurts everyone emotionally. The person getting fired feels awful. The person doing the firing feels awful (unless they are a real sociopath). And team morale tends to take a big hit.

Here is my stance: if you hire someone who isn't a good fit, unless they actively deceived you, it is your god damn job to find a way to make it work. As a principle you should treat people with respect and dignity, and not as easily disposable and replaceable cogs.

No, it isn't. This is why probation periods exist. If you hired someone and they aren't working out, then at the end of the probation period you don't keep them on.

Trying to force someone who doesn't fit the team dynamic to stay is going to hurt your org. It doesn't make you a "good" manager to say to everyone "I know this sucks but deal with it because letting them go would mean I was wrong."

> As a principle you should treat people with respect and dignity, and not as easily disposable and replaceable cogs.

Which is ironic because so many job descriptions I see today are basically written as "we want to hire someone with exactly these skills, who requires zero training, and can become an expert in our systems in their first week."

No one is that way, unless your system consists of pressing one button all day, but then the job description would probably require that the person have intricate knowledge of the button and is friends with the engineer who designed it so they know what to do if the button suddenly stops working.

If companies actually treated people with respect and dignity, I'd get the training I need to become a better employee, instead of going to management and begging them for any training every 6 months like the industry is now.

/rant

Doesn't this rather presume that your "team dynamic" is actually good to start with?

Let's say you had a team of not very good engineers. Then you hired quite a good engineer who looked at all the terrible practices (e.g. no version control, shitty or nonexistent testing, poor build processes) and said to themselves "look, I need to fix this shit or I'm leaving, and I've got ten better offers in my inbox".

They might not be a very good team fit, but that's because the team is filled with idiots who haven't figured out how to use version control or whatever.

So, you know, the best thing to do is to get rid of them for not being a culture fit or for not being good for the team dynamic...?

Yes, if you have a team like this and you hire someone who has a higher standard, there is going to be some friction between them and the existing team members. Letting that person go isn't your concern, because as you said yourself:

> and said to themselves "look, I need to fix this shit or I'm leaving, and I've got ten better offers in my inbox".

I've been in that situation before. I was hired to a company and when I got there I found out that every single day they were fighting fires because of stupid decisions management made with little foresight into how it would affect the team. Funny enough none of this was mentioned during the interview, although it was a definite red flag that they had high churn for this particular position.

I stayed there for my probation period trying to fix things so the team would fire fight every day and change management's mentality, but it wasn't happening, so I gave notice and went somewhere better.

> So, you know, the best thing to do is to get rid of them for not being a culture fit or for not being good for the team dynamic...?

No, you took me too literally. Obviously if you've got someone who has friction with the team, but they're a hard working individual who is trying to make your team better and more efficient, you should try to work through those stressful periods because in the long run it will be better for your team's health and the company's health. If some of your low performers leave during this period, that's okay, they were only going to hurt you in the long run. That being said, don't burn bridges with your existing employees. Try to find a happy middle ground that results in a better work environment for everyone.

I have also quit a job because they fired the wrong person.

In my opinion, if you fire someone and the reaction from the whole team isn't "thank god, that guy needed to go", then you made a mistake firing them and should have tried to make it work. In the past when I fired someone, the general reaction was much more along the lines of "what took you so long". In both cases I was the one at the table defending the person while everyone else said they needed to go.

Interestingly, in both cases the reason for firing them was that the person in question was not treating other people with respect. So what is worse, letting one person shit on your whole team and make everyone else feel bad, or getting that person off your team?

Managing isn't easy.

That attitude is how bloat happens. There is a middle ground here. Not firing bad employees also hurts many people emotionally as does an underperforming, overbloated company. Employees are as replaceable as employers. To use a sports analogy, it's the big leagues and you may not make the team and often times it is hard to know whether someone can make the team without a trial. I believe these draconian interview practices and contract-to-hire approaches are a direct result of the never-fire-bad-employees attitude.

Ergo they own the problem, not so much the Noogler. Also generalists == mediocre code in my experience because there's no passion for such work in a lot of people who are fantastic with other in-demand skills, but I digress.

And when I joined, Google wasn't so much bloating as it was metastasizing. Most of the people I knew who joined around the same time have long since left. In contrast, I've been at the same gig ever since I left Google. The Google experience was the outlier.

I'm not sure if this is the norm--I believe it differs for industry hires versus those fresh out of school--but it's certainly not true that, as a rule, you can never meet potential teammates.

Because for the most part, Googlers aren't bozos (although a couple of the true believers in the Googleplex blew my mind with how crufty their skills and knowledge had become), but that doesn't rule out one of the many great engineers there promoted to their managerial level of incompetence. And that's what I had - a guy with no people skills whatsoever - and two teams with a total of 20+ engineers to "manage."

If the candidate cannot invert a binary tree and gets mostly there, and has demonstrable real world software, it's a different thing.

What does that even mean? Swap left-right child nodes? Write it linearly (n-th children at 2n and 2n+1) and reverse it as if it was a string? OP later described it as "to min-max the tree, ascending to descending." confusing me further.

That doesn't disprove what he said. In fact it strengthens it and makes missing a good hire even worse, because, as he said missing good hires -> MORE change of bad hires (that can "poison your team").

In other words, it's not a choice: "I'm better of rejecting a good hire than getting a bad one, because a bad one could poison the team".

By rejecting good ones, who're actually getting MORE bad ones. So it should be corrected to:

"I'm better of NOT rejecting good hires, or else I'll get more bad hires and poison my team".

Yes, but what hiring managers are doing isn't passing over candidates that they know are good, they're passing over candidates that they're not very sure about.

> Because "good" candidates are rare, every time you pass on a good candidate that increases your odds of making a bad hire! This is simple Bayesian reasoning!

Similarly, of course this is true, but again hiring managers aren't passing up candidates that they know to be good, they're passing up on candidates that they're not sure about, whom the acknowledge could be good.

Under certain conditions, every time you pass on a candidate you're not sure about, you decrease your chance of making a bad hire. The conditions are that increasing hiring standards must weed out more bad candidates than good candidates.

Let's work with your model. Suppose 1% of candidates coming for an interview are good and 99% are bad.

Hiring strategy A manages to hire all good candidates it interviews, and 1% of the bad candidates it interviews. End result: for every 100 people you interview, you get 1 good candidate and 1 bad candidate.

Hiring strategy B is more conservative and hires 50% of all good candidates it interviews, and 0.1% of the bad candidates it interviews. End result: for every 100 people you interview, you get 0.5 good candidates and 0.1 bad candidates.

The claim is something like, the team produced by strategy B is better than the team produced by strategy A, even though team B has less good candidates than team B.

1) This means that by raising your hiring bar (adopting B instead of A), you eliminate more good candidates than bad candidates. You now have to prove this empirical claim. 2) All I wanted to say was that the statements you made like "every time you pass on a good candidate that increases your odds of making a bad hire!" is only true under certain conditions (namely that raising hiring standards eliminates more good candidates than bad candidates), and it's not "simple bayesian reasoning".

As long as good candidates are rare, and bad candidates have a small-but-nonzero chance of tricking you into hiring them, it's very expensive to pass on a good candidate.

Even if you pass on 50% of the good candidates (no matter how many bad ones trick you), you're doubling the amount of time you're spending interviewing.

The only way to be sure about how many "good" candidates your are missing is to hire some random percentage of the people who fail your interview. Only a large tech company would have the resources to do that, and I'm not sure if it would be ethical, or even get the employer in legal trouble.

NO employer knows how many good candidates they miss out on, which makes this analysis very difficult.

Also, I question the ability of most employers to evaluate employees AFTER they are hired, so any analysis of post-interview performance might just be reinforcing whatever biases are present.

Also, candidates fall into THREE groups: great, mediocre, and toxic. The catch is that the toxic ones are most likely to trick you into thinking they're great. That makes it even more expensive to pass on a good candidate.

Yes, I agree with you. My point is that even taking this into account, even after taking into account all the other costs you mention into account, it might still be better to pass on candidates you're not sure about.

> The original slogan "It is better to reject a good candidate than hire a bad candidate." specifically says to make that fallacy.

So going by the slogan, even if passing on too many good candidates increases your odds of a bad hire (say from 50% to 80%), it's still better than hiring a bad candidate, since if you hire a bad candidate, the odds that you made a bad hire is 100%!

My interpretation of the slogan seems different from yours, mine is something like: if you hire a good person the value of your business will increase by X, if you hire a bad person the value of your business will decrease by Y, and Y is much greater than X.

A bad hire can easily cause more friction than if nobody was hired at all. Net effect for the business is negative. You're also probably severely overestimating the likelihood of a bad hire going through.

But the cost and other effects of doing so vary significantly depending on where you are. Most of the US may have at-will employment, but much of the rest of the world does not.

We had a really bad hire about 2 years ago. So bad it caused us to review our entire hiring process to understand how he got in. It took almost a year before he was fired (and he was a contractor so it should have been easier). In that time, he used up untold resources while we tried to find work he could actually do, people helping him "just in case he just needed a helping hand" and so on. Finally after wasting other people's time for 9 months, a manager made the decision to get him out.

A year later I got an email from him asking for a recommendation. Nothing ventured, nothing gained I guess.

I.e., I don't know your particular situation, so I wouldn't dare to assume the reaction was wrong, but too often "we much at all costs make sure it never happens again" overwhelms any attempt at reasonable approach and cost/benefit analysis completely. Maybe getting one bad apple in occasionally is a reasonable price for quickly and efficiently hiring a lot of good people?

Why did the manager wait so long?

Employee X is hired. After a month it becomes clear to the whole team that X is a bad hire. But how do you turn a subjectively obvious feeling into an objectively obvious reason to fire. Because if that person decides to sue the company after getting fired that's what you will have to demonstrate.

Just imagine how hard it is to quantify what makes someone good at our job? Code Quality? Team dynamic? These are really fuzzy metrics.

You could document how many times the engineer affected production badly and how much that cost the company. But to be realistic even great engineers do that. Heck I touched production at Google and decreased revenue by millions of dollars and it was expected that this happens. So you'd have to let him affect the company enough times to be obvious He's worse than your other engineers.

You are going to have to have documented enough clear failures to do the job to justify starting the process of firing. If you don't have a performance improvement plan then you might be able to speed up the process a little. However not having a performance improvement plan is both a bad idea and, I would imagine (IANAL etc.), could cause problems later on down the road in a potential suit.

Taken in that light 9 months doesn't seem that long at all.

It is "at will employment".

There is no need to prove that employee is causing losses.

It's the employee who has to constantly "prove" to employer that this employee's salary is justified.

FSK: If you pass on many good candidates, and you have a small chance of hiring any given bad candidate, then each good candidate you reject actually INCREASES your odds of making a bad hire.

Idiot: We made a bad hire once! Never again! Now we reject lots of good candidates to avoid that repeat disaster!

FSK: But, if you want to minimize your bad hire rate, you also have to minimize the number of good candidates you reject.

Idiot: NO! NO! NO! The way you make sure you hire no bad candidates is to be so strict that you reject lots of good ones! That's what everyone told me so it must be right!

In one ear and out the other. Why do people who don't understand statistics get to be managers? If you don't understand this statistics argument I made, you're unqualified to work in any sort of technical area.

Whether or not this actually reduces the number of bad hires is beside the point. It's a classic principle-agent problem.

They fear they might be bad candidates. They'd rather reject too many than too few, so they make sure they reject everybody who they're not 100% is a good candidate. That means they may reject some good candidates that aren't easily identified as such, but it doesn't increase their chance of hiring a bad candidate; it decreases it.

Hiring a good employee is not nearly as impactful as hiring a bad one. If you can have a strategy that filters out 100% of bad employees, but unfortunately also filters out 90% of good employees, this is preferable to filtering only 50% of good employees, but also only filtering 90% of bad employees. You may have more good employees with the latter strategy, but the bad employees can kill the team.

Firms are hierarchy-based entities. "Technical Merit" is about a third or fourth order away from what really drives the hiring decision. Its also very imperfect predictor of actual performance.

The issues is that companies use the term all the time. They want people to believe they were hired for their merit, but merit is almost always 'fit' and not technical in nature. The technical hoops are just a CYA for when the 'fit' doesn't work out (mis-judgement) and they need something to point to as to that is not arbitrary in nature to explain how other people were not hired instead.

The theory behind the "raise the bar" argument is that obviously good hires are easy to spot (this is the part most people reasonably take issue with), so people who do not pass that bar of "obviously good" aren't worth taking a risk on. The conclusion is statistically reasonable if you accept the premise (which, again, you probably shouldn't).

This is only true for new grads. The population of engineers with ten years of appropriate corporate experience (that match the technology survivor bias) and at the ~12 locations google can use is tiny.

When I look at my old corporation, only 3 people (of 500+ I would be aware of) were hired by google. One of them is genuinely great, but I doubt he passed the current process as a blind hire. The other two I wouldn't want to work with, but I bet they passed this process precisely because the right kind of focus. (I.e. everything people around them didn't know was their priority and since we normally focus on what's important to completing our project, none of that was so important..)

I was very interested in google when I was under the impression that (without experiencing menlo park on a daily basis,) I could either walk away with over $500k (gross) in 2- years, enjoy working there for 5 years, and/or work with the best >experienced< engineers in our field. When glassdoor and my own linkedin network revealed my best perspective into their setup, blind applying to them is now just a good filter to test my new age employability skills. So, now they've built themselves a new problem of true positive false positives who are just along for the ride.

The hiring market is already NP Hard for both sides when you are genuinely trying to get a good enough fit for yourself rather than the best deal on the market. If you try to misuse the other side they will see less ethical constraints in using the resources you'll have to put in.

How many developers genuinely want a job they can't do that they will have to be awkwardly fired from in six months and explain at every future interview?

Humans are more complex than that. I don't think you can assume that candidates will perform the same all the time. Sometimes an excellent candidate can perform badly for multiple reasons (e.g. nervousness, poor preparation, bad interviewer, personal problems, etc).

It seems to me, that rejecting a good candidate, and have him/her interview again after some time, if that candidate was a 'good-hire', then it would increase the chance of hiring him/her, since it is most likely they will prepare better, and know what to expect.

If your flawed process rejected a good candidate the first time around, what makes you think the same flawed process won't reject them a second time?

I'd never even apply to Google based on the stories I've heard, and I'm sure there are plenty of others in the same position who are even better at what they do than I am. There are just so many stories out there of how crappy the hiring process is that everyone who's any good must have heard about it. Some significant fraction will have said, "Yep, not for me."

In practice, they select for people with good memorization skills. If you can remember the details on a ten dozen different algorithms and data structures, you can pass one of these without having a single lick of creativity or skill.

I say this as an employee who has worked alongside many unskilled drones who made it past the algorithmic interview process.

I recently interviewed for a security engineering position at a startup, and while I got offered the job, the interview was quite silly.

The first thing I was asked to do was to write a lisp interpreter. It was a pretty trivial task, but it left me scratching my head since not only did it not tell them about whether I would be qualified at all, but I had explicitly avoided writing parsing code since I found ANTLR during undergrad.

In the end I wrote a basic stream abstraction and wrote my lisp interpreter on top of it with no real difficulty, but it was a completely stupid question. I told them on the third interview that they weren't asking me anything relevant and I still got another question later on about how to iterate over a tree in a specific order.

Part of the issue was that most of my interviewers were fresh out of college, it was literally their first job and they had no idea what to ask besides the kinds of questions they had been asked in their own interviews.

In the end there were a lot of other issues that made me not take it, but not knowing what is necessary seems pretty typical wrt security. However, in those situations you want to have wide latitude to affect change because the thing they hire you to look at is probably not really where their problems are.

Infatuation with "coding competitions" and high flux intelligence tasks is often an anti signal.

Sure, what they demonstrate looks good at face value, but unless you attach a micromanager over their tasks, they'll constantly deviate to the new-shiny every week instead of staying on task for the long haul.

I know even YC has been bitten a few times by accepting people who are top-performers in very narrow contexts (e.g. people obsessed with winning coding competitions every single weekend) only to see they can't do anything coherent for more than a week at a time.

Just because someone is great in a narrow context doesn't mean they can carry that over the months and years needed to deeply iterate (and suffer through the low points) on successful projects.

Basically, imagine that there's two ways to graduate college with a CS degree - you're either the kind of person who's smart enough to get things if you work your ass off for them, or you're a genius and you coast through. If you're a genius and you work your ass off, you get a doctorate or found a startup, and aren't in the candidate pool. So you wind up with a choice about what to compromise on: work ethic, or smarts.

Ideally, you compromise on whatever makes the least difference to your organization, compared to your competitors. Hiring smart/motivated people out of non-traditional backgrounds is a great option for this.

They're more interested in how you approach real world issues (the questions I got asked were conceivably real-life issues a company like Google would face with its products). If you can solve that issue by applying efficient and well understood data structures and algorithms, then that indicates you understand the problem space and solutions that may apply.

It's not like they get you in a room and ask you to draw a linked list or a binary tree.

I had two phone interviews - the first had quite a few questions about my prior experience (over a decade) and how to approach real-world problems from a high-level, including some that I had worked on at my current position. The second was primarily purely technical, but did have some more theoretical/project-management-y type of questions. In neither one was I required to write any code.

On-site: one interview was entirely whiteboard-coding (in a collaborative style), on a set of related generic problems. Next was one with a set of problems related to my experience. Third was almost entirely telling war stories. Last two were some generic graph-theory-type problems and some simple problems involving data structures relevant to the my area of experience.

As I hadn't interviewed for anything in 11 years, I did spend some time brushing up on my basic algorithmic theory, and essentially followed Steve Yegge's suggestions. I honestly think I probably could have done the vast majority of it without any studying, but spending time practicing solving problems on paper (with a countdown-timer as an artificial pressure-inducing device) certainly did help me, I think, in the on-site. No amount of memorization could have helped with most of it, aside from basic knowledge that anyone who's taken Data Structures should know.

I didn't find the process to be insulting at all; it was an enjoyable challenge. Everyone I talked with on the engineering side of things I can only say the best about, and so far as I can tell the team I'll be with has some really great people. I am a more senior developer, so perhaps I got a different experience than some.

I was later declined. Had a couple of friends at google ask the interviewer. He said I was declined for not finishing my data structure.

Their interviewing process was quite frustrating. I'm fine with getting declined but not under those circumstances.

That was my first technical interview over the phone so it was pretty obvious it was related to that single interview. One of the Googlers I knew that checked the system said the same.

I had the impression that they all had to agree for a hire. Hence one no means no hire.

Once you get to that point, though, if they asked me "and how would you invert the tree in-place?" I'd answer "well, first I'd make sure we aren't just using a tree structure that already knows how to invert itself, or could easily be extended to know how. Then, assuming that didn't pan out, I'd google 'in-place invert binary tree' and read three or four solutions that already exist to burn the semantic structure of what I'm about to write into my head so that I don't subtly screw it up and have to fiddle with it for the next hour when I could be coding something else. Then I code it."

And that should be enough.

Another in the same interview got in my face (this should be easy) when he thought it was taking me too long too multiply two numbers like 637 and 41 during an estimating problem. I understand the point of most of these questions is quick and dirty estimation (600 x 40), but seriously...

637 is an awkward number, we'll start by rounding up to 640: 640 * 2 = 1280, anyone in tech knows 2x that is 2560.

Make up the missing 3: 3 * 4 = 12, 2560 - 12 = 2548.

2548 * 10 = 25,480.

25,480 + 7 = 25,487

25,487 + 30 = 25,517

25,517 + 600 = 26,117.

That said, I did make a screw up when calculating it, and added the 637 before multiplying by 10 (which may have been the differentiating part of that question, combined with the intentional stress, to see how you cope with pressure? Although I didn't sleep last night, which might be the cause :D). I dunno if they wanted you to do it as quickly as 600/640 x 40 though, which obviously makes it much more difficult.

Afterthought, due to sleep deprived state, quicker way to solve:

600 x 40 = 24,000 40^2 = 1600 25,600 quick and dirty, for accuracy: 3 * 40 = 120 25,600 - 120 = 25,480 25,480 + 600 = 26,080 26,080 + 37 = 26,117.

Sorry, this comment turned into a bit of a ramble.

And yet the OP was turned down for not being able to invert a binary tree (based on limited information, etc etc.)? What do you feel that is, if not a "whiteboard this algorithm" question?

As for many of the other companies who try and emulate Google - this is exactly what they do.

Your source is a series of salty tweets.

And in either case, my original comment was directed at the idea that "algorithmic interviews provide false negatives, but not false positives".

You say that as if it's a good thing. Do you expect that most people could be e.g. effective teachers, effective marketers, or effective taste-testers, with no previous experience?

Obviously he didn't give 1 shit about "how you approach the real world issues".

On the other hand, knowing that DFAs are equivalent to regexes are equivalent to NFAs is already a step of theoretical knowledge that any "Just let me write code" so-called "dev" is likely to complain about being asked for.

I too don't remember much.

Regardless, I only meant to make the point that I disagree with the comment "They're more interested in how you approach real world issues" and that this statement is false: "It's not like they get you in a room and ask you to draw a linked list or a binary tree"

edit: by "expert" I just mean something I'm particularly skilled in, not something I'm an authority in from theory to practice.

It's important to know how a person approaches a hard new problem and how easily or not they give up. I'd guess that a person who didn't solve a hard problem, but got close enough by displaying creativity, curiousness and a solid thought process might have an edge over a person that implemented a familiar algorithm with ease but got a little flustered, and didn't show much creativity or inquisitiveness, when challenged with something new.

Whiteboard interviews might miss eccentrics who can't express their clever thoughts verbally or visually, but it can depend on how tuned in the interviewer is to these eccentricities or how much value their team puts on expressive skills.

Algorithm/data structure interviews, whiteboard or not, also have the added benefit of being exceptionally good at eliminating candidates that:

1) Drastically misrepresent their skills

2) Give up easily at difficult tasks

3) Don't seek help from others

4) Frequently have a bad attitude

I had them attempt to solve the problems on a whiteboard that I would give to our intern candidates. Both totally bombed hard, and our other "re-interviewers" had the same result when they asked some design-related and algorithmic related questions.

This wasn't "regurgitating algorithms". It was basic problem-solving and software design. From their track record of development we didn't believe them to be qualified (despite their own opinion of themselves), and they only confirmed it by totally bombing the "re-interview" process (which was identical to our normal interview process).

The only way to validate your highering process is to randomly accept people you would otherwise fail. Anything else is meaningless.

Say I pass the invert a tree question. Does that prove I am good? That I can design a product, listen to customer requirements, come up with ideas that elude others, read a research paper and turn it into something commercial, solder a circuit board, make a schedule, mentor junior engineers, write documentation? No. All inverting a tree tells them is I studied trees recently, and/or I'm at least superficially clever.

Google lets go of plenty of people. They aren't making perfect hires.

Other than to wonder why they still haven't done anything about it. (I interviewed there ~8 years ago, pre Android when they were looking for deep mobile expertise and got flunked out on a similar problem. I am not at all interested in working for them now)

But do you? How catastrophical would it be if Google accidentally hired not the top 0.001% but instead somebody from top 0.01%? I mean, same people that build everything else around us and the world still didn't collapse yet? I get it, you have to have standards, and you don't want to waste time and money on somebody that can't pass fizzbuzz test. But once you've moved past that - do you need to obsess so hard on ranking and quantifying it? There are probably some positions in Google that require people to invert binary trees (speaking figuratively) day in and day out, but my decades of experience in the industry shows that most positions aren't like that. I've not worked for google but I'm pretty sure it's also this way there. If you hire smart and competent people, it's OK even if they don't reverse a binary tree here or there.

Good teams have a balanced skill sets I've found. You need some uber-algorithm guys who can pass questions like this, but you also need engineers who can fill in all the rest of the tasks that make up a production worthy system. I have not found that the uber-algorithm guys always pay attention to detail, put in good comments, think of all the edge cases, communicate well with outside teams, etc.

Those types of engineers are what you consider a "bad hire", and won't be working at Google.

What's to keep a good engineer like you describe from buying a couple of books and spending a couple of months working on becoming the type of person that can do well on these questions?

Google doesn't make everyone multi-millionaires anymore. If you want me to jump through a bunch of hoops for you, you'd better have a pretty solid case for what the outcome will be.

By actively selecting against people who don't want to answer bullshit questions, they're definitely turning away creative, talented people. They're selecting for different people instead. Perhaps that's what Google needs to feed the machine now that the company is mature, so I won't necessarily fault them for it. But that filtering or selection IS happening, even if they don't think it is.

Can they, though? Obviously they believe they can, but are they correct?

Google's not going away any time soon, but they could easily slip a long way down from the top of the heap. There are signs that's started to happen.

I don't think they can be nearly as casual about losing top candidates as they seem to believe. In five or ten years we'll know, I suppose.

I also know a few "top talent" engineers that rejected the google offer because they didn't like the process and the people they met. I know even more ex-Googlers that quit within the year of starting there.

It's not an issue for them? From where I'm looking, most of the experienced top talent (that it's not working at google already) is keeping away from it, in greener pastures and most won't look back.

Yep, google is not going anywhere anytime soon, but I'd be just a bit concerned if I were them.

Like I said, Google is still an amazing company, but it is by no means the only one out there. Talents won't come to work for it just because it is Google, without great compensation and interesting projects.

It never worked, what do you think happens when you start asking these kind of questions in interviews? People just go out and spend insane amount of time memorizing solutions to interview questions on the internet.

They continue the same after you have hired them. So their on the job productivity remains low. Please note, they need to prepare for their next job in the current one.

So the only thing this results is in people spending insane amount of time preparing interviews doing very little work in their day jobs.

I never realized that some people put as much effort into practicing interview questions as I put into learning how to actually write software.

Does this mean technical interviews, even a structured interview, are completely useless? I.e., if you follow an interview script, eventually candidates find out about your script, and then it's useless.

IQ tests supposedly become inaccurate after 150/160, so you wouldn't really want to put too much emphasis on 180 vs 170 at those levels.

"Hmmm... it looks like this guy really gets around. He's on the same project at GoodProgrammer A and GoodProgrammer B. He also tweets about functional programming and was mentioned in GoodProgrammer C's latest blog."

Nothing says Google must accept sub-par technical people, but Google fails to realize you don't have to be the top 0.0001% in absolute algorithms intelligence to do great work.

Google's basic theme seems to be "you must be low latency ultra smart in our narrow interest areas" to pass an interview (or well-connected in other ways to lower scrutiny), but Google's main problem these days isn't lack of smart people — it's lack of projects with meaning and lack of how to organize smart people into anything resembling a coherent world-moving force.

In The Plex is great read for insight into their entire process. Basically, Google is run by people who have never been told "no" to anything in their lives, so they continue to think they are the best at everything until reality forces them to reconsider their delusional assumptions ("montessori naivety").

Which is unfortunate, because objectively Google doesn't actually have a very impressive track record of creating successful products and services given its size and resources. It has a goose that lays golden eggs (the on-line advertising business), two strong on-line services (search and mail, both over a decade old) and two well-established platforms (Android and Chrome, both nearly seven years old). Other than those, most things Google tries seem to land somewhere between unremarkable and complete failure, with Google+ surely the most obvious example of the latter. They also seem to be developing an unenviable reputation for killing things off as a result, which is going to make it more difficult for them to succeed with future endeavours. Whatever workforce their hiring process is producing for them, it doesn't seem to be one that is very good at creating successful new projects.

Google Maps is certainly widespread, but it's hardly the only on-line mapping service available. They keep messing around with the UI, often not for the better. I often find the data itself and the live route planning/traffic news to be inaccurate.

Maybe it's better for those in the US, but here in the UK it's exactly what I meant by unremarkable. The local data from OpenStreetMap seems to be just as good for general mapping purposes and sometimes more accurate and/or current, and for car journey planning and real-time traffic news the dedicated satnav devices still seem to do a far better job.

I've been at Google for 3.5 years (in the NY office) and have never heard this. I don't think I've ever even seen anyone wear a college t-shirt/sweater.

> These aren't Googlers I'm talking about, except the boyfriend.... remember that most of these conversations happened when I was actually in college (a few even before then, while applying to schools), and I just have a really long memory

Sounds like someone who's just into remembering people's SAT scores?

I do wear my college t-shirt though. My graduating CS class was three people, so have to have a little pride there!

I jest.

But if you're Google, why wouldn't you aim for the top 0.0001%? It's not as though you have a shortage of candidates.

And even if there were such a thing, you're not going to find the top n% by asking questions from an undergraduate textbook.

And you're certainly not going to find them by pissing off people with proven practical achievements. Acting like that is evidence of anti-intelligence, not a sign of being smarter than everyone else.

It's one of those "gift/curse" things. It's good they can challenge assumptions, but they don't realize how wrong they are when they are wrong.

There are some notes at http://www.amazon.com/In-The-Plex-Google-Thinks/product-revi... and it's also drawn up nicely in the book itself.

I think you made an excellent point. It seems that outside a tiny minority of world-class experts, Google is more interested in hiring interchangeable workers.

I know some people get frustrated by those kinds of questions, but I'd just see it as a reverse weeding out process. If you still want to work at (insert company here), just build something valuable and have them acquire you. At that point they'll acqui-hire you and you'll leap frog all the people who got in because they had Knuth books memorized.

You know, there is something to be said for someone who has a good product sense, but not good developer skills. They sound very valuable, so why are they applying to a developer position? Just because you are unqualified for one job, doesn't mean you deserved that job, or that you're worthless.

Go do what you're good at.

As such, the best approach to these interviews might be to say, "Look, I could take a stab at that algo question, but I haven't touched that stuff since school, and if I needed it I'd google it. It might be more productive if we talked about what I've been doing day-to-day for the last ten years to ship successful products, because that's the main value I can bring to your company."

Any mature company should focus on finding those specific candidates - the ones who fit the company and specific team, on several dimensions beyond standard skillsrequired for the job. That's someone who will be called the best candidate in that specific company. And it's absolutely natural that s/he won't be considered "best" insome other company.

It was several hours, with many interviewers one at a time, of academic exercises. Some I could see were relevant to some of Google's projects, but that wasn't the emphasis- it was very much a "how much do you remember from CS courses?" (with a few exceptions- one had me explain why a snippet of C would crash- something more what I would expect a senior engineer to know that was more practical-oriented).

I _think_ I did pretty well (again, it was part of a bigger due-diligence-- another story altogether, so I never heard), but in the end I was struck by the fact that (a) not a single interviewer had looked at or asked about any of my publicly available work, and (b) not a single one even asked something along the lines of "what are your strengths / what do you think your contribution would be" (or weaknesses, for that matter, but that seems less important).

Of course, one of the other guys I worked with lucked out and got interviewed by one of the paypal-mafia, and ended up with a reportedly very stimulating hour long discussion about actual work, strengths, and actual situations that one would hypothetically need to handle at google.

And ye olde "what's your greatest strength/weakness" question sounds like a terrible way to judge an engineer.

Asking an engineer what their strengths are and then to demonstrate or explain in concrete terms is how you find out their unique value proposition. I'm not talking about "I'm a hard worker" type garbage, I mean "my strongest experience is in systems programming on Linux." "How so?" "For example, I wrote a specialized TCP kernel module that works like this..."

Again, not saying that should be the whole interview- but there are some non-academic skills and experience (like managing and leading a critical system used by thousands of people) that are worth more than a few weaknesses in problems that were already solved years ago and that are easily looked up. It's how you should judge people looking to get into a graduate program, but falls short if you're trying to build teams of awesome fury that need more broad experience and even (gasp) unique experience that you don't have a ready-made question for ;-)

To illustrate, here's the kind of thing Mr. TCP kernel module should be applying for: https://www.google.com/about/careers/search#!t=jo&jid=107205...

And here's the kind of generic role they probably shouldn't be: https://www.google.com/about/careers/search#!t=jo&jid=34154&

It could be dangerous. Let's say you explain some interesting techniques you used on your GPL'd software and a Google product starts doing something suspiciously like what you showed them. You may even sue and end up making their source public after some litigation.

If they did makes copies of an applicants copyrighted work and distribute it, then they could get sued. Some companies has been know to explicitly ask applicants to bring source code from previous work places (also called industry espionage), and those been clearly intended crimes and not something that just happened to company during the process of an interview.

Only to bad interviewees.

You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board. By "absolute no hire", I mean the kind where some of the interviewers tell me in the debriefing "I will quit if we hire this guy".

Not all excellent engineers have impressive résumés but they all share a common characteristic in my experience: they all really enjoyed working on the problems I asked them to solve on the white board. I even had some of them be disappointed when we ran out of time because we were having interesting conversations about the problem.

Hmm, at least in my experience it's really quick and easy to tell if someone is bullshitting about their resume or not by simply talking about the different projects they worked on. I know a few developers who didn't go to a 4 year school so they don't know all of the correct terms or algorithms (one even interviewed for Google and failed) but I would hire them in a heart beat because they are really awesome.

I still feel some sort of pair-programming exercise or something similar is better than simply trying to solve problems on a white board. Unless you're in a SCIF you're going to have access to the internet to refresh your memory, etc so I've never found utility in asking academic questions. In fact I've had a few people who could pass the academic questions but couldn't build an application to save their life so I don't even bother anymore.

That's just a self-reinforcing selection bias - you hire people that are good at these kinds of problems/enjoy them - you filter out the rest by default and it becomes ingrained in the culture - it doesn't say anything about the suitability of the candidates you filtered out. If you said "we hired a guy who had a great resume but he couldn't do algorithmic problems, turned out to be a bad fit for the company" - that would still be a single data point but at least it would be relevant.

One of the challenges with Google's interview process [0] is they are very worried about hiring mistakes, and also know that the process is very noisy. As such, they interview a tremendous amount of people for hiring. In addition, they've found it more efficient to just keep a high bar (missing many good hires to keep out 1 bad hire) than to conduct more than 5 interviews.

The one thing I've wonder is - if they want the top 100 computer scientists in the world to work for them, will this process produce that? Or is there another process for them?

I think the most effective way to get a job there is to build a small company and get acquihired.

[0] I don't work at Google, but I've researched the process in anticipation of an interview.

Look at it this way. If you're a cream of the crop programmer and you're looking for a job, Google has the most drawn out and arduous hiring process. Even if you apply there and start the interview process it often takes a lot longer than the industry average to get to an offer. In the meantime a multitude of other companies have probably already determined that you are an excellent programmer and tried their best to snap you up.

Google seems to be happy with the tradeoff they're making but I'm pretty sure their process is not optimized for getting the best people in the field.

Many of the interviews could actually work if they broke the process down into 8 questions instead of one (how would you represent a tree? a binary tree? how would you find node X? how would you move node X to the other side of the tree?). But, the ability to accommodate understanding takes empathy and human connection, not being a jerk programmer on interview duty who is browsing HN while listing to the interviewee mumble on your speakerphone.

Never underestimate the lack of ability in the interviewer and not the interviewee. Except, the company always believes itself to be more competent than outsiders, so you're ultimately left with being condescended to unnecessarily.

Whatever! They asked me back but it sure is a frustrating feeling even if I tend not to appear flustered until I walk out, introspect, and realize what a doofus I was.

They don't just stop at binary trees. Think of it more like memorizing hundreds of magic tricks that could be done using a deck of cards. The tree is more analogous to those deck of cards. The data structure remains constant but the tricks you can do keep changing.

I know of situations where candidates have been grilled whole full hours on tree traversal methods, and then asked to code up perfectly working solutions for them.

Do these people seriously think people who can invent 50 years of CS research by sheer analysis over an hour on the whiteboard, will be ready to work for them to write shell scripts? If not you are only testing memory skills.

One thing that I'd recommend to anyone seeking any kind of job is taking some improv courses--they are pretty common in major centers and even some smaller towns, and can really improve your ability to deal with this kind of nonsensical interview situation, which tests a bunch of skills that have nothing to do with your ability to actually do the job.

The answer was transactions (database). You never forget that sort of mistake.

Of course, the irony is that for vast majority of the people they hire, most of the work they do will be building and not much algorithms work. So then what will happen is either you have people who are great at building things and force them to suffer through the interviews or you have people who are great at algorithms but not that interested in programming.

Of course, you might also have people who are great at both, but I wonder how many of them there are..

Correct me if I'm wrong, but a binary search tree is a very simple data structure. It has rules, and just by it's definition, and the definition of "inverted", you should be able to come up with an iterative solution, even if it's just walking the tree and re-creating it.

It may not be the best, but it's a solution, it's a starting point.

But if you're interviewing for a job solving problems, shouldn't you be able to solve problems? Even if they aren't the best solution? Genuinely asking here, as this approach seems to have a 85-90% success rate for me.

While there certainly are incompetent interviewers, I think ones that extreme are rare.

See also: overused brainteasers. I remember being asked the 5 litre / 3 litre / get 4 litres problem for my Microsoft intern interview, and honestly told them that I already knew the answer, so I wouldn't be "solving" it, but here it is anyway...

Once I notice that it's not really going well, I try to politely as possible suggest that maybe we adjourn, so as to not waste each others' time. That hasn't really ever backfired, and actually turned one rejection into an offer, but I find it's polite to respect everyones' time.

Engineering is the use of knowledge/science to solve problems, right? So why is asking someone to use knowledge to solve a problem not applicable to the hiring process?

To be clear, this isn't the same question as "why are manhole covers round", or "how would you move a mountain".

If these problems were so reliant on individual problem solving ability, there wouldn't be dozens of books with reams of answers to these questions on the market. These questions test memorization and nothing else.

Google said early on they want to hire the best and brightest and that was the most important. We got the mantra that passing over a good person is better than hiring a bad one. And they were right. But they're a huge company now. They, and other gigantic tech companies are always complaining they can't find 'good people'.

But how do you make this philosophy scale? Do you say, "This person is smart but lacking some skills so we'll invest in them"?

I have no idea. :(

Google has decided that the only way to tell if someone is smart is by asking academic questions.

Even though anyone with half a brain knows that there are other ways to gauge how smart a person is... such as experience.

Does anyone really think Max can't look up how to invert a binary tree if he needs to do that? He obviously knows how to read and learn. So why is that a reason to reject someone?

Google is filled with smart people.. but their interview process is pretty stupid.

Google is filled with people who can solve Data Structure / Algorithm questions in 50 minutes on a whiteboard. Their interview process selects for people whose past experiences led them to being able to solve Data Structure / Algorithm questions in 50 minutes on a whiteboard.

The extent to which solving Data Structure / Algorithm questions in 50 minutes has anything to do with building maintainable production software, developing talent, a good working environment, or even this mysterious concept known as "being smart" is up for debate.

I wonder about that, actually. I mean sure, right after they're hired, I bet they're GREAT at doing whiteboard problems. But then after a few years of real work, I bet they've coded about as many algorithms from scratch as the guy from Unknown, Inc. (which is approximately two) and they probably wouldn't even pass another Google interview without a boatload of practice.

My guess is that they're unable or unwilling to improve the process but they don't really have to since they're deluged with candidates.

I think I'm really smart.

Therefore, our current interview process manages to hire really smart people. Why change it?"

The "can't find good people" argument can usually be solved either 1) raising the pay, or 2) increasing the labor pool (i.e. H1B, etc). Raising the pay is what is done in finance because it's harder to make the argument that the required "skills" are lacking in the labor pool. To enter investment banking, and then private equity, it often only requires a B.A. in French literature and willingness to work 90 hours.

I guarantee if dev positions paid as much as medicine or ibanking you'd have more devs. Not necessarily really good devs, but certainly people who pass the Ivy + 1600 SAT sniff test and can memorize the SAT book of Google interview questions.

Google (and other interviewers) might as well be asking me to name the last 1000 digits of PI. The Kafkaesquen ability to recite how to do the task correctly reflects nothing about the candidate, except the strength of their memory.

It boggles the mind that the field of computer science does not have any standard way to detect the competency of a person. It is extremely discongruous for a company with as many smart people as Google to have such an absurd hiring policy.

"I see your resume says you've been writing software for 30 years, and wrote this really well known tool. Wellllll....That's good enough for me. You're hired!"

I don't support skipping interviews even for good candidates, but if you were going to it would work the other way around -- you'd value recent accomplishments over more distant ones.

People don't understand that cutting out folks who had their name attached to some big successes but can't solve a toy problem in an interview is usually a really good thing. It's a strength of the system more often than a weakness. You wouldn't believe the number of senior candidates I interviewed who had really impressive resumes but were clearly checked out from doing real technical work -- folks who obviously no longer lived close to the code and either were very rusty or just no longer had the temperament to spend time thinking through a slightly tricky piece of code.

One of the reasons not to skip an interview for a candidate you're confident is good is that a good interview can be a great sales pitch to come work for your company.

IIRC, a Portuguese proverb states that paper accepts whatever is written on it. One should always take a self-assessment with a grain of salt.

Without running a `git blame`, the interviewer cannot say how much of the code is from the author and how much is contributed by someone else and even then asking questions is an important part of any interview.

I'd take the 30 minute interview route and risk not hiring a clever programmer.

If a guy has some kind of a git-mutating program that makes it seem like he writes good stuff, he's probably a good programmer to be able to write such a thing.

If they can't talk about what problems they solved, they probably didn't solve any.

Investment banks recruit bright young graduates, putting them through a tough selection process (c.f. all those hard-working interns we keep reading about), and select the ones who perform/conform the best. The rationale for bringing in young (as opposed to experienced) people is that they'll work their asses off, can be moulded to fit the culture (i.e. independent thinkers aren't necessarily sought), and (perhaps most importantly) are too junior to present a threat to the incumbents.

If Google's going down the same path, it may be a sign that their corporate culture is solidifying, which would be a bad sign, IMHO.

1: https://twitter.com/mxcl/status/608698037100244992

For the top elite of experienced engineers that may not be the case, as they will come with some overall good analytical skills that Google wants. But for most in our industry, what we have learned over the years is how to be good in various sets of tech around our platforms of choice... and that is mostly irrelevant to Google, as they have their own platforms.

But then it occurs to me that they won't have seen them in -this- role acting -this- way for -this- film/play/whatnot and that's what the director needs. And given the amount of money and risk involved, it's probably wise to check first...

My team does whiteboard questions, but we try to keep them practical.

Typically they are the types of problems that we'd expect new engineers to have to look into on their first day. Oftentimes the questions are less "come up and an answer" and more "let's explore this problem domain and see what we can uncover."

As an example, the interviewer will write up on the board a data structure that is too big and has redundant fields in it, and start a discussion about how to optimize that structure. The optimizations go more and more in-depth as the candidate gains experience thinking within the problem space.

Another problem, the interviewer will give an example of a synchronous operation and work with the candidate to break it up into a set of asynchronous calls.

My team tries to avoid "puzzle questions with 1 correct answer".

I do ask simple data structure questions just to test basic programming skills. On occasion someone does make it through who cannot even write a FOR loop.

My standard go to question is "Please do an in order print of this already sorted binary tree."

It is 5 lines of code, and ~80% of candidates who haven't seen a tree in a decade can still figure it out.

IMH the goal isn't to try and trick people, it is to try and see if people can hold a conversation about a technical topic and make valuable contributions to a discussion.

What I mean to say is, I have tended to use existing libraries that might make use of binary trees, but that I have never had to print or modify them. If modification is necessary, it's always through the library. So while I understand the basic concepts, I'm having trouble understanding why it would be a useful interview question.

Do developers at Google and Microsoft actually manipulate binary trees on a daily basis? Like, ALL of them? I can understand that they would be a common thing in the bowels of some code, but surely not all developers in either company would run into them on a regular basis?

It all depends on the team though, the interviewing process is completely non-regulated here. We get training telling us what to legally not say, but other than that is a free for all.

Teams ask white boarding questions because they heard other teams ask white boarding questions.

http://finance.yahoo.com/news/11-common-interview-questions-...

1) Actual programming and a technical interview are not and never will be the same thing. Assume you know nothing. And I do literally mean nothing. 2) Start with a basic intro to programming book in a language you aren't familiar with and try to do simple tasks in a language you already know. This simulates a bit how it feels to program under pressure. Things you know you know seem not to come out quite as quickly. This helps to emphasize point #3. 3) Practice. Practice. Practice. Practice. Practice. A decent chunk of your typical interview questions exist out there. I'm not saying to memorize them, but be familiar with their solutions. Eventually you'll get to the point that an approach for solving a new problem will come from pieces of old ones. 4) Since coding is done on whiteboards, do not use a compiler. Pencil and paper. 5) Find someone to give you an honest-to-goodness mock interview.

While this may be quite different from interviews for MS Redmond/etc full time jobs, this was my experience:

In my interviews, I mentioned off the bat that I wasn't great at algorithmic stuff. Now, don't get me wrong, I can do them, I'm just far, far behind the curve. (Students, esp. CS students, in India spend lots of time on sites like SPOJ and CodeChef solving algorithmic questions; I prefer to do stuff in open source). The interviewers were understanding. I got asked fun stuff like "what do you enjoy about [project I work on]". "Walk me through some large problems you grappled with on [project] and how you solved them". I got to have great back-and-forths on these things. It wasn't easy explaining nuanced and intricate problems, but I was able to give them a rough picture which I think is what they wanted. Shifting the focus from "can he solve this puzzle" to "what work has he done in the past" was great.

There were also algorithmic-y things, but not the usual kind. For example, one interview focused on designing and optimizing a build tool. The idea was that we had a bunch of components, with dependencies on other components, and I had to efficiently generate a viable order of building. There were some other constraints which I forgot. I realized that the problem was similar to a garbage collector (not that I knew how to model that either :P), and did some sort of mark-and-sweep thing. Then, after being asked by the interviewer, I optimized out some for loops and stuff.

I didn't need to know any algorithms beforehand. Sure, if I had known how `make` does dependency management, or had read up on garbage collectors, I would have done it faster. But I didn't need to know anything, and it worked out.

My fellow interns had really rigorous algorithmic interviews. They were okay with that because they were good at them. It's understandable that "solve this puzzle" is the default since not everyone has real world projects they've worked on (students). I don't like the status quo, but I don't think the interviewers will be intent on maintaining it either. If you have stuff you've worked on that you'd prefer to talk about, I think they'd like that.

If you think the interviewer will be open to it, I suggest mentioning it. They will know you're not from CS; you can mention that you don't have much practice with algorithmic stuff.

Major YMMV though. Also I've done very few programming interviews so the advice here could be totally misguided. :)

Generally, you have a problem, you research, you experiment and then you wrap all that in a nice easy to use utility class or api and forget the details because there is something else you need to work on and that problem was just one piece of the puzzle anyway.

The worst hypocrisy in all that, is if you ask a specific question to a veteran developer on a average size codebase, he will very often need to look in the code and you will not think any less of him. But if it is an interview and he does not remember some trivia in a piece of code he didn't write - my god, he is a loser.

No computers. Pen only.

For me, rehearsing an answer works out. Then, I try to see how to deconstruct it and apply it to a similar problem I don't know.

I can deliver an answer sounding confident and competent because I practiced an answer. It's a bit of a crap shoot.

What irks me the most is that people are doing the interviews. They can be fooled and persuaded with tones and intonations without them realizing it.

It's not. I hate whiteboarding as much as you but I try not to think of it that way. This method is just a way to increase your chances of succeeding. I've not succeeded in every interview, for sure.

I do what I must to press on. :(

The best thing to do is not to take the rejection personally. I always ask, as nicely as possible, what areas I should focus on to improve for the future.

Sometimes I get no response but I often get replies, good replies.

We do what we must.

That's true. I have other features that reduces my chances of getting hired, but doesn't eliminate them. Still, I wish I had someone else's mind.

Have a friend do a mock interview with you.

You spot patterns but there's so many different ways they can ask things and things that you just remember from studying it, that I imagine I'd do worse now unless it was close to what I've done since. On the spot I couldn't invert a BST right now.

I suspect you could probably pass a whiteboard interview a few weeks after taking a mooc on data structures/algorithms with enough depth for example.

That said, memorization, in my limited experience, won't be that helpful, because the questions will likely come with a twist that requires that you understand the algorithms and are good at adapting and applying them - and you need to be able to do it in 45 minutes on a whiteboard. It is very difficult.

I did find "cracking the coding interview" to be helpful prep, and really, the hard problems are fair game. Again, memorizing won't really help you, instead, view these as the kinds of problems you need to be able to solve in 45 min at the whiteboard.

I am kind of blown away that people can do this. I went home and did one of the questions I remembered from my interview with a compiler, and it took me several hours (though I didn't look up a solution, I did use the compiler constantly to check logic, and so forth, something that isn't available of course if you write on paper or a whiteboard). I suppose might be able to get this down to 45 min at a whiteboard, but it would take me a lot of time to get that sharp, months or more of study and practice.

None of this is mean to comment on whether this is or isn't a good interview process, it's just advice on how to prepare.

Yeah...that is memorization. I've had questions like that before and the problem isn't adapting. Its the fact I don't have everything memorized. I have no problems taking an algorithm off a book/Google and implementing it in 45 minutes, even with some kind of twist.

The problem is I can't remember things I haven't used in 10 years so expecting me to do anything with them in an interview is kinda pointless. Sure, I'll remember the purpose of the algorithm, but I'm not going to remember the algorithm implementation details.

I didn't get past the technical interview at google or amazon, so you might want to take advice from someone else, but here's what I think I'd need to pass the algorithm section of the technical entrance exam at google.

You must be able to do the following in about 5 minutes or less at a whiteboard with no errors:

1) print all permutations of a set 2) build and print a binary tree (preorder, postorder). 3) create a hashing function 4) quicksort and mergesort

(I'm leaving out linked lists, arrays, stacks and so forth because you won't be able to do 2 or 3 without them anyway).

The reason you need to memorize these (yes, I'll go ahead and use your word now, I agree with you that this is memorization) is that you can't be dealing with how to implement these if you're going to do enough in 45 minutes to pass the exam. I think that these three things form the foundation for most variants on recursion, sorting, traversal, combinatorics, and so forth.

Next, you need to be able to identify when something is a variant of these algorithms and solve it very quickly at the whiteboard. "Cracking the coding interview" is good practice for this, but in this case, I don't think "memorizing" these questions and answers would be especially helpful, because you're unlikely to get that exact question.

Here are a few of questions I've invented on the spot (not from my interview, not from cracking the coding interview) that you'd probably want to get close to solving in 45 minutes or so. In other words, if a buddy wanted to apply to a top tech company and asked me to give him some practice, I'd give him 45 minutes at a whiteboard for each of the following questions.

"In a binary tree with positive and negative integers, find and print all paths with a positive sum. Now assume the tree is ordered, and make your code more efficient."

"In an nxm matrix, find all sub square matrices with a positive determinant."

This might just be me, but I was kind of struck with just how much progress and accuracy you are expected to achieve at the whiteboard. And like I said, I am kind of blown away that people are able to do this. While I can pose those questions and develop a mental model for how to approach it, I just couldn't solve them at a whiteboard in 45 minutes to anything approaching what I believe is the standard.

Again, whether this is a good way to filter people out isn't something I'm discussing here, this is just my advice if you are planning to apply and want to be prepped. Also, there will be more than just data structures and algorithms on the exam.

That is why I stress its memorization because without memorizing things you've long since abstracted to libraries, you really can't perform in the stressful interview situation to the level the interviewer expects.

If, however, you take something the interviewee implemented in the past 6 months as the "standard problem" they could probably do it without much trouble.

i based my comment on the only thing I could find: https://wwwx.cs.unc.edu/~duozhao/entry/2014/12/binary-tree-u...

this is only slightly harder than the trivial (if u know recursion) "mirroring" a tree problem

For big companies that want to scale hiring process, there's really not much you can do.

You put difficult questions and you hope that bad engineers will not be able to solve them. Then you absolutely have to commit to not hiring the guys who can't solve the assignment, otherwise it's all for naught.

I should have turned it down. I've written on this thread already what a career-churning waste of time my brief stint at Google turned out to be because I was blind allocated.

Fortunately, the skills that got me noticed by Google were in demand elsewhere then (and, ironically, in demand at Google now) so I just exited the building when it became clear HR had labelled me a troublemaker for trying to find a position that made use of my talents rather than opt for the career reboot they seemed to expect of me. Great perks, but the 2nd worst gig I've had my entire career.

I quit after a month or so. Later I learned their bait and switch tactics were S.O.P. and the company mostly existed to fund the CEO's various mistresses.