Inverted Binary Tree and Homebrew

What could an inverted binary tree and the OSX package manager possibly have in common? Well, this prolific tweet by Max Howell, the creator of Homebrew, hints at a narrative I've been think about quite often lately, currently being in the interview process for my first full-time position myself: how relevant are coding interviews in determining the merits of a candidate? I'm of the boat that they are a relatively fair representation of how hard the candidate is willing to study their subject matter, but first lets go over a quick solution to the inverted binary tree problem. To invert a binary tree, you want to swap the left and right children of every node. A simple solution in C# is as follows:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

// Definition for a binary tree node. public class TreeNode { public int val; public TreeNode left; public TreeNode right; public TreeNode(int x) { val = x; } } public class Solution { public TreeNode InvertTree(TreeNode root) { RecursiveInvertTree(root); return root; } private void RecursiveInvertTree(TreeNode node) { if (node != null) { TreeNode tempLeft = node.left; node.left = node.right; node.right = tempLeft; RecursiveInvertTree(node.left); RecursiveInvertTree(node.right); } } }

That wasn't so hard! We separate the recursive part into it's own function, then just return the root of the tree, because if you invert the tree, the root won't change places. The recursive function does a check to make sure that the node isn't null, and if it succeeds, it swaps the children and recursively calls itself on the left and right children. Easy enough!

What makes this challenge even remotely hard during an interview is the interview itself. Writing code on a whiteboard is challenging! There aren't any practicing software engineers who regularly write actual source code on a whiteboard, yet we continue to do it during technical interviews all the time. I personally miss Visual Studio's Intelli-sense and tab-completion, as well as the speed I have using Vi. It takes me ages to write code on a board, and during the dead time of me writing, I occasionally lose my train of thought and have to re-adjust my bearings. It's a really tough game, and there are a lot of people that say it isn't even one worth playing.

Take Max Howell for example. He's written some genius software in his day (Homebrew is a godsend) and yet when he was asked to interview at Google, they didn't offer him a position because he didn't do well enough in his technical interview(s). It really confuses me that interviewers don't allow their candidates to code on a computer. I'm sure that if Howell was given a computer and a single Google search that he would have found the answer on StackOverflow and had it coded in about two minutes (I did not use Google or SO to come up with my solution by the way, but I'm also still in school and solving these problems regularly). Which begs the question, are interviews really extracting the information that interviewers need to make an informed decision about whether or not this person can have a positive impact on their company?

I am going to fence-sit for only a little while longer and say yes and no. It is important that software engineering know basic algorithms (honestly, inverted binary tree is one of the easiest questions you could be asked) as well as how to explain them to the interviewer. You shouldn't need a fancy debugger and SO to solve basic problems like this. There are much, much harder questions that I've been asked however, and I think that just 3 minutes reading about the problem on Google before starting would have allowed me to solve some problems I otherwise struggled on. For instance, I was asked to write a program to recursively search through a directory and all subdirectories to find files that had a phone number in them. I knew to use grep as well as regular expressions, but because I don't have all of grep's flags memorized and because I usually just Google "grep regex" anytime I want to use it, I was pretty much useless. Maybe all the interviewer wanted to see was that I knew what tools to use, but I wanted a better sense of closure for the problem.

I do, however, think that whiteboard coding gives the interviewer a sense of the candidate's technical communication skills. It's absolutely critical to talk through every line of code you put on the board to make sure that the interviewer is on the exact same page as you. Sure, it's important to get the question right, but it is also very important to make sure that the interviewer is following your train of thought. Because there is so much dead time spent writing, use it to explain what you're doing and why. If anything, that is what I've taken away from whiteboard interviews: you must be able to explain your rationale behind every line of code you write.

So what about Homebrew? Howell unfortunately didn't get an offer from Google even though he wrote one of the most excellent and important OSX applications ever. Sure, he's exaggerating that 90% of Google employees use it (I doubt that 90% of Google uses Mac, full stop, though I would guess that 99% of Google employees who use Mac use Homebrew), but should they discount a man who has already proven himself to be a very high quality engineer just because he couldn't answer a pedantic question that doesn't have much to do with anything on a whiteboard? I don't think I'm in a position to make that call. 

I do, however, think that if you're in the process of looking for a job, you should crack your data structures/algorithms textbook and get studying. Howell should've known ahead of time that he was going to be asked questions like this, and as I mentioned before, this question is a freebee. It's about how hard you're willing to study their game to ace the interview and get the job. Go on LeetCode and do 3-4 questions a day, gradually ramping up the difficulty, and when you get into the interview, you will be fine. And I understand that people are busy and don't have time for that between work, family life, school, etc. but you've really got to find the time to just do the work. It's just one of those things in life where you've got to put your head to the ground and study hard. Which is what I'm going to do right after writing this!

Is the interview process strange and alienating from what the job is actually like? Yes. Is it completely useless for determining the merit of an engineer, especially a new one? Definitely not! It's vital for showing that someone knows the basics of coding, and from whiteboard interviews, you can learn a lot about technical communication habits. Who is to say whether Google was right or wrong about not hiring Howell? It is their own prerogative. I just definitely do not want to be the guy who gets into an interview and can't solve a binary tree question, so on that note, I'm going to hit the books!