At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees.
Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how much do you want to work here." If you care enough, you can pass. That said, these types of interviews do favor fresh grads over experienced programmers (you have algorithms and data structures fresh in your mind), which means that they are flawed in IMHO.
These types of interviews work really well for the "I got 1600 on my SATs and went to {insert high profile school here} crowd" There are books out there just to prep you for Google interviews I see these as very similar to SAT test prep books. I'm not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
Think of the problem from Google's perspective though. At some point, you have tens of thousands of candidates and you need a system to quantify how good they are. Further, it's reasonable to have false negatives (people you don't hire that should have been hired) but really bad to have false positives (people that you hire that you should not have). Together, these boil down into the de facto whiteboarding interview process.
This has got to be the biggest hiring fallacy I've ever heard. "It's better to reject a good candidate than hire a bad candidate."
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!
Those are simple numbers, but they don't get at the real issue. People say that because 1 bad hire can have negative effects on the whole team, causing others to get less done and leave. Missing a good hire doesn't poison your team.
But 1 bad hire is easily correctable - you fire the person. You won't know that you missed on the good hires.
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.
>>But 1 bad hire is easily correctable - you fire the person.
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.
> it is your god damn job to find a way to make it work.
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.
> Trying to force someone who doesn't fit the team dynamic to stay is going to hurt your org.
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...?
> 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.
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 been a manager, and I have had to fire people.
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?
"it is your god damn job to find a way to make it work"
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.
If Google didn't apply the equivalent of the Hogwarts Hat to placing its employees, I'd agree with you. But in doing so, they remove the ability of the potential Googler to meet their potential teammates and decide whether it's a good fit.
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.
Hmm. When I joined Google, I interviewed the managers of both teams I was offered a position on, and a team member on the one I ultimately decided to join.
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.
Two decades in the valley has taught me that you can't decide anything in a half hour conversation beyond recognizing an absolute bozo incarnate. You need to meet the whole team and preferably have lunch with them and figure out whether it's the right next step. What Google does instead reeks of magical thinking to me.
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."
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.
>People say that because 1 bad hire can have negative effects on the whole team, causing others to get less done and leave. Missing a good hire doesn't poison your team.
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".
> 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.
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.
I agree with you that if hiring strategy B led to hiring 10% of the good candidates and cut the odds of hiring the bad candidate to 0.5%, compared to 100% and 1% for hiring strategy A, then strategy B is worse than strategy A. However
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".
The original slogan "It is better to reject a good candidate than hire a bad candidate." specifically says to make that fallacy.
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.
> 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.
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.
But the US is the place where the "It's better to reject a good candidate than hire a bad candidate" mantra comes from! European companies practice it, but they do it because they're forced to, and they don't preach it like a gospel. The US does it without any need to do it, and thinks they're gaining some sort of advantage in the process.
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.
Here I see the same logic that caused the TSA. Some rare and bad event happens, and people rush to rebuild the whole system to never let that happen again. Not even considering maybe accepting that rare and bad events happen and dealing with them more efficiently would be better? Maybe rebuild actually doesn't even prevent bad events, just specific type of bad event that already happened and is unlikely to repeat anytime soon? Maybe dealing with imperfection is better than trying to be perfect every time?
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?
Because it's hard to fire someone. Lets discount the emotional cost completely and simply look at this in terms of financial risk to the company.
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.
Idiot: We don't want to make any bad hires! Therefore, we reject a lot of good candidates!
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.
It's actually fairly reasonable. The manager doesn't want to avoid hiring bad candidates. The manager wants to avoid being blamed for hiring bad candidates. They want to be able to say "I looked really really hard for reasons why Bob was a bad hire, and didn't find any, so you can't blame me for Bob being a bad hire."
Whether or not this actually reduces the number of bad hires is beside the point. It's a classic principle-agent problem.
You're missing something vital here. They're not rejecting good candidates because they're good candidates, they're rejecting them because they're not sure enough that they're good candidates.
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.
Strictly speaking, I think raising the standards also could lower the probability of a bad hire (depends on the model - is bad hire completely random? does it depend on some parameter that is controlled?) together with a probability of a good hire, so I'm not sure it is a robust argument that raising standards always raises chance of a bad hire. I'd be happy to see a more rigorous proof (I know it's complete waste of time but for some people it's fun).
Basing all of your management decisions purely on statistics is a bad strategy. You're assuming that the weighting of good vs. bad candidate is the same, when they're not.
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.
People have an irrational belief in their ability to tell the difference. This is how one gets such flawed thinking in the first place (regarding priors and probability distributions).
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.
Not really. The population is large enough that you're treating each potential hire as a random variable. Given the amount of possible good new hires the effect of passing on one actual good hire has negligible effect on the next potential hire.
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).
> The population is large enough that you're treating each potential hire as a random variable.
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?
The difficult thing with hiring bad candidates vs not hiring bad candidates is that you get to experience the bad hire every single day, so it is quite apparent that you made a mistake. With not hiring a good candidate, you don't really know what you were missing. You may just assume that the best applicant you reject is no better than your average employee. But there is a chance that that person would bring something to the table so unexpected that you can't even imagine the world that would have been had you hired them.
Apparently you hadn't been recruiting anyone in Europe. Once you've hired a bad candidate, it is very hard to get rid of it (borderline impossible in Scandinavia, for example).
I understand your point, and I'm not trying to be a troll.
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.
And why don't they count the cost of good candidates who simply drop out of their hiring pool entirely, because they can't be arsed to bone up on the easily gamed idiotic hiring process?
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."
Of course, people hired after their second interview are more likely to be mediocre, because people with more options are more likely to not re-interview (like mxcl https://twitter.com/mxcl/status/608687283869503488)
If only whiteboarding interview processes actually weeded out false positives.
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.
That last sentence is telling. Would you even consider working there if they had no idea what to do? I have worked at established companies where there is clearly nobody at the helm and it is frustrating.
I considered it for a bit, they were hiring their first security engineer, so it's understandable that they weren't very sure what they were hiring for.
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.
I'd generalize your point a little more - for a given level of life success, intelligence will anti-correlate with other hire-ability skills like work ethic, diligence, attendance, emotional stability, professionalism, etc.
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.
That's not what the interview process is like at all.
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'll be starting at Google in a week and a half. I can't go into specifics, but I can say this:
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.
When I interviewed with them, it seemed the interviewers had quite a large effect on how each session went. I had four great interviews, and two that were unpleasant. This had very little to do with how challenging the questions were and a lot more to do with the style of the interviewer.
My experience wasn't a real life type one more academic instead. My interviewer was really late and refused to let me finish my data structure implementation to optimize a single method instead. When we finished it was time for him to go. He wouldn't let me go back to finish my data structure as he didn't have the time.
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.
I can assure you my story is accurate. The interviewers do not make decisions regarding the entire hiring event but they do give feedback regarding how you did in each interview. I was given poor feedback due to, according to him, a zero tolerance like policy where the data model for that particular question had to be complete and I was unable to complete it.
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.
The important part of the "realistic" process is the part where you go from "the crawler's indexing is too slow" to "it might be because it allocates a lot of little bits of memory; it needs to first generate a BST of outbound link weights, and then functionally invert that into a second graph with a bunch of inbound link weights, and then inject all that into the PageRank matrix. You could probably save some time (though at the cost of memory-safety) by inverting the first BST in-place."
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."
One of my interviewers at Google asked me to implement a balanced tree insert on the whiteboard in C. After doing so he immediately told me it wouldn't work. I searched futilely for a minute or two to find the problem before he condescendingly pointed out I had left out a semicolon on one of my statements...
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...
RE your second paragraph, it's easier than it sounds.
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:
Of course multiplying two numbers is easy: primary school children learn how to do it. Doing it in your head under pressure in an interview is entirely different.
> It's not like they get you in a room and ask you to draw a linked list or a binary tree.
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.
> There are tens of thousands of employees at Google. Most of them interview.
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?
That said, I recently heard about a Google interview where the interviewer asked the question and left the room for 30 minutes while the candidate white boarded.
Obviously he didn't give 1 shit about "how you approach the real world issues".
Ok, on the one hand, you should be able to answer the question with, "Get a standard-issue POSIX-conformant regex library. Next question!"
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 was asked that question about 7 years after reading Mastering Regular Expressions and about 10 years after taking Automata in college. It so happens that I am an expert in regex, have a patent in the field, regularly answer stackoverflow regex questions for fun, etc. Unfortunately, the question involved me actually drawing a DFA, trying to remember the notation, etc. At this point I don't even remember the particular question, only that I couldn't remember how to draw or read the diagrams.
The interviewer told me this was a favorite question of his. Also I don't think I presented myself as a regex expert to them. Anyhow, I'm an expert in regex like a DBA would be an expert in SQL or particular databases. The interview was for an ordinary software engineer role.
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.
I think what Google tries to find are the engineers with creativity, skill and ability to work intelligently at a problem which they haven't seen before.
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.
I think you want to think that way, that whiteboard interviews have a shred of competency about them. I bet you dollars to doughnuts though 9/10 times a company will hire someone who can regurgitate algorithms rather than an eccentric who can't get them right but thinks really cleverly.
It seems this criticism is of the interviewer making a poor decision based on missed/incorrect observations, not with the whiteboard interview itself.
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:
I've never answered it wrong and gotten hired for my "thought process" even if I was close. I had to fart around on my own for another ~15 minutes to fix my bugs to make it work. But it seems they just want a guy who memorized it and pretends to discover the perfect solution on the first try.
On two occasions I have "re-interviewed" current or past developers who wanted to move up from working on extremely simple low-complexity code / sysadmin work, and start working on our flagship project. In both cases the team leads and I didn't think these people were qualified to do so, but the candidates were really convinced they were. These were employees who had come into the company through non-standard channels, so hadn't experienced our normal interviews.
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).
Nothing you said actually means they could not have done the job. You basically said, we gave them a test and they failed so clearly the test was a good idea.
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.
They have publicly admitted there's no correlation between their hiring process and outcomes. I'm not even clear [why] we're still debating this.
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)
To show that there is a correlation you have to quantify both hiring process evaluation and job performance. Since both are elusive quantities that are hard to quantify, showing there is no correlation may just mean that measurements are done poorly. E.g. when job success is measured by boss satisfaction.
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.
Yes, exactly, since it's Google, they can afford to have strong filters which will definitely filter out a bad hire, may be at the expense of rejecting a good candidate. Their policy might expect good candidate to get absorbed in Google one way or other, but they definitely want to filter a bad hire. However, in the recent years, I have seen this to be not working as expected. Still, I don't think it matters to Google as an big organization.
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.
> 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.
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?
> 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.
I'd rather flip it around - what's the reason for me to do that? I don't see them offering obscene piles of money anymore, so they don't get to make up ridiculous hoops and demand everybody jump through them. This stuff is rarely useful in the real world, and when it is, you can grab something off the shelf, or look it up then. I'd rather spend time learning the other stuff on that list, that's useful to companies that have their priorities straight.
There is a glut of interesting opportunities out there. For me personally, there are just many more interesting ways to spend my time than revising the CS classes I took almost 15 years ago.
In the long run, this could affect Google, but, then again, if they change their hiring policies for better even after long 5 years, the best talent that might had been rejected before would still go to work at Google. So, still I don't think Google really consider it as an issue for them. Though, I have been burned once myself by them.
I don't consider myself "top talent", so I won't comment on my own experience through the interview process. But I do know that I don't want to work for google. Hell, I'm happier doing my own thing.
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.
Google is not the Google it was. I mean I still consider that working for Google is attractive, but things I get from tens of my friends who work there are to say the best....mixed. Google might still have the vigor and excitement at its core, but unless you are an already exceptional engineer, the work you get assigned there, often times, ranges from bland to boring.
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.
>>However, in the recent years, I have seen this to be not working as expected.
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'd rather spend a year learning Python or Go or whatever, instead of spending a year practicing interview questions.
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.
This cracks me up a bit. I don't have anything against whiteboarding, even though I find it meaningless. With this you more often than not have false positives.
And if Google had so many resumes they have to filter through, then why do they have all these recruiters literally spamming you to join? they have recruiting issues like many others tech companies, but the whiteboard is really a bad filter. I've seen very much capable,competent and experienced engineers being denied just because they didn't spend too much time learning cute algorithms or coding in the whiteboard, in front of interviewers sometimes more focused in showing off how smart they are.
"Google's perspective" shouldn't be a monolithic thing. Sure if you're sorting through candidates that were dropped on you then this process makes sense. But if you've discovered someone that by reputation and demonstrated code base has already excelled, and you're actively chasing them, then the interview process for that individual has to change. It's more about seeing if they'll thrive in your environment, and convincing them that you're an inevitable part of their career.
It's true that evaluating candidates is a hard problem, but you'd think that at the very least they would try to evaluate them based on skills that will actually be used in the job. Judging programmers based on their whiteboard skills is like judging a ballet dancer based on how eloquently he can describe his training routine.
Well, my suggestion would be to use Page Rank to sift through the resumes. If you are respected by respected computer programmers then your "score" goes up. They could measure that by mentions in a blog, twitter "conversations", Github commits on the same project, etc.
"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."
People have previously mentioned hallway discussions at Google routinely devolve into bragging about SAT scores and GPAs.
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").
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.
Triple up-vote for this. That said, As said before, I would say if they get more applications than anyone else, their pool of possibilities is larger, so, even if their hiring process is sub par, it's still possible to get more better people. They have a lot of good people and quite a few really good people. And, likely more of those really good people. Someone has done the numbers.
It's a question of efficiency and maybe one of those smart ones is optimising it. It's quite possible that the process that looks shit on the outside is producing the right numbers.
It seems we have different definitions of "excellent".
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.
And Google Maps was built from acquisitions like Where 2 and Keyhole. Their data processing has improved vastly, but the product seems mostly unchanged.
> People have previously mentioned hallway discussions at Google routinely devolve into bragging about SAT scores and GPAs.
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 worked in one of the Mountain View offices for a year and a half with people who had never even been to college, and never heard that. Doesn't mean it never happened but the idea that it's even close to common is just laughable.
I do wear my college t-shirt though. My graduating CS class was three people, so have to have a little pride there!
My friend worked at Google a few years ago (in a non-engineering role). After his in-person interviews, the recruiter called him back to ask him how many hours he worked during college (to pay his way), so as to excuse is less than 4.0 GPA to the hiring review board. He had completed his undergrad degree was 20 years in a subject not directly related to the Google position. He since had an relevant MS degree and real-world work experience, but that undergrad GPA was apparently still really important.
> 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.
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.
Because there's no such thing as "the top 0.0001%". Software development is a collection of talents with multiple basis vectors, not a single linear talent you can stack rank.
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.
Do the math: 0.0001% of 7 billion is: 7,000. How many employees does Google have? Not to mention the fact that of those 7 billion, probably at least 6.9 billion have no appreciable training in software development, which would leave you with 100 candidates.
> Google is really interested in hiring the best engineers but rather a specific type of engineer.
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.
Exactly. I see it as a tacit admission that you are effectively a cog in a wheel if those are the kinds of questions they are asking.
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.
Really? Being able to solve basic CS101 problems requires some sort of privileged upbringing? I grew up poor - my family lived off food stamps for a while. This stuff is easy. I find it disgusting the level of entitlement swept throughout this thread. Oh Google HAD to give you that job, it was yours and they stole it by testing basic skills.
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.
I suspect the issue is that programmers right out of college are strong on testable skills (like how to do X to a linked list) and weak on experience-based skills that are harder to test (like how to keep projects under budget or how to manage technical debt). Whereas veterans naturally tend to be the opposite. And hiring processes naturally tend towards what's easier to test.
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."
I aced some data analyst interviews fresh out of grad school. A lot of the questions were excel and probability questions, which I used to teach. Now, I have more experience and knowledge, but I would be much slower in those interviews.
>not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
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.
I interviewed @ google several years ago as part of some due-diligence they were doing to decide if they wanted to acquire the startup I was working at, [redacted].
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.
Your previous work is what gets you in the door, but interviews at Google are explicitly structured so that you need to demonstrate competence right then and there.
And ye olde "what's your greatest strength/weakness" question sounds like a terrible way to judge an engineer.
Makes sense for google. And it's not that I didn't appreciate doing all that (and I did do well), it just struck me how they knew nothing else about me afterward except that I could answer academic questions, and how different that was from the startup world- where, at the very least, you want to know what they're passionate about and that they are productive.
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 ;-)
For broad-spectrum roles like software engineers, Google hires people first and then figures out what team they should join later. If you want a specialist role, then you'll need to find one on their jobs page.
> not a single interviewer had looked at or asked about any of my publicly available work
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.
You can't make anyone making source code public, only stopping them from distributing copies of code which you have authored. Copyright and patents works very differently, and its quite hard (impossible) to copy source code wholesale from a interview by accident.
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.
Replying to myself- too late to edit. Some other comments in here lead me to believe there would be experience-related questions ideally these days. Again, my experience was a few years ago :-)
"How much do you want to work here?" is probably a better predictor of your performance on the job than your experience is. I don't see the problem with that: IMHO, the fresh grad who really really wants to be there should be hired over the experienced veteran who's just putting in time. I'd like to think that an experienced veteran who really really wants to be there would also get the job, though, over both of the other candidates.
> At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees.
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.
> 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.
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.
>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".
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.
I would agree with what you said if you replaced resume with reputation. Anyone can fill out a nice resume.
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.
Well I know one mistake they may have made in hiring. Guy I used to work with had a totally unclear design process and couldn't complete his work. He would design flawed algorithms that made no sense to anyway and then he asked for lead a project which he dug himself into a hole and had me pulled in to help him and then abandoned me and left the company. Spent 3 months cleaning up his mess. I wonder how he is working out for them...
Ah, they are very unlikely to get the top 100, but very likely to get e.g. 100 of the top 200? Now I think I understand the trade off they are going for (e.g. Getting 100 of the top 200 is more efficient and they are "good enough")
Eh I don't know that they're getting 100 out of the top 200 either. At some point Google's reputation for an insane hiring process causes the best computer scientists to not even bother applying because it's a waste of their time. Those people have many, many options that would pay them handsomely for their talents.
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.
It's also stressful. To be fair the tree problem he got was easy, but brain freeze can kill you. I flubbed a trivial problem at a FB interview that still haunts me today.
Often it's completely free-form too. So you have to pick the language, the data model, the data structures, the traversal mechanism (recursive vs. iterative), state to track (allow duplicates? prevent infinite loops?) and how to test the example all at once before even getting _started_ with their problem description.
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.
Ha, I totally messed up a question for a front end interview today that could have easily been solved with timeouts. I didn't realize timeouts had resets as I haven't used them extensively and bam I'm trying to essentially design a reset for a generic counter. Boy I felt ridiculous. As soon as he said use timeout reset it's immediately obvious what I had to do. I'm not a bad programmer but between brain freeze and whiteboarding, and interviewing day after day for a few weeks, it just didn't occur. Killed me and I hope I don't miss out on an offer from a company I was actually really interested in because of some bullshit brainfart on something I'm not particularly well versed in.
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.
In my academic days I used to refer to say "physics-standing-up" is a different subject from "physics-sitting-down" and needs to be studied separately. Some years after I left academia I had the good fortune to get in contact with the person who introduced me to acting at a very young age and thank her for her contribution to my academic career. About 30% of my success was due to my comfort working in front of an audience--even a panel of examiners is "an audience"--and I had a huge advantage over my peers because of it.
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.
I'll disagree that these questions require weeks of preparation. I think it's more just unfair because they favor a certain type of person: those whose interests align more strongly with the theory and algorithms and less with building things.
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..
I don't necessarily agree though, I think if you can reason about a problem, you are infinitely more valuable than someone who memorizes problems and just applies them blindly.
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.
It depends how your interviewer is ranking/scoring you. One interviewer might be impressed with your ability to talk through and solve the problem from first principles, where another might ding you for not instantly knowing the answer. The former type of interviewer would be happy to give you hints and prompts, the second is a stone wall. I try to be the first -- it helps assess how a candidate responds to coaching too! -- but there's a spectrum between "nudging" and "telling them the answer straight out".
I've definitely seen interviewers (both by reading other people's feedback, and in one rare case, being an interviewee) who expected a "correct" answer and wouldn't work with the candidate to get there if they didn't already know it.
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...
I've seen the same thing, but I tried to account for it in the 10-15% of cases where I haven't had success.
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.
Is a binary search tree a problem that the Dev would have needed to solve? In over 5 years as a dev, I have never once needed to solve a binary search tree. Why not ask the candidate how to perform a kidney transplant.. That's solving a problem too. White boarding algorithms is not relevant to the majority of Dev jobs. It's related, but not particularly valuable as a screener.
I'm not sure how asking someone who's going to be working in computer programming something about computer science is equal to asking someone who's going to be working in computer programming something about medicine. Those two things aren't equivalent. Could you perhaps clarify?
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".
The act of creating a, say a self balancing binary search tree, is something you should know about. If you ever have to implement it, you go look it up. Engineers are exactly the same - you would rather have one that know where to look up all the stuff, or search for information, than one that can regurgitate the entirety of his education theory.
Typing "how to reverse a binary search tree" into google is not the same thing as solving a problem.
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.
I mean, that's a little strong. My undergrad degree is in math, so I would be thrilled if I was sitting in an interview and was being asked questions like that instead of stuff about how computers actually work.
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"?
Smart people will learn what they need to to do a job if they're interested in it.
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 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.
> Google is filled with people who can solve Data Structure / Algorithm questions in 50 minutes on a whiteboard.
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.
> The gigantic tech companies are always complaining they can't find 'good people'.
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.
The "supply problem of engineers" is the great lie of our industry of our time.
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.
I wonder about that. What percentage of their employees are recent college graduates? From all of these anecdotes, it seems like their process is optimized to select cheap recent CS grads.
I agree. I feel the overpowering urge, when asked this sort of basic interview question, to shout back "WHY?". What does inverting a binary tree have to do with software engineering, at all?
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.
At my job, our interview guidelines explicitly say that we don't expect non-graduates to be able to whip out fancy data structures. We want to see that the person can program, how he thinks about problems and system design, and how they deal with being stuck. I've seen people with impressive CVs and PhDs that were unable to solve very simple programming tasks.
Google interviewers are strictly told to ask these data structures and algorithms questions, it doesn't matter to them if they are relevant for future work. I have even read reviews by PhD candidates where even they were asked these questions in the interviews. When I interviewed with Google last year, I remember that the interviewers had a blueprint of the type of questions they were allowed to ask. They hardly concentrate on your resume during the interviews.
At what point during one's career should one simply be hired at face value and be exempt from interviewing? After 10 years? 20? 30?
"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!"
Background: I worked at Google for 5 years and did a bunch of interviewing for them.
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.
I've interviewed and worked with 30 year programmers and for some of them it was obvious could not program and their resumes were concocted. I would never rely on a resume.
"Self-assessed" as a resume speaking for the candidate.
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.
Aren't we trying to hire clever programmers? Isn't that the point?
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.
I guess everything I do is 'solving problems'. That's pretty open-ended. Maybe 'describe a situation where things didn't work the way they were supposed to/documented to work. How did you resolve it?' or something like that.
Another way of looking at it is that they do these kinds of interviews particularly because they do want to hire fresh grads (and ideally, the best 5% of those) over experienced programmers. And if that's the case, then it's not really flawed, it's doing what it's supposed to do.
Actually, Max himself said that it "Felt like they would have preferred a fresh comp sci grad."[1]
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.
I think this is probably overall true. I'm a bit cynical, maybe, but the set of tech used by developers here at Google does not necessarily intersect with what is used in the rest of the industry. So much is proprietary, and best practices are heavily codified and well understood. So in reality I suspect that new grads are as valuable or more valuable to Google as experienced engineers since it's unlikely the specific technologies an experienced engineer has under their belt will be specifically applicable here.
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.
It always surprises me when people like Pacino or De Niro talk about going for auditions - I'd imagine they had a large enough body of work that directors would know what they can do.
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...
That's true. However In Google defense, they tell you upfront what kind of interviews you're going to get and their process it's pretty well known anyway (with all its flaws).
I went through the same pain myself a few years ago and I'm not disagreeing that the chap should have just got the job there, but their process is well known and perhaps he just had the wrong expectations.
(I'm at Microsoft, FWIW, every engineering team here does hiring their own way)
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.
I hate to show my ignorance, but why the focus on binary trees? I've been programming for decades, but there are plenty of things I've never touched because I just didn't have a need in the particular job. Binary trees are one of those things.
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?
Coding Interviews Exposed covers most questions you'll be answered.
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.
I recently went through an MS phone interview and didn't do as well as I would have hoped. I did learn quite a bit though. Here's my advice:
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.
I'm currently interning at MS (India). I am a physics student with programming as a side hobby. (Not yet sure what to do as a career)
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. :)
Even if you have used them like a few months ago. Very few people work on variation of the same problem over and over again, except in research.
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.
> How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
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.
It's about gaming the system to get a job. When you are in a position to hire other people, you can worry about a less awful method to select candidates.
> It's about gaming the system to get a job. When you are in a position to hire other people, you can worry about a less awful method to select candidates.
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.
They all just seem to be varying levels of fanciness over relatively common data structures and algorithms. I was only applying for internships but the whiteboard stuff wasn't too bad when I did (and other questions I practiced online), I imagine almost completely because we'd done 2 related modules at university.
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.
I interviewed (unsuccessfully) at google. If you want to be prepped, yes, I would recommend going over the algorithm books, and make sure that you can do all the basics in your sleep.
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.
> 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
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.
Yes, that is true. Memorization doesn't necessarily mean rote memorization - for me at least, the algorithms are too complex to memorize by rote, I have to understand them to "memorize them". But yeah, if you are able to implement certain data structures and algorithms "in your sleep", then this does imply, as you said, a kind of memorization.
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.
> 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.
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.
Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how much do you want to work here." If you care enough, you can pass. That said, these types of interviews do favor fresh grads over experienced programmers (you have algorithms and data structures fresh in your mind), which means that they are flawed in IMHO.