I think people were making fun of Google, because it is a caricature of their whole interview process.
If a large number of your engineers is using Homebrew, having its developer is an asset for many different reasons (e.g. influencing the focus of the project, getting formulae in that interest you, or simply improving a tool that is important to your productivity). But no, they reject him because he cannot invert a binary tree.
It's like throwing one of the better offenders out of your soccer team, because he cannot substitute as a goalkeeper.
I don't see how this is relevant - in this case, a coder was rejected for a coding position. If we substitute your case, you could re-state it as "A player was rejected for defender" (or attacker/etc). In your example, you've changed that to "A manager was rejected for defender". Not the same.
Having the developer of Homebrew as an employee is only an advantage if you want to influence it's development, and if the developer is happy for his application to be influenced by his employer rather than the Homebrew community as a whole.
In fact, I would see Google hiring the leaders of open source projects in order to influence the direction the project takes as a problem. Sponsoring an open source project is brilliant, and Google are great at that, but buying influence over it is completely different and (potentially) an issue that would lead to people forking the project.
If interviews are really made to maintain high-engineering standards and prevent bad hires, interviewing and rejecting the author of a software that 90% of your employees use everyday is quite perplexing indeed.
While I understand that interviews are sometimes necessary to evaluate a candidate, it seems completely out of touch for Google to pass on an applicant with such an impressive background.
Not only that, but heaven knows that it takes a lot of dedication and leadership to lead an open source project from ideation to wide-spread use. If I were a startup founder, I would kill to get someone like him on my team.
>I think people were making fun of Google, because it is a caricature of their whole interview process.
To be honest, it kind of makes me wonder about the kind of code Google has, if this is a measure of a good coder. Are low level algorithms haphazardly re-implemented in python everywhere there is a need for one?
I've seen lots of code like that before. I was very unimpressed.
def invertTree(self, root):
queue = []
if root is not None:
queue.append(root)
while queue:
current = queue.pop()
current.left, current.right = current.right, current.left
if current.left is not None:
queue.append(current.left)
if current.right is not None:
queue.append(current.right)
return root
def invertTree(self, root):
queue = []
if root is not None:
queue.append(root)
while current is not None or len(queue) > 0:
while current is None:
current = queue.pop()
current.left, current.right = current.right, current.left
if current.left is not None:
if current.right is not None:
queue.append(current.right)
current = current.left
else:
current = current.right
return root
No needless enqueuing / dequeuing of things unless you need to. As a bonus, if the nodes maintain a count of how many children the have overall you can always recurse on the smaller child first and use less memory.
That's certainly possible - this would get you 'a' containing an array from the first function and 'b' with the result of the last.
Can't off the top of my head recall actually seeing such a bug. I totally appreciate the desire to reduce the potential for errors from typos, but that ship has kind of already sailed with either language. I guess it just depends how far you're willing to let it go.
Well it's a 140 character description from someone who's probably feeling a bit emotional. I'm sure he got a clearer problem description in the actual interview.
I have to admit, the idea of swapping children on all of the nodes would not have come to me immediately as a solution for reversing the sorted tree - I have not been exposed to that kind of application before, and haven't spent a lot of time thinking about that kind of problem.
Its prevalence suggests that it's a pretty big issue that many interviewees face, and nobody has the answer on which is the best approach for hiring competent developers at scale.
What's hard is to have necessary CS background to understand what "inverting a tree" as a term means. As a non-CS major, I don't know what they use it for as a "term" and it evokes several things I can do with a tree as an outsider. So interviewers can quickly eliminate me as a non-CS. How to invert a tree on a whiteboard? Use a mirror.
I've enjoyed many of the responses on this topic, some people like to use it as a self congratulatory platform to express their position that the solution is trivial and "any engineer should be able to do it like me" with a piece of example code, while others use it as a soapbox to moan about the scourge of the tech interview process.
I've noticed that dichotomy as well. It seems to be splitting along culture lines - so one of these two camps would be right at home at Google, the other would be fairly miserable.
Of course, this creates its own issues related to creating and maintaining a mono-culture, but that's a topic for another thread.
At first I thought that he was given a slightly harder problem: given a binary tree and a particular leaf node of that tree, return another tree that's graph-isomorphic to the original, but has that node as the root. (You can visualize that as picking up the tree by a leaf node and shaking it, then reinterpreting the result as another tree.)
55 comments
[ 3.8 ms ] story [ 130 ms ] threadI think people were making fun of Google, because it is a caricature of their whole interview process.
If a large number of your engineers is using Homebrew, having its developer is an asset for many different reasons (e.g. influencing the focus of the project, getting formulae in that interest you, or simply improving a tool that is important to your productivity). But no, they reject him because he cannot invert a binary tree.
It's like throwing one of the better offenders out of your soccer team, because he cannot substitute as a goalkeeper.
In fact, I would see Google hiring the leaders of open source projects in order to influence the direction the project takes as a problem. Sponsoring an open source project is brilliant, and Google are great at that, but buying influence over it is completely different and (potentially) an issue that would lead to people forking the project.
While I understand that interviews are sometimes necessary to evaluate a candidate, it seems completely out of touch for Google to pass on an applicant with such an impressive background.
Not only that, but heaven knows that it takes a lot of dedication and leadership to lead an open source project from ideation to wide-spread use. If I were a startup founder, I would kill to get someone like him on my team.
To be honest, it kind of makes me wonder about the kind of code Google has, if this is a measure of a good coder. Are low level algorithms haphazardly re-implemented in python everywhere there is a need for one?
I've seen lots of code like that before. I was very unimpressed.
But I guess it's file while ignoring the order of the items, and just caring if it's containing items or empty.
Carry on :)
var invertTree = function(root) {
};Especially as Ruby has automatic unpacking of function returns, yes?
So something along the lines of:
could cause bugs.Can't off the top of my head recall actually seeing such a bug. I totally appreciate the desire to reduce the potential for errors from typos, but that ship has kind of already sailed with either language. I guess it just depends how far you're willing to let it go.
Yay choice. Testing will catch it anyway, right?
:/
> @rogerdai16 to min-max the tree, ascending to descending.
https://twitter.com/mxcl/status/608891015945170944
One more for the toolbox, I guess.
TreeNode* invertTree(TreeNode* root) { if (root) { TreeNode* temp = root->left; root->left = invertTree(root->right); root->right = invertTree(temp); } return root; }
But it's an interesting concept, I've had to use a similar one in the past for a job interview.
Of course, this creates its own issues related to creating and maintaining a mono-culture, but that's a topic for another thread.