The dystopian world of software engineering interviews
I see peoples&#x27; opinions here generally falling into one of two camps. The standard way interviews are conducted are either good or bad. I think it&#x27;s important to consider both the good and bad elements, and then come to a conclusion about what to do in order to move the collective interview process in a better direction. To note, I&#x27;ve never gone through a traditional technical interview, so take what I&#x27;m saying with a grain of salt. Let&#x27;s look at the example in the given in the blog post, <i>write an algorithm to find the Kth highest value in a binary tree</i>. Now my data structures and algorithms are a bit rusty, so assuming that I remember the correct definition for node height, I believe the solution looks something like the following.<p><pre><code>  data Tree a = Tree a (Maybe (Tree a)) (Maybe (Tree a)) deriving Show

  -- Assuming k=1 Means the highest node, k=2 means second, etc...
  -- Note this solution successfully puns non-positive k&#x27;s
  -- to return Nothing
  kHighest :: Int -&gt; Tree a -&gt; Maybe a
  kHighest 1 (Tree a _ _) = Just a
  kHighest k (Tree _ (Just l) (Just r)) =
    case (lRes, rRes) of
      (Just x, _) -&gt; Just x
      (_, Just x) -&gt; Just x
      (_, _) -&gt; Nothing
    where
      lRes = kHighest (k - 1) l
      rRes = kHighest (k - 1) r
  kHighest k (Tree _ (Just l) _) = kHighest (k - 1) l
  kHighest k (Tree _ _ (Just r)) = kHighest (k - 1) r
  kHighest _ (Tree _ _ _) = Nothing
</code></pre>
Barring some fundamental misunderstanding of the problem (entirely possible), the evaluation criteria is not that the solution is exactly correct and covers all edge cases. The evaluation criteria is does the solution show fundamental knowledge about properties that are used to classify things as tree-like, and does it use the common idiom (decomposition into smaller sub-problems) that is used to process tree-like data.<p>In my opinion, the common criticism that interview questions hold no similarity to day-to-day software engineering problems, holds no water. Yes, you will not directly re-write the tree data type every day in your job. However, you deal with recursive data definitions that require solution by decomposition _multiple_ times a day. If you are not dealing with problems that fall under that category, then you should think hard about which problems you see that could be framed as such because I guarantee you&#x27;re missing a few.<p>The beauty of the tree as a data structure is that it captures a common set of algebraic properties. Even when other data structures don&#x27;t exactly fall under said algebra, the concepts to reason about them are reused (note the early language that specifically said &quot;tree-like&quot;).<p>The point of drawing interview questions from your data structures and algorithms course is not to test you on remembering arcane minutia from 5+ years ago but to see your fundamental reasoning skills within the domain of computer science.