I’m a senior engineer, interviewer and hiring committee member at Google. I agree 100% that a technical interview should not be “an exercise in how many data structures and algorithms one can remember from their college days”. That’s not our aim and I’ll explain why.

Rather than asking candidates to implement a specific, well-known algorithm like balancing a tree or writing Quicksort, we prefer to ask them to solve a novel problem. This involves using the skills they have to develop a fresh algorithm. Knowledge of particular software engineering techniques is only a part of the picture. It’s possible some problems would benefit from knowledge of binary trees and what it means to balance a tree. Knowing some sorting techniques might help on another. However if candidates can’t recall this knowledge, we’ll see how they use the skills that they do have to help crack the problem. (The best problems can be solved a number of different ways). We’ll see how candidates respond to reminders and prompts, and if they’re able to use those to make progress on a problem. Personally, if a candidate is completely blocked on a problem I offer them a fresh problem to see if they fare better.

I aim to see if the candidate can understand a problem, analyse it, investigate lines of inquiry, communicate their ideas, produce a thorough solution, and show a positive, inquiring attitude. These are many of the skills that will make a successful career at Google.

Incidentally the reason we put candidates through so many interviews is not to make them sweat, but to find a pattern and to allow the possibility of overlooking any one interview that goes wrong for the candidate. Interviewers don’t have the final word on hire decisions. All interview feedback is read by a committee of some the most experienced engineers and interviewers. When making our decisions about an application we’ll only consider feedback that tests the right skills.